141–150 of 189 posts
Earlier quoted context omitted.
A library that you install via vcpkg or conan. How many libraries do you read the source code after installing them with the package manager?
Typical C++ dev schizophrenia. In one thread complain about Node and its death-by-a-thousand-packages, then suggest the same in another.
Earlier quoted context omitted.
It is "cryptic" and "ugly" to you just because you're not familiar with it. You'd pick the macro-based implementation because you are familiar with it. Seeing this argumentation is so tiresome, because it feels like there is a lack of self-awareness regarding what is "familiar" and what isn't, which is subconsciously translated to "ugly" and "bad".
No, it is objectively cryptic and ugly. I honestly don’t understand how can anyone keep up with this garbage, but the ship has sailed long time ago. It is just a soup of symbols at this point.
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 sure you wouldn't say "it doesn't matter how long it takes to compile" it if took days. So where do you draw the line? Regardless, it matters.
Earlier quoted context omitted.
This works for extreme needs. But you're probably not doing s ton of metaprogramming all the time like you should be, and would with a language that allows it. The lack of metaprogramming is also why C is so slow compared to C++
C is not slow compared to C++. C++ compilation time are slow though.
Earlier quoted context omitted.
The implementation doesn't look too bad, but the usage is terrible: #define E_LIST(X) \ X(V0) X(V1) X(V2) X(V3) DEFINE_ENUM(E, E_LIST) That's not how I want to declare my enums...
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.
Yes, xmacros have the best compile times, but you can't possibly argue that they are elegant to use compared to the alternatives.
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.
Utter BS. Compilation times matter for productivity, developer motivation, iteration speed, CI turnaround time, and so on. I'm sure you wouldn't say "it doesn't matter how long it takes to compile" it if took days . So where do you draw the line? Regardless, it matters.
Earlier quoted context omitted.
> But if given the choice, I'd choose the C-macro implementation (which is 30+ years old) over this, every time. Why? The implementation is not pretty, but you only need to write it once and then it works for all enums. The actual usage is trivial, it's just a function call. The C macro version is horrendous in comparison. Why would I want to declare my enums like that just because I might want to print them?
Then why isn't part of the stdlib? Why should everybody maintain their own version?
Curious to see if Epic Games ever refactors their reflection in Unreal Engine to use C++ 26 reflections or not.
That'll never happen. The engine's entire serialization system is built around their custom reflection layer and UHT. Not to mention how this would affect licensees. PLUS, they just laid off a bunch of people, and the leftovers are focused on Tim's Verse fiasco. I hate to use jargon here, but there's no "business value" to switching. EDIT: and based on these compilation time results, this would be a major setback for…
Earlier quoted context omitted.
So every time you compile, you run your test suite? I don't. And you trust that I have experience writing and compiling programs too...? It should be a goal to keep rebuild times around 1 second (often not quite possible, but 3-5 seconds, even for full rebuilds, is often realistic). I edit, compile, run, edit, compile, run. Editing and running can often take as little as 1-3 seconds, and I sometimes do it dozens of t…
You run your code before running tests? IMO that's bad practice. 1 second, seriously? Even the Linux kernel is based on C, and it doesn't even have compilation times approaching that. I guess I also work on a lot of big data projects, where getting results will take... 48 hours or so, so anything shorter than that is basically some sort of unit test or dry run... so in that context, compilation times do not even regi…
Yes, seriously, have you ever written a project from scratch? A simple .c file with a thousand lines in it should easily build and start within 100ms. A compiler should be able to do basic parsing and codegen at 1M lines per core.
If your runs take 48h, of course you need a strategy to avoid noticing bugs only after dozens of hours running. You can't tell me that it is efficient to make changes and to wait for minutes or even hours before noticing that your code wasn't even syntactically valid, or maybe it did compile but your code had a small oversight and you need to start over building.
The Linux kernel is a HUGE project, one of the biggest around. Yes, a full rebuild takes a long time, depending on configuration. Incremental rebuilds do not, though.
I'm actually working on a Linux kernel module (distributed filesystem client), it's on the order of 40 KLOC. I can do a full rebuild in 10/15 seconds (debug/release), and that includes calling into the kernel's infrastructure and doing a lot of stuff that shouldn't have to be done. An incremental rebuild after changing a single .c file is about 3 seconds. Restarting the module (swapping for the newly built one) takes less than 10 seconds also. And this can be already a stressful bottleneck depending on the task. Say you're improving logging in a particular section of code, this can easily require 5-10 attempts.
I'm working on Desktop GUIs (2D/3D) too. You need a quick turnaround time as much as possible. Many changes are trivial but you want to do many small incremental improvements, recompile, run and test (manually), often with a breakpoint on the code you're currently working on.
The projects I'm working on are written in C or conservative C++, and most have from thousands to hundreds of thousands lines of code. They can be built from scratch in a short amount of time (You can also design a C/C++ codebase to always do a full rebuild, compiling everything as a single unit. That can be faster than trying to do incremental builds, for codebases of considerable size. Try out the popular raddebugger project, a complete build after checkout is about 3 seconds. It's ~300 KLOC I think.
Earlier quoted context omitted.
In practice, C means you end up with generic data structures with pointers to what they contain, rather than being inline. You do see a lot of macro use to deal with this, but that is just primitive, non-typesafe metaprogramming, and it gets unwieldy enough that in practice, you see people add an extra pointer. This is why it gets slower.
In practice, I see people write very performance C code where it matters, while moving on quickly where it does not. C++ code is often highly templated with annoying compile times, but still often slow because it still does not use the right data structures, and the amount of instruction bloat by specializing everything does not help for anything which is not a toy benchmark.