We are very excited to announce the release of Visual Studio 2010’s Release Candidate. The official announcement can be found on Soma’s blog. You can download the RC from this location and it includes a go-live license for people who want to deploy in their production environment. This release incorporates many Customer Connect bug fixes and includes significant performance improvements. Just like Beta2 you can log Customer Connect bugs for this release. Here you can find a list along with descriptions of what is new in Visual Studio 2010. We are excited to see your feedback and answer your questions.
Thank you,
Kelly Evans
Visual C++ Team
I love coding C++ D3D11 applications in VS2010. Lambdas and the templates in the algorithms header go great together.
When would VC++ 2010 express edition RC would be released?
Congratulations! When will Express Edition be released?
Hi, I read the release launch date is set to April 12th 2010, but how about general availability/RTM date?
Thanks!
Sorry for capturing this reply, but my question is burning holes into things 😉
Is there any reason why ATL and CString use different CString implementations?
With the CString revamp after VC6 I was very much hoping that they would be "united". Currently, this means for us that we have separate ATL and MFC builds for many libraries.
It would be interestign to know the reasons for this separation.
@ Jagannath and Limal: We will not be releasing the Express SKU’s for the RC. It will be available at launch.
@ Marc: Product will be available at launch.
Thank you,
Kelly Evans
Visual C++ Team
Has the VC++ directories dialog been moved back into global options yet? It is the most glaring omission in the betas.
If not, will it ever be?
The moving of the global project directories from an easily accessible place is a HUGE problem for any shared team environment. It is impossible to ensure that all developers have the exact same SDKs installed in the exact same paths and since these are now part of the project files it now means that project files cannot be shared across developers. For us this is basically a show-stopper for all use of 2010 which is a huge shame.
Ashira and Andrew, the old functionality is still in place, there just isn’t an obvious UI for it. See http://blogs.msdn.com/vcblog/archive/2009/10/22/visual-studio-2010-beta-2-is-now-available-for-download.aspx#9913959
Not sure where to post this, so here goes.
I just built my project with the RC, and there are some differences in std::string::operator[]. In previous versions, operator[](size_type _Off) performed this check for validation:
if (this->_Mysize < _Off)
_DEBUG_ERROR….
Now it performs this check:
if (this->_Mysize <= _Off)
_DEBUG_ERROR….
This means you can’t index off the end of the string where the null-character is (e.g. mystring[mystring.size()]). This is admittedly a bad thing to do, but we have some code that relies on it, as it was originally coded for C-strings.
Interestingly, the const version of std::string::operator[] still has the old check, and I can "fix" my broken code by using const strings, instead of non-const.
I’m curious why this decision was made (both to change the non-const behavior and to introduce the discrepancy in behavior between const and non-const versions).
@peterchen: MFC uses the ATL CString class (see afxstr.h) and has done so since Visual Studio.NET, as far as I can tell.
Pat Brenner
Visual C++ Libraries Development
[Ben]
> I’m curious why this decision was made (both to change the non-const behavior and to introduce the discrepancy in behavior between const and non-const versions).
Our debug checks are intended to enforce the Standard’s requirements to the greatest extent possible. During VC10’s development, we discovered that string::op[]() contained insufficiently strict debug checks, so we tightened them up.
The Standard prohibits access to the null terminator for modifiable strings and references, but allows access for const strings and references. The Standardese is C++03 21.3.4 [lib.string.access]/1:
"const_reference operator[](size_type pos) const;
reference operator[](size_type pos);
Returns: If pos < size(), returns data()[pos]. Otherwise, if pos == size(), the const version returns charT(). Otherwise, the behavior is undefined."
Stephan T. Lavavej, Visual C++ Libraries Developer
>>Ashira and Andrew, the old functionality is still in place, there just isn’t an obvious UI for it.
Yes, we know it still exists, but it’s a PITA to access it. I really want to see this back where it was before.
For some, per-project configurations are better–but you’ve added those, haven’t you?–and for some, the old global settings is better. Like for me, for instance.
Killing this UI is the biggest VS-killer of this version. I am sadly thinking of staying away from it because of this.
I know I complained about this before…
The UI is still there for setting directories globally; going into the property manager is just as easy as going into VS options, it just isn’t as intuitive. I certainly wouldn’t consider a different UI for the same functionality a "VS-killer".
@Ashira and Andrew Cross: It’s not so hard to access the global settings: Open the Property Manager (View menu -> Other Windows -> Property Manager), then simply doubleclick on the Microsoft.Cpp.Win32.user property sheet. In there, set the global paths to whatever you like.
A more convenient shortcut to opening this property sheet would be handy (for example so it can be opened without having a C++ solution open), but it’s hardly "A PITA to access". It takes a few clicks more than before, but since it’s effectively a global setting you might modify *once*, I think it’s tolerable.
Not only a few more clicks, but the property sheets, if I am not mistaken, are horrible, as well. Having to enter paths manually and separate them with semicolons is hardly user friendly.
Why can’t you just let the global paths option be, as it was in VS2008 and before? You are not obligated to use it in any way.
And despite what you may think, it’s certainly a killer, in sense that it makes the IDE so much more annoying to use properly. I will pass on the RC and wait for the final version and I can only HOPE that Microsoft restores this as it was before.
I don’t mind the new place to setup directories, the average person trying to compile my code out of source control could not find the old one either. However, RC still escapes some characters like ( ) to %hex codes.
@Pat Brenner (MSFT): But there are still two different implementations. One "light" version if you don’t use MFC and the regular if you do.
@Ashira: Sometimes it pays to actually *look at* the feature you’re complaining about before you complain.
If you’d done so, you’d have seen that the UI is actually *the same* as it used to be. You open the property manager, click on the property sheet, select VC++ directories, and enter the paths *exactly as you used to*. Not semicolon-separated, just one path per line. And you have the same "browse" button too, for finding navigating to the folder instead of typing it in.
The UI is the same as it used to be. It’s just found by doubleclicking on a property sheet instead of entering the Options dialog.
So no, I don’t think it’s a "certainly a killer". They’ve given us the best of both worlds, the flexibility of property sheets, and the UI we used to have for editing the paths.
The only complaint I have is that it’d be nice to have a more accessible shortcut to editing this property sheet — it seems silly that I have to load a solution before I can edit settings shared by all new projects. But that is pretty minor, and far from being "a killer".
type
decltype(*this)
and compile, then compiler crash
Concerning property sheets: they are very useful and I’ve been using them in 2008, but the UI for setting them up is pretty terrible– it would be nice if it were possible to easily copy the property sheet inheritance from one project to another. Basically every time I add a project to my solution I have to then manually go and add 6 property sheets(3 build settings * 2x property sheets per setting). Very very tedious.
Concerning linking in VS 2010 RC– is anyone else having trouble getting automatic linking of static projects to work? I’ve done this dozens of times in VS2008 without trouble, but in RC linking never seems to work unless I manually add the lib into the additional dependencies(tried all the linker settings– nothing helps).
Is there some new secret to how this works in VS 2010?
@shaz
Yes, I get exactly the same problem – I have to manually add references now. Don’t know if it’s by design or a bug though.
Hi. I have a question: Why did you (in vs2010 beta and in msdn documentation) resigned from side-by-side installation of redistributables and went back to 90’s dll hell?
Does that mean that microsoft is slowly retracting from the idea of WinSxS?
Best Regards.
jalf:
In the beta, so far as I understood, the only way was the property sheets which were terrible. And that is exactly why I asked if it had been fixed.
I’m not about to download this big download and wait 5 hours for it to install just to check whether it has been fixed.
For that matter–I don’t know if it’s been fixed now, but anyway–uninstalling the 2010 beta while having 2008 installed corrupts the 2008 installation, NOT something I want!
ryouj888: thank you for the bug report. If you’d like, you can file this report on Connect and have tracking information about it. At this point, it is unlikely that we will be fixing this for VS2010. Here is a workaround:
struct C{
void foo(){
decltype(this) pc;
decltype(*pc) c = C();
}
};
Thanks!
@Ashira: I uninstalled VS 2010 beta on two machines where VS2008 SP1 is installed as well. No problems with VS2008 after uninstalling the beta.
@jalf, regarding editing the property sheets controling VC++ directories, these property sheets are located at $(USERPROFILE)appdatalocalmicrosoftmsbuildv4.0 directory. You can manually edit them without launching IDE.
Yes, I agree some kind of shortcut to directly edit these files is a good idea.
Li Shao, Project and Build Team
@Gabest: I will look further into the CString implementations to see if there is more merging that we can do in a future release.
Pat Brenner
Visual C++ Libraries Development
@shaz
For the property sheets, you could consolidate into one property sheet per build setting in to reduce the amount of clicks. Another way is to edit the project via editor and copy and paste the set of property sheets. All the property sheet data should be grouped up with a Label="PropertySheets".
Reference to a static lib project should automatically added the .lib to link. Could you open a connect issue so we can look at it?
@shaz, like Felix mentioned, please make sure you have project to project reference for the static lib project. You can take a look of this forum post: http://social.msdn.microsoft.com/Forums/en-US/vcprerelease/thread/3bb7fe8d-42d8-4a54-aa75-5ae523d5868b.
If the static lib is an IJW project, we do have a known bug that you have to manually add the lib explicitly as additional dependencies and this is not likely to be fixed for the final release.
Li Shao, Project and Build Team
@Li Shao – thank you, setting it up with project to project references instead of project dependencies fixed it
I’ve converted a smallish C++ project (~45000 lines) to VS2010’s format and the project makes moderate use of Boost.
IntelliSense takes about 15 seconds to populate on a simple this-> within a class.
Caveats: I don’t have a similarly sized project without the use of Boost to test with, nor do I have other hardware to test with. It might just be that my hardware is on its way out (I’ve seen lots of hard drive-related errors and the like).
It works perfectly snappy for even smaller projects that I’ve tested with, and I can’t imagine that you didn’t test use cases with Boost, so I’m assuming that my computer is simply garbage. Still worth mentioning if it leads to any performance increases.
The product is looking extremely solid otherwise. You guys and gals have done some great work.
Bill, I had the same experience with Beta2, just including spirit.qi 2.1 into a project crippled intellisense, which wouldn’t be so bad except that the entire editor hangs. Back to Visual Assist X, again. :-/
@Adam, can you please try your scenario with the RC? we definitely don’t want to cause editor hangs!
Why no snippet support for C++????
Why no class diagram editing support for C++????
As far as I can see, VS2010 is NOT the new VC6. It sucks!!! It is as same as VS2005 & VS2008
Hi Bill,
15 seconds is bad on simple MemberList operation. We’ve been testing with Boost 1.40 and we did find bugs. Most of those are fixed in current VS2010 RTM build. You might not have enabled PCH usage for the project? Can you check? If PCH enabled, can you please make sure you’re references to Boost headers are within PCH borders, i.e. no #include statements after #include "stdafx.h" etc.
Thanks,
Ulzii Luvsanbat
Windows C++ Team
Oh BTW does VS2010 fix the slow incremental links and slow multi-project builds? If it doesn’t, don’t bother releasing it.
When are you guys going to fix Visual Studio? Ever since VC++ 6.0 this product has been going backwards. Multi-project builds are painfully slow. At least with VS2003 we could use Fast Solution Build to get around your horribly slow linker. FSB was never released for VS2005/VS2008, so we just ignored them. But now Windows 7 doesn’t work with VS2003, so we have to upgrade. But really in ten years what have you guys done? Nothing. You add all sorts of crap none of us care about. All we want is a fast C++ compiler that works? Try googling (sorry, "binging") for "Visual Studio 2003" and "Windows 7" and you’ll see why the world hates Microsoft so much. Just fix this damned wretched compiler that we’re all stuck with.
PS. Telling us to run VS2003 under Virtual PC is a crock.
PPS. If we could upgrade to VS2008, we could, but we’d rather have a fast compiler. Hell! If you can’t fix that I’m going back to XP. Anything better than growing old and gray waiting for your lardass compiler to shuffle its fat ass.
> Very Depressed
It should be possible to use the MsBuild-system in VS2010 to launch the VS2003 compiler.
So you will use the VS2010 IDE but the VS2003 compiler. See this guide for how VS2010 supports this:
http://blogs.msdn.com/vcblog/archive/2009/12/08/c-native-multi-targeting.aspx
Btw. VS2010 is just as slow as VS2005/VS2008 when it comes to compiling and linking.
The IDE sure has gotten slower and fatter over the years. The beta was horrible in performance. Are we ever going to see a slimmer, faster IDE?
It seems that all products Microsoft do and full of bugs, bloat and performance issues.
In all previous versions of Visual Studio it’s been possible to place the exe in a different directory than the other output files (.pdb, .obj etc), but now I’m getting a warning:
warning MSB8012: TargetPath(F:FrameworkTest4ReleaseFrameworkTest4.exe) does not match the Linker’s OutputFile property value (F:FrameworkTest4FrameworkTest4.exe). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).
I have managed to get things to work by also modifying the Debugging Command to match where I put my exe. So now it’s mostly just an annoying warning on every compile.
Of course, that’s until I saw this Code Analysis thing and wanted to give that a shot, which promptly gave me this error:
MSBUILD : error : CA0055 : * Could not load file: ‘F:FrameworkTest4ReleaseFrameworkTest4.exe’.
Of course that’s not where the exe is, or is supposed to be. I don’t understand why this change has been made. It was good the way it was, now it seems I am forced to put the debug output in a specific directory for everything to work, so why even have an option to change it? Is there some way to resolve this issue, or is there an explanation of why this has changed was made, or do I simply misunderstand some new concept in the 2010?
Hello Ashira,
That’s a fair comment. The IDE has gotten "fatter" full of new features over the years, and unfortunately Beta2 was a good example of its impact on performance and heavy memory usage.
However, I think you’ll be pleasantly surprised how much perf and memory improvements we’ve done in VS2010 RTM after Beta2. I cannot quantify the improvements, but our entire focus post Beta2 was on perf and memory usage of VS. So, yes, answer to your question is, it won’t be as much slimmer, but it will be much faster.
Thanks,
Ulzii Luvsanbat
Windows C++ Team
@Rolf Kristensen (Cool site BTW) and @Very Depressed
We hear you on the throughput issues We have made some improvements in VS2010 to help compile and link times. We have done some work on speeding up LTCG (something that we recommend you use) compilation by about ~30% in our test scenarios. PGO PGI run times have also improved. We have also done work on multi-threading the linker by offloading the pdb writing task. There have been other CQ or code performance speedups across the board.
Specifically, look at Ten’s blog post: http://blogs.msdn.com/vcblog/archive/2009/11/02/visual-c-code-generation-in-visual-studio-2010.aspx, Chandler’s post: http://blogs.msdn.com/vcblog/archive/2009/09/10/linker-throughput.aspx and Lin’s post on LTCG and PGO improvements: http://blogs.msdn.com/vcblog/archive/2009/12/01/gl-and-pgo.aspx
If you are not seeing speedups in your projects please let us know through the blog here or through Connect. We’d like to dive deeper into your scenario and see if there are improvements that we could do on our side.
Thanks,
Vikas.
VC++ Team
@Emil Persson: This warning was introduced to workaround a limitation that we have when converting applications from previous version of Visual Studio.
As you may know, Link.OutputFile is the value defined at Linker -> General -> Output File on the property page. By default, its value is $(OutDir)$(TargetName)$(TargetExt), which is the same as $(TargetPath). When we convert application from previous versions, however, it is pretty hard for us to parse Link.OutputFile to figure out what exactly are the the values for $(TargetName) and $(TargetExt),as different customers may format them in different ways. To work around that, we have decided to have conversion preserve the value of Linker.OutputFile. $(TargetName) will be default to $(ProjectName). $(TargetExt) will be default to the default extension for the application type: .dll for Dynamic Library, .lib for Static Library and .exe for Application. Warning MSB8012 will be issued if Link.OutputFile and $(TargetPath) are not the same in the conversion log. You will get the same warnings when building the application.
$(OutDir), $(TargetPath) and $(TargetExt) are exposed on the "General" property page, as "Output Directory", "Target Name", "Target Extension", respectively. You can manually change the values of these properties so that you no longer get the warning.
In your particular case, it looks like your $(OutDir) is F:FrameworkTest4 instead of F:FrameworkTest4Release, you can change the "Output Directory" value to "F:FrameworkTest4" and that should eliminate the warning. It should take care of the issue you are seeing with lauching exe as now the value of $(TargetPath), which corresponding to $(OutDir)$(TargetName)$(TargetExt) is ‘F:FrameworkTest4FrameworkTest4.exe’
Li Shao, Project and Build Team
Thanks Li, the solution was easier than I thought. 🙂
So I’ll give you a harder problem then. 😉 I just yesterday found an issue with the machine code generated by the compiler in certain situations. See my blog post here:
http://www.humus.name/index.php?page=News&ID=299
This is not specific to VS 2010, I saw the same problem in VS 2008. I could provide a sample project if you guys need.
Thank you Emil for reporting the issue. Could you open a connect bug for this. You can submit connect bugs through here: http://connect.microsoft.com/VisualStudio/content/content.aspx?ContentID=12362
Li Shao, Project and Build Team
Hi, you did a great work!
But I have one small suggestion, could you make a summary table like this http://gcc.gnu.org/gcc-4.5/cxx0x_status.html. It will be very interesting to know what c++0x features exactly realized.
Best Regards.
Mr. Luvsanbat:
I do use precompiled headers for this particular solution. The source files are designed for multi-platform use and the precompiled header essentially includes many of our commonly used standard library/Boost includes.
/Yc is specified for PrecompiledHeader.h and the project is set to /Yu PrecompiledHeader.pch.
If you’re referring to the IntelliSense precompiled header specifically, I’m not quite certain how to see whether or not it’s enabled or modify those options.
I poked around with a bunch of the options, such as having rescans, not doing the rescans, disabled/enabled auto updating, and having more cached translation units (which worked fine after the initial 15 second population – until I wanted information from a class outside of the already established IntelliSense databases), etc.
Other than having more compilation units (which didn’t speed up the initial time), there wasn’t much that increased the effectiveness of the original parse.
@Igor: Thank you for your suggestion. I will talk to the relevant team and hope will have something like that for you.
Li Shao, Project and Build Team
@Igor: Thank you for your suggestion. I will talk to the relevant team and hope will have something like that for you.
Li Shao, Project and Build Team
VC++ Compiler is very slow and generates large executable. Simple Wizard-generated MFC Dialog-based dummy application took about 90 seconds to compile and generated 1700 KB executable. VC++ compiler in Visual Studio 2005 and 2008 too 20 seconds to compile and generated 300 KB executable for the same application. Why is it so?
@Shah:
The problem you are seeing is not a slow compiler. Most of the additional build time is because you are building a statically-linked MFC application.
The increased capabilities of MFC have introduced a number of additional interdependencies that end up causing more of MFC to be pulled in when linking a minimal application that links with the static MFC libraries. We are actively working on finding and eliminating these interdependencies so that the size of a minimal static-linked application will shrink, and will definitely address this in a future release.
Please note that linking against the static MFC libraries is not the default (this being one of the reasons) so I recommend that you link dynamically instead. Also note that as your MFC application grows (a minimal MFC application is probably not that interesting) the statically-linked application size differences will be less because more of MFC would be linked in anyway.
Pat Brenner
Visual C++ Libraries Development
@Bill:
When you load your solution if PCH is enabled, we’ll create intellisense pch files under "ipch" directory where your .sln file is. See if the time-stamps of the binaries inside are getting updated as you open your solutions.
I assume you’re doing GotoDef or CallHierarchy when you say "-until I wanted information from a class outside of the already established IntelliSense databases". How big is that translation unit? Can you please preprocess with /P and see how many lines of code there are? And how much of that comes from PCH? If it is really taking 15 seconds to do initial parsing on your translation unit, then increasing the number out of proc parsers "Max cached translation units" could alleviate the need to recycle your parsed states. But looks like you’ve already tried this.
Here’s what we expect with VS2010 RTM for intellisense performance:
– For a 7MB 640K lines of code (Boost+Windows headers) without using PCH, the initial parsing for intellisense is about 7-8 seconds. On 2GB RAM machine.
Thanks,
Ulzii Luvsanbat
Windows C++ Team
Mr. Luvsanbat:
The output of the /P (I threw it in the most included file in the project and consequently, the file that also has the most includes) gave me 1072905 lines over 11.5MB, so there were a lot of lines that were composed of only a carriage return/line feed pair.
A different compilation unit that has nothing to do with that larger compilation unit (not included directly or indirectly) ended up being 1059581 lines over 11.3MB.
Changing the precompiled header to include 8 fewer files that aren’t super useful, mostly Boost:
Original compilation unit: 1027151/11.2MB
Other compilation unit: 935633/9.90MB
IntelliSense population took about the same amount of time – which isn’t really surprising with such a minute decrease.
I’m not terribly concerned, my hard drive is truly on its way out. It’s running about half as quickly as it was 2 months ago by all metrics I’ve used. Thank you very much for trying to see if there was more to it. That kind of dedication to performance should not be taken lightly.
Hi! I do not found in this release of how can I work with Databases (to create the set of data and s.o.). Also I do not found the prompter, when you type, for example, this-> and just is opened the list of all elements of object. In C# and VB such possibility is.
Thanks
@pbi
You can check out http://msdn.microsoft.com/en-us/library/7wtdsdkh(VS.100).aspx for information about data access with Visual C++.
Thank you, Boris Jabes, for the answer. But in VC++ RC it doesn’t works such as in VC++ 2005. and as in C# RC.
@pbi are you using C++/CLI? If so, the Intellisense experience is degraded but we intend to rectify this after RTM (can’t be anymore specific).
Thank you, Boris Jabes. Not so,not so. If you would send to me your e-mail, I would send to you two pictures what specify my problems. Thank’s
My e-mail is
boris_pahomov@mail.ru
@ pbi the Visual C++ Language forum (http://social.msdn.microsoft.com/Forums/en-US/vcpluslanguage/threads) is the best place to post this question . Thanks!
Kelly Evans
Visual C++ Team