On 30.05.10 19:51, Christian Froeschlin wrote:
> this is certainly true. However, as far as I understand VS 2010
> includes only that subset of C++0x which is deemed to be stable
> and which will likely be present in other future C++ compilers.
> Despite all reasoning to the contrary, MS folks are not
> completely stupid. They will have picked carefully.

If this only was true :-(  For a long time, the M$ person on the ISO C++ 
committee tried to force the "concept" feature into the standard, 
subsequently leading to the two year delay when this unfinished idea had to 
be pulled because national bodies would not have such a broken incomplete 
idea in an international standard.

For what I see with other vendors, they simply pick the low hanging fruit 
concerning C++ 2011 features - namely, they introduce library changes.

> One of the purposes of drafts and beta versions is to give
> developers time to prepare for changes so an incompatibility won't
> hit them out of the blue. It would be rather unwise to knowingly
> release 3.7 with such an incompatibility.

There is no such incompatibility. It is as simple as turning the features 
off in the compiler. In fact, this is not much different to any other 
previous C standard update. As you might now, a lot of C compilers also 
support disabling C99 features.

> I'm not arguing against using namespace statements here, but at
> least the known almost certainly soon-to-be name conflicts should
> use fully qualified names even if the assessement is based on a
> draft. Otherwise you get "academic code quality" ;)

As said, there is no problem as long as new experimental compiler features 
are not enabled. There are actually C++ macros that return the version that 
is being compiled against. I would argue that it might be a good idea to 
check this version and refuse to preprocess if the required version is not set.

The more interesting question is the following though: Why does the problem 
appear at all? The answer is equally simple: Some header file pulls in the 
non-standard shared pointer class.

I would provide you with details, but the MSDn support pages are not the 
most Safari on Mac friendly (besides being even messier than before). You 
can find the starting link around here: 
<http://msdn.microsoft.com/en-us/library/ct1as7hw(v=VS.100).aspx>

	Thorsten

Post a reply to this message