# Slow Chat Archives > Slow Chat: C++0x >  VC++ 10 impact on existing code?

## zyvxn

Are any of the new features in C++ that are going to be in VC++ 10 going to negatively impact existing programs?

----------


## Damien Watkins

Hello  

So I guess it depends on what you mean by negatively impact. If you look at the repurposing of auto then clearly yes, valid existing code may now break:

auto int i = 0; // now illegal in C++0x

So far we have not seen any real issues with this anyhow. The CTP has a switch to maintain the old semantics too. 

The Lambda syntax looks like the MS attributes syntax and Jonathan had to do a lot of work to check that we parsed them correctly, but users should not see an issue.

Our other additions do not use existing syntax, so I think we are mostly fine  but this is the whole point of having a CTP, so you can try it out with your codebase and verify this. Also we would expect to have bug or two, the earlier we find them the better too.

Of course, adding new functionality may make the compiler itself either a little bigger or possibly a little slower (if it has more options to check with new functionality/keywords) but we have seen nothing significant here  again let us know your experience with the CTP

Thanks
Damien

----------


## TheCPUWizard

Asside from the "required" breaking changes (e.g. auto keyword repurposing) are there ANY features from VS-2008 (especially invluding SP1) that are not in the CTP?

If there are any (probably due to overlap in the releases) will they all be resolved by Relase?

----------


## joncaves

There is one change that fell out of the implementaion of rvalue references that has broken some code bases internally. It is code like the following:



```
struct S
{
	S();
	explicit S(const S&);
};

void f(S);

int main()
{
	S s;

	f(s);
}
```

This code compiles with Visual C++ 2008 SP1 (and with previous compilers) but it is, correctly, rejected by Dev10. If you make the default copy-constructor of a class 'explicit' you are saying that you can't pass an instance of the class to a function. The "fix" in every case we have seen so far is to remove the 'explicit' keyword from the default copy-constructor - it was usually added as a result of over enthusiasm.

----------


## TheCPUWizard

That is actually GREAT news. Putting the explicit on a copy consstuctor SHOULD prevent passing arguments by value. It has long annoied me that this was not detected.

----------


## laserlight

> This code compiles with Visual C++ 2008 SP1 (and with previous compilers) but it is, correctly, rejected by Dev10. If you make the default copy-constructor of a class 'explicit' you are saying that you can't pass an instance of the class to a function. The "fix" in every case we have seen so far is to remove the 'explicit' keyword from the default copy-constructor - it was usually added as a result of over enthusiasm.


Ah, but this is just a bug fix rather than due to a C++0x clarification of semantics, right?

----------


## Russco

> There is one change that fell out of the implementaion of rvalue references that has broken some code bases internally. It is code like the following:
> 
> 
> 
> ```
> struct S
> {
>     S();
>     explicit S(const S&);
> ...


Learnt something new. I never understood why people make copy constructors explicit because as far as I knew it only prevented assignment-looking calls to the copy constructor.

ie.

classname a;
classname b(a); // is ok if copy constructor is explicit
classname c = a; // fails if classname has explicit copy constructor.

I suppose thinking about it passing by value would be an implicit call and not an explicit call.

Is there ever a good reason to make copy constructors explicit?
Personally i have only used explicit constructors for single argument or multiargument constructors where all but one argument has a default value.

While talking about explicit, is it so hard to implement explicit conversion operators which is something I felt c++ needed for years?

----------


## STL_MSFT

Our library changes (not present in the CTP) will break some nonconformant programs. One popular example, occurring throughout VS's own codebase, is people using back_inserter() without including <iterator>. We changed our header dependencies (the Standard headers include each other in unspecified ways), and now <iterator> isn't dragged into some translation units where it was before.

Obviously, we're trying with all our might to avoid breaking conformant programs.  But we depend on CTP and Beta feedback to identify as many occurrences of this as possible - as large as our test matrix and internal codebase are, they're dwarfed by our users' codebases.

----------


## TheCPUWizard

Actually that is a welcome (sort-of) breaking change. Anything that reduces dependancies is good  :Thumb: 

A few years ago I wrote a fairly decent analizer for C++ #include hierarchies, making sure that the structure was minimal (don;t include things that are NOT needed), yet complete (including a single header will always compile). Saved lots of time over the lifecycle of the program.

----------


## Damien Watkins

Hello

Probably a little off-topic for this posting, but on re-reading I thought I should also mention the move to MS Build as the build system in VC2010 (this is a change but is not a language/libraries change and most importantly this should not be a breaking change.) Marian has a great post on this if you want more information: http://blogs.msdn.com/vcblog/archive...msbuild-n.aspx. 

Thanks
Damien

----------


## Lindley

Hmm. I notice that mentions building multiple projects in parallel. Hopefully someone's fixed the (annoying but not actually damaging) issue where one build complains that it can't open the build log file because another build is using it.

----------


## amohindra

Hi,

This should be fixed as part of the new project system. Earlier developers could run into this if two projects resided in the same folder and were writing to the same log file accidently ($(IntDir)\BuildLog.htm).

In the new project system the build log file names will be patterned to be unique based on the name of the project thus correcting this behavior.

Thanks,

Amit Mohindra
Visual C++ Team

----------

