1992 was just the year MFC came out. I would go as far as saying that C++ of the early '90s was at its Nadir of inelegance. I'd go as far as saying that C++ frameworks of the early 90s were the absolute nadir of elegance.

STL only started getting into compilers around '95, so we had no standard containers and dozens of different string implementations. The only part of the standard library widely available was iostreams, which is easily the most despised part of that library.

With no useful standard library to speak of, C++ devs were basically using the C standard library, rife with such shining gems of perfection as scanf(), strcat() and dear_hacker_please_inject_shellcode_here(). Since no generic containers were in sight, pretty much all 90s code I've had the pleasure to see was infested with macros. Pieces of exquisite beauty. I still have nightmares sometimes.

Then came the late 90s and early 2000s. The STL was widely supported, Boost started to gain ground and Andrei Alexandrescu released Modern C++ Design. Template metaprogramming slowly got out of hand and both code and errors were indecipherable.

The thing is, C++11 and beyond is the very opposite of this. Hairy template metaprogramming is replaced by simple and straightforward constexprs. Proper lambdas obsoleted functors, a gang of bloated design patterns (Visitor, Obeserver, Strategy, Command, Template Method, Decorator and so on) and several complicated lambda libraries from Boost.

Modern C++ is still a mess, but I believe it's way more elegant than ever before.

> I would go as far as saying that C++ of the early '90s was at its Nadir of inelegance.

Yup. '92 C++ was what gave Java such a boost. If we'd somehow started with '98 C++, or better still C++11, Java might never have picked up so much momentum.

Java picked momentum because in 1996, ANSI C++98 wasn't a thing, each compiler was catching up with the standard and many library vendors just gave use C libraries with us having to write C++ wrappers ourselves.

Also in 2000 I was writing K&R C on a HP-UX compiler, let alone the state of C++ compilers for writing portable code.

> Java picked momentum because in 1996, ANSI C++98 wasn't a thing, each compiler was catching up with the standard and many library vendors just gave use C libraries with us having to write C++ wrappers ourselves.

Yes. The experience in the early 90's meant everyone was looking for a saner choice. By the time C++ was the saner choice, Java had already received a giant boost.

> 1992 was just the year MFC came out.

Ignoring the nice work of PowerPlant , Turbo Vision and Object Windows Library, because they were too high level for C devs.

So Microsoft ripped off their Application Frameworks (Afx) prototype and we got MFC instead.

OWL and TurboVision... now these are names I haven't heard in a long time. I remember the company I interned at was looking for TurboVision programmers at some point, none were found, soin a true Russian fashion they just wrote their own clone of it.

I used Turbo Vision in Turbo Pascal 6/7, then migrated to Turbo Pascal for Windows 1.5 with OWL and eventually to Turbo C++ 3.1 with OWL.

As a dissenting opinion from someone who has not quite 20 years of experience with C/C++ but 14, modern C++ is what brought me back to the language. The idioms allow me to use the language more functionally. More importantly, the STL is actually usable now and you can just code using it and std::algorithm without thinking of the nuts and bolts of move assignment and stuff at all. In the case where you need performance, you have the paradigm at your disposal. Also, you have a ref counted pointer thread safe pointer! A means of transferring ownership so heap allocated objects can also follow the same RAII pattern!

I have a much easier time holding the entire picture together but others are correct in saying you have to throw away old conceptions and ideas of the language. I personally have thrown away the way I think about C entirely (at least when I code in modern C++).

C++ still cannot compete with proper high level languages in this area.

C++ is precisely useful because it's a better C: it has a C-like subset, and works directly with C data structures and function call interfaces. Plus it has features to do that kind of programming in a safer, more managed way.

I would absolutely not use C++ for anything that isn't in the area of "this should be ideally written in C, but that would bring in undue difficulties, risks and time".

The more C++ moves away from its focus of being a language for writing low-levelish systems middleware, the more it loses its relevance.

> Also, you have a ref counted pointer thread safe pointer!

Had those in 1997 using draft ISO C++, thanks.

just be careful with those ref counted pointers: shared_ptr/weak_ptr introduce a lot of atomic variable access. if you use them from a single thread then that's pure overhead.

Yes, of course. A big chunk of my time at various previous companies was removing usage of such things when not necessary. It's also not "a lot" of atomic variable access but you do need a strong fence to provide the correct semantics (so it is some). To what degree "a lot" or "some" is depends obviously on what you're doing.

Honestly, back in '92 the language seemed easy, but the practice was hideously complex and error prone. Most people still couldn't even figure out how to do exceptions properly. I would argue that today, the language is more complex, but the practice is comparatively simpler (still complex as a ll get out, but compared to '92...).