|
|
|
|
|
|
by rleigh
1980 days ago
|
|
|
Absolutely. It makes perfect sense, and in an ideal world this would be the direction which would benefit many, if not most, projects using C and/or GLib2. Unfortunately, there are far too many people who are wedded to the philosophy that C is perfect for every task, and C++ is the devil. Despite the fact that GLib/GObject are more complex than C++, more error-prone than C++, slower than C++ and make static code analysis impossible (due to all of the unsafe typecasting). A few years ago now, I ported a C GLib/GObject-based application to C++. In removing all of the unnecessary typecasts I found a couple of minor (but real) bugs which were previously hidden from the compiler. Simple use of real classes, along with basic containers like vector and map, was the vast majority of the C++ usage in the whole application. It benefitted greatly in becoming smaller, simpler, easier to read, easier to maintain, and having the compiler able to typecheck everything. Like yourself, I've also used C++ on MCUs. Some vendors even provide an "Embedded C++" C++ subset you can use, which is "safe" for safety-critical real-time code. Works fine. A lot of C embedded projects would benefit from the extra safety it provides. So long as you don't go overboard with the features; stick to a simple and easy to understand subset. |
|
|
Basically C++ARM as per language standard, on a 386SX running at 20 MHz, 2 MB but 640 KB was more than enough, right? :)
Our high school teacher giving us C classes with Turbo C 2.0 also had it around, so as it were back in those days, I eventually got a copy.
My gateway drug to programming until then were Turbo Pascal 6.0 and TASM, and C++ was in the same ballpark of features and culture for safer systems programming.
Never had any issues using it in such kind of PCs, including with my own bounds checked string and array classes, hardware that most modern MCUs can easily outperform.