Marius Bancila’s Blog

Visual Studio 11 brings many new things for native development, including support for new features from C++11 (unfortunately not all), or ability to write Metro apps with C++/CX including modeling the UI with XAML. In this post I will talk a bit about three favorite features that I noticed immediately after trying VS11 from Windows 8 Developer Preview.

Use of namespaces
Finally, I see namespaces promoted in native code. Yes, it’s C++/CX and they were probably forced to use namespaces for a consistent experience from the various languages that target the Windows Runtime, but it’s a very nice change to the default templates for C++ projects where everything is put in the global namespace. I can only hope they will improve that in this version or the next for standard C++ applications (whether Win32 console apps or MFC apps).

namespace Sample
{
    public ref class MainPage
    {
        public:
            MainPage();
            ~MainPage();
    };
}

UPDATE: looks like I wasn’t clear enough, I’m not saying namespaces is a new C++ feature (duh), I’m saying Visual Studio templates for C++ don’t promote that. Create a Win32 project, an MFC project, and ATL project, there are no namespaces. You’d have to code everything manually, but if you do it, you mess the wizards. So, what I’m saying is that I hope we can see namespaces promoted for other project and item templates too.

Partial classes
I already wrote about partial classes, but I want to reiterate this feature. Partial classes gives you the ability to define a class in several files. This is great because developers and code generator tools such as designers can edit different parts of the same class without interfering one with the other. This feature made it possible for supporting XAML user interfaces in C++/CX Metro applications.

I’m actually wondering why isn’t this already part of standard C++ and I can only wish that the next version (which hopefully will not take another decade to conclude) will include this feature.

Better Syntax Highlighting
Below is a comparison for the same piece of code highlighted by Visual Studio 2010 on the left, and Visual Studio.vNext (11) on the right.

There is hardly any formatting in VS10. However, on the other hand, the highlighting in VS11 is beautiful. User defined types (including library types) are displayed with another color than the built-in types (such as int), including in their definition. STL types (string, vector, etc.) are finally identified as types and displayed with the appropriate color. Also the name of parameters is displayed in italics which makes them easily identifiable. There are other things about the highlighting, but these striking changes.

It is often that I see people using namespace directives in header files. This is a bad practice maybe not enought explained, so I will try to clarify why one should always avoid this.

When you are using a using directive (such as using namespace std) or using declarations (such as using std::cout) you are bringing into the current namespace (either the global one or a named one) all the entities from the specified namespace (in the case of a using directive) or the entities specified with using declarations. Header files are meant to be included in sources files (usually more that just one source file) and the order of the include statements is most likely different.
If entities (types, functions, constants, etc.) with coliding names are brought into the same translation unit (source file) via different header files then the compiler will trigger errors due to ambiguities.

The following example will demonstrate this aspect. Suppose that you have an own list implementation in a file called mylist.h.

#pragma once 

namespace mycontainers
{
   class list
   {

   };
}

and you make use of this container in a class called foo, but in the header you are using a namespace directive to avoid writing the fully qualified name for list.

#pragma once
#include "mylist.h"

using namespace mycontainers;

class foo
{
   list mylist_;
};

However, a second class, called bar, is using the STL list, and also using a namespace directive.

#pragma once
#include < list >

using namespace std;

class bar
{
   list< int > mylist_;
};

All good as long as you use foo and bar separatelly. But the moment you need to include them both in the same source file (maybe directly, maybe via another headers) errors arise.

#include "foo.h"
#include "bar.h"

int main()
{
   foo f;

   return 0;
}

Here are the errors:

1>d:mariusvc++win32_testbar.h(9) : error C2872: 'list' : ambiguous symbol
1>        could be 'c:program filesmicrosoft visual studio 9.0vcincludelist(95) : std::list'
1>        or       'd:mariusvc++win32_testmylist.h(6) : mycontainers::list'
1>d:mariusvc++win32_testbar.h(9) : error C2872: 'list' : ambiguous symbol
1>        could be 'c:program filesmicrosoft visual studio 9.0vcincludelist(95) : std::list'
1>        or       'd:mariusvc++win32_testmylist.h(6) : mycontainers::list'

Of course, if you switch the order of #includes in you get another error:

1>d:mariusvc++win32_testfoo.h(8) : error C2872: 'list' : ambiguous symbol
1>        could be 'd:mariusvc++win32_testmylist.h(6) : mycontainers::list'
1>        or       'c:program filesmicrosoft visual studio 9.0vcincludelist(95) : std::list'

A second, more hard to spot error is explained by Sutter and Alexandrescu in C++ Coding Standards – 101 Rules, Guidelines, and Best Practices.
When you make use of a using declaration (using std::list), a snapshot of the used entity is taken. All later references to this entity are based on this snapshot. They provide the following example:

// sample 1
namespace A
{
   int f(double);
}

// sample 2
namespace B
{
   using A::f;
   void g();
}

// sample 3
namespace A
{
   int f(int);
}

// sample 4
void B::g()
{
   f(1);
}

When using A::f is encounted, a snapshot of A::f is taken from what was found so far. Only f(double) was declared already, f(int) is found only later.
So though this later overload was a better match for f(1) it would be ignored, because it wasn’t known at the time of the using declaration.

This issue complicates more if each of the first 3 samples were in different files. Then the order of the $include directives in the file that contains the 4th sample would dictate which overload of f() to be used.
And if sample 4 was itself in a header, other that the first 3, the order of the includes would become even more critical.

For these reasons, you should keep in mind never to use namespace directives or declarations in a header file. Instead use the fully qualified name for the types, functions, constants, etc. that you use, and leave the using directives for the source file exclusively.