I really did. I programmed in C++ 20 plus years ago, first on a Sparc workstation and later on a Windows computer. At the time, it seemed to be a good language, and in fact about the only object oriented language for developing both server and client applications.
But something happened between then and now. That something was the development of a number of programming languages (Java, C#, D, Go, Rust) that tackled the myriad problems that C++ presented.
I will not enumerate the problems that compatibility with C has produced because we are familiar with them, and at least I could live with them. And the C++ standard has advanced enough to provide alternatives for some of these problems (e.g. smart pointers instead of “dumb” pointers). There are still a number of problems that may or will be addressed in future updates to the standard.
Where I have trouble with C++ is mostly with templating. Don’t get me wrong, I think templated classes and methods can be wonderful. Where I have problems is in its other uses: trying to overcome some of the limitations of the language, such as lack of reflection. For an example, have a look at my post titled Compile Time Checking of Class Template Types for how to use SFINAE to determine if a class contains a certain method. This would have been so much easier to do with reflection. Every time I attempt to do any template programming outside of simple class templates, it seems to take days to accomplish.
I am not the only person who has problems with templating and SFINAE. Just pop over to Stack Overflow and do a search for SFINAE. As I write this, there are 2073 questions about it.
There are many changes to the language and standard libraries that would make C++ easier to use, and some of these will be addressed in C++20 and beyond. There are libraries in Boost and elsewhere for a number of these, but their inclusion in the standard libraries will no doubt make changes to those existing APIs.
So I have decided to to look over some of the “replacement” languages: C#, D, Go, and Rust. Each of these languages has the advantage of observing C++ problem areas that arose during at least the first 15 to 30 years of C++ use, and could therefore address in the design of those languages.
Most of the problems could be addressed in C++ except for the stated requirement of backward compatibility between the various C++ standards. Some languages effectively reinvent themselves by introducing new versions that make breaking changes with previous versions; for example: Perl, Python, and D.
Java, C#, D, and Go get around some of C++’s problems by using a garbage collector. Garbage collectors are no-no’s in certain areas of programming where C and C++ are the go-to languages: real-time programming areas such as embedded systems, operating systems, and drivers. But there are some new replacements even in those areas; for example: Rust.
Since my programming efforts are unlikely to involve real-time programming, I can live with the occasional slight slowdown that a garbage collector will cause. At least my limited past experience with Java and C# have shown no problems in that area.
So, I am moving on from C++, and possibly back to a programming language that I have used in the past.
This is the last post on this site, at least for now. You may want to check out my other blogging site, Jim’s Adventures in Programming, for non-C++ related topics. There may not be much there yet, in fact there is nothing as of today, but I will be added content there soon.