Hacker News Reader

Comment by gary_0 | Hacker News Reader

They started changing the definitions in C++11 to support move semantics. I don't remember much about C++98, that was decades ago. If that's what the Standard said back then I'll take your word for it, but I wasn't talking about historical C++ Standards.

Keep in mind, my original comment was pretty much just drawing a line through TFA, which also argues that you can't cleanly map C++ object concepts onto C structs. C++ has some backwards compatibility with C obviously but nowadays it's a totally separate language with an independent standards body (for better or worse). Specifying "do what C does" might have flown in 1998 but that changed a long time ago.

View on HN

I am generally not a fan of the standards committee nor what it is trying to do with the language. The word "Object" used in C++ land has a different meaning than the same word used in C land since there is an "Object Model" in C++ while there is none in C. Hence trying to map C++ object concepts onto C does not even make sense in the general case. But because of C++'s evolution having started as "C with classes" there is some mapping at the set-of-bits level which is where the POD (with all its limitations) comes in.

I am fully with Stroustrup in arguing that C++ should strive for as much compatibility with C as possible in the spirit of the original (see ref. at https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B...). But sadly the rest of standards committee don't seem to want this which i believe is a huge mistake. On the other side, the C standards committee should be very careful what inspiration they take from C++ in the evolution of the language since it was designed as a "minimal" language which was one of the main factors in its success. Whether people call it "primitive", "well behind other languages" etc. does not matter. You definitely don't want C turning into C++-lite. Hence IMO the conclusions stated in the last few paragraphs of the submitted article are quite right.

In my experience the number of C++ developers with nice things to say about the Committee is... very small.

In a way, the whole C++ endeavor was doomed from the start. C was old and pragmatic and vague, a "portable assembly", and it was a shaky foundation to build C++ on top of. When the Standard tried to tighten things up, it just got more lopsided, full of hacks to fix hacks. But the alternate universe where C++ had a more pragmatic, laissez-faire design going forward probably isn't any better; maybe the "standard" would have become "do whatever GCC does"--or in the Darkest Timeline, "do whatever MSVC does".

I disagree that C++ "respecting its C roots" is viable. The C++11 and later Standards were trying to make the best of a bad situation, and that required leaving C behind because the C way of doing things doesn't fit with a higher-level language like contemporary C++. Especially when the language has multiple implementations that need to compile the same code the same way. The "C with classes" days are long over for most of us who have to use libraries expecting std::vector, smart pointers, and exception handling. We live in mortal fear of compiler writers smiting us for innocent things like punning through a union.

> You definitely don't want C turning into C++-lite

I agree. Trying to quickly hack classes or templates or whatever back on top of C would just start the whole C++ nightmare over again.

> In a way, the whole C++ endeavor was doomed from the start ... I disagree that C++ "respecting its C roots" is viable.

Hey! Them's fighting words! :-) "C++ as a better C" (which is what it started as) was/is/always will be needed and necessary. It gave you the best of both low-level and high-level worlds with full control and just enough complexity. Instead of implementing structs full of function pointers to design dynamic dispatch object models you just had the compiler do that for you while still retaining full control over other aspects. I still have some manuals that came with SCO Unix one of which was on the then newfangled C++ language. It had one chapter by Stroustrup himself (his original paper probably) on the C++ object model showing how vptrs/vtables are implemented and thinking it neat that the compiler did it for you. Also templates were just glorified macros then with none of the shenanigans that you see today. Hence moving from C to C++ was easy and its usage and popularity exploded. But with the infusion of lots of people into C++ land people who were not aware of the original vision/design/compatibility goal of the language started asking for the inclusion of more and more OO and modern language features. The result? The standards committee reinventing the language from C++11 onwards(and changing every freaking 3 years) and alienating the old C++ folks who made it popular in the first place. No doubt there are some benefits like increased design space and modern programming techniques but am not sure whether the increased complexity makes it all worth it. For me it is still C++98 with the addition of the STL and some simple generic programming techniques which is the sweet spot.

> We live in mortal fear of compiler writers smiting us for innocent things like punning through a union.

C++20 introduced `std::bitcast`, so I appreciate alias analysis getting all the help it can.

Reply on news.ycombinator.com