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.


Comments (0)

Skip to main content