191–200 of 214 posts
Earlier quoted context omitted.
Serialisation often needs additional information not present in the struct definition: for enabling backwards-compatibility and default values. Same for command line parameters. We want documentation strings, maybe dashes in the name etc. But that can surely be solved with a little more advanced struct
I have one word for you: attributes (which the compiler, and the reflector, know about).
Earlier quoted context omitted.
> the people that really care found workarounds Or stopped writing C++, I'd consider myself one of these for many use cases I used to use it for.
> Or stopped writing C++, I'd consider myself one of these for many use cases I used to use it for. Some use cases like GUI programming sound like they are better addressed by specialized tech stacks. Nevertheless, either you're talking about greenfield projects or you are hard pressed to find a justification to rewrite a project in another framework. Claiming you stopped writing C++ doesn't fit the bulk of the exper…
Earlier quoted context omitted.
Also that the features c++ is getting are bolt on additions that we already have solutions for. I think fmt is a great example - fmt is a header only library that can be dropped in. Meanwhile std format was standardised without printing to stout. That took 3 years to standardise. Meanwhile we’re working on things like ranges, and instead of implementing them in the language it’s shoe horned in as a library feature -…
You can't have faster compile times. If you want fast compile times C++ needs to sacrifice something else (ABI compatibility, compatibility to compile code from 1979 for some dead big endian 12-bit word chip, etc. In fact the truth is the people working on C++ don't actually value fast compile times over other matters (fast runtime, ABI compatibility, etc.) They say they do. But they don't in their actions. One egreg…
Earlier quoted context omitted.
> There are still too many half-baked ideas that turn out to be mistakes afterwards (...) Care to point an example?
Some examples on top of my mind: - export templates is the canonical one. - Universal references are a great feature in principle, but the way they are integrated in the language is far from ideal. - Both features are great in isolation, but the interaction between initializer lists and aggregate initialization is a giant footgun. - Coroutines are overly complex and still incomplete but I still have hope. - Modules f…
Which is what I have been using on my C++ hobby projects for the last two years, on work projects we are still on C++17 land anyway.
Earlier quoted context omitted.
There is no alternative to modernizing C and C++ Indeed I wish they were even more aggressive about breaking changes Rust is nifty but there is simply too much existing C/C++ out there and "rewrite it in Rust" is not a serious suggestion Maybe one day we have some cool AI that magically rewrites old C/C++ automatically, but by then I also assume we will have AI-designed languages Until then, we need C/C++ to be maint…
Thoughts on Zig? Just not popular enough to fit the bill or are there technical reasons? I bring it up partially because they are not taking a "rewrite it in Zig" approach, they are specifically aiming for incremental migration in mixed C / Zig codebases.
Earlier quoted context omitted.
Just because it's newer doesn't make it better. There are good reasons for avoiding iostream
That's my point - iostream is a really bad piece of code, and if you're anyway going to use modern C++, it's really recommended to stop using it.
Earlier quoted context omitted.
Maybe this doesn't count as static, but I used to regularly use reflection in C# to generate code for interacting with foreign DLLs. This was a video game mod, essentially. I needed to create a text interface to modify settings for any other mod that might be installed. Other mods would simply implement a settings class with certain attributes, then I could list out all fields and their types. The list was processed…
C# also has the compiler available at run time, which is an extremely powerful feature, so the line between static and dynamic reflection is blurred.
I'm surprised at the positive response in this thread. I find the syntax of this beyond atrocious! My goodness C++ really does not know how to do anything simply does it?
Earlier quoted context omitted.
That's my point - iostream is a really bad piece of code, and if you're anyway going to use modern C++, it's really recommended to stop using it.
iostream is good enough for most jobs, unless one is writing high performace IO code battling for each ms.
Earlier quoted context omitted.
iostream is good enough for most jobs, unless one is writing high performace IO code battling for each ms.
Or unless one wants to write formatted output, or unless one wants to handle IO errors with RAII...
Happily using iostreams since Turbo C++ 1.0 for MS-DOS in 1993, and will keep doing so, unless chasing ms optimizations.