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

Visual Studio 2012 introduced a new framework for writing debugger visualizers for C++ types that replaced the old autoexp.dat file. The new framework offers xml syntax, better diagnostics, versioning and multiple file support.

Visualizers are defined in XML files with extension .natvis. These visualizers are loaded each time the debugger starts. That means if you make a change to visualizers, it is not necessary to re-start Visual Studio, just re-start the debugger (for instance detach and re-attach the debugger to the process you debug).

These files can be located under one of these locations:

  • %VSINSTALLDIR%\Common7\Packages\Debugger\Visualizers (requires admin access)
  • %USERPROFILE%\My Documents\Visual Studio 2012\Visualizers\
  • VS extension folders

In Visual Studio “14” CTP (in response to a UserVoice request) these files can also be added to a Visual C++ project for easier management and source control integration. All you have to do is add the .natvis file to your .vcxproj file.

Here is an example. Suppose we have the following code:

If you run this in debugger you can inspect the value of p and it looks like this:

To change the way the point objects are visualized create a file called point.natvis with the following content:

Add this file to the project.
When you run the application in debugger again the point object is visualized according to the per-project .natvis file.

There are two things to note:

  • changes in the natvis files are now picked up automatically by the debugger; you no longer need to stop the debugging session and then start again if you make changes to a natvis file
  • natvis files from the project are evaluated after all the other files from the other possible locations; that means you can override existing (general) visualizers with project-specific visualizers

For more see Project Support for Natvis.

, , , , , Hits for this post: 35707 .

If you tried the Win8 Developer Preview and built WinRT components (native or managed) you noticed the .winmd files. The name stands for Windows Meta Data and the format of these files is the same used by the .NET framework for the CLI, i.e. ECMA-335. That means you can actually read these files with a tool such as ILDASM or Reflector, or of course, through .NET Reflection.

If you look in C:\Windows\System32\WinMetadata folder you’ll find the WinMD files for the Windows Runtime. You can browse the content of these files with one of the aforementioned disassemblers.

Here are two dummy WinRT components, one developed in C++/CX and one in C#.

Native WinRT component in C++/CX Managed WinRT component in C#

In the case of the native component, the output includes a DLL and a WINMD file (and of course a PDB file). In the case of the managed component, the output is either a DLL only or a WINMD only (plus the associated PDB file), depending on the Output type as defined in the project properties. If the type is Class Library the output is a DLL; this is enough if your component is supposed to be consumed from a managed language. However, if the component should be consumed from C++/CX or Javascript, then the project type must be set to WinMD File. In this case the DLL is replaced by a WinMD file, that contains, at least in the current version, both the matadata (as implied by the name) and the implementation.

Native WinRT component in C++/CX Managed WinRT component in C#

It should be possible to use reflection with winmd files. However, the reflection capabilities of .NET 4.5 in this developer preview seem to be very limited. The only available Load method in the Assembly class is

Trying to load the winmd file fails with a FailLoadException with the message “Could not load file or assembly ‘Winmdreflection, ContentType=WindowsRuntime’ or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)”.

It is possible though to read information for the types described in an winmd file in native code using the IMetaDataImport/IMetaDataImport2 COM interfaces. You can find an example here. But this has the drawback that you have to instantiate an object first and then query for its type information.

To use a Windows Runtime component in a Metro application (managed or native) you have to add a reference to it. That is pretty straight forward. In the following example I’m adding a reference in a C++ Metro application to the two WinRT components, one native and one managed, shown earlier. To do this, you can go to the project’s property page and open the Common Properties > Frameworks and References page, or use the References command from the project’s context menu which opens that page directly. You can add a reference to a project from the same solution, to a Windows component or you can browse for the winmd file.

Having done that you can instantiate the WinRT components.

, , , , , , , Hits for this post: 94659 .

Not long ago I ran into a COM interop problem that was a bit tricky to fix. So I’m sharing the problem and the solution here in case others encounter the same problem.

I had this native in-proc COM server that initially was built only for x86. It was used in a native MFC application as well as a C# Windows Forms application, where it was added as a COM reference. Both worked nicely. But then I needed to port the MFC app to the x64 platform, so I had to do the same with the in-proc COM server. They both worked correctly, but the managed app, which had to be available also both as 64-bit and 32-bit (even on 64-bit machines), was broken. Eventually I traced the problem to some COM method calls which were a bit atypical, because the arguments to the methods were not COM “native” types, but custom structures.

These structures looked like this:

and the COM method signature:

When you add a COM reference to a .NET assembly, Visual Studio runs tlbimp.exe to generate a .NET assembly with equivalent definitions to the type definitions found in the COM type library. This interop assembly is used to access the COM server. It contains Runtime Callable Wrappers that bridge the two worlds together. By default, the interop assembly, generated in the project’s output folder, is called Interop.<comname>Lib.dll. For instance if the COM server is called NativeCOMServer, the interop assembly is called Interop.NativeCOMServerLib.dll.

The wrapper that was generated in the interop assembly had the following signature for the aforementioned method:

and therefore used like this:

The call was performed correctly, the native code was executing, but as soon as it was returning an access violation exception was occurring. Thanks to Hans Passant I figured the problem was rooted in the way Visual Studio generates the interop assembly. The generated RCW didn’t know how to handle the custom structure correctly. Probably different padding on the two sides generated the access violation.

The trick was to generate the interop assembly directly, as a custom build step in the COM server project, and include it as an assembly reference in the managed project. Here are the commands for the custom build (must to make sure you have the correct path to the 32-bit and the 64-bit version of tlbimp.exe):

The result was a wrapper with methods like this:

which of course had to be called like this:

To include either one or the other in the C# project I had to manually change the project file, since Visual Studio does not know conditional references, a feature available in MSBuild. I didn’t build the managed app for Any CPU because it had to be able to run as 32-bit on 64-bit machines, so I had two configurations, one for x86 and one fore x64.

But this time the wrappers were able to bridge the call and everything worked smoothly.

The lesson learned is that when you have COM custom structures you should not rely on the way Visual Studio generates the interop assembly. You should build the interop explicitly (maybe as a custom build step, like I did) and include it as an assembly reference to your managed project.

, , , , , , Hits for this post: 55159 .