161–170 of 214 posts
Earlier quoted context omitted.
You can sort of do it so long as the return type is a template parameter. template T my_construct() { T result; return result; }
That's not polymorphism as that template parameter won't be deduced in any context and you will always have to explicitly instantiate the template.
edit: you get pseudo call-by-name as a bonus.
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 -…
>instead of implementing them in the language it’s shoe horned in as a library feature Quite the opposite. Proliferating the language itself with ad-hoc constructs would be shoe-horning.
Earlier quoted context omitted.
What are you talking about? At runtime, an enum value is just an integer. You need to look up the enum case that corresponds to your integer in order to convert it to a string. Which is precisely what the code above is doing.
Sure, but reflection requires some support from the compiler either way. There's no reason why if you have an expression like x.str, where the compiler can see that x is an enum, that it can't rewrite it into a table lookup like __Enum_strings[x]. This would work even if x is an unknown run-time value. This is basically what any other language that supports converting enums to strings natively does. I understand that…
>Reflection needs support from the compiler. Just add new syntax and put it on the compiler, ffs!
Converting enums to strings is one use case for reflection. Do you suggest introducing bespoke syntax for the other use cases too?
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.
> 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…
My experience maintaining old codebases is that you are just as hard-pressed to find a justification to write code to use new language features, or even to take the time to upgrade the language and compiler version. Most often you just continue writing code in the same style as the rest of the code base using an old version of the language and runtime.
That's perfectly fine. You should only pay for what you use.
Your average project, however, consumes dependencies and needs to keep them updated. Just because the code you write doesn't use them that doesn't mean your dependencies don't. So everyone still benefits with each release of C++ even if the are not using fancy features.
Earlier quoted context omitted.
> There are still too many half-baked ideas that turn out to be mistakes afterwards (...) Care to point an example?
marshall cline's c++ mini-faq is a list of about 100 pages of them from the 01990s
Published in 1994.
Literally 30 years ago, years before there was even anything resembling a C++ standard.
I'm not sure why you thought it's relevant.
Earlier quoted context omitted.
C++ has gotten a ton of quality of life features with each update. The issue is less that new features aren't coming and more that new features bake through countless iterations of proposals for close to or often over a decade until everyone in WG21 is happy. So it's not that we aren't getting features. They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and kee…
> They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and keep up with. I never got this. Can't you just decide to use subset of the language? No-one forces people to use every single feature. It's okay to use C++ like "C with classes" and occasionally cool new thing, when it is right tool for the job. Only people where this argument is truly valid are compiler/…
However that opinion is kind of a minority. There are a lot of people in the community who don't want to have to learn new features just because a dependency happens to use/expose them. I don't personally see the issue with it.
I'd rather learn std features any day over non-std features. It's just a better use of my time because they work everywhere and someday I might need them. However again not everyone shares this opinion.
Earlier quoted context omitted.
> They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and keep up with. I never got this. Can't you just decide to use subset of the language? No-one forces people to use every single feature. It's okay to use C++ like "C with classes" and occasionally cool new thing, when it is right tool for the job. Only people where this argument is truly valid are compiler/…
> Can't you just decide to use subset of the language? That is harder than it sounds. First you have to select which subset to use, it is almost impossible to get any two engineers to agree on that - if you do get agreement that is a bad sign - generally it means the people in the room don't know C++ well enough to make the decision and so you choose the wrong one. The best you can hope for is a compromise where nobo…
Plenty of the modern C++ people already do this by enforcing things like "no raw loops", "no raw pointers", or "no raw synchronization primitives" during code review.
The issue is that it's a lot harder to justify avoiding new features than it is to justify avoiding old features unless you have a tooling specific reason (ex lack of support) to do so.
Earlier quoted context omitted.
i accidentally used the new implicit constructors for aggregates in c++ the other day, and then my code didn't compile with the version of clang i have installed on my cellphone
LOL. What used to be a typo is now becoming valid syntax (and of course the compiler can't warn you because it's now valid). Ouch. At least an old compiler saved you...
Earlier quoted context omitted.
C++ has gotten a ton of quality of life features with each update. The issue is less that new features aren't coming and more that new features bake through countless iterations of proposals for close to or often over a decade until everyone in WG21 is happy. So it's not that we aren't getting features. They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and kee…
I think the bureaucratic cadence of the things also make C++ not a unified entity. C++ is patchwork language. So many of the new features don't work well together or don't fit together or they have conflicting goals. Since the proposals target problems with differing philosophies, they each have different traps in them from bad time complexity to outright unrefined behavior. Keeping up with the updates hard because o…
I don't really see this as true. In my experience most C++ features actually "just work" together and there are relatively few footguns involved in mixing features.
And it's less that C++ is a patchwork language and more that it is multi-paradigm and multi-discipline. Some features have specific applications and they get used inappropriately but in my experience that is solved with a quick reference/citation of the standard during code review or in a new ticket.