The new Visual C++ 2017, currently in release candidate phase, provides a series of updates and fixes to both the C++ compiler and the standard library. A comprehensive list of these improvements is available at What’s New for Visual C++ in Visual Studio 2017 RC.

In this article, I want to shortly look at the new standard library features from VC++ 2017.

  • std::any (available in header <any>) is a class that represents a type-safe container that can hold the value of any copy-constructible object. To read the value stored in an any variable you need to use the non-member function std::any_cast.

  • std::optional (available in header <optional>) is a class template that may or may not contain a value any moment in time. If it contains a value, it is allocated as part of the optional object, and therefore does not incur any memory overhead.

  • std::variant (available in header <variant>) is a class template that represents a type-safe union. A variant can hold any number of alternatives, but they cannot be of type reference, array or void. The first alternative must be default constructible, because variants are default constructible and a default-constructed variant object contains a value of its first alternative. If the first alternative is not default-constructible, std::monostate (an empty, default-constructible class) can be used for that purpose. If it contains a value, it is allocated as part of the variant object, and therefore does not incur any memory overhead.

  • std::basic_string_view (available in header <string_view>) is a class template that represents a view of a contigous sequence of characters (defined by a pointer to the start of the sequence and a count). Several type aliases are available:

    basic_string_view has an interface almost identical to basic_string so that switching from the later is as simple as possible. A typical useage of this class template is for function parameters as a replacement for constant references to basic_string.

Additional new supported C++17 standard library features are:

  • std::apply is a function template that invokes a specified callable object with a tuple of arguments.
  • std::make_from_tuple is a function template that creates an object by invocking its constructor with the members of a specified tuple.

To have all these available the /std::c++latest compiler switch must be used. This can be also set from the project properties, at C/C++ > Language > C++ Language Support.

, , , , , , Hits for this post: 3905 .

Last week I was in Redmond for the Microsoft MVP 2016 Summit. At the same time, the ISO C++ committee was having its fall meeting in Issaquah, which is very close to Redmond. Therefore, after the summit ended, a group of VC++ MVPs, including myself, decided to make the short trip to Issaquah and attend as observers the meetings, that are actually opened for the public. It was a very interesting experience and I am glad that I had the opportunity to take it.

The committee is organized in several working groups (WG) and study groups (SG). You can actually read all about that here. These groups have separate meetings as they are focussed on different things. I have attended a meeting of the Evolution Working Group (aka EWG), as, at that point, it looked like the most interesting of them all. These meetings actually took place in the same location where the final version of C++14 was voted.

Apart from the topics that have been discussed, which I will not elaborate on here, even though they were interesting and important, it was rather the way the committee is working that it was of most interest to me. I always had the impression that discussions were held in the fashion of the debates in the British Parliament or something similar, and I was surprised to see a much more organized, though still vocal, group. People are patiently taking turns to speak, constantly come with unexpected arguments or counter examples and eventually take polls to see what is the group’s overall opinion on the discussed topic(s). It also helped understand the process proposals go through from an initial form to the one that is eventually voted, if that is the case. I realized that it is way too easy for us to complain that things take too much time to be accepted. The reality is there are so many details that have to be taken into account and it takes many people to see them all. Everything needs to be backward compatible and it takes a lot of scrutiny and proposal iterations to reach a generally accepted form.

Overall, it was definitely a trip worth making, and I am looking forward to doing that again. I also encourage all of you that are interested in that and have the opportunity to take it.

For information about the progress in Issaquah see Herb Sutter’s Trip report: Fall ISO C++ standards meeting (Issaquah).

, , , , Hits for this post: 3079 .

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: 4190 .

C++17 was supposed to be a major update of the C++ ISO standard. After the Jacksonville meeting (29.02 – 05.03) it looks like it’s rather going to be a major disappointment. I’m not trying to downplay the things that have been voted into the C++17 standard so far, but all major features we hoped for this new version were moved out: modules, concepts, ranges, coroutines, uniform function call syntax.

Here is a brief report of the meetings, Trip report: C++ meeting at Jacksonville, and a quote of what was moved out for the next version:

Let me start enumerating the things we are not going to have in C++17:

  • Modules: They will not be in C++17, but in a separate technical specification. That is really a pity, as we will be for more years without having what I was expecting to let me get rid of the text substitution paradigm of the include directive as well as improve compilation times.
  • Concepts: They will not be integrated in C++17, but stay for now in their own technical specification. There were concerns about some issues in the TS, which I do not consider essential. Despite that there is implementation experience and even other TS depends on it, it was rejected to move concepts to the IS.
  • Ranges: This is a library solution highly depending on concepts. So, no way.
  • Coroutines: There was a very sound proposal with implementation experience. However, again this was targeted to another technical specification.

Besides that, we also will not have the half of uniform function call syntax that I thought was not controversial. To be clear, I really wanted both halves.

You can discuss on the report on reddit. The general feeling is disappointment though.

On a side note, standard C++ library in Visual Studio 2015 update 2 is C++17 feature complete (on what has been voted so far prior to the Jacksonville meeting).

, , , , , , Hits for this post: 9809 .

Extension methods in C++

A few days ago Bjarne Stroustrup has published a proposal paper (N4174) to the C++ standard committee called Call syntax: x.f(y) vs. f(x,y). The following excerpt from the paper summarizes the proposal:

The basic suggestion is to define x.f(y) and f(x,y) to be equivalent. In addition, to increase compatibility and modularity, I suggest we explore the possibility of ignoring uncallable and inaccessible members when looking for a member function (or function object) to call.

x.f(y) means

  1. First try x.f(y) –does x’s class have a member f? If so try to use it
  2. Then try f(x,y) – is there a function f? If so, try to use it
  3. otherwise error

f(x,y) means

  1. First try x.f(y) – does x’s class have a member f? If so try to use it
  2. First try f(x,y) – is there a function f? If so, try to use it
  3. otherwise error

This may sound a bit crazy, but to me this immediately shouted EXTENSION METHODS, which is something that I’ve been wondering for a while how could be added to the language. I find this one of the most important proposals (I am aware of) for the evolution of the C++ language.

UPDATE: Recently I have discovered that a second paper on the same topic exists. The N4165 paper, called Unified Call Syntax, is authored by Herb Sutter. Unlike the first paper, Sutter’s paper proposes only making x.f(y) equivalent to f(x,y) and not the other way around. Here is a quote from the paper:

This single proposal aims to address two major issues:

  • Enable more-generic code: Today, generic code cannot invoke a function on a T object without knowing whether the function is a member or nonmember, and must commit to one. This is long-standing known issue in C++.
  • Enable “extension methods” without a separate one-off language feature: The proposed generalization enables calling nonmember functions (and function pointers, function objects, etc.) symmetrically with member functions, but without a separate and more limited “extension methods” language feature. Further, unlike “extension methods” in other languages which are a special-purpose feature that adds only the ability to add member functions to an existing class, this pro-posal would immediately work with calling existing library code without any change. (See also following points.)

Herb Sutter argues that the unified call syntax would achieve major benefits including consistency, simplicity, and teachability, improve of discoverability and usability of existing code and improve C++ tool support. However, he also explains why why making f(x) equivalent to x.f() is not possible since it would break existing code.

Extension Methods in C#

I’ll take a step back for a short paragraph on extension methods in C#.

An extension method allows you to add functionality to an existing type without modifying the original type or creating a derived type (and without needing to recompile the code containing the type that is extended.)

Let’s assume you want to write a method that counts words in a text. You could write a method called WordCount that looks like this (for simplicity we’ll only consider space as a delimiter):

You can use it like this:

Just by changing the syntax a bit and adding the this keyword in front of the type of first argument (always the type you want to extend), the compiler treats the method as part of the type.

With this change we can now write:

WordCount(text) vs. text.WordCount() is exactly what the Stroustrup’s N4174 paper is proposing.

Notice the extension methods in C# have several requirements including the following:

  • the extension method is always a public static member of a static class
  • the extension method has access only to the public interface of the extended type

Extension Methods in C++

The question that one may ask is how would this equivalence of x.f(y) and f(x,y) be beneficial to the language. My immediate answer is that it defines extension methods and enable developers to extend functionality without touching exiting code.

Let’s take a real case example. The C++ standard containers provide methods like find() to find an element in the container. There are also generic algorithms for the same purpose (that work in a generic way for various ranges defined by iterators). But this find() methods return an iterator and you have to check the value against the end() to interpret the result. Using std::map for instance, many times you just need to know whether it contains a key or not. std::map does not have a contains() method, but you can easily write a helper function:

And with that in place you can write:

However, I would very much like to be able to say (because in an object oriented world this seems much more natural to me):

If x.f(y) and f(x,y) were equivalent this later code would be perfectly legal (and beautiful).

Here is a second example. Suppose you want to define some query operators like the ones available in LINQ in .NET. Below is a dummy implementation of several such operators for std::vector.

(Many thanks to Piotr S. and Yakk for helping with the implementation of select.)

Those functions enable us to write code that “sums the square of the even numbers from a range” as shown below:

I don’t particularly like how the code looks. You have to catch the return value from each function even though it’s an intermediary value that you discard later.

One can improve that by using the return value from the previous call as a direct argument to the next call:

However, I like this even less. First, because it gets hard to follow what are the arguments for each call (and even if you try to format it differently it’s not going to help much) and second because it inverses the natural reading order or the operations. You first see sum, then select and last where. Even though this is how we described it earlier (“sums the square of the even numbers from a range”), it is misleading with regard to the order of the operations.

However, if x.f(y) and f(x,y) were equivalent it would be very easy to write the above code like this:

Isn’t that beautiful? I think it is.


The N4174 paper is rather an exploration of possibilities for uniform calling syntax than a very formal proposal. There are various aspects that have to be carefully considered especially when considering how to treat f(x, y). The N4165 paper makes a good case of the uniform calling syntax, explains the benefits better and argues against treating f(x) equivalent to x.f(). You should go ahead and read the two papers for detailed information. However, I sincerely hope that one day this will be accepted and become a core feature of the C++ language.

, , , , Hits for this post: 20141 .

Concepts are out of C++0x

Concepts were supposed to be an important new feature in C++0x. They were meant to allow programmers to specify properties (like constraints) for templates, allow compilers to do some optimization and tools to do some formal checking on the code. After years of debate, the standard committee found them “untried, risky and controversial” and ruled them out last month during their meeting in Frankfurt.

Danny Kalev, a former member of the C++ standard committee, wrote about this controversial removal, and later interviewed Bjarne Stroustrup about the concepts and the future of C++. You can read this interview, published on, here.

You can find more about concepts in this paper by Bjarne Stroustrup.

, , , Hits for this post: 26446 .

The new C++0x standard provides support for type inference. The auto keyword that was doing nothing in C++ was given a new meaning: a placeholder for a type inferred by the compiler. For those familiar with C#’s var keyword, this is basically the same.

Here is a comparison between auto in C++ and var in C#.

C++ C#

with the output

C++ C#

As you can see, the use is very similar, except that in C++ you can use auto for a lambda expression, while in C# you cannot. The C# compiler raises an error, CS0815, when you try to use var with an anonymous function expressions, a lambda expression, a method group expressions, or the null literal expression, because these don’t have a type.

Just like with var, you can only use auto locally, and not as return type from a function, or parameter to a function.

While it might not be of that much help for ints or strings, using auto for instead of vector< int >::iterator, or map< string, list< string >>::const_iterator comes in handy. The auto type inference helps us write less verbose code.

In addition to auto, the C++0x standard introduces a new keyword, called decltype (think of it as ‘typeof’), that can be used to determine the type of an expression at compile time.

However, this new keyword was not yet introduced in Visual Studio 2010 CTP. According to Stephan T. Lavavej from the VC++ team, it might be possible to be introduced in a next CTP or beta version.

Implementing auto doesn’t implement decltype (C++0x’s name for what was previously called typeof) for free.

Paraphrasing our libraries and compiler front-end program manager Damien Watkins, the CTP is only the first look at our VC10 functionality and there is definitely more to come. We understand that certain features “go together”, and that adding complementary features is a good thing in general. As always, customer feedback is a vital resource in forming our plans.

, , , , , , , , Hits for this post: 58184 .

The Oxford meeting of the ISO C++ standards committee between 15-20 April resulted in new features beeing into the draft paper of the C++0x standard.

One of the features refer to Unicode support: a new header, called <cuchar>, was introduced. This header makes available new built-in types char16_t and char32_t, as well as new prefixes u and U to designate UTF-16 and UTF-32 encoded characters and strings.

A list of all papers submited before the Oxford meeting can be found here.

More about the results of the Oxford meeting can be found in:

, , , Hits for this post: 17748 .