151–160 of 189 posts
Earlier quoted context omitted.
C is not slow compared to C++. C++ compilation time are slow though.
This is a myth, C++ is not inherently slow to compile. It's the standard library that is very bloated and the main culprit for slow compilation.
A quick compiling C++ project is most likely extremely conservative in its use of C++ (vs C) features.
Earlier quoted context omitted.
Typical C++ dev schizophrenia. In one thread complain about Node and its death-by-a-thousand-packages, then suggest the same in another.
Package? We're suggesting to copy paste 5 lines and stick them into a header.
Its misleading to call it "cost". In the C++ world only runtime cost matters. If using reflection allows to generate faster result code, it doesn't matter how long it takes to compile.
I'm now trying to migrate from msbuild to cmake+sscache+PCH for std libraries while also trimming unnecessary includes to reduce suffering in the future - if not for me then at least for future developers. So I would say compile time is important for development. It causes other limitations too (like bugfixing becomes a huge commit with several squished fixes together to avoid recompiles, messing up git history or slower context switching when developing several features in parallel)
Earlier quoted context omitted.
Yes, I've heard that before, but comments like this one in your linked issue still make me wonder: > at least for gcc and Visual Studio using #pragma once has a significant impact. The fact is, the compiler does not need to continue parsing the whole file when reaching a #pragma once. otherwise the compiler always needs to do it even if the include guard afterwards will avoid double processing of the content afterwar…
The compiler doesn't need to open the same file multiple times. It can remember if a a file is guarded or not every time it sees its name. My understanding is that this is an optimization that has been available for a very long time now. The only issue is if a file is referred through multiple names (because of hard links, symlinks, mounts). That might cause the file to be opened again, and can actually break pragma…
Earlier quoted context omitted.
As a developer who doesn't really write C++ code I'm inclined to agree, but I think Herb Sutter's "syntax 2" project might provide a nice way out of that mess eventually. I played around with cppfront over Christmas and it was a lot more ergonomic than my distant memories of C++11, which I don't even have negative memories of per se. [0] https://github.com/hsutter/cppfront
That isn't going anywhere official. It is no different from any other language that compiles via C or C++ code generation, it got sold a bit differently due to his former position at WG21.
But I do think it is different than other "compile to C++" languages, because it seems to be more of a personal case study for Sutter to figure out various reflection and metaprogramming features, and then "backport" those worked out ideas to regular C++ via proposals. And the latter don't have to match the CPP2 syntax at all.
In multiple examples he's given in talks the resulting "regular" C++ code is easier to read, mainly because the metaprogramming deals with so much boilerplate.
Earlier quoted context omitted.
The compiler doesn't need to open the same file multiple times. It can remember if a a file is guarded or not every time it sees its name. My understanding is that this is an optimization that has been available for a very long time now. The only issue is if a file is referred through multiple names (because of hard links, symlinks, mounts). That might cause the file to be opened again, and can actually break pragma…
gcc actually documents this behaviour: https://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.htm...
Earlier quoted context omitted.
In practice it is written like like this: #define MY_ENUM(x) x(MY_A) x(MY_B) x(MY_C) enum my_enum { MY_ENUM(ENUM_ENTRIES) }; static const char *my_enum_names[] = { MY_ENUM(ENUM_NAMES) }; but one could also make it even more compact if one cared.
That doesn't look any better. Yes, xmacros have the best compile times, but you can't possibly argue that they are elegant to use compared to the alternatives.
Earlier quoted context omitted.
This is a myth, C++ is not inherently slow to compile. It's the standard library that is very bloated and the main culprit for slow compilation.
Many C++ features are very slow to compile, especially templates. A quick compiling C++ project is most likely extremely conservative in its use of C++ (vs C) features.
My entire VRSFML codebase compiles from scratch in ~4s and I liberally use C++ features, I just avoid the Standard Library most of the time.
Templates are not inherently slow, people just don't know how to use them and don't know how to control instantiation.
Most people still think that templates have to go in header files, which is also just plainly false.