Top 10 features that I miss from C++

DISCLAIMER: the following is a pure hypothetical list of wishes I had about C++. You should treat it as it is. This is not supposed to be a collection of community agreed list of wishes, nor it is intended to make complete sense, as some of these features are available through the standard library. Please procedure further with that in mind.

I was thinking lately what are the top language features I am missing from C++ but are available in other similar languages (such as C# or Java). After some consideration I have come up with the following list. Note that this list refers to language features only, and not library features and they are listed in a rather random order.

  • Native string type, other than char*, rather a language built-in std::string
  • Native datetime type, that would allow us to specify points of times without a built-in resolution. Obviously adding this after the chrono library makes no sense. This refers rather to a language feature that should have been available from the beginning. The reason for that is specifying date and time is a common operation we often need to do.
  • Native interfaces, other than abstract classes with pure virtual functions only as it is currently possible, because such classes can also contain data members. The reason for this is convenience in defining interface. The syntax for this should not require us to define the member functions as virtual and pure, they should be virtual implicitly. Interface member functions should also be mandatory public so we should not have to declare that either. And last, but not lease, interfaces define contracts and therefore a special interface class should not allow to define data members, not static methods.
  • Properties, basically a pair of get/set accessors over a data member. Having automatic properties to create data members and accessors would be even better. We manually write these all the time and having the compiler generate them for us would be a productivity boost.
  • Extension methods that would enable extending exiting types with new methods without modifying the type itself. This can be be achieve in different ways, but support in the language for this feature means we can extend existing code with new methods without touching it, and call these methods as they were actual member of the class.
  • Template type constraints basically what concepts will provide in the future, so I will not insist on this. Current workarounds with enable_if and SFINAE, static_assert and even deleted functions currently exist.
  • Events to enable a subject to notify observers that something has happened. Obviously this can be implemented explicitly using existing functionality, having native support for that would simplify writing code and increase productivity.
  • Switching on other types than integral types, especially on strings. In general it should be possible to switch on any compile time constant expression. The reason for this is to replace if-else statements with a simpler to write and read switch statement.
  • Finally block for a try-catch so we can specify code that should execute regardless of whether an exception occurs or not. This is supposed be achieved by implementing the RAII idiom. Resources should be released properly upon destruction, but the reality is that a lot of code does not use RAII. Having finally blocks would enable us to run clean up code either if an exception occurred or not.
  • Static classes, that can contain only static members, and static constructors, that are called before main and have access only to static members of a class (there is actually a proposal for static constructors under discussion for standardization). Helper functions may be implemented as static members of a class, and having the class as static would be a constraint on the class to only contain static members.

I do known and understand the principles of C++ and I know these may look counter intuitive. I know why string is a library container, and why time points are available through a library and why these are general purpose implementations intended to meet many needs. For instance the chrono library is resolution agnostic, which means that in the future clocks will deliver picosecond resolution we won’t need to update the library to benefit from that.

On the other hand the reality is that general purpose implementations lack many features developers use all the time, such as converting a string to upper or lower case. This is available in many languages or string libraries, but not in the standard library string. Yes, we can implement that simply in a helper function, but if extension methods were available we could call such a helper function as it was a member of the string class, which would look, arguably, more natural, and also similar to what is available in other languages.

Another reality is that many developers use more than just one language. Some of these features would enable developers coming from a background of .NET or Java development to get a faster and better grasp at C++.

The most important benefits of these feature would be less and probably more readable code and an increased productivity. There are workarounds for these and, yes, we can live without them. But I do not believe that makes at least some of them unreasonable.

I would like to hear what are the features that you miss the most and see if they also appear on this list.

, , , Hits for this post: 8271 .
Trackback

9 comments untill now

  1. Gravatar
    Guillaume Racicot @ 2016-11-09 16:31

    > Native string type

    I have no idea how it would improve the language. Char arrays have their uses. In a context where there is no dynamic memory (eg. in a constexpr function or a literal class) Char array does the job marvelously.

    > Native datetime type

    Why? A “native” datetime type would be a wrapper around some integral values. This belongs in a library, by preference the standard one. User (or standard libary) defined type behave like native one.

    > Native interfaces

    We have multiple inheritance. We don’t need that. Are you trying to turn C++ into C#?

    > Properties

    Thanks for answering my question. C++ don’t need properties. Just make your members public if you don’t need to transform data. If you do, make a function. Simple as that.

    > Extension methods

    This is actually interesting, but it already exists. It’s called std::function. Just put one as a member that you can reassign, and set a default value.

    As for adding new one, you better using free functions or a CRTP for the moment. I wouldn’t get my hope too high as this feature would require some runtime machinery. But again, this feature is easily replaceable with current idoms.

    > Template type constraints

    Everyone is waiting for that. My hopes are that it would change completely how templates are made in C++, and the current paper is aiming for that. I really hope it comes out before C++20 though.

    > Events

    This is eyecandy stuff. I wouldn’t hold my breath as again, this feature would implicitly require dynamic allocations and holding a list of observers without the programmers knowing it. For a C++ programmer this is bad. There is many libraries to do that. I even saw one that enables observer pattern on a single member of an object. The point is you can emulate such behavior with template, but would require some work, or there is libraries that can do that for you.

    > Switching on other types than integral types

    http://en.cppreference.com/w/cpp/string/basic_string/stol
    http://en.cppreference.com/w/cpp/string/basic_string/to_string

    You’re welcome.

    > Finally block

    As you said, RAII is there for that, and a far better idom than finally, as it work for any situation, not just finally.

    > Static classes

    You could use Scott Meyers singleton in the meantime. Not quite the same syntax but does closely what you want. But honestly, I think it is already too easy to abuse global data.

    Btw, You forgot modules.

  2. Gravatar

    I am not trying to turn C++ into C#, but there are good things in C# that would be nice to have. Why not? Are we religious about it? This is a list of wishes. It does not really need to be rational. I know things have workarounds and some things may be coming in one form or another. So look at it a bit relaxed and don’t try to justify everything.

  3. Gravatar
    Domen Vrankar @ 2016-11-09 20:15

    I’m glad that for now most of C++ standardization people have different wishes for the language than you 🙂 For me your wish list (all bullets starting with N, P and F letter) closely resembles my what-I-dislike-about-Java-D-and-Swift list 🙂

  4. Gravatar
    Domen Vrankar @ 2016-11-09 20:26

    @Guillaume Racicot For me a better argument against properties would be: Most of the time class should not spill out its guts and return only computation/task results (non trivial getters) except when you have a container class/object that moves stuff from for e.g. database to data processor. Making trivial getters/setters a first class citizen would encourage people to spill out the guts of their classes and encourage class instances with broken invariants (the stuff that I often see in code coming from the hands of Java developers – have less experience with results from authors using other languages).

  5. Gravatar

    @Guillaume, the only rational where I find property handy, is to access functions as data-members. e.g. myobject.thing = 3; would be compiled ± to myobject.setThing(3); (isn’t how python properties work?)

  6. Gravatar

    Many people often forget that C++ is not just used on desktops. If you are working bare metal on a chip with 6k or RAM you thank god people put things in libraries rather than the language so you can opt out or build your own.

  7. Gravatar
    Miro Zupa @ 2016-11-10 13:21

    You are probably thinking about C++ in a C# way. I am a huge fan of C# and I like many of its features. But as a programmer who often uses both of these languages, I have to say that most of these features either don’t fit C++ or it already has a better ways to achieve the same goals.

  8. Gravatar
    jsphadetula @ 2016-11-12 14:52

    the new std::uncaught_exceptions will make it possible to finalizers that execute on scope exit

  9. Gravatar

    >Native string type
    a template friendly string type would be nice,
    closest we have now is using a variadic char template, which is what the templated literal operator uses

    template double operator “” _x()
    where 123_x is the same as call operator””_x();

Add your comment now