61–70 of 444 posts
When a new C++ feature is proposed does the proposer have to provide a reference implementation? How can features be missing from the major compilers?
It is so ironic, that now that Apple and Google decided to focus on their own language stacks, the C and C++ compiler vendors that profit from clang's license aren't that keen in making the upstream work for catching up with ISO C++. Thus making the once famous clang having an honorable third place in ISO C++ compliancy. Seeing this from a Google team makes it even more ironic.
gcc is better than clang on every metric. Sorry, it's the facts. ¯\_(ツ)_/¯
After a lifetime of using GCC, I (like many others) moved to clang a few years ago, out of frustration with the slow development of GCC, a desire to use new C++ features, and stayed because of the superior error messages and, in my use cases anyway, superior code generation.
In addition, I gather it's a much cleaner and easier to maintain code base. As a result, we get to have cool things like emscripten, llvmpipe, all sorts of static analysis tools that would be more challenging to build in the GCC universe, and much more.
Honestly, I thought GCC was slowing down development wise.
Is GCC worth trying again? Can you name a few "cool new things" I can do with GCC that I can't with clang? There's plenty of the opposite...
Earlier quoted context omitted.
I've always preferred clang for its better lints, and friendlier error messages (sans some decrepit parts around templates that are equally horrendous everywhere)... And theoretically clang has better ASM output in some cases I say theoretically, because it's been shown that GCC's "worse" ASM performs better; I'm not really an architecture aficionad, so I can't comment as to why that is. Also, it's been a few years n…
I wonder how up to date is the old belief of better error messages. The was some great redhat blogs about structured error messages in newer GCC.
Many are of the listed items are merely being deprecated. These shouldn’t really qualify as breaking changes. In fact, the ability to migrate away incrementally is precisely the point of deprecating instead of removing a feature. What surprises me is that a lot of the deprecated functionality seems really recent — C++14 or newer. Compatibility is C++’s big thing, that’s historically why it kept almost all of C as a s…
If every time they're going to add things, remove things and break things then we're in practice talking different strands.
Imagine some preprocessor where you can mix them like
#flavor(ginger)
Instead of say c++11 and then proceed with whatever flavor as necessary.
I know you can do that at the linker and with makefiles and compile flags, this is about a more sane presentation.
Earlier quoted context omitted.
Which of these things is Rust immune to? How stable is it over a 10, 15, 20 year life? How old can the code be that Rust compiler still compiles and links successfully and bug-free?
Rust does well on this front. There's a new release every 6 weeks, and majority of users jump on it straight away (to complete shock of everyone not used to it). Rust has editions which keep old code working without any changes, even if you mix it with new code, even if you do it with macros. It has rustfix that automatically migrates majority of the old code. Rust has a standard project layout, standard test runner,…
Rust needs to exist for at least 20 years before you can say it "does well" on 20yo projects.
> majority of users jump on it straight away
This is a sign of a language with a tiny mostly-hobbyist user-base.
Earlier quoted context omitted.
I wonder how up to date is the old belief of better error messages. The was some great redhat blogs about structured error messages in newer GCC.
Ok, that's kinda true I suppose; I remember that GCC's error messages have indeed gotten better after a major version release. Also, when you say structured, do you mean errors over LSP, or do you mean more structure in the formatting when reporting in CLI?
Is there a case for or against incrementally adopting Rust ?
Is one release really causing so many problems? I thought C++ treated backwards compatibility as a holy thing.