←back to thread

196 points svlasov | 6 comments | | HN request time: 0s | source | bottom
Show context
lallysingh ◴[] No.40851756[source]
Wow this got really long. I was one of the coauthors for a reflection proposal (N3340) over a dozen years ago. Implementing compile-time reflection is honestly trivial - you basically transfer data from the symbol table on-demand into template specializations. It was roughly 1500 LOC to modify g++ to do it.

Looking at the examples (https://isocpp.org/files/papers/P2996R4.html#examples) what really stands out is the direct integration of type-syntax into the language. It fits in with a certain token-substitution way that connects back to templates. It also replaces some of the uglier operators (typeof?).

I hope it goes int! During the language's stagnation I left for a while, perhaps it'll be competitive again soon.

replies(2): >>40851990 #>>40855315 #
stiglitz ◴[] No.40851990[source]
By ”stagnation” do you mean “not getting new features”?
replies(3): >>40852374 #>>40852457 #>>40852476 #
jacoblambda ◴[] No.40852476[source]
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 keep up with. The issue is that those are the same features everyone has been asking for for over a decade so the people that really care found workarounds and eventually move over to the new std way of doing things when they can while everyone else continues waiting for that one feature they really care about.

replies(7): >>40853490 #>>40854139 #>>40854365 #>>40854369 #>>40854878 #>>40855193 #>>40856663 #
account42 ◴[] No.40855193{3}[source]
Personally I'd rather the comitte take longer and require more implementation experience before accepting new features. There are still too many half-baked ideas that turn out to be mistakes afterwards, resulting in either needless breaking changes or being stuck with bad solutions.

This is especially true for library features where users can always use third party libraries for containers/algorithms that are yet to be standardized (or indifinitely - not everything should be added to the stdlib). But even language features can and should exist as compiler extensions before we are stuck with them.

replies(2): >>40855217 #>>40855232 #
1. chipdart ◴[] No.40855217{4}[source]
> There are still too many half-baked ideas that turn out to be mistakes afterwards (...)

Care to point an example?

replies(2): >>40855257 #>>40856069 #
2. gpderetta ◴[] No.40855257[source]
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 feel DOA so far.

- Unrestricted compile time evaluation is great, but the constexpr qualifier per se doesn't guarantee any useful property.

edit: overall I'm happy with the evolution of the language, but the standardization process has flaws

replies(1): >>40864377 #
3. kragen ◴[] No.40856069[source]
marshall cline's c++ mini-faq is a list of about 100 pages of them from the 01990s
replies(1): >>40858862 #
4. chipdart ◴[] No.40858862[source]
> marshall cline's c++ mini-faq (...)

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.

replies(1): >>40860348 #
5. kragen ◴[] No.40860348{3}[source]
it was actually originally published in 01991 (at which point it was just the comp.lang.c++ faq), but cline continuously updated the faq-lite until 02012†; see the update history at https://web.archive.org/web/20140225204048/http://www.parash.... so it's entirely your choice to only look at a version of it from 01994; you can easily find him merrily celebrating c++'s boneheaded design errors continuously after c++98, after c++03, and indeed after c++11, although the document was looking increasingly old-fashioned

however, even if we only consider the 01994 version, i still extensively disagree with your comment, and i will explain why in detail

in fact c++ was already well defined before ansi formed their committee in 01990, four years before the version of that faq that you chose to read. the arm (not the arm arm, the annotated reference manual) was the standard standard until c++98, and it's written as one. it says things like

> The following rule limits the context sensitivity of the rewrite rules for inline functions and for class member declarations in general. A class-name or a typedef-name or the name of the constant used in a type name may not be redefined in a class declaration after being used in the class declaration, nor may a name that is not a class-name or a typedef-name be redefined to a class-name or a typedef-name in a class declaration after being used in the class declaration. For example,

(that's from §9.9 if you want context)

but why would it be relevant whether there was a c++ standard or not? it would be relevant if the problems documented in the 01994 version of the faq-lite had been eliminated by standardization. but that is comprehensively not the case. every single one of the misconceived features in the 01994 version of the faq-lite is still in everything resembling a c++ standard, so all the pitfalls of poorly interacting features it documents are still relevant today. that's why i think that even the 01994 version of the faq-lite is relevant

so from my point of view it is not only wholly false to say that there was nothing resembling a c++ standard in 01994, it is also irrelevant whether there was anything resembling a c++ standard when the faq-lite was written (at least for 01994 and later versions)

furthermore, your particular choice of 01994 is unjustifiable and evidently only serves to provide a spurious veneer of justification for your irrelevant objection that (interpreting you generously) the faq-lite predates the c++98 standard. if you thought that was important you should have picked a version of the faq-lite from 01999 to criticize

______

† after a hiatus, since 02019, it is again being updated at https://www.parashift.com/c++-faq-lite/ but obviously the new center of gravity for this kind of thing is stack overflow and cppreference

6. pjmlp ◴[] No.40864377[source]
Module are already being used by Office, and those of us that don't need to rely on GCC, don't hate CMake, can already enjoy using them.

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.