What's New in Visual C++ 8.0

First I would like to apolgize for my silence over the last few months - I really have been heads down trying to finish off the compiler for the next release of Visual C++. Finally we are starting to see the light at the end of the tunnel and so I can relax a bit and find the time to share with you some of the up coming features in the next release of Visual C++.

I know that Brandon has been doing a great job talking about the new features of C++/CLI so I thought I would focus on some of the changes we have been making outside of the C++/CLI space. I'm going to focus on changes we have made to the native C++ compiler - both features we have added and bugs we have fixed.

Access to Friend Functions:

One of our many observant users discovered that the compiler was allowing code like the following:

class A {
void mf();
};

class B {
friend void A::mf();
};

According to the C++ Standard this is illegal because in order for B to make A::mf() a friend it needs to be have access to A::mf() and in this case it doesn't as A::mf() is a private member function. Now this particular example mightn't look that "dangerous" and you probably could argue that there is no harm in allow B to have access to A::mf() but the following example show a less clear cut case:

class A {
class N {
};

void mf(N*);
};

class B {
friend void A::mf(A::N*);
};

Now if the compiler allowed B access to A::mf(A::N*) it would also need to allow B access to the nested private type A::N this is probably more than most users would want as the author of A has probably had a good reason for making N private. So the best (and simplest) rule is that if want to make a member function of another class a friend of your class then you need to have access to the member function.

There are several ways to get around this problem: the easiest is to make B a friend of A instead of just A::mf. Another possibility is to change the access of A::mf to public - though this is a more invasive change and it may not be possible in all cases as the author of B may not have access to the definition of A.

Using '>>' To Terminate Template Arguments

How many of you have ever written code like the following in C++?

std::list<std::vector<string>> strings;

Only for the compiler to tell you that a template argument list must be terminated with a '>' and not a '>>' have you then shouted "Stupid compiler! Why can't you treat '>>' as '>' '>'?". Well the C++ Committee has listen to your complaints about this and they have decided to allow '>>' to terminate nested template argument lists. This change to the C++ language will be in the next version of the Standard (which is expected towards the end of this decade) but th Visual C++ team decided that this was such a small change to compiler and would help novice C++ programmers that we decided to include this change in the next version of the compiler.

The one downside of this change is that it does break some existing currently valid C++ code. The code in question is stuff like the following:

template<int value>
class X {
};

X<0xffff >> 2> x;

With the proposed change to the C++ language the compiler will interprest this as:

X < 0xffff > > 2 > x;

The fix is to wrap the right-shift expression in parenthesis:

X<(0xffff >> 2)> x;

I think most users will agree that breaking code like this is a small price to pay in order to be able to use '>>' to terminate template argument lists.