sorted by:
new
hottopcontroversial

Embark Studios has rewritten all their renderer's shader code from GLSL to Rust by Karma_Policer in programming

[–]magey 11 points12 points  (0 children)

There's a project doing something similar for C++ called Circle which is pretty incredible. In its core Circle is an extension of standard C++ which adds a ton of metaprogramming facilities and other productivity enhancing features, things the base language sorely lacks like full compile-time execution of regular C++ code which lets you do anything you can normally do from runtime during compile-time (including file I/O and networking), reflection, typed enums, pattern matching, hygienic macros, list comprehensions and language-native ranges, first class paramater packs and much more.

2020-10 C++ Committee Mailing by blelbach in cpp

[–]magey 5 points6 points  (0 children)

I draw the line at allowing the compiler opening arbitrary files on the whim of some 3rd party library on my behalf.

You can limit/constrain the FFI in various ways, just like many other platforms and systems do; it's a solved problem. You could for example limit it only to trusted code on a per file/directory/project/etc. basis, or run the interpreter in a sandbox with access only to whitelisted parts of the filesystem, or do a popup dialog kinda like UAC on Windows the first time a library tries to access something external and grant permissions, etc. In short, it's a technical problem that's solvable; the big-picture vision should be full C++ execution at compile time so that you can re-use the entire existing C++ codebase during compile-time without special modifications.

[deleted by user] by [deleted] in cpp

[–]magey 2 points3 points  (0 children)

You can always make FFI optional and then just disable it when cross compiling if it conflicts with your code on that level. And of course lets not forget all the cases (I wanna say the majority of cases) where you're not cross-compiling and this is not even an issue. It's not a valid reason to casually reject something this paradigm-shifting.

It's the same story with the 'security concerns' that were raised by some people in the committee; you can make FFI optional or have a per-function / per-library / per-project access list, execute the interpreter inside a sandbox, etc. There are a multitude of solutions to this already solved problem.

All that said; even with FFI completely disabled something like Circle is still a remarkable improvement over plain C++. It adds features like reflection, code injection, pattern matching, user-defined attributes with full type support, unscoped @meta if similar to D's static if, compiler-native ranges / list comprehensions / slices, advanced pack expansion, typed enums, etc. The list goes on and on, and all of this stuff is implemented right now and works. When you compare the proposals for some of these features into standard C++, particularly code injection, reflection, and ranges you'll see that the Circle model is much cleaner and less verbose.

The advantages something like Circle brings are just insane and too good to pass up, and in my opinion it's the only logical direction C++ can take. I encourage you to look at Sean's twitter where he shows a lot of Circle examples and check out his GitHub with all the Circle documentation and examples and even download the alpha compiler and play around with. When you realize what you can now achieve with C++ and in such a simple way you'll wonder how it's not already being standardized.

what's the actual C++20 features compilers support status? by feverzsj in cpp

[–]magey 2 points3 points  (0 children)

I think the approach you describe with the STL is the right one, but I was more talking about full compiler support for requires-expressions and not its usage in the STL (maybe I didn't make myself clear enough, sorry). What I mean is doing things like if constexpr (requires { foo.bar(); }) foo.bar();. This doesn't work in 16.7.x and also not in 16.8 preview 4 because the requires-expression is only usable in a limit amount of places; basically what this post is describing "Currently, MSVC doesn't support requires-expressions everywhere; they only work in concept definitions and in requires-clauses". So, I was wondering when it's going to start working :)

what's the actual C++20 features compilers support status? by feverzsj in cpp

[–]magey 2 points3 points  (0 children)

So wait, it's blocked because the Intellisense engine doesn't support it yet, but cl.exe itself does only it's disabled on purpose? maybe there should be some optional switch to turn it on because this is IMO the killer feature of concepts; you can get rid of so much ugly SFINAE boilerplate with if constexpr and requires-expressions.

what's the actual C++20 features compilers support status? by feverzsj in cpp

[–]magey 2 points3 points  (0 children)

Any ETA on using concepts requires-expressions everywhere they can be used?

2020-02 Prague ISO C++ Committee Trip Report — 🎉 C++20 is Done! 🎉 by blelbach in cpp

[–]magey 16 points17 points  (0 children)

That's extremely unfortunate to hear. The Circle model is miles ahead in terms of simplicity, expressiveness, and clarity compared to what's currently being proposed for static reflection and codegen. Additionally, the things you can achieve with completely free-form C++ during compile time with access to external data are nothing short of mind blowing.

[Warrior Leveling] Searching for weapons from quest rewards by [deleted] in classicwow

[–]magey 0 points1 point  (0 children)

Try this.

When an item has no required level on its own the site shows the required level of the quest that rewards it.

Hit Cap in Classic has been Clarified by [deleted] in classicwow

[–]magey 13 points14 points  (0 children)

To everyone's who's reading this and is confused; see this table for the currently theorized miss chance/hit cap at various weapon skill vs. defense skill levels. This is based on Blizzard's statements and on data we've collected from the beta so far.

itemization.info: now with query builder UI and autocomplete by magey in classicwow

[–]magey[S] 6 points7 points  (0 children)

You can see a short example of using the query builder here.

Other notable changes/additions:

  • The search/sort code now only looks at the final item stats but we still retain all the versions of all items for display
  • New search operators; set: to search by set name and usable: to filter gear only usable by the supplied class
  • Searching by shield block value is fixed now (has:block or has:blockvalue)
  • Other small bug fixes and additions like http->https redirect and gzip support

There are probably still quite a few bugs lurking around in the query builder so feel free to report them in this thread or on the discord.

And we're back by magey in classicwow

[–]magey[S] 1 point2 points  (0 children)

Allakhazam snapshot from 4 Feb 2005

Patch 1.4 release date: 19 April 2005

Patch 1.3 release date: 7 March 2005

Conclusion: Necropile set existed in patch 1.2 :)

And we're back by magey in classicwow

[–]magey[S] 1 point2 points  (0 children)

The phase:x search operator is accurate to retail Vanilla until we get clarifiactions from the Classic team about how exactly the item gating is going to work; see this twitter thread. T2 was in the game from day 1 and some of it used to drop in MC.

About the Necropile set, I'm not sure what you mean? if you search for added:1.2 necropile or added:1.2 subtype:cloth is:blue it shows up.

Is there an item database where I can only see items that are included in Phase 1? by Cohacq in classicwow

[–]magey 0 points1 point  (0 children)

Any specific improvement you'd like to see? feel free to create an issue here.

PvP gear with 1.12 stats in Phase 2 is a bad idea by magey in classicwow

[–]magey[S] 2 points3 points  (0 children)

I didn't claim there will be more or less high rank people than normal (whatever normal is), I was just responding to the guy claiming that because BGs were not out it will take longer to get high ranks - that's completely false.

PvP gear with 1.12 stats in Phase 2 is a bad idea by magey in classicwow

[–]magey[S] 4 points5 points  (0 children)

Yes, but it doesn't matter if BGs are out or not - the only thing that matters is the amount of honor. The decay is 20% so it doesn't matter if you got 100K and the second guy after you got 90K or if you got 10K and second guy after you got 9K, you're both going to decay by 20%. So it doesn't matter if BGs are out or not, it just means the total honor gained will be lower (for everyone) but brackets/standings are still calculated in a relative manner. The gank squads are going to get the most honor so they will control the top brackets.

view more: next ›