It’s about time to rethink C++

0
80

Here’s a C++ brainstorm:

I’d like Microsoft to refocus on C++, with a twist.

Let’s face it, C# and its managed world have taken over. C++ is all but dead for most of the Microsoft community. It’s a shame. C++ offers some significant advantages over C#. Take low-level image analysis, for instance. Sure things are possible in C#, but it’s not the baseline and not safe references permeating through your code are a good warning sign something’s not right. And then there’s the default garbage collection. In my book, the whole garbage collection implementation is backwards. Efficiency should come first–especially if there’s a way to do it that solves the majority of the “problems” people have with memory management. The catch all approach should be the option–the minor case. But that’s just me and probably an issue unto itself that should be left for another discussion.

The reality is that C++ and its world are withering away. MFC is fading. At least in the Microsoft world, more and more pitches to use Managed C++ are being made. I have no problem with leveraging Managed C++, but C++ shouldn’t become synonymous with “legacy.”

So what to do?

Here’s what I’m thinking. Clean up C++. Yeah, break the language. I know, I know. This generally isn’t good, but what’s the alternative? One legacy language patched endlessly with Managed C++ or a modernized C++?

Some changes I would make to C++: Lose the header files. They made efficiency sense once upon a time. Today they don’t. They get in the way. Yes, there are some clever things you can do with header files, turning off and on macros, for instance. But I’d get rid of all that. The pragma once is a good start. I’d make that the default in the current compiler. It’s a step in the right direction. You can’t redefine things twice. Macros would probably have to go too, but that’s just me. Using them for constants can be fixed by using constants and where you’re using it to “generate code,” clean up syntax and the like, well, I guess a function will have to do. That’s not terrible. And templates….wouldn’t removing the header file solve some of the problems they create in terms of where the code is placed and how the programmer thinks about where they should put their code?

I’d keep the same old pointer and memory allocation models, however. That’s what would differentiate C++ from lets say C#. The baseline would have no managed libraries. None. You could use them, but that pulls in the .NET Framework like it would today.

So what about GUI development? That would be a problem. MFC would be useless and not worth porting I imagine. In fact, until an appropriate C++ GUI library could be developed, C++ development would be relegated to UI-less development–that is, unless the .NET Framework is pulled in.

This would allow me to code for performance and yet leave the door open for developing a better “MFC” if you will. The ATL was one approach. Managed C++ is another. But doesn’t it seem like there’s a more performant, easy to use approach waiting to be created? I do.

And what about other libraries, such as STL? For some I wouldn’t mind losing them. It’s something to think about. Generally, I’d look forward rather than backwards on something like this.

This is the first time I’ve typed out some of these thoughts, so this post probably reads more like a brainstorming bullet list than complete arguments, however, I’ll go back to my original thesis that at least for Microsoft’s community C++ is dead. It shouldn’t be. It ought to be saved–not just by pounding out more libraries, but by brining the language up to date, yet without losing it’s core value: