I then didn't touch it for most of a decade and re-learned C++ essentially from scratch maybe...three years ago? C++11 from the jump, with slowly adding in C++14 stuff as it made sense. And I like it well enough. It's never going to be my first-choice language, but that's because the environment around C++ is a mess rather than the language itself. The language has stuff to know, but I find that most of it is stuff that is totally comprehensible given that I understand how C++ works--like, of course I need virtual dtors if I've got classes, because I understand vtables and the necessity for a lookup in one. It's complex, in that there are a ton of different components, but I don't find it complicated, in that any component is difficult to understand in isolation or that the interactions between components have particularly many gremlins. (Which isn't to say that I'm a particularly good C++ developer or anything, but I understand the land mines and how to be better at stuff I need to be better at when it matters.)
These days, I can't envision ever writing more C than is necessary to wrap C++ for use as a library in Ruby, etc.; life's too short to not have dtors.
Sadly they seem to have added more than they cleaned up. It's 2016, I don't want to have to write another freaking include guard. That should have ended years ago. UTF8 and friends are also a consistent pain, mostly because 3rd party library support is absent. This requires a strong message from the standard library or it's always going to falter.
I'd say there are bigger issues with C++ than include guards, but include guards should be out when modules are in the standard (2020?).
We used to call it C+. It was code that could not be compiled by a C compiler. But at the same time was painfully obvious that it was not proper C++.
What makes C++ proper is pretty much what code style and best practices your organization/project decides to adopt. For some projects, 'proper' may be object-oriented C++ with class hierarchies, whereas for others it may be a more functional or template-based style that doesn't even use classes a lot.
Even C++ARM was already a pleasure compared with bare bones C.
I has lucky to be able to bring Turbo Pascal best practices into C++, and that Borland had very good tooling.
On my opinion, Turbo Vision, Object Windows Library and Visual Control Library beat anything that I saw from other vendors in regard to C++ frameworks for desktop applications.
It always saddened me that given C++'s compatibility with C, most vendors would just throw over the fence a C library and it was up to us to create sane C++ bindings for them.
A good example is the sad state of database bindings.
But I do use C++ on personal projects, and C++11/14 has been quite rejuvenating and I do enjoy using it, specially for hobby coding across mobile OSes, given that it enjoy first class support in all SDKs.
Edit [0] Not saying I was any better :o)
At the heart of the languages, in C you can only make additions and divisions, in C++ you can also make classes and use containers to store data.
These are very low level building blocks, it's not enough to make any meaningful development productively. You're forced to use 3rd party libraries if you want to achieve anything. (e.g. File, IO, Socket, Thread...)
There are many libraries/frameworks out there. I'd dare saying that C and C++ are extremely fragmented [by domains, platforms, tools...].
There is a minor subset of the desktop C++ developers that pick Boost as the default library choice and try to put that in all projects. They're just very vocal on StackOverflow [and all over the internet].
Boost is still very useful for many advanced or domain specific libraries.
Also, one big deal is Asio. Which, granted, can be had separately from Boost... but Boost offers a convenient place to get it along with other minor stuff.
Then there's the question of how up-to-date the C++ implementation you're coding against is. A lot of stuff is nominally in the standard library, and if you use the latest and greatest, you might even have it out of the box... but for many people, they're still working on, at most, C++11 compilers, and so they need an outside source for stuff like filesystem.
If you use Qt, for example, it is likely that you will also use their collections, streams etc, rather than STL and Boost.
Ditto if you use MFC (though thankfully that is largely relegated to legacy code now), wxWidgets etc.
Having said that, Boost has, to significant extent, become the prototyping sandbox for things that are then added to C++ standard proper - shared_ptr, any, variant, filesystem and many others all originated in Boost, and after many years of use and polish by the community, became (or are in the process of becoming) a part of the C++ standard library. This makes Boost more important than it used to be.