Two features C++ urgently needs

Here’s the thing. I tried to get attached to other programming languages, but somehow, deep inside my heart, C++ continues to reign supreme. It’s absolutely lovely, it has raw power, and you can optimize everything to hell and back. No, it’s not C; C is too low level and sometimes can harm your performance by not being able to do copy-paste the way templates do. Plus the things you need to do with macros…

But the problem is that I can’t get myself to create projects in C++. I would love working on one, but I just can’t get myself to start. I need these features which I’ll present without further ado.

The modules specifications.

Not only the modules spec should be pushed forward and fast, but it should be made mandatory and anything else obsoleted. And that includes the preprocessor from C. C++ will be a totally different language as soon as it removes the need of a very verbose, hand-generated header files.

I don’t mind if, in the back, C++ compilers will continue to support header files. It can very well do that, since old code must be supported, I don’t want to go Jonathan Blow on this and create my own language. I don’t think I want to discard the 25+ years of compiler experience from the C++ compilers. I don’t want to discard 25+ years of libraries (or do I?) but I do want to get rid of the need to read header files kludged with macros and whatnot, only to find out that those header files are from a different version of a library. And yes, I want the libraries to deliver the public interfaces as well, the way they were compiled. And I want a compiled version of the standard library.

The modules specification actually can make the C++ library writers a lot more efficient. Right now it’s a bit hard to specify in a clear manner what you want to export publicly and what you want to keep inside the library, so that people don’t count on unpublished internal interfaces that might change in time. Not only that, but also there will be no need to deliver a ‘development’ package, because you deliver it with your libraries. Just like decent people would. And, anyway, it will be easier to focus on what you expose, and think three times if something needs to be exposed or not. And that will make everyone write smaller and more efficient interfaces. Or they can go Boost on you, like they always do :(. But hey, freedom!

A new standard library

STL is as bad as a heart-attack. You can survive it, but it will affect you for eternity, and your performance will never be the same. And the C++ standard library has come to be associated with the STL. With all due respect to Mr. Stepanov, who I think is a great computer scientist, but STL is an example on how not to write a library.

C++ has the worst strings support out of the box. It’s convoluted, it’s complicated, you can’t convert properly from various encodings without some horrible gymnastics. It’s badly documented. It has an inexpressive interface. It probably is the worst string class ever designed by humans.

Then, other containers. Again, they do have the worst interfaces possible, in naming as well as concepts. push_back is the worst name you could have for an operation where you add an element. For vectors, there are 8 iterator functions, and 7 functions related to the number of elements. I emphasize on the iterator functions because nobody in their sane mind looks for ‘iterators’. I never needed an ‘iterator’ in my entire programmer life. I used them, but I never needed them in an explicit manner. They shouldn’t be there. We don’t need to see them.

The STL gives, in any usage scenario, the feeling that you’re in a construction site, and all you can build is skeletons. You don’t use finished sets of pieces, you use steel bars, and that’s all the finish you can put in your work.

And I know that the conceptual problems that C++ tries to solve are indeed complicated. That’s why you have to write seven functions for every class, constructors and assignment operators just to make sure that your class will behave properly. Hopefully. That’s why you can have a different function for const X&, const X*, X& and X* parameters. That’s why you have to learn that you can overwrite the -> operator, and it’s as insane as it sounds. C++ can and will let you do that.

The sad part

The more I write about C++, it’s obvious that I don’t really need C++. Currently, C++ is one of the least portable programming languages. It has problems behaving on the same platform with a different flavor. You can’t deliver a complete, no-nonsense C++ environment, you can’t deliver for a C++ environment. That’s why, for example, game developers are bowing to Valve for creating SteamOS – because that’s a platform they can count on.

So I guess I should go Jonathan Blow on this one. Maybe we do need a new programming language after all. Or maybe I should stop complaining and learn Haskell.

The Swedish warship Vasa -- Ralph Bruce

The Swedish warship Vasa — Ralph Bruce

Comments

Two features C++ urgently needs — 10 Comments

    • I know cppreference, but the problem still remains. The API is not elegant, it doesn’t “flow” well, the strings support is painful to say the least, and the rest… how easy is it to use the random part of the library?

      And Boost is ugly, it makes me cringe. And I see that things can be done a lot easier, a lot more elegant. I see it all around me, and I wonder: what’s STL? It’s the ugliest library ever written, by far. I tried to debug stuff with containers. it’s painful to say the least.

      But I can work with that. What I can’t work with is headers. I can no longer work with header files especially in the kickstart phase when I have to create fast a lot of classes. And I get demoralized and tired. I feel like I’m fighting with the language. I feel like saying: “can’t someone else do it?”. I will definitely come back to C++ when modules are working. I don’t really feel like getting there before that.

    • Am going in a very slow manner. My problem there is that I can’t really see how mutation is done (I know, it’s not), because that’s how I feel that states should be implemented. However, I need to choose a project of the right size (larger, yet doable fast), to actually get how Haskell works.

      However, the more I read about the functional paradigm I feel that I understand where it comes from. But I still don’t see the whole thing working. Of course, I still don’t understand what monads are, and this is after I went through two presentations that laterally discussed this topic.

  1. Concepts will also go a long way to nicer C++ development.

    Yes, C++ sucks. There’s plenty of better languages around but none have its industry support in terms of tools or libraries (one could argue that Java has great industry support, but I do not consider it a better language).

    Programming these days is a lot more about using the right tools and libraries than writing something from scratch. Unless you’re a giant company which can afford to write everything from scratch :).

  2. If you want middle ground between C++, Haskell and the Jonathan Blow way you should look at Rust.

    It’s low-level, it has some functional features, and it’s not quite 100% finished but it’s very close to the 1.0 release.

  3. I should probably mention that sample code that you can find on the Interwebs is usually garbage, outdated (the language evolved very quickly) or both. If you’re interested go through the “Book” on the official website.