Somasegar's WebLog

The more that you focus your efforts on native code, the better.

Managed code is great, but 100% of my managed code development is done in C#. When transitioning to managed code, customers ask me to rewrite the code in C#. They do not want native / managed interop.

Each release of VC++ has improved compliance with the standard. However, there are a much of issues still remaining. I think these should be a high priority. The older standard should be fully implemented before implementing the currently proposed update. For starters, export is still missing. (Like it or not, it is part of the standard and it is not being removed.)

I can not speak for everyone, but in my experience, any work done to further interop will be useless to me. The more done to improve native code the better. Make the most compliant compiler on the market.

IDE Pain Points

Each version of VS

- loads more slowly

- compiles more slowly

- the IDE is more unstable

- library searches produce more irrelevant hits

- introduces more on screen clutter

Dynamic help isn't and probably never was.

Closing a file opens the branch in solution explorer. Never found the collapse all.

Would be nice if the current IDE could drive the older compiler chains.

Debugger sometimes looses selected stack frame wrt watch variables.

Remote debugging setup stupidly manual.

CRT deprecation system is broken for legacy and cross platform code.

Platform Pain Points

Concurrency/Throughput

- some interesting technologies and APIs (e.g. IOCP), but...

Portability

- the great debacle for server type apps

- older Windows and Unix platforms have severe API differences

- least common denominator or multiple implementation?

- mixed results with common open source libraries

Standards

- kudos for improvements, keep it up

- IMO, forget export, it was DOA

Top 3 requests:

- C++ 0x support - really like to this get into future VC++

- IDE Performance (browsing, opening, editing, ...) - can save a lot of time and electricity :-p

- Stardard compliance - VC++ is too tolerant for bad (old) C++ code

Larry,

We hear your concerns, especially regarding code bloat in VS and the impact it has on performance (such as load time and compile time).  We've worked hard in VS2008 to hold the line on performance and to improve it in many areas, and we'll continue to do so in the future.

In the mean time, if you have any specific performance concerns (especially for the VS2008 Beta) you're welcome to e-mail us: DevPerf@Microsoft.com.

Best Regards,

David Berg

Developer Division Performance Engineering Team

David, my post ended up more negative than I had intended. I do like the VS editor and debugger very much. But I spend quite a bit of time with it and a fewe things just end up driving you crazy.

I tried beta 1 only briefly but did run into an  issue. VS will refuse to (directly) open solution files if the previously open solution file's directory is removed. I haven't had a chance to install beta 2 yet. Is there a reason you need to register to submit bug reports?

Larry,

Thanks for the input, I'll forward it to the appropriate team.  Registration for Bug Reports is primarilly so we can follow up with the individual submitting the bug if we need more information or need help in verifying a fix.

Regards,

Dave

Larry,

Can you e-mail me details on how to reproduce the open solution issue you mentioned: David.Berg@Microsoft.com?

Thanks,

Dave

I was waiting for Orcas for one little C++ thing: a valid TR1 implementation.

It seems that I will have to wait for the release of C++0x in order to get all these nifty classes (other solution: DIY or buy a separate implementation... Well, DIY is quite fun (especially since compiler support hurts a bit), and there is not much available solutions out there).

Other than that, the C++ compiler is roughly similar to VC++ 2005 (it still accepts the same bogus code, especially wrt double phase lookup), so is there a specific reason to update?

Thanks everyone for the comments.  We definitely hear you with regard to improved C++ conformance (both compiler and library) as well as IDE performance and scalability.  There are things that we are actively working to address for Orcas+1.  

Bill Dunlap

Visual C++ Development Team

I really would like to see more convinience libraries like the .NET classes over in C++. There are many similar looking things but they drive you crazy if you try to use them in the same way like in C#.

The ATL CPath class is very cool but CAtlFile is a nightmare to use.

CAtlFile OpenFile(const CString &file)

...

CAtlFile openedFile = OpenFile("C:\\foo.txt");

If I try to use it as simple as this I get compiler warnings that I use a non standard compiler feature (conversion of a value to a reference).

If the open fails and I do check the file handle now for NULL or INVALID_HANDLE_VALUE?

After fumbling around I did go back to good old HANDLE values I can much easier check for correctness.

A new library with a consistent error handling approach would be very cool to make silly coding errors where you check for the wrong return code occur less often. Yes exceptions can help but any new library should work as seamless as possible with the Windows APIs for interop.

Yours,

  Alois Kraus

I'd like to put in a vote for continuing to address interoperability smoothly. I am working on a very large legacy C++ project, so native code is critical. But as we build more data interoperability the XML and webby friendliness of the CLR libraries are too much to resist. And large pieces of the new interface ought to be built using managed code, but will clearly need to call back and forth with the unmanaged components -- including unmanaged interfaces in libraries like Qt. In short, managed code should represent a practical way to augment existing C++ code without having to flip a switch and recompile the whole thing.

I really like VS 2005.  I develop mostly C++ native apps.  The performance of C++ Intellisense is the number one pain for me.  I have 100,000 lines of code spread out over 10 projects, and normally keep them all in the same solution.  I use boost and stl quite a bit.  I have had to turn off Intellisense (via renaming feacp.dll) because my CPU goes nuts every time I change a header file.  I have a dual core machine, not sure if that makes it worse or not.

In constrast to many of the folks who have posted comments, managed/native interop is EXTREMELY IMPORTANT to my group and to others who are developing high-performance critical applications.  My application is medical imaging, and our front-end is .NET but Managed C++ for performance reasons.  (We heavily utilize OpenMP and there is no way we can get the same performance using C# - believe us, we've tried).

Forms support in VS C++ 2005 basically sucks.  Half the time the designer can't load the form and how come it takes 10 minutes for a form to load while in C# it takes a couple of seconds?  Sometimes we've had to resort to manually editing the header file to move buttons around!

Also, the designer generates atrocious looking header files.  Why not borrow from C# 2.0 and use "partial class" definitions.

More OpenMP/multi-core enhancements would be appreciated, fix the forms support, I personally don't care about export but do care about C++ TR01.  My group is also very interested in STL/CLR.

As an ISV working in Visual Studio extensibility we work with every version of the Visual Studio family from VC6 and eVC4 through to VS2008. You wouldn't believe some of the howlers we've seen in the IDE interfaces - the Visual C++ automation interfaces (VCProjectEngine) in particular.

We still develop mostly in VS2003. Why? Simply because developing add-ins in VS2005 is a royal pain - the environment is sluggish (especially when the IDE is loaded under a debugger, which we of course do regularly) frequently locks files it shouldn't (especially Satellite DLLs) and can't even successfully toggle the load settings of add-ins loaded through HKLM (this bug, incidentally was reported to MS in VS2005 Beta 2 and closed as "won't fix").

As such we are stuck using earlier versions of the Windows SDK and with a real problem on dev machines running Vista.

We'd love to believe that VS2008 will be the platform that will allow us to move to the latest Visual C++ libraries, but the fact is that unless VS2008 addresses these issues *and* makes the runtime library easier to install (hint: provide a way to circumvent those SxS manifest requirements where appropriate) it just won't happen.

+1 for the vote about allowing VS to open and work with previous versions of solution/project files too. We maintain dual VS2003 and VS2005 (the latter primarily for occasional work on Vista) solution and project files, and keeping the settings in sync is a royal pain. How about providing a tool for automated conversion in both directions?

Oh and if you are serious about really getting VC++ up to speed please do something about getting the toolset in sync with other Visual Studio supported languages. Tools like Sandcastle need to be able to handle native code too.

I'd love to see some tighter integration between VS debugger and virtualization technologies. Actually, that applies not only to VC++ but the whole VS in general. With the vastly improved performance of Virtual PC, I tend to do development & testing on a virtual machine more and more. The way I debug my applications in virtual machine is using Remote Debugger (or WinDbg). Well, it works, though I am absolutely positive that you guys can achieve some more seamless experience.

I presume improvements in this direction will be welcome even more when employing virtualization for development needs will become mainstream (if it hasn't become such already).

We have a 1M lines C++ code base CAD application suite and very active ongoing UI intensive development. My main issue is developer productivity - I want my team to be able to use the state of the art in building complex UI using all the new .net, XML, etc tools, but I need to do it in C++ rather than in C#. We also have large MFC legacy (over 500 dialogs) so transitioning to a friendlier platfom for forms work is needed. In summary, our need is the developer friendliness of C# with the performance of C++.

I found the problem in resource processing (from VS2003 and after). I have Russian Windows and Italian resources. Each time I'm saving Italian resource file all accented symbols are lost. The resolution is only load Windows under Italian local.

Can you resolve such the bug?

1) Please fix the broken CRT in VS 8.0 - you can't just build an app then copy the executables to another machine without getting that dreadful "this app is not configured properly". Its a *binary* app - it doesn't need configuring. For this reason we cannot and will not port our projects from VS 6.0 to VS 8.0.

2) Same comment for the MFC libraries

3) Please can we have more than 1 watch window in VS8? VS 6 gives me 4 - so much more usable.

4) If the app is just a native app DO NOT ask me if I want to do managed debugging - just straight into the debugger as fast as possible. Some bugs I never get to see because by the time I've got through the GUI interventions asking me which debugging I want, oh dear the app is no longer running, thus I can't see the bug. How useless is that?

5) Please re-instate the MFC class wizard.

6) If you have (as we do) 11 million lines (across 39 products) of C++ targetting MFC you will appreciate that we are not going to port this to C# and WPF. Its just not going to happen. Therefore we want and need first class support for C++ and MFC in Visual Studio (without that #1 issue above) before we can use Visual Studio 8.0.

You need to treat C++ equally to C# if you want us on board for the ride (and that includes the GUI design tools such as class wizard).

All that said, thank you for fixing in VS 8.0 the key bindings so that now F7 does actually do a build etc. Also nice that the project settings are always available (as they are implicitly selected) and that I don't have to select the project before I edit the settings (like in VS 7.0 - so broken!)

Have now moved a large C++ project to VS2005 from VC6. Occasionally have to go back to VC6 to maintain an old version. Its like a breath of fresh air, like seeing an old friend again, makes you realize how slow VS2005 really is (or least for native C++) and no really nice extras such as re-factoring to compensate!

Major areas that seem to have gone down hill

Resource dialog editing - interface is terrible compared to VC6

Compile/load time

Help - nearly unusable in VS2005  both speed wise and feature wise compared to VC6

What would be nice to see:

Seamless integration with managed framework.

The Documentation facilities that are in C#

Re-factoring

Better/faster dialog resource editing

Pop Context when browsing through definitions (or maybe I can't find it in VS2005!)

Overall speed up

Help - more like VC6 - The 'Locate' button was heaven!

Please make your tools case-sensitive. VC++ 2005 converts file names to lowercase during compilation, debugging, and source code browsing ("Find all references" etc). Sometimes it even *renames* the files. Ttypical scenario: you typed something in the file MySource.cpp opened by debugger and pressed "save" - oops, now it is mysource.cpp. This makes the development difficult. There are case-sensitive file systems and development tools (preprocessors, compilers, source control systems, log analyzers, etc.) that expect the file name to be unchanged.

My recommendation: let your tools show and use file names in the same form as in Windows Explorer.

It would be nice for VSTS to present a list of files updated when we do a "Get Latest". Keep improving the interop as we'd like to figure out ways to use WCF and WPF in our large native C++ application.

We've been waiting a long time for Class Designer for C++. We'd like to see static code analysis become more configurable, perhaps allowing us to add our own coding standard variable naming conventions. We would really like to see the VSTS Unit Test framework directly support native C++ rather than having to jump through hoops.

We appreciate all of your hard work. Keep the improvements coming - Visual Studio is the best IDE in the industry.

I agree with  Stephen Kellett

And

I am very very concern by the interest from Msoft for C#, for various reasons, not all technical.

VC++ is becoming "poor parent", and C++ Looks like going to be in futur what Macro assembler is today; The language of choice for speed, not more.

But C++ is the language of choice (aside perl, etc ..) in the Unix world.

A dangerous attractor (dangerous ?) to switch to non-Windows OS as free community or collaborated code is done for; gcc, make, for BSD or Linus RunTime.

A good path would be to help VC++ being a *real* bridge to the Unix world. Take make, compile, run!

CRT surely require a revamp for that, Third party ? I won't take that chance

Being Posix etc ... is *not* the solution. Msoft have a long legacy of defacto standardization, same happens with C++ under unix which establish it's set of defacto std.

I woud love more open env with pre compiler allowing perl script or PHP code to be converted to C++ and compiled. Speed *is* back as an issue with today requirement on server.

At same time asking an engineer  to switch to ASP technology is an irrevrsibble path (too much to learn every minutes) so they reluctantly take that path.  (ASP faster ?)

So

New guys use .Net VB, C#, Java

Old guys design considering need for Unix compatibility.

Too bad VC++ is the best IDE I know (so far) but it's futur will stick to C++ futur or be put sideway

We don't need an incremental VC++ version++ !!

We need the swiss army knife with same level of innovation as VC++ 2.0 gave.  years ago.

Take your chance guys!!

Yes there will be flaws on first versions.

Yes you will have to consider being compatible with a specific version first.

But being static is NOT a sign of life.

I'll look on 2008 and maybe change my mind but not sure from clumsy and over enphase put on new features.

PS: Don't know how you work at Msoft for P&L but VC++ is way too expensive. ('express' version is a patch)

Loosing ground of small devloppers versus choosing big rich enough companies is not OK during mutation time, like what current Web mutation era is.

Not to mention endorsing dangerous switch to Silverlight, WPx etc .. versus legacy Flash

I like VC++ so move it please

Will GUI designers still use fixed coordinates instead of sizers (a la wxWindows, er... wxWidgets) or anchors (a la Delphi and C#)? Anything is better than manually resizing things.

Visual C++ really looks like a second class citizen when it comes to GUI tools and well-designed library support.

Bill Dunlap wrote:

"Thanks everyone for the comments.  We definitely hear you with regard to improved C++ conformance (both compiler and library) as well as IDE performance and scalability.  There are things that we are actively working to address for Orcas+1."

What does that mean exactly? Are we talking about TR1 conformance or 0x conformance, I certainly hope it's the latter. I do of course understand that you might not have time to implement all of it but there are significant parts (all of TR1 and more) that have not been changed since they were made part of the draft, and probably wont change either.

I'm currently looking into a library licence from Dinkumware, but the cost combined with the licence for VS is quite high (considering that most of it I already got with VS)

I'll reiterate what I said to Microsoft Canada when they asked me for my feedback on the VS development toolset.  

1) I believe the development environment should be rock solid stable - like the OS.  A debugger crash doesn't give me confidence in the product I'm using.  VS2002+ has this issue and it hasn't been resolved.  How many more crash reports do I have to send before VS2002, VS2003 and VS2005 will be fixed?

2) Which leads to the next issue - service packs.  My end-users expect product hotfixes and updates because it tells them that my company stands by what we produce.  What has the VS team been telling me for the last several years?  Speaking as your customer, it is not confidence boosting to get a service pack and the issues fixed aren't a pain point - see point 1.

3) MFC is important to many companies.  Please continue to support, enhance and keep it alive.   I'm working on a 2M LOC product - it will never be to ported to C#.  There is no business case that could ever be created to justify rewriting 15 years of code.

4) Somewhere between VS6 and VS2002 the help system got seriously broken.  It is impossible to find anything.  Google has become the preferred help system.

5) A major pain point I have with MS dev tools since Microsoft C6 is that every release changes project files.  As far as I can determine the only compatibility difference between a VC2002, 2003 and 2005 vcproj file is the file version number.  Do you know how tiresome it is to change 100+ project files when you know all you have to do is change the file version number?

6) Oh, and more pain points.  Can you guys do something about SxS?  It doesn't work.  Very simple - it does not work.  Period.  Has anyone in the VS team gone through the fun of figuring out why a COM+ app won't run because some SxS module is missing?  Or contact a vendor to get an updated merge module so you can distribute your product?    

Thanks for the opportunity to speak.  I'm looking forward to playing with VS2008.

We use VC++ entirely for legacy application work.  Our new systems are C#.net for most everything which calls via a RPC a few legacy computation engines written years ago in C++.  Our main issue is that C++ foundered with half-adopted measures such as STL and Boost to address know shortcomings instead of a much needed POSIX v2 standard class library.   Ideally, we would like to see a native set of file, directory, socket, rpc, memory classes from .NET 2.x framework make it into a  C++ POSIX v2 ISO standard.  This would greatly help us for both Unix side and Windows side C++ legacy code.

You should have titled this: "The future of Visual C++" or something. Futures and C++ mean something very different:

http://video.google.com/videoplay?docid=7625918717318948700

One of the biggest reasons to upgrade to Visual C++ 8 was improved conformance. I have told the rest of my team that I would be very surprised if Visual C++'s C++0x / TR1 support was lacking.

Please don't make me out to be a liar!

The main thing that bugs me currently is that the STL seems much slower than necessary. I've seen tests showing STLPort's vector class to be a full 4 times faster than the MS one. (and that's when disabling bounds checking, checked iterators and all the other stuff)

Speaking of which, I think that is a mistake to enable by default as well. Here's why:

- One of the major design philosophies for C++ is "you don't pay for what you don't use". So why enable bounds-checking on operator[] by default? We don't expect it, it isn't there in other implementations. And when we want it, we can enable it easily enough.

- Along the same lines is "the principle of least surprise". We expect [] to be fast, and .at() to do bounds checking.

- And finally, I think it might not actually reduce the number of bugs at all. Imagine an intermediate C++ programmer who isn't aware that you decided to do bounds checking and all that extra stuff. He just uses std::vector because that's what people say you should use. So he profiles a bit, and finds out the vector is *much* slower than an array. Guess what he does then? That's right, rolls his own. So now you have people using home-made, buggy, insecure array wrappers instead of std::vector which is at least bug-free. If you want secure code, I think giving people the *option* of enabling bounds checking would be much better than stealthily enabling it by default.

- And finally, the justification for all this that I've heard is that "when you use our iterators, we can eliminate most of the bounds checks, so you don't suffer the big performance hit". Yeah, great, except reminds me again, what is the purpose of std::vector? That's right. Random access. In a lot of typical cases, you don't iterate through the vector, you perform a bunch of random accesses, so you *do* get the performance hit.

I think the whole "Secure SCL" is a mistake, at least by default.

Ok, another suggestion: Please please please improve support for property sheets. They're awesome. Why don't the standard project types use them? I hate how when I create a Win32 project, it overrides the output/intermediate paths, instead of just inheriting a value from a property sheet. So if I want to change it, I can't just add a property sheet with my values, I have to *manually* clear out the overridden values in project settings. Can't all the default project settings be specified in a property sheet?

And of course, the project wizard API itself... Yuck. Give me a nice clean C# interface like the cool people use, not an ancient, mess of javascript and html.

As people mentioned above, the whole manifest thing is silly too. I (think I) understand the reasons for it, but it is a major pain in the ass that when I build an executable, I can't just deploy it on other computers. There's got to be a better solution.

And finally, though this isn't C++ specific, but Visual Studio in general, it's slooooooow. Amazingly slow. And single-threaded... Does the entire program *really* need to freeze completely while waiting for Help to load? While waiting for intellisense to update? While doing *any* of the vast number of actions that takes 30+ seconds?

Jeff,

Can you send me some details about what scenarios you're seeing where SxS doesn't work?  Are these design time issues or run time issues?  What specific components?  I'd like to make sure the right people are following up on this.

Thanks,

Dave Berg

David.Berg@Microsoft.com.

I am right now more C# than C++, but have found a lot of good things on the C# side that can jump to the C++ side without being Managed code, on libraries like MFC, ATL, there are a lot of Data Structures that can be included on a basic C++ for instance, Lists, Dictionaries, things like this, that allow a handling of information like it is in C#, but available to any application not exclusively MFC, some times I need this on a console application.

Win32 native windows programing is complex, and the visual tools for windows are not good, the language and tools are not object oriented, nor even event oriented, so it would be great to improve in this side.

Jeff's comment about SxS reminded me, why on earth isn't the Microsoft Visual C++ Redistributable Package sent out through Windows Update? I've developed dozens of small tools that should only require a quick copy and run, no fancy installations or such, but when I try to use them on a computer they don't run because the runtime files are not installed. And on some computers the user might not have permissions to install them either. The installer is less than 3MB, I can see no reason why it should not be installed on every computer running Windows. If not the ability to run the applications developed on other machines is a feature I don't know what is!

I'm with the other folks who are saying we have several million lines of C++ across several apps and will never port to C# or use the .NET runtime. I echo the requests of many, asking you to focus on performance (especially intellesense), fixing the help system, circumvent SxS when appropriate, etc. "'friction-free' interop between native & managed code" should be secondary at this point.

One other request I'd like to see: Please provide a way to tell the IDE to NOT, in any way, shape, or form, pretend to know about a source code control system (ie, don't offer to "unbind", "work offline", etc) Just treat read-only files as read only, don't look for vssscc files, and so on.  There's times that source control integration just doesn't work, so

I'm with the other folks who are saying we have several million lines of C++ across several apps and will never port to C# or use the .NET runtime. I echo the requests of many, asking you to

- focus on performance (especially intellesense)

- fixing the help system

- allow circumvention of SxS

- add refactoring capabilities

- add unit test framework that directly supports native C++

"'friction-free' interop between native & managed code" should be secondary at this point.

One other request: Please provide a way to tell the IDE to NOT, in any way, shape, or form, pretend to know about a source code control system.  When integrated source control works, it’s great, but there are times that it just doesn't work, and the best I can do so far is get down to one dialog offering to unbind from source control (which sets all files to writeable if you choose ‘yes’). Don't offer to "unbind", "work offline", try to overwrite writeable files, and so on; just treat read-only files as read only, and let us manage source control, if we so choose.

That said, there are some good improvements in VS2005 C++, such as the call browser and code definition windows, greatly improved error/warning display, and the Data Tips and Visualizers. Keep your team focused on what C++ developers need, and you can make VS the leader of the pack again.

First off, Soma please do more channel 9 interviews ( you rock ! ).

For me I am evaluating (and would really like to use) the usage of managed to un-managed code in my applications (communication oriented programs).  I am also hoping that visual C++ will take advantage of the C++0X standard which is set to release soon (09?) .

I think both Managed and UnManaged code is needed in todays world.  I just hope the VC++ team keeps up the good work and continues to build the best tools available for us grunts in the trenches !

Thanks again for all of your comments!  We are reading each on and will factor your views into our product planning for the next release.  A couple of high level bullets:

1) IDE performance/scalability - we hear you loud and clear.  This is something we absolutely are looking to address in Orcas+1.  We know that many of you are working with MLOC and we need to update the IDE to support this better.

2) IntelliSense isn't very good - we are working on this one as well.  As indicated previously, our goal is to provide a "C#-like" IntelliSense experience in Orcas+1.  We working on a front-end parser re-architecture right now that will facilitate this (and a whole lot more).

3) MFC - we are working on a huge update to MFC that should knock your socks off.  I can't tell you too much right now, but this is closer than you might thing <g>.  

4) TR1 - we're doing a lot of work in this space as well.  I can't give our exact plans right now, but we do understand the importance of this library.   As above, we'd like to release this sooner rather than later.

5) C++0x - we are carefully tracking the latest C++ standard.  Our commitment to standards compliance still stands and we will work to support once all aspects of C++0x are finally approved.

6) Deployment - this is not as easy as it should be.  We're going to be looking at this for Orcas+1 as well.

Keep the comments coming!

Bill Dunlap

Visual C++ Development Team

I would definitely love the feature of 'total deoptimization' :-) It should generate such code, that no hackers will ever be able to understand what's going on inside :-)))

I think the major problems with VS2005 have been well addressed here, except for one:  F1 help.  This is such a joke in VS2005, and worked so much better in VS6, that it is a constant source of amusement in our development shop - sometimes someone will forget how bad and how slow F1 help is in VS2005 and hit the F1 key, and say "Damn!  just hit F1!" and everyone laughs.  Google is an order of magnitude faster and more accurate than F1 help in VS2005.  Please, please, fix this.

MSDN help needs attention both in the DVD form and via msdn.Microsoft.com.  We've reverted to searching for API help in this order 1) google usenet groups, 2) google web search limited to microsoft.com 3) local msdn copy 4) msdn.Microsoft.com 5) google unrestricted web search.  The main contention is that MSDN produces far too many false leads and far too many topics that have no sample code.  We have the last MSDN before .NET was first released as a second major source of documentation since much useful content was removed instead of being updated once .NET was released.  

You said you were going to "hold the line" in terms of performance. Does this mean you've given up on improving it because you recognize that it's a lost cause?

For native code developers, the VS2005 IDE just plain sucks. It's clear that native code developers have become an afterthought.  How is the VC team going to address what is clearly the domain of the MS marketing nazis?

MSDN is completely worthless (to all developers, but especially the native code developers), and has been since the mid 90's.  It may as well not even be shipped with Visual Studio.

Yes, I'm bitter. I think .Net is NOT appropriate for desktop apps, and MS's aim is to turn native code developers (that *got them where they are today*) into their mind-controlled robotic demon spawn of the CLR.

Okay, so maybe that's a little over the top, but I think you understand how I feel...

Simply put, just get the new C++ compiler and make it work with VC++6.0. New compiler is good, but the IDE of VC++6.0 was the best and most suited and most stable for C++. Just make new one same as VC++6.0, so simple. Class Wizard was way better than this propery editor, and faster too.

Also, why do the IDE addins stop working with each new version? I am an author of one of the popular addins but I will not keep porting to each and new version. Shame on you for that. You should be able to make old addins work with new IDE. I can see people actually implementing addins that work for multiple versions on CodeProject. Why can't you?

Product is way too expensive for the quality of it. I use the latest versions at work - company is silly enought to pay for that. But tool is way overpriced and wont make it to my home. I can afford it easily, but it's just not stable of convenient enought for me to buy that.

Stop inventing the wheel where a de-facto standards exists. E.g. XML comments are so primitive for documentation - why not support doxygen format natively? Also, why not support CVS natively? The source control interface is so bad I don't know where to start on that...

New IDE looks, from the begining in 2002, like a re-worked Visual Interdev from VS60. It even calls workspaces a solution - dead giveaway. Well, Visual Interdev was one of the worst tools I even worked with and now it's calling itself VS2003-2005. It's primitive and looks like made by some VB developer on a weekend. I guess that makes VB developers quite happy.

Annoying message boxes must stop. I drag a project onto the IDE and it tells me I can't and I should open a solution instead!? Or while I am debugging I try to type the code and it tells me to stop debugging first! But it tells me what to do instead of giving a button to actually do that, it's totally counter-productive and make me think that VS development team doesn't understand the first thing about GUI design and can't make a functional product.

Don't care much about intellisense - I use Visual Assist for that. If you want to see what to do in that aread then look ath Visual Assist and other addins (resharper etc) and just do that.

I am not sure why I even bother to type all that. Nothing will probably change because we seem to be living in some sort of IT dark age where "simple" and "easy" are keywords to cover for arrogance and ignorance of modern programmers.

Microsoft's Visual C++ team has been mapping out the future of the development platform, looking to highlight native and managed code capabilities, a Microsoft executive wrote this week. "The Visual C++ team has been looking at what they should [feature]

I don't even care about submitting feedback anymore. MS failed to listen to C++ devs between 2002 and 2005. MS even publicly solicited feedback on the IDE in February 2005[1], and failed to act on it in 2005, and again has failed to act on it in 2007. So it's been 9 years since the last good IDE was made and we'll have to wait until what, 2010 for Orcas+1? Then _maybe_ you'll fix some things in the IDE? No thanks, I'll only let you abuse me for so long. I'll stick with VC6 where I can actually get work done.

[1] http://blogs.msdn.com/aprilr/archive/2005/02/18/376494.aspx

Thanks, everyone, for the fantastic feedback.  Your passion and enthusiasm for the product has certainly gotten our attention -- in fact, this very thread was the major topic of hallway conversation here on the VC++ team today.  :)

I'd like to take a moment to touch on some of the topics raised here...

>>You said you were going to "hold the line" in terms of performance. Does this mean you've given up on improving it because you recognize that it's a lost cause?<<

I won't put words into Dave's mouth, but I can say that the effort of Dave's perf team have definitely paid off for us.  Right now our VS2008 perf tests show us as beating VS2005 in several of the key performance scenarios that we are critical for VC++ developers.  There's still much more that we want to do here, but I see it as a major step forward that we've reversed the regression trend.

>>For native code developers, the VS2005 IDE just plain sucks. It's clear that native code developers have become an afterthought.  How is the VC team going to address what is clearly the domain of the MS marketing nazis?<<

Native code developers are absolutely the focus of the VC++ team.  Bill and I discuss this in detail in the Channel9 video that Soma references above.  Also, as Soma  mentions, we already have a good chunk of our team working to create a fantastic IDE experience to ship in the next major VS release after VS2008 "Orcas."

>>MSDN help needs attention...<<

Absolutely agreed.  I admit that I do not have my finger on the pulse of what the help team is doing to improve the F1 experience, but the volume of feedback I've heard here has convinced me to make it a priority.

>>I'll stick with VC6 where I can actually get work done.<<

Indeed, VC6 is a common theme in this thread.  While I actually believe VS2005 and VS2008 are superior products, I can also see why VC6 remains a touchstone for many: it's fast, it's simple, and it takes a totally C++-centric view of the world.  This feedback is well taken, and we have been paying a lot of mind to the things VC6 did well as we design the Orcas + 1 IDE experience.

>>Jeff's comment about SxS reminded me, why on earth isn't the Microsoft Visual C++ Redistributable Package sent out through Windows Update?<<

That's a good suggestion.  We are actually looking right now at what the redist deployment story should be for Orcas + 1, and we know that the current SxS system has caused some headaches.

>>Will GUI designers still use fixed coordinates instead of sizers (a la wxWindows, er... wxWidgets) or anchors (a la Delphi and C#)?<<

We don't have any specific plans here, but -- as Bill mentioned -- we are doing some major new work in MFC that we'll announce shortly.

>>Other than that, the C++ compiler is roughly similar to VC++ 2005 (it still accepts the same bogus code, especially wrt double phase lookup), so is there a specific reason to update?<<

You can learn more about our VS2008 feature set on the VC++ team blog as well as some of the channel9 videos we did recently.  Specific to the compiler, we've made some good improvements in build throughput on multicore machines and for managed/mixed code.   Regarding compiler bugs, we've addressed them according to the bar we published back in June 06 at http://blogs.msdn.com/vcblog/articles/621116.aspx.

Thanks again,

Steve Teixeira

Group Program Manager, VC++

I have almost the exact same concerns as the first post from Larry. In my career I have been using VS for the last 10 years for mostly MFC based applications. I believe I started out using VS 5 (possibly 4.X?) and now I am using .NET 2003. Being that we have an academic license with maintenance I have used all versions of VS from (VS 5 to VS 2005) to write and maintain the approximately 500K lines of mostly MFC code I have worked on in that time. Most of this time was spent in VS 6 which although the compiler lacked features (templates) it had by far the best IDE for building my MFC apps.  My biggest complaints with the .NET versions all seem to have a buggy GUI and the help system gets progressively worse.  With .NET 2003 (which I use mostly now) it is so very rare that the help (F1 when a keyword is selected) actually finds something useful that I generally opt to do a google web search instead as that actually has a chance of finding something relevant. This is very annoying as the help for VS 6 was much better than this although it was annoying that I could not get rid of the Foxpro docs and still be able to see the SDK help. Then there are the gui bugs. Clicking on a class in the class view (in vs 2003) and then selecting add a member function or variable crashes vs2003 probably 20% of the time so I have learned to avoid that feature that I used and liked a lot with vs6 and this is not hardware related as this has happened on several different machines. Also the built in tools for editing message maps and adding handlers is significantly harder to use (and more awkward) than it was in vs6.

Now the improvements I would like to see after the bugs I have mentioned above (are fixed) are the following:

1) I would like to see a large  improvement in the build system to at least make better use of multi core processors while building and possibly extending this to include some type of pooled build like gcc does with distcc. Also possibly implementing something like ccache as well.

2) Better tab support in the GUI (like wndtabs does).

3) Implement saved window layout where choosing a button on the toolbar will restore a window layout which includes the sizes and positions of the docked windows. Being that program and remotely debug with very different screen resolutions I find myself updating the window layout in vs2003 50 times a day and this is very annoying.

I liked the workspace, slide out with the tab on it,of the files,classes and resource. better than all the slide out that keep popping out on me every time I move my mouse.

but like the tabs in the editor better than 6 to switch and select the editing file.

and what happen to the tip of the day,splash screen, Great help output,and the class wizard are the thing I miss

Thanks for adding BRIEF key mappings back into VS5, and please have a BRIEF aficionado actually use it. VS6 is as good a BRIEF implementation as there can be and VS5 is possibly the worst.  I get the feeling that nearly no-one uses BRIEF, so this may only be my problem....

First, it sounds like y'all have a good idea of the direction for future improvements. In our environment, we have some managed code, in C#, a lot of native code, in C++, and a little bit of glue code in managed C++. This mix is unlikely to change significantly. (In case it's of interest, one of the main reasons we use C# instead of C++/CLI for the managed code is to avoid the problem of too much mental overlap between managed and native code. Easier to mentally switch gears from C++ to C# mode.)

Second, I agree with all the comments about needing serious support for high-productivity usage of GUI stuff from C++. This seems to have been left rotting over the last couple releases.

Finally, a minor request: add an easy way to make different activity-based configurations the same -- in other words, make it possible to transfer GUI rearrangements from coding mode to debugging mode. It's much easier to customize the minor changes to make one mode more useful than it is to redo the same major toolbar etc. customizations multiple times.

Responding to Dave Berg and to the list:

My compaints about SxS is not really about whether the technology works but the extra burden placed on developing software.  

What did me in with SxS was when I encountered a problem with a debug COM+ component that wouldn't load and the only way I could get it to work was to create a setup program for it.   I think the issue was a dependent DLL needed one of the runtime but the error that was happening wasn't useful.  

The other scenario that makes SxS difficult to diagnose is with managed code.  If your assembly is dependent on a native code DLL and you're missing runtimes it is very, very difficult to figure out that you're missing a library.  The .NET runtime doesn't provide too much assistance to help.  Previously you placed the DLLs in the directory or looked in the system directory.  How do you find out if you're missing a DLL now?

SxS seems to me as an overly complex way to deal with something that's been pretty much resolved.  We haven't had problems with DLL versioning for a number of years.  Not since MS started forcing versioning as a requirement to getting software certified.

I like Erik's suggestion that the runtimes being distributed via WUS would go a long way to dealing with the many scenarios where things don't run and all that is missing is the runtime install wasn't done.  

But there are a couple other things that make installation rather challenging.  

The first is having to chase down merge modules.  Can't this be worked out with vendors?  Especially if they have some of their components distributed with the VS development system?  ie.  the VS versions come with MMs but the full version of the product MMs are hard to get.

The other issue is the klunky way that you have to search a system to figure out if some library is installed.  There seems to be no clear way to figure this out.

Thanks for the soap box.

It would greatly help us to have tools to convert COM based applications into a single statically linked executable (i.e., remove all of the COM plumbing and COM calls) since a good portion of our legacy C++ systems were written by ex-VB6 developers overly used to plopping in VB6 COM components for everything even when both the application is the only user of the component and they both are on the same machine.  We're incrementally improving the stability of our systems by making them statically linked and free of any type of RPC, COM call or CORBA call.   Our applications are hard hit with any OS patch, OS upgrade or new version of our product because it affects 100+ production machines.   Multiple binaries (dll, com, or exe), registry settings and COM registration make it much harder to make sure all componets get setup / installed correctly.

I agree with some of the previous statements - please work to keep VC++ the platform of choice for developing *native* code. Keep the dependencies to a minimum so that native applications can be deployed (e.g. no CRT or MFC runtime conflicts - re-think SxS) with minimal fuss.

A huge percentage of us develop the third-party native code applications that keep the Windows platform alive and vital. Please stop pretending that we should all switch to WinForms / WPF / WhateverNewThingComesToMind.

If I'm writing managed code, I'm using straight C# - and have very little interest in native / managed interop.

With regard to Intellisense being poor - who cares? Every C++ developer should own a copy of Whole Tomato Software's Visual Assist (no I don't work for them). Why focus Microsoft's internal efforts on Intellisense issues when a third party app solves them adequately and inexpensively?

Please keep progressing MFC, bring back the class wizard, and improve resource editing for native apps. What's there today in VS2005 is just pathetic.

Hello.  Catching up with the last set of comments.  Here are some high level thoughts:

1) MSDN/documentation - I agree that this is a problem.  It's not that there isn't good content, it's that separating the useful from the irrelavent is too difficult.  While we don't own this technology, we will definitely share with them your comments.

2) IntelliSense revisited - I see a number of people telling us "don't worry about IntelliSense...just use Visual Assist'.  I agree that Visual Assist is a very fine tool.  But the bottom line is that fast, accurate coding tools should be like air or water.  There's no reason you should need to turn to another tool for this level of support.  In addition, don't think of IntelliSense as the "end game".  Think of it as the beginning.  Once we have our new engine in place - and an object model on top of our parser - there could be a whole set of source analysis tools we (or third parties) could provide to help you better manage large-scale software projects.  

3) Interop - we know that most "pure" .NET applications are being built in C# and VB.  That's one of the reasons we should be focusing on native - we're the only player in that particular space.  But interop is important because there are lots of people that want to extend their native apps to use .NET code.  We need to ensure that this is an easy thing to do.  

4) VC6 as best native IDE - I agree with these sentiments.  VC6 was the best native development tool we've ever released.  Now that our vision is once again focused on native code, I believe that we'll be able to surpass what we did in VC6.  That's certainly the mission we're embracing.

5) Do we listen to feedback - We honestly do.  Certainly I can't make it so everybody's favorite feature goes into the product, but the high-level trends we hear do influence where the product is going.  That's why it's important to share your perspective.  And now that we have a focus (once again) on native code, we should be able to show bigger leaps in progress.

Thanks again for your comments!

Bill Dunlap

Visual C++ Development Team

Some other issues that are sort of C++ related...

COM+ components continue to be a pain to distribute commercially.  Is it possible it will ever be possible to write and deploy a COM+ app in a standard setup program without some extra effort?

Oh, and COM+ stuff again.  The attributed programming thingie to generated IDL is a great idea.  I haven't used it in a while because it didn't work as I expected.  The scenario that caused me an issue was I wanted to pass an COM object as a parameter.  i.e. and ADO object as a function parameter.  I had all sorts of problems trying to figure out how to include the typlib in the IDL so that it could build properly.  What I had to do was save off the generated IDL, hand edit and go back to the old-fashioned way using MIDL myself.  A work around but I wasn't happy with the attributed COM programming thing.

This is a more general comment on the whole VS development IDE.  It is evident that the development platform has migrated to scenarios where the developer is working and deploying software in-house.  

This needs to be rebalanced to work with us that write and sell software for a living.  The problem is huge in the .NET world.  For example, Click-Once applicaton for commercial distribution is very difficult to do, web applications and Biztalk applications are a problem too.  

While it may not seem to be a C++ issue it is when you're trying to distribute apps with .NET application UIs and native DLL and COM component back-ends.

I think MS should offer tools and technologies that are capable of distrubiting in many different scenarios.  

My wish list

1. Stop removing features from the IDE (Connect ID 105507 for example).  It makes us less productive when we "upgrade".

2. Stop breaking features in the IDE (Connect ID 139752 for example).  It makes us less productive when we "upgrade".

3. Add multi-targeting support for MSVCRT/MFC just like for .NET since the project and solution files are incompatible across all IDE versions since 4.2.  Without it, it is more difficult to "upgrade" to a newer version, since everyone on the team has to do it at once, but it can't be done until the project has been built and tested on the new compiler.

4. Native (unmanaged) C++ should have access to all the OS capabilities that managed C++ does.

5. Native (unmanaged) C++ should have access to the new UI technologies like WPF so that existing applications can be updated to use them without having to be rewritten in a proprietary language.

6. Complete and correct support for standard C++.

> But interop is important because there are lots of people

> that want to extend their native apps to use .NET code.

Let me be blunt: customers that I work with wanting to move existing applications to .Net specifically ask me to rewrite code in C# and specifically not to use interop. In other words, it is either all native or all managed, but no where in between.

The only use that I have for C++ is for native code. (Just as the only use for C# is managed code.) I'm sure that Microsoft has their own internal agenda and goals. But please do not waste too much time and effort on interop. I have absolutely no use for it. And looking at some of the comments above, a number of other people seem to be of similar opinion.

I would suggest roughly 90% be spent on improving standard compliance. While there has been much improvement lately, significant portions of ISO/IEC 14882:1998 and 2003 are still not implemented or need further attention. The other 10% could be spread out over other miscellaneous IDE features, proprietary libraries, interop etc.

I'm looking forward to Orcas+1.

Good luck.

I will be upgrading to Orcas specifically because I have heard that it has an integrated class diagram feature.  This is important to me.

We have a large existing code base in C++.  Now we would like to start using some of the new Windows features that are available in WinXP SP2+, but without using managed code or interop.  I hope this will be possible in the future.

"4) VC6 as best native IDE - I agree with these sentiments.  VC6 was the best native development tool we've ever released.  Now that our vision is once again focused on native code, I believe that we'll be able to surpass what we did in VC6.  That's certainly the mission we're embracing."

Bill, that's the best news and possibly the only mission statement you need for VS. If you did this, we'd all be very happy. Can you make VS as fast as VC6 (eg I start the debugger... and wait, I edit a resource and .... wait), use as much memory as VC6 (I can open 4,5, 6 VC6 IDEs no problem whatsoever. I open 2 VS2005 IDEs and its welcome to the land of swap).

Interop needs to be more seamless, you should be able to write GUI apps in jav, sorry C#, and connect them to back-end native services easily. Similarly, using managed libraries should not need so much changed syntax for stuff the compiler should be able to figure out (I'm still annoyed at the 2 destructors you have to provide for  C++/CLI, and think the 'managed pointer' is just laziness on the C++/CLI team not being able to add better support for a C++ that can be used as if it were C++ and not a bastardized extension language).

The help is pants. Bring back the technology used for VC4, that was the best system I remember using, and Visual Interdev is quite the worst IDE MS ever wrote, its such a shame VS2005 feels so much like it.

Anyway, I'm sure we're all waiting impatiently for proper support while we're thinking about just trying out the competing IDEs out there :)

I'd like to see proper compiler performance diagnostics. When writing template heavy code, I often hit a kind of "inline" limit where simple static passthrough functions don't get inline any more, so I wind up with ASM functions that basically contain just a single call instruction.

Trying to figure out why the heck the compiler didn't inline these is no fun today, you can try to set __forceinline on all and try where it can't inline and start guessing, but the warning messages are worse than bad (pointing into STL stuff where there is no STL usage anywhere).

Take a look where the Intel Compiler is going to, giving you verbose information about which loop was unrolled etc., and Sun Studio (see for example their compiler commentary: http://blogs.sun.com/x86be/entry/compiler_commentary_support_in_sun).  VC8 is far behind that in any respect, even though the optimizer is not that bad.

Second, give the users more options. If I want super-expensive inlining where the compiler is going to spend hours to find out which one-liners can be directly expanded, let me do it, same goes for loop unrolling etc. Don't force the people to get used to the compiler, rather allow the compiler to be driven by the user with loads of options.

Third, try to help people who use modern development methods. Writing template static dispatchers is not easy already, together with a buggy/sluggy IntelliSense which does display bogus stuff half of the time and a compiler which does not inline single call statements, I'm often using the VS as a better text editor with a 3rd party compiler in the background.

BTW What's the recommended way to get in touch with the compiler dev team to share such kind of feedback, somehow I get the feeling that commenting blog entries is surely not the right way?

We use VC6 as an IDE for third-party cross compilers targeting various micros via external makefiles. With Visual Assist and Window Tabs it actually makes it halfway pleasant to write embedded C code - as much as it can when you're targetting a 4K device anyway. Most cross compilers can be run from a command prompt or from an external makefile, and their 'IDE's leave a lot to be desired.

We'd love to be able to do this in VS2K5 or VS2K8.  You should market an express version that these compiler writers could target with their products - the 'eclipse' of the embedded market.

Hello

To answer your question: “BTW What's the recommended way to get in touch with the compiler dev team to share such kind of feedback, somehow I get the feeling that commenting blog entries is surely not the right way?”

You can always use the VC blog at: http://blogs.msdn.com/vcblog/ - a number of us read this almost daily. For example, if you look at Stephan’s (one of our Library Developers) recent post at: http://blogs.msdn.com/vcblog/archive/2007/08/10/the-future-of-the-c-language.aspx  you can see the long and detailed conversation that followed between him and interested customers. If you would like to interact with Steve Teixeira (our Group Program Manager) and/or Bill Dunlap (our Business Manger) you can reply to their Channel 9 video too: http://channel9.msdn.com/Showpost.aspx?postid=281987.

Also you can feel free to email me and I can send comments on to the relevant people. My email address is “my first name” at “you know where”.com.

Thanks

Damien Watkins

Hello Tom

Re your comment: “I will be upgrading to Orcas specifically because I have heard that it has an integrated class diagram feature.  This is important to me.”

The VC++ Class Designer team recently asked for feedback: http://blogs.msdn.com/vcblog/archive/2007/07/23/class-designer-needs-your-feedback.aspx. Although the survey may be closed now you can still add comments/suggestions/feedback on the VC blog page of you like.

Thanks

Damien Watkins

Hello

To answer your question: “BTW What's the recommended way to get in touch with the compiler dev team to share such kind of feedback, somehow I get the feeling that commenting blog entries is surely not the right way?”

You can always use the VC blog at: http://blogs.msdn.com/vcblog/ - a number of us read this almost daily. For example, if you look at Stephan’s (one of our Library Developers) recent post at: http://blogs.msdn.com/vcblog/archive/2007/08/10/the-future-of-the-c-language.aspx  you can see the long and detailed conversation that followed between him and interested customers. If you would like to interact with Steve Teixeira (our Group Program Manager) and/or Bill Dunlap (our Business Manger) you can reply to their Channel 9 video too: http://channel9.msdn.com/Showpost.aspx?postid=281987.

Also you can feel free to email me and I can send comments on to the relevant people. My email address is “my first name” at “you know where”.com.

Thanks

Damien Watkins

[Jalf]

> The main thing that bugs me currently is that

> the STL seems much slower than necessary.

There are definitely areas in which the performance of our Standard Library implementation can be improved.  If you can create self-contained test cases that clearly demonstrate areas in which we could be faster, please file bugs with Microsoft Connect.

> I've seen tests showing STLPort's vector class

> to be a full 4 times faster than the MS one.

Missed inlining opportunities can often trigger such massive performance differences.  Fortunately, these are often easy to fix, with a minor simplification of code.

> So why enable bounds-checking on operator[] by default?

Security.

> And when we want it, we can enable it easily enough.

It's best to err on the side of security than the side of performance. (At least, when the performance cost is small enough.) People who notice performance problems can easily disable _SECURE_SCL and friends, while noticing security problems is a lot harder (and more painful).

> And finally, I think it might not actually reduce the number of bugs at all.

_HAS_ITERATOR_DEBUGGING's purpose is to find bugs during development so that you can squash them.

_SECURE_SCL's purpose is to serve as a last line of security defense - your program may be buggy and trigger a heap overrun on the user's machine, but at least the program will die instantly rather than compromising the machine.

I know we haven't communicated their purposes as clearly as we might have ("iterator debugging" and "iterator checking" sound so similar).

> And finally, the justification for all this that I've heard is that

> "when you use our iterators, we can eliminate most of the bounds

> checks, so you don't suffer the big performance hit". Yeah, great,

> except reminds me again, what is the purpose of std::vector? That's

> right. Random access. In a lot of typical cases, you don't iterate

> through the vector, you perform a bunch of random accesses, so you

> *do* get the performance hit.

It's "when you use Standard algorithms, the bounds checks are lifted out".  Even in the absence of _SECURE_SCL, it's a really good idea to use Standard algorithms whenever possible.

> I think the whole "Secure SCL" is a mistake, at least by default.

There is a tradeoff here.  Performance is very, very important, but so is security.

[Craig Vayes]

> I would suggest roughly 90% be spent on improving standard compliance.

> While there has been much improvement lately, significant portions of

> ISO/IEC 14882:1998 and 2003 are still not implemented or need further

> attention.

2003 supersedes 1998.  :-)

Exactly which portions do you consider to be "not implemented or need[ing] further attention" in the compiler and standard library?  (Two-phase name lookup, exception specifications, and export are well-known to be missing.  If I had my way, export would be erased from human memory...)

Thanks,

Stephan T. Lavavej

Visual C++ Libraries Developer

Hi ~AVA:

The behavior you are observing is not by design in the Visual C++ IDE.  The problem you mention about the case changing to lower case when debugging, compiling and browsing is a product bug.  We are currently working on a VS 2005 hotfix for the latter (browsing).  Coincidentally, I happen to be testing it.  It is currently in the Customer Testing stage. Basically, on this stage our PSS guys work with the customer that reported the issue to make sure our fix addresses their problems.  After that, we'll test it one last time and make it available.

Can you provide us with examples on how compiling or debugging changes the case of a file name?  I think for the debugging scenario, it might be a side effect of the same problem we are fixing for browsing.  Compiling would be a whole other story.  Can you elaborate?

Thanks for your feedback.  Keep posted for that VS 2005 hotfix.

Alvin Chardon

Visual C++ IDE Team

Stephan,

> If I had my way, export would be erased from

> human memory...)

Take a look at SC22/WG21/N1459, section 6.3

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1459.html

Export is in the standard and it is not going anywhere. Comeau and Borland compilers support it. Because VC++ does not implement it, more and more of our code base does not cross-compile as is. I keep looking for it it with each new release of VC++, but to no avail. How about simply announcing which version and year it will be implemented so that I can check back then.

Earlier this week Soma, Vice President for the Microsoft Developer Division, blogged about the future

[Allan Richards]

> Export is in the standard and it is not going anywhere.

I don't always get my way.  :-)  (Let's not even mention the eternal enemy, vector<bool>.)

> Comeau and Borland compilers support it.

Borland supports export now?  (I don't follow news for that compiler.)  For a very long time, only EDG-powered compilers supported export.

> Because VC++ does not implement it

Neither does GCC.

> more and more of our code base does not cross-compile as is

If you want your code to be actually-portable (rather than theoretically-portable), you should avoid using export.  Support for it is not widespread.  A great majority of C++ developers get along just fine by ignoring the existence of export, and some (e.g. me, and anyone else who takes the position advocated by "Why We Can't Afford Export") are convinced that it doesn't actually buy anything, and carries significant complexity costs.

How exactly does export help you?

Thanks,

Stephan T. Lavavej

Visual C++ Libraries Developer

The fact is that export is part of the standard, so I should reasonably be able to assume that it will be available on standard-conforming compilers. Suggesting that developers avoid standard-conforming code to be portable does not seem right. Perhaps I am wrong, but I have always thought that being standard conformant was a high priority of VC++.

In my experience, most developers "get along just fine" without export because they have never had a chance to use it. It took me a little bit to get used to, but now I find it quite useful when writing templates. Since VC++ (and gcc, as you pointed out) does not support it, though, I always need to sprinkle some preprocessor magic around it to enable "portability".

 We're writing code that compiles on halve a dozen platforms by even more compilers (or compiler versions).

Standard conformance is our main concern. If all compilers were standard conforming, we'd lose most of our headaches instantly.

 >>Exactly which portions do you consider to be "not implemented or need[ing] further attention" in the compiler and standard library? (Two-phase name lookup, exception specifications, and export are well-known to be missing.<<

 Two-phase lookup is what I miss most as VC lets slip truly and hilariously absurd bugs due to this. I am actually forced to write much of my template code on the Mac (which I hate, since it forces to grab the mouse for just about everything), as its compiler catches these errors.

 >>If I had my way, export would be erased from human memory [...] some (e.g. me, and anyone else who takes the position advocated by "Why We Can't Afford Export") are convinced that it doesn't actually buy anything, and carries significant complexity costs. How exactly does export help you?<<

 A big problem we have with template code is the cascading dependencies. If I want to give users of my code the template T, I also have to give them access to T1 which is used in T's implementation. However, T1 needs T2 which needs T3 which... This means pulling in hundreds of LOC and polluting namespaces with irrelevant identifiers. And if the minor helper template irrelevant::detail::helper<T> changes we need to re-compile millions of LOC . (That's no theoretical scenario. We spent a lot of money on IncrediBuild to "solve" this problem by throwing raw processing power at it.) I have been told by people who (implemented or) work with export that it solves the problem of cascading dependencies. Which is why we would be happy to have it.

So there seems to be general consensus that VC++ has fallen behind in a number of important ways. It's obvious that the product hasn't received the attention it needs for quite some time, and now we're hearing that this is going to change.

This is great news indeed, but when is Orcas+1 actually going to be delivered? I would just like to remind MS that it's very hard for commercial application developers to wait around - our need to evolve our software products (to remain competitive in our respective markets) constantly evolves. If VC++ cannot evolve with us (and it hasn't), we must pursue other native code development options.

My suggestion at this point? Compensate. Get us the capabilities we've been lacking sooner rather than later, whatever it takes.

Please cancel Orcas.

I'm serious. Based on trying the beta (VERY disappointing) and reading blogs, it appears that it's nothing more than a Visual Studio 2005 SP2. In the last month you and several other Microsoft employees have made it very clear that almost ALL the important changes and fixes are for a mythical product called "Orcas+1". Since that's what I want and thought Orcas was going to be, why should I waste my time with Orcas? Answer; I won't. Seriously.

I've been planning a major update and migration for our entire company next spring in  an effort to have a single development platform (we use three version of VS C++.) I am on the verge of canceling this migration entirely AND PERMANENTLY.

So, congratulations, in regards to C++ you guys are now acting like Borland. (In case you didn't get the point--your middle finger is blinding me.)

Brian said:

"Help - more like VC6 - The 'Locate' button was heaven!"

I think you are talking about the 'Locate in the TOC' feature - ?  It is still there, and it wasn't obvious to me at first, either - it is a book icon with a left arrow and right arrow, just left of the Ask a Question Icon/Button on the default toolbar.

Other features I miss from VS6 are Search Titles Only, Search in These Results and more...how about you?

...

Some of you will remember me from my time on the VC++ team.  I left VC++ to work on help.  It hasn't turned out to be as straight forward as I thought it might be, but please know I'm lobbying for the changes, resources and investments needed to improve the help! I am also working with the content teams' managers to prioritize and work on documentation specific improvements.  Thanks for all of the feedback here, it does get attention!!  

- April Reagan

Developer Division User Education Program Manager

I really like to push standards compliance in blog comments, but i am much more excited about C++0x than export.

Hell, even C99 has a few nice features (specially those that bring C closer to C++ and those that are coming in C++0x)

Wish list:

1. Stable IDE for  ISO C++  *and*  C++/CLI

2. See 1.

Thanks - Mike

Interop is important to me!

[Allan Richards]

> "It took me a little bit to get used to, but now I find it quite useful when writing templates."

As I asked earlier, what exactly does it do for you?  "Why We Can't Afford Export" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf) addressed every claimed advantage of export that I've heard of (but perhaps there are others).

[Hendrik Schober]

> "Standard conformance is our main concern."

Mine too!

> "I have been told by people who (implemented or) work with export that it solves the problem of cascading dependencies."

But it doesn't - see "Phantom advantage #2: Fast builds, reduced dependencies" in the paper above.

[ikk]

> "I really like to push standards compliance in blog comments, but i am much more excited about C++0x than export."

That perfectly captures my state of mind.

Stephan T. Lavavej

Visual C++ Libraries Developer

I have read a few comments, and many here seem to think that C++/CLI is only useful for migration, and that good .NET-Apps should be written in C# exclusively anyway.

This may be true for some apps, but it's definitely not a general rule: We're building a .NET app from scratch, and we're building lots of C++/CLI code, mainly for performance-critical parts and for code parts that needs to use complex 3rd-party libraries (with lots of pointers...). IMHO that's one of the key advantages of the .NET framework: You get all the benefits of a managed environment, but it's still very easy to program closer to the metal where you have to. I hope future development of C++/CLI continues to support this.

And, btw, I also think that SxS hell (the replacement for dll hell) should be improved. What I really would like to see would be a tool like Depends that can tell you exactly what other assemblies and P/Invoke'd dlls some assembly will load at runtime, and where it will look for them. Currently I have tools like Reflector that tell me what an assembly references, but that doesn't include P/Invoke-DLLs, and it doesn't tell me from where it will look for them. I also have Depends, but that can only tell me what DLLs get loaded while a programm is running, so I need to manually test all the functions of the program to find out which assemblies it uses, because they are loaded on demand. It's also not a great help if assemblies aren't found. Fuslogvw can sometimes help when an assembly can't be found, but it doesn't help much if a P/Invoke'd DLL or one of it's dependencies is missing.

I've been using VC since VC. Most of my complains against VC2005 have already been said by others.

IntelliSense is terribly slow and useless 90% of the time (several coworkers have asked my how to disable it, and they have a Core 2 Duo 2.66 GHz !). Useful (and more importantly, correct) refactoring tools would be nice.

Standard compliance is one of the best, but compared to the latest GCC version it is clearly inferior (e.g. template friends). Even if not strictly required by the standard, GCC is also able to check non-instanciated template code and detect several errors that VC2005 does not see (e.g. undeclared variable name). And of course their is C++0x.

_SECURE_SCL should not be on by default. Most people do not know it exists and wonder why their applications are 4 times slower.

Also, disabling _SECURE_SCL implies recompiling *ALL* used C++ libraries. E.g. linking an application compiled with _SECURE_SCL=0 with Boost, which is compiled by default with _SECURE_SCL=1, will result in weird and random crashes that are hard to diagnose.

I do not buy the _SECURE_SCL should be on by default because of security. _SECURE_SCL mostly affects the STL, and code using the STL is already inherently more secure than the typical C-buffer-overflow-code. Checked iterators are a good thing, I'm actually very glad that they've been implemented in VC2005. I just do not think it's a very bright idea to enable it by default for Release builds.

VC2005 STL implementation is significantly slower that the one that ships with the latest GCCs (even with checked iterators disabled). In my experience, areas where GCC is significantly faster (i.e. 2-4 times faster) are strings and streams. I've also found that their containers implementation tends to be faster due to better memory/cache allocation and management.

For example, our OBJ 3D Model loader (that basically linearly parses an ASCII file) is still two times faster on a Linux/GCC old Athlon XP 2.1 GHz than on a Windows/VS2005 Core 2 Duo 2.66 GHz.

The build system on multicore is not very logical. VS2005 does build projects in parallel whenever possible, but will only run one thread for compiling one project. Makefile have solved that problems for decades: one project compilation should still use multiple available CPUs by compiling several files at the same time.

As it was already proposed, VC redit runtime should be on Windows Update to avoid useless deployment hassles.

I've been using VC since VC.

Make that VC6. ;-)

You know what I would like to see? Stop breaking existing code.

For example: Service Pack 1 for VS.NET 2003 broke the editor. When you create a new document, the cursor doesn't display until you've entered a second line. If you do a select all and then delete, the cursor stays on the same line as its last position, even though the text has been deleted.

In VC6, you could use block indent/outdent to increase/decrease the tab level of a block of code. If some of that code wasn't indented partially with spaces, it still worked. VS.NET 2002 and 2003 broke that. They substitute tab characters, period. That forces the user to go back and replace the spaces you removed.

I know these sound like nits. The point is, these are things that simply ought to be _right_, with no questions.

I'm leaving a comment to emphasize that "F1 isn't king anymore".

I loved the context sensitive help integration in VC6. You just put your cursor on something, pressed F1 and got the information you needed.

An by "information you needed" I mean reference information! No community content or whatever.

If I'm looking for community content I'm using my web browser to search for that.

And as already mentioned here before the performance of the help system is bad. It takes much more time to have any result displayed after pressing F1. During the waittime  I can easily start IE, do a google search. I always thought VS is hosting the IE to display help content, so why is it much more slower than the IE itself which must transfer the contents via tcp/ip? I stopped using F1 after VC6.

Also I would like to see some "Intelli-Content". Means if I'm working on a native MFC project It's very likley I want to see the samples for an API function in native C++ for the native API function, not some C# for Compact Framework. If VS knows what type of project I'm working on please use only the subset of helptopics I need to view for my project.

And please do this for VS2005 SP2. The missing help is a major issue to me

Thanks

Jan

[Tanguy Fautre]

> _SECURE_SCL should not be on by default.

Think carefully - which is actually better?

1. Having extra security barriers enabled by default, making developers of applications whose performance is significantly degraded have to go figure out that the security barriers exist and then figure out how to work around them or turn them off - probably during development, since the performance will be noticed then - OR

2. Having extra security barriers disabled by default, making developers of applications that contain security bugs have to go figure out - *after a security exploit* - that the security barriers exist and then figure out how to turn them on - probably after development, since security exploits won't be noticed until then, so now they have to ship a security patch and suffer the hit to their reputation.

Having to choose a default for all VC users worldwide, we chose "on".  Can you blame us?

> weird and random crashes that are hard to diagnose.

If you read my latest VCBlog entry, I mentioned that we are investigating how to diagnose _SECURE_SCL mismatch between statically linked translation units in VC10.

Yes, in VC9 things are quite painful if you are not extremely careful.

> code using the STL is already inherently more secure

> than the typical C-buffer-overflow-code.

Yes!  But more security is better, at a small performance cost.  _SECURE_SCL usually has a small performance cost.

> areas where GCC is significantly faster

> (i.e. 2-4 times faster) are strings and streams.

If you can construct self-contained test cases where VC's Standard Library implementation is significantly slower than GCC's libstdc++, please please PLEASE file a bug in Microsoft Connect.  We (myself in particular) are very interested in improving Standard Library performance.

Stephan T. Lavavej

Visual C++ Libraries Developer

I have been coding in C++ since the late 80's, and have written numerous books on the subject (mostly early 90's.)

At first I was of the opinion as many here are that MFC is important and the focus for new work on Visual C++ should be on cleaning up the many problems it has.

But recently, after using WinForms in C# for a while, I've changed my mind. Not having to worry about resource ID's, (a fatal flaw of MFC) and being able to move code for dialogs, controls around with ease between projects makes the WinForm approach much superior, not to mention all the fancy new dressings that are available to  keep your app in fashion.

Having had a stint with C# and WinForms for a while, and being much more productive at building gui's with it, I'm moving back to C++/CLI, but will stick with WinForms, either in C# or C++/CLI.

I'm of the opinion it's much easier to learn WinForms, etc, using C# than C++/CLI mainly because of cleaner syntax, and no longer having to hassle with header files. But having learned the gist of how it's done in C#, it's time to go back to my favorite language of choice, C++.

C#'s screwed up memory management (where it appears the designers of C# were severely confused about what destructors were for, which is to clean up after the object, not neccessarily just worry about freeing memory, and thus the designers discarded deterministic destructors), is my opinion an almost fatal flaw of C#, and the work arounds for it are much worse than the disease (the Dispose() pattern is confusing, convoluted and error prone -- if only the C# designers had implemented destructors right in the first place, C# would be a fine language.)

Thus, I vote for making C++/CLI work better with WinForm's, etc. For example, have the code generator create both headers and source files for the designer code, rather than just jamming it in a header file. Make the generated code more readable and formatted better. Follow C#'s approach and split the class definition and implementation into code generated pieces and user crafted pieces.

Better yet, figure out some mechanism for eliminating the need for header files in the first place. The #using approach of C# is much superior. I found that going back to C++ was a real headache, having to maintain both a header and source file. I'm not saying get rid of header's altogether, they are part of the C++ standard and should be kept in, just add the module approach of C# somehow (and I have no idea how.)

Don't worry about what kind of extensions you need to make to C++ to do this -- who cares if you add keywords for gui purposes, gui code is rarely portable anyway, so who cares if it "breaks" the language this way. Just be sure to keep the ability to write standard C++ code for the non-gui parts.

Microsoft has already done a lot of this with the managed extensions to C++ in C++/CLI. And I think the effort along these lines has been commendable. (And thank heavens you guys got destructors right in the managed C++ world.)

As far as making STL work better in VC++, this may sound heretical, but I don't care one bit. I personally think STL is an abomination. I avoid it like the plague. It's not that having standard libraries is a bad thing, but STL has gone way overboard. And really, having to include thousands and thousands lines of code everytime you include a header to use STL is really dumb dumb dumb. Sure, doing meta-programming with templates is a fascinating adventure, but for production code/maintainence, it is a nightmare. (Sorry Stroustrup.)

STL wouldn't so bad if the whole implementation of templates wasn't severely broken in the language. Not being able to separate implementation from definition for templates is almost a fatal flaw. It's not completely fatal, if you use templates sparingly and use them simply. Unfortunately, that doesn't sound like STL, does it?

>I left VC++ to work on help.

>It hasn't turned out to be as straight forward as I thought it might be,

>but please know I'm lobbying for the changes, resources and investments needed to improve the help!

>

>- April Reagan

Please April Wan Kenobi ... your our only hope ;-)

Time to summarize some of the big things we've heard in the last set of comments:

1) Improve "fit & finish" -  I totally agree that this is something we need to do moving forward.  The features we add need to feel right for C++ developers.  

2) C++/CLI - I want to assure people that C++/CLI is not going away.  It's very important to our strategy and we will continue work in this area.  Understand, however, that we are not pursuing the path of making VC++ a "first-class" .NET development environemnt.  C# and VB are perfect for this role.  There's nothing to stop you from using the C++/CLI language facilities to build a full-fledged managed application, but - moving forward - our feature set will not be geared towards this.

3) Orcas - Please reserve judgment on Orcas until after launch.  As I hinted at previously, we are working on some major library updates around MFC and TR1.  Stay tuned.

Thanks again for the very interesting posts.  I know that some of you are frustrated - and you have a right to be.  Hopefully you'll see that our transparency (both here and in our blog) represents a new dynamic.  Our strategy is firmly in place and we know we need to supplant VC6 as the "world's greatest native development tool".  Hang with us and we'll do you right.

Bill Dunlap

Visual C++ Development Team

I have to admit that I was rather surprised about this, i.e. that the VC Team speaks openly on new futures and actively seeks feedback. In the past, I had rather the feeling (and I'm sure I wasn't the only one) that Microsoft "is doing their own thing" and does not listen to customers any more. Good to see this change.

I'll offer a slight dissenting view to Bryan Flamig. I find WinForms vastly inferior to the traditional resource file (MFC in his parlance) method since it mixes interface and implementation.

Likewise, I prefer the header/source separation of C++. While I easily adjust to the C# model, I sometimes get annoyed by having my member definitions getting lost in all the code. Nevertheless, I do agree that it is jarring to switch back to header/source when doing C++/CLI since my mindset is usually more in the C# camp than in the traditional C++ camp.

I totally agree that non-deterministic destructors (or at least a method that's guaranteed to be called when a class goes out of scope) is a big problem with C#. It actually creates resource leaks which are far worse, in my own experience, than memory leaks.

I also agree that STL is an abomination. I personally find the non-inheritable model to be beyond stupid. Plus, all too often it's like killing mosquitoes with a sledgehammer. Beyond that, I just don't like the way it, and boost for that matter, were designed. (Long before STL and Boost, like many C++ developers, I wrote my own very lightweight collections library. It still blows STL and Boost away for what I need.)

Incidentally, a huge problem with C++/CLI is that the documentation is simply terrible and there is very little comprehensive sample code.

[Bryan Flamig]

> thus the designers discarded deterministic destructors

Indeed, deterministic destruction is underappreciated.  Modern C++ avoids resource management problems *and* the complexities introduced by garbage collection.

It also appears that shared_ptr in C++0x will have a cycle collection ability.  (This has not yet been voted into the Working Paper, but it's still under development.)

> Not being able to separate implementation from definition for templates is almost a fatal flaw.

It is a fundamental consequence of how templates work.  The object code (which is just machine code with a few loose ends not tied up) generated by a template can be massively different depending on how that template is instantiated.  Therefore, the definition of a template is required at the point where it is instantiated.

[Joe]

> I personally find the non-inheritable model to be beyond stupid.

Inheritance has been overused in C++.  ("Object-Oriented Programming" was all the rage once upon a time.)  The problem is that inheritance introduces extremely strong coupling - the relationship between a base and derived class is stronger than any other relationship except friendship.  Runtime polymorphism also causes programs to forget types, and dynamically discover them through virtual function calls.  Often, loose coupling without forgetting types is desired.  This is what templates enable.

The simplest example of this is containers.  In olden days, people used "based object" containers, by making every object derive from an Object and then having a container of Object *.  The problem with this is that you have to cast pointers upon getting them out of containers.  You also have to deal with resource management (something that wasn't completely solved until shared_ptr - which is a template).  And you can accidentally make your containers heterogeneous, because you have relaxed your type safety.

The STL did away with this true abomination and made containers work with value types.  This is a much simpler model that is also more robust, and works with builtin types as easily as user-defined types.  (int, after all, does not derive from Object.)

Note that when you combine shared_ptr with the STL, you can now put polymorphic objects in containers - the best of both worlds.  Container-of-shared_ptr is an extremely powerful construct.

Stephan T. Lavavej

Visual C++ Libraries Developer

Hello

Regarding your comment (Saturday, August 18, 2007 4:17 AM by Anonymous):

“I have to admit that I was rather surprised about this, i.e. that the VC Team speaks openly on new futures and actively seeks feedback. In the past, I had rather the feeling (and I'm sure I wasn't the only one) that Microsoft "is doing their own thing" and does not listen to customers any more. Good to see this change.”

I am sorry to hear that we have not been as attentive or responsive as we should have been – thanks for taking the time to let us know. Going forward please drop by the VC blog whenever you get the chance; we really enjoy posting about what we are planning/doing and soliciting input/feedback on all aspects of VC++: http://blogs.msdn.com/vcblog/

Thanks

Damien Watkins

Visual C++

Regarding the comment about "Incidentally, a huge problem with C++/CLI is that the documentation is simply terrible and there is very little comprehensive sample code."

I totally agree.

I will for sure pass this along to the doc folks. Hopefully, in areas that apply we should have samples on all languages.

Thanks,

Ayman Shoukry

Lead Program Manager

VC++ Team

Firstly I would like to thank everyone who has the taken the time and gone to the effort of writing to this thread – we find your first hand comments invaluable in directing and prioritizing our work.

C++ Intellisense is a topic that came up several times throughout this thread. I agree with you that today’s experience with Intellisense is poor, both in terms of performance and scalability. As Bill Dunlap noted above, we are working on a rewrite of our compiler front end that will provide Intellisense functionality at least as good as any other compiler for the our Orcas + 1 release. Of course we also realize that we need to address some of the pain-points with Intellisense in the immediate future.

With this in mind, we’ve been working throughout the month of August on fixing some of the performance issues reported. Bear in mind however, that due to the complex nature of this component we are not be able to address every issue. We are looking first at increasing the responsiveness of the IDE during expensive Intellisense operations, especially when using it with large scale codebases.

We plan to release these fixes for both VC2005 and Orcas as a downloadable hotfix this autumn. Once the download is available, we will post the link on blogs.msdn.com/vcblog. Please stay tuned as we look forward to your feedback on this hotfix.

Thanks,

Marian Luparu

Visual C++ IDE

Pass this on to the help people:

Help is becoming more and more useless.  For example, if I search for some API, I get all kinds of .NET trash, even though I'm working on native Apps.  If I set the filters to concentrate only on VC++ Native, I *still* get .NET trash, all kinds of CLI methods.  These would only be of interest if I was programming using CLI, which I don't.  The search in VS2005 is truly useless.

NEVER drop a KB article!  If it becomes obsolete, then its content should change to say "The former contents of this KB article are no longer relevant starting with VS2005" (or XP Pro, or Vista), but the problem is that it is *still* relevant to VS6, running under Windows 2000.

I often either receive code or write code based on a KB article and see, or include as my comments, "as per KB article XXXXXXX".  But a few years later, when I go back to look at the article to see why the code looks like it looks, the KB article is simply gone.  This is inexcusable.  We need to understand legacy code, code that is a decade old, perhaps written under VS4.0.  If a workaround is no longer needed, we need to know that the code we have can be rewritten.  If a special hack is no longer required, we need to know that we can remove it.  But since we don't know why the code is there, we don't know anything about its significance.  There is absolutely no excuse for deleting an article because it has become obsolete; we need to know why it had relevance in the first place!

Hello Joseph,

Will for sure pass your feedback to our help folks.

 Thanks for sharing such issues.

Regards,

Ayman Shoukry

Lead Program Manager

In Orcas we have a new Index/TOC filter for native development, so that should help at least in the TOC/Index pane.

KB articles are owned by CSS, so I've passed on your feedback to them.

Orcas includes a major F1 fix that makes F1 work better for .c files. While I'm not sure it will address all the concerns raised here, it should improve the situation, especially for C code.  

The Help system in general is in need of a dedicated, sustained improvement effort.  So far that hasn't happened, but feedback like this helps us make the case that it's needed.

Thanks!

Gordon Hogenson, Visual C++ Documentation Manager

Gordon,

For far too much of the MSDN api documentation, the documentation entries are just a minimally reformatted function header from a source code file.  

The api/library calls that do include sample code most times do not have any real world error handling.  Good example code has a) identifying if an an error occured and b) breaking the error down into specific test cases.  

For example, to open a file:

if (open file failed) then

{       //this is really bad example code

print 'open file failed'

return;

}

else

{

do processing

}

Versus better sample code

if (open file failed) then

{

   if (failure code is 'file is in use by someone else) then

        {

        ....

        }

   if (failure code is 'file does not exist') then

        {

        ....}

   and so on until the major errors are handled

}

else

{

do processing

}

I find that I have to sandbox test most of the library/API calls because the sample code either does not exist or does no error handling.

My real world systems need to return a meaningful error code to the end user and, more importantly, to our technical support staff.  A generic 'file could not be opened' is ok but much less useful than 'file ABC.txt could not be opened (code E_0345)'.  E_0345 would refer to a specific block or C++ code and a specific api/library error code.

Stephen Kellett wrote:

“Please can we have more than 1 watch window in VS8? VS 6 gives me 4 - so much more usable.”

VC8 also has 4 Watch windows available just like VC6. Default shortcuts are Ctrl+Alt+W, ‘n’ where n is between 1..4.

Steven Ackerman wrote:

“Most cross compilers can be run from a command prompt or from an external makefile, and their 'IDE's leave a lot to be desired. We'd love to be able to do this in VS2K5 or VS2K8”

Starting with VC2005, you can use the IDE for makefile projects. Use File > Project > New Project from Existing Code, specify the files part of the project, the build, rebuild and clean command lines you use, and you are ready to go.

Sergey Kartashov wrote:

“I have Russian Windows and Italian resources. Each time I'm saving Italian resource file all accented symbols are lost.”

Can you try saving the RC file as Unicode? On VC2005 SP1 or above, select “View Code” in the context menu, then File > Save As..., and in the Save dialog, select from the Save split button “Save with Encoding”. In that dialog, pick Encoding: “Unicode – Codepage 1200”. If you are still seeing dataloss after this, please open an incident on connect.microsoft.com and follow up with me on email at mluparu at ms.

John M. Drescher wrote:

“I would like to see a large  improvement in the build system to at least make better use of multi core processors while building”

Tanguy Fautre wrote:

“VS2005 does build projects in parallel whenever possible, but will only run one thread for compiling one project”

As Tanguy already noted, VC2005 already support multi-proc build on project level. Coming with VC2008 there is also the ability to build multiple files in the same project in parallel. All you need to do is add /MP to your cl.exe switches. For details please refer to Peter’s VCBlog entry: http://blogs.msdn.com/vcblog/archive/2007/03/12/multi-processor-builds-in-orcas.aspx  

On the same topic of build system improvements, Managed Incremental Build is another new feature coming with VC2008 that improves throughput in scenarios where you’re building managed C++ projects. More details here: http://blogs.msdn.com/vcblog/archive/2007/03/02/managed-incremental-build.aspx

Thanks for all the feedback. And keep it coming!

Marian Luparu

Visual C++ IDE Team

Interop technologies are extremely important.  The majority of us cannot 'rewrite' everything just so it is all in C#.  There is no good business reason to disrupt application stability and take away resources from being able to add new functionality for our customers.

Of course, the ideal scenario would be 'true' support for continued native development.  Why is the only way to take advantage of new features such as WCF, WPF, LINQ only available with 'managed' code?  And then to make it worse, the support of C++/CLI by Microsoft is dismal.  At all Microsoft events, conferences, magazine articles; the only decent level of support by Microsoft representatives are for C#.  Why no representation for C++/CLI?  Why such poor marketing of the C++/CLI capabilities?  It appears that C++ was abandoned and therefore we must now change everything we’re doing if we want support by Microsoft.  

I find it disgusting.  If I must now rewrite everything, why in the world would I choose to follow Microsoft again?  They have already demonstrated that they only care about the ‘new and fluffy’.   Significant more time is spent in maintenance.  Very little time (comparatively) is spent in the ‘new and fluffy’ startup code.

If the ‘future’ is all about running in a virtual machine, then I would rather go with Java.  At least Java isn’t constantly pulling the rug out from underneath developers.

And 'now' you say that you care about us and want to know what we want so that 'maybe' in the future something 'might' become available to help us with our C++ code base.  

You do have us stuck, what can we do?  Rewriting everything in Java makes about as much as sense as rewriting everything in C#.  Basically, it doesn’t make business sense.

[Stephan T. Lavavej]

> "I have been told by people who (implemented or) work with export that it solves the problem of cascading dependencies."

But it doesn't - see "Phantom advantage #2: Fast builds, reduced dependencies" in the paper above.

I think you might like to read another paper, written by Jean-Mark Bourguet on this issue:

http://www.bourguet.org/cpp/export.pdf

Please also note that, although the previously cited paper was presented to the C++ standard committee, and was quite debated there, the decision was not to remove export, not for compatibility reasons, I beleive, but for its own benefits.

[Stephan T. Lavavej]

>> _SECURE_SCL should not be on by default.

>

>Think carefully - which is actually better?

>

> 1. Having extra security barriers enabled by default [...]

> 2. Having extra security barriers disabled by default [...]

I can understand the importance you give to security. However, all C++ programmers I personally know do always disable it. Hence, for all these programmers (myself included), having it enabled by default is counter-productive.

I realize that alone I'm not really statistically relevant. But it may be good to know actually how many C++ programmers do leave it enabled versus how many disable it.

>> code using the STL is already inherently more secure

>> than the typical C-buffer-overflow-code.

>

> Yes!  But more security is better, at a small performance cost.

>  _SECURE_SCL usually has a small performance cost.

Depends on the application. I've always found _SECURE_SCL performance impact to be non-negligeable.

>> areas where GCC is significantly faster

>> (i.e. 2-4 times faster) are strings and streams.

>

> If you can construct self-contained test cases where VC's

> Standard Library implementation is significantly slower

> than GCC's libstdc++, please please PLEASE file a bug in

> Microsoft Connect.  We (myself in particular) are very

> interested in improving Standard Library performance.

I've just submitted the bug report. Its ID is 294551.

Submitted another STL performance bug report. ID 294554.

If the only useful fixes are coming in "Orcas+1" drop Orcas altogether and go straight to "Orcas+1".

I will gladly pay you Tuesday for a hamburger today - Wimpie

[Tanguy Fautre]

"all C++ programmers I personally know do always disable it."

If any of their applications have security exposure (and the ones that don't are few and far between), that makes me nervous.

It's really tempting to hit the "go faster" button, but you should think really hard about what you're giving up.

Thanks for submitting the two perf bugs!  They've been ported to our internal database and I've tagged them so I can track them.  The /MT versus /MD one is especially intriguing.

Stephan T. Lavavej

Visual C++ Libraries Developer

In all this discussion thread I've something else to say.

People here are talking all sort of stuff regarding VC++ stuff with regard to the commercial application sure they are but lets not forget the Open Source Developers too. Specially guys like me who are trying to port open source software on windows and trying to avoid mingw or cygwin.

Here is my wish list. I know this will be like second priority for you guys but please put some thoughts.

1. nmake compatibility: As of now VC make file and gnu make files are not cross compatible. Please provide us with some tools or build support conversions of make (or nmake for that matter) to vcproj files.

Currently we are setting up a cygwin command line environment using gnu make setting environment variables like CC=cl and LD=link. but this requires lots of rework and tweaking in the rules files. cmake folks have done great work but it is very slow.

2. CVS/SVN Support: Even a very basic support will help us a lot. Please consider this if this is possible.

3. Project From Existing Code: This wizard is not very helping. What I'm looking forward with this wizard is to  do a) automatic library dependency scanning stuff and if the required library is not available it should suggest the meaning full library names (not just the missing header files).

4. Support for POSIX (I know I'm asking too much) libraries: libc, libstdc++, libcrypt(OpenSSL),and libpthread. Ok I do know that this is like random thing I'm asking for but see, this helps in portability.

5. Backward Compatibility with Visual Studio Plug-ins: Its not their. If it’s for marketing reason I can’t go any far talking about this

6. Support for Backporting: VS should support earlier version of common Microsoft libraries (mfc/atl/crt) and some IDE option for enabling or disabling earlier version support. Just like we have dotNet target version stuff in 2008.

7. Intellisense: I wont go more in detail, but just to give a quick Idea, each time I open KDE4 (kdelibs) project in visual studio with intellisense makes my computer frozen and CPU usage is 100%. Please do something about that.

8. Document Removed Features in a more better way. Helps us porting application with newer version of IDE.

9. Side by side assembly: Its breaking compatibilities. Please help us with a tool option to disable SxS.

10. Disable secure scl. If we want it we will enable it. Write a KB regarding this

11. Missing Library Suggestion System: Instead of reporting a missing header files, Visual studio should go one step further in detecting and finding the dependency of the project and suggest the users with library names

--------------------------------------------

Some minor stuff:

12.Please have same code beautification as we have with C#. for example,

C#/ if entered code : a=34+45

                               converts to  a = 34 + 45

it improves code readability

13. vcproj and sln files backward compatibility. If you are really adding a lot of stuff into these files while incrementing versions then its OK otherwise it looks very unnecessary.

[Kunal Deo]

> 4. Support for POSIX (I know I'm asking too much) libraries: libc, libstdc++

VC already has implementations of the C and C++ Standard Libraries.  If the programs you are working with specifically require glibc or libstdc++, then they contain nonportable assumptions.

This is why we have International Standards.

Stephan T. Lavavej

Visual C++ Libraries Developer

[Stephan T. Lavavej]

>> > "Standard conformance is our main concern."

Mine too!<<

Good. Can I have two-phase lookup by yesterday please? The lack of it is embarrassing. (Having export by tomorrow would be early enough.)

>> > "I have been told by people who (implemented or) work with export that it solves the problem of cascading dependencies."

But it doesn't - see "Phantom advantage #2: Fast builds, reduced dependencies" in the paper above.<<

Well. I've known Herb's paper for a long time. AFAIK, when he wrote it, he did not have access to a compiler providing 'export'. So it's all what he /thought/ about it by then. (To quote P.J.Plauger: "[...] Sutter gave a glib summary from incomplete data and he was soundly countered by those of us who had some real experience.")

OTOH, Daveed Vandervoorde, who implemented, and P.J.Plauger, who uses, 'export', in newsgroup discussions (which with their threading and ability to quote are so much better than this abomination here, BTW) repeatedly said that it is indeed able to solve the problem of cascading dependencies. (And also, that it prevents cluttering namespaces with irrelevant symbols, which Plauger once said he considers its greatest advantage.)

What do you think I trust more - a many year old theoretical thought or concrete experience?

>> > _SECURE_SCL should not be on by default.

Think carefully - which is actually better?

1. Having extra security barriers enabled by default [...]

2. Having extra security barriers disabled by default [...]<<

No need to think here. The biggest project here currently is at 2.6MLoC. (When you shipped iterator debugging etc. it was probably 2.0MLoC.) Iterator debugging found us about half a dozen bugs in there, which so far had slipped. Let's assume it helped us catch another few, so we're up to a dozen now. A dozen bugs /which nobody ever noticed/. TTBOMK, no report of one your runtime security features kicking in ever came from the field. (We do get other bugs, though.) OTOH, we have to put a lot of effort in speeding up our applications, as /this/ is what customers demand. (Not to forget the gazillions of spurious warnings we get when we compile a well-tested piece of platform-independent 3rd-party code on VC. I think we get a four-digit number of warnings from compiling 3rd-party code. Code we cannot fix, which is well-tested, and very portable. This makes warnings more or less useless, as we can't find the important ones anymore. And all this because you are unwilling to tell those who write unsafe code that they might have to take a book or two and learn a few basic techniques.

>>Intellisense<<

Some of us here have simply turned it of. (Did I say "simply"? Having to rename an installed DLL...) Mine's still on, but don't ask me why. Visual Assist is so much more better. Incidently these guys also proof that you don't need to wait for a new compiler in order to improve on the current situation. Obvioulsy, a new compiler isn't what is needed for this. All it takes is a few determined bright minds.

On last thing: This small edit window is ridiculous. So is the quoting ability. And the fact that there's no threading here. Can't you start this discussion in the newsgroups? It's what they are for, and it's what they are good at.

Here is my wish list for next versions of visual C++ (I know many have already been asked for, I just repeat them to give more weigth)  :

Editor:

- Intellisense that works as well as for C# (I've been quite happy to read it's on its way), refactoring

- Improved help system, faster, with more usefull filters (separating C++ from win32 from C++/CLI from the .NET framework)

- Please, keep the possibility to use the same key shortcuts as in VC6. Modified shortcuts are a real pain for all developpers.

- A UML tool with real time code update on graph modification & real time graph modification on code change (something like the Together software) would make my wildest dreams come true !

Compilation:

- Support for all of C++98 & or TR1. A strict mode that check for non standard extensions, but still enable the use of windows headers.

- Optionnal support for C++0x (at least partially, mostly for the stuff that is no very likely to change before the official standard)

- Improved build time, especially wrt templates

- Improved compilation diagnostics, not with the horrible error list, that hides interresting information, but by enhancing the output window : Optionnal filters for templates error messages, use of color to differenciate error, warnings, #pragma todo,... additionnal shortcut to go to the next error, not only to the next (file/line) info next info about the current error.

Project/Solutions

- The possibility for project properties to define a default for all configurations, and then a configuration by configuration delta with this default. With the current system, it is quite common to edit the project un debug mode, but forget to apply the same modification in release mode. Properties sheet are a step in the good direction.

- Recursive solution. For instance a developper works on a solution that handles his part of the projet, an integrator includes this solution into the daily build solution. Of a unit test solution include the main solution.

Integration with other languages:

- A possibility to automatically provide a .NET C++/CLI wrapper for a C++ class, just like what exists with tlbimp for COM.

- I personally don't care much for MFC. For GUI, I either use .net after creating a wrapper (that's why I'd like simplified wrapper creation) or with something like Qt.

And some misc stuff:

- More intelligent syntax coloring, for instance it would be nice to be able to color the line starting a function definition

- Autolink for windows libraries

- And everything else I forgot :)

I Am very speaking for parallel compiling. It may not be so advanced like IncrediBuild but would spend a lot of time in every project. Some people here speak for increasing compiler performance. Heh, it is nice but can give only small performance increase. Ever developer has at least dual-core machine and it's a shame he cannot employ it. (And I don't mean that parallel thing in VS2005 which looks like some student's work. I want compile single project in paralel!).

Tomas,

The capability to compile multiple files in a single project in parallel exists in the upcoming Visual Studio 2008 "Orcas" using the /MP switch.  You can test it out here: http://msdn2.microsoft.com/en-us/vstudio/aa700831.aspx.

Thanks!

Steve Teixeira

Group Program Manager, VC++

[Hendrik Schober]

> Can I have two-phase lookup by yesterday please?

I'd like two-phase name lookup too.  Unfortunately, it is perceived as being able to break a lot of customer code while providing little value to customers.  While my sympathy for non-conformant code is almost nonexistent, and my desire for conformance overwhelming, I must admit - my only counter to this objection is "but you could have a compiler option".

If you (and others) can clearly make a case for why two-phase name lookup support would significantly help you, above merely checking for non-conformant code, that would help address the "little value to customers" perception.  (Note that by compiling code with multiple compilers, you get the union of their conformance checks - although you also have to endure the union of their bugs and quirks.)

I can think of lots of things I want more than two-phase name lookup, as well.

> What do you think I trust more - a many year old theoretical thought or concrete experience?

Fair enough.  I'm more inclined to believe Vandevoorde and Plauger, instead of the dozens of random programmers I've seen who think they want export (but haven't used it yet).

On the other hand, I notice GCC's conspicuous lack of movement towards export.

[Loïc Joly]

> Support for all of C++98

C++03, please!  :-)

> Autolink for windows libraries

Oh, that would be *nice*.  I love Boost's autolinking.

Stephan T. Lavavej

Visual C++ Libraries Developer

As a full time software engineer and a part time academic, I have spent over a one and a half decades using the Microsoft C++ compilers. In that time I have been trying to build metrics gathering tools, refactoring engines and debugging tools as well as delivering software products to our customers. We have a product-line-architecture at work that has received person centuries of developer effort and weighs in at more than 10 million lines of C++.

Building tools for this volume of code is hard. So I thought I would list the MS offered options and try to build a bigger picture.

Remember the browser database? Well there was an API to read the file called BSCKit. It’s still there if you want it, but it breaks and is old and does not scale to multi million lines of code. What it offered is a wonderful symbolic engine. It listed every reference to a variable, every call site for a function and, as it was symbolic, would cope with virtual functions in the correct way – by referencing the known base type at the call site.

What the BSCKit lacked was type information. So we can turn to the DIA SDK. This is an API that allows you to crack the PDB debugger information. (Search for “DIA SDK” and an article by me is the first hit). There is such a wealth of type information in the PDB file; I have written tools that generate complete C++ headers just from an (unstripped) PDB file.

Then we must consider MSR. They developed a alternate backend to VS6 called ASTKit. It was research and broken (did not cope with templates, did not scale and did not track service packs), but allowed you access to the entire abstract syntax tree that MSVC created during the compile.

More recently there has been phoenix – MSR’s compiler writer’s toolkit. Its early days, but phoenix completely replaces the ASTKit with an environment for writing all sorts of spelunking / dev tools. However it lacks a full symbolic engine as offered by the BSCKit, and does not have the rich type information of the DIA SDK.

Now we hear about the improvements to the database behind intellisense, and I fear yet again we will get half a story. A C++ parser is very hard to write; it must expose as much information to the developer as possible. Writing real refactoring tools for C++ is key the language’s survival (look at what Eclipse does for Java). The C++ community requires industrial grade tool-suites, not just the industrial grade compiler.

If we are to build such tools we require symbol engines, type information and binary re-writers. IBM Visual Age promised such information with their Montana project, GCC-XML is starting to offer parts of this, as are the Edison Design Group.

Please allow the community to build a wonderful and rich ecosystem for you. To do so offer us the information you have locked away in your compiler & debugger developer divisions. You have the power to re-energise the C++ community to make the non Windows developers even more envious. Please …

Cheers,

James.

James Westland Cain, Ph.D.

Principle Software Architect

Quantel Ltd.

james.cain@quantel.com

[Stephan T. Lavavej]

>>If you (and others) can clearly make a case for why two-phase name lookup support would significantly help you, above merely checking for non-conformant code, that would help address the "little value to customers" perception.<<

Consider this:

 struct X { template< typename T > void f() {h();} };

here, 'X::f()' calls a function 'h()' that's not declared. VC never catches this silly error. Any compiler implementing two-phase lookup (GCC, CW, Intel, como...) does. (The reason is that 'h' is not a dependent name, so the compiler should check the call when it first sees the template. If it was dependent, it shouldn't be checked until 'X::f()' is instanciated with a specific template argument.)

Everyone who writes template code to be used by others will regularly run into this problem: You write your code, it compiles, it even works, but you haven't instanciated /all/ templates in your code. Simple spelling errors like the one above (meant to call 'g()' which is declared somewhere but mistyped 'h()' instead) will slip through as VC doesn't find them. Then someone compiles your code using a conforming compiler and sends you an embarrassing list of compiler errors.

But there's more to this: Even if 'h()' was the right function and I make sure 'X::f()' is instanciated during my test, 'h()' might be declared where I /instanciate/ 'X::f()' but not where it is /defined/. VC will happily accept this (as it only parses the code when the template is instanciated), while other compilers would (rightly) flag an error in 'X::f()'. /This/ can be a real show-stopper as you might have to re-factor code due to the previously undiscovered dependency of 'X' on 'h()'. I ran into this several times, which is why I now use other compilers when I write none-trivial template code.

(Note that 'export' would make it possible for me to move the implementation of 'X::f()' into some cpp file and not clutter my header with it - thus reducing such declaration dependencies.)

Of course, at first look this only affects you should your code ever be compiled using a conforming compiler. However, unless Microsoft openly announces that they will never attempt to implement two-phase lookup, some day VC will bark at this. The longer you procrastinate fixing this issue, the more code with such (undetected) errors will be out there the day Microsoft comes out with it - and the bigger will the customer's problems will be. IME this holds for all bugs that make a compiler accept faulty code: The longer the compiler accepts it, the harder it will be to fix it without seriously annoying everybody. (Almost ten years after the release of VC6 many still haven't upgraded because they can't afford to fix their code so that it compiles using modern compilers.)

Resource Editor - support anchored controls in MFC Forms & Dialogs.  

I want:

- IDE optimization. Each new version gets more bugs and is slower! Have you tryed to manage a Form with 500 controls? what a pain. If you add to that the Intelisense updating itself each 30second and the AutoRecover function = you can't code, the computer is halted.

- A button to update MANUALLY the damm Intelisense, not when it wants... when I want.

- Distributed cluster compilation ( ala Incredibuild ).

- Windows Presentation Foundation with FULL Managed C++ support ( currently in VS2008 beta is only C# ).

- SSE3 optimization compiler option ( /arch:SSE3), SSE4 support too.

- New languages support: Digital Mars D, C++ 0x

Oh sorry, I forgot...

- Support for GCC .a/.so libraries.

- Allow to insert images in the code comments... For example, imagine I want to attach to the file an image with a diagram explaining how to calculate a geometric reflection vector from an input vector and a surface normal... Currently you have to make ugly ASCII art for this... I should be able to insert images in C++ comments... perhaps with a #pragma imagecomment or in the project file settings.

- Official support for Subversion source control, not only for Source Safe/Team.

Interested to know ... What IDE/compiler tools does the VS Dev team use ?

Thanks

I was disapointed that profiling (performance testing) was removeed and then later added to the Team System. I would like it back (but I don't expoect you will give us this one).

Would like faster compiling. Every new version seems to halve the compile time. I do understand this is partly necessary, but some work here would be good.

(Current) Standards comformance is important. Getting C++TR1 and up and coming C++0X which will probably be done before orca+1 is important too.

Better help system (i.e. only look for C++ Standard libray , or only MFC , or only WIN32 or a selection of these in a specified order)

- Faster compilation times, ala VS6

- More optimizations and support for SSE3, SSE4, etc...

- Better intellisense

- Standard C++0X

- More frequent updates to visual studio

- Don't mind about .NET integration, but mixed types could be usefoul.

I really appreciated Refactor!

Here is my wishlist:

* fix intellisense

  don't consider it fixed unless it works with stl, boost, wxWidgets and similar toolsets

  actually test it with these libraries

* add refactoring tools

* add a c++ class designer

* improve help

  throw away current help and start from scratch

  both, the help mechanism and the contents of the help files are badly broken

* stop changing things from one version to the next just for the sake of it (projects/solutions/help/addin)

* decide on an architecture and keep it stable for 10 years, unless you can deliver really dramatic improvements for programmers

* make 'property sheets' for projects usable

  its a joke that, when I want to switch from static linking to DLL for example I have to click my way through a ton of dialogs.

* deliver a solid, robust profiler. Make it available from professional versions on upward. Take a hint from IBM VisualAge profilers from the 1990ies, especially their way of visualising multithread execution. You could actually, visually/graphically see deadlocks, race conditions or performance bottlenecks. They are still the best profiling tools I've seen.

I've been using VS since version 6 and have lately wondered if I might ever have to switch to a different toolset.

As MS focuses on managed code and .NET I get the impression that the resources for VS C++ development have dwindled. I've seen a similar thing happen to IBMs excellent (back then) VisualAge C++ compiler 4 (for OS/2). Resources are assigned elsewhere and the product is left to die.

That had me wonder for how long Visual Studio C++ will remain a reasonable solution for C++ development.

Hopefully Orcas+1 can counter that impression. Microsoft, has lost a lot of credibility.

.NET 2002 -> horrible

.NET 2003 -> soso

VS 2005 -> slow and broken

compilation ERROR messages with templates:

These are not much better than they used to be with vc6, back then. we need to do better than that. I know this is not an IDE issue, but a compiler issue.

MSDN Help has abandoned C++! Today, you go to google or msdn.microsoft.com and all you get are C# hits!! not to mention that the current pages are much harder to navigate than the old ones. If it's not broke, dont fix it!! please bring back the native code msdn pages.

I'd vote for a tick box to remove all managed (.net framework) help from the help,so if you're developing native it doesn't even try and look for .net classes etc

I'd also like to thank the folks who put the BRIEF keyboard option back into VS2005.  I wish it *worked* perfectly, but that's a different problem altogether. :)

I've got a ton of code written in MFC and a rapidly aging interface.  We don't *want* to port the back end code out of MFC, but we'd desperately like to be able to put a modern looking interface on the client application without going absolutely insane.  And we're still an MDI app and likely to stay one for a while.

In other notes:

It'd be nice to have a set of serialization macros that supported schemas for virtual base classes that contain data values.  I hacked my own, but I hate having to do that.

I would *love* to see a cookbook for porting an MFC app using views and dialogs (and things like DDX/DDV) to use some of the .NET style interface controls.

Could we *please* have an object that combines a Mutex (single writer) with a Semaphore (many readers) in MFC?  Once again, I rolled my own, but I'd rather not have to.

CMultiLock doesn't execute the Lock function of the underlying objects.  I *understand* this is by design, but you should at least *document* it.

Will Class Designer finally work for VC++?

That's the only thing I really want for XMas.

We use VC8 and C++/CLI to compile up a legacy MFC project with over a million lines of C++ code into a single .EXE

My #1 request -- get incremental linking working with /clr!

When we compile the project as managed (/clr), it always does a full link which takes over 4 min on a fast machine and severely reduces our productivity. When we compile the code as unmananged, we get incremental linking and life is good again. We want to take advantage of all the new .NET stuff, but the increased edit-compile-link times are killing us.

My #2 request -- Fix intellisense

We use a lot of #ifdef's in our code and VC8 frequently gets confused about what is compiled and what is not. I'll change a #define, wait for the intellisense update and code I know is now in the project is still grayed out. Sometimes making a change to the file seems to force intellisense to recheck the file and enable the code, but the flakiness is annoying.

For VS2005, my #1 request is fix bugs before adding features, and don't make us upgrade to VS2008 to get the fixes.  On a large project team, the cost to upgrade is a major problem, and we all need to run the same version.

Right now, my #1 quality problem is that mixed mode debugging often randomly hangs the IDE (have to kill process on devenv.exe) when single stepping in C# or C++. I've given up trying to use it.  (I'm on a multi-core machine)

Also, why is there no list of hotfixes published since SP1?

I would love to see enforced code formattting in C++ (like there is in C#).  I'll also put another vote in for Intelli-sense and interop.

[Hendrik Schober]

> VC never catches this silly error.

That's a missed chance to detect invalid code.  While I'd like VC to detect this, regularly compiling your code with multiple compilers will catch this.

There is a second, more lethal type of nonconformance: the type that causes you to rewrite perfectly valid code in order to work around a compiler's deficiencies.  There are ways to "take advantage" of two-stage name lookup in this manner, but they are all rather obscure.

[jogshy]

> SSE3 optimization compiler option ( /arch:SSE3), SSE4 support too.

[Thomas]

> More optimizations and support for SSE3, SSE4, etc...

VC9 has intrinsics for everything except AMD's very recently announced SSE5. This includes SSE3, SSSE3, SSE4 (both SSE4.1 and SSE4.2), and AMD's SSE4A.

/arch hasn't been extended to automatically use these new instructions.

[Digby]

> What IDE/compiler tools does the VS Dev team use ?

Speaking for myself: I don't use an IDE. Never have, and probably never will. I use a Notepad clone (Metapad) for editing, and Source Insight for browsing large codebases.

The VC compiler and libraries are, of course, built with themselves.  We bootstrap them on the command line, which is now mostly powered by MSBuild.  (Andreea Isac, our MSBuild guru, blogged about this at http://blogs.msdn.com/vcblog/archive/2006/12/07/converting-to-msbuild.aspx .)

[Thomas]

> Faster compilation times, ala VS6

[Malcolm D]

> Would like faster compiling.

Orcas includes a wonderful bugfix that will significantly accelerate the compilation of large projects that are template-heavy and use PCHs.  I remember the speedup as being around 20% for a real example.

> Getting C++TR1

We're working on it!  :-)  See Bill Dunlap's comments above.

[Thomas]

> More frequent updates to visual studio

Goodies are "closer than you might think", to use Bill's words.

[vick]

> compilation ERROR messages with templates:

Agreed!  I love-love-love templates, but even I must admit that template error messages can be rather frightening.

Whenever you find a code construct that triggers a warning or error that could be significantly better, PLEASE file a bug in Microsoft Connect.

As you can imagine, this sort of thing is really difficult to test for, so customer examples are super valuable to us.

[Mike Hudgell]

> I'd vote for a tick box to remove all

> managed (.net framework) help from the help

I'll second that!  :-)

[Bill Roper]

> we'd desperately like to be able to put a

> modern looking interface on [MFC]

We hear you!  Some Vista support was added to MFC in VC9 (see Pat Brenner's post at http://blogs.msdn.com/vcblog/archive/2007/03/21/mfc-updates-for-vista-common-controls.aspx ).  On top of that, to quote Bill again, "we are working on a huge update to MFC that should knock your socks off".

Stephan T. Lavavej

Visual C++ Libraries Developer

Re: What IDE/compiler tools does the VS Dev team use ?

I can't speak for everyone inside Visual Studio but I am using the Beta-2 release of the IDE and for tools I am using a set of tools that was built on August 15th.

Especially from the tools side I always like to ensure that I am using a really "fresh" set of tools - doing so makes it easier to catch potential problems sooner.

Jonathan Caves

Visual C++ Compiler Team

I hope the decision not to make C++/CLI a "first class .Net language" is not based on someone's personal affinity for a homegrown language (C#).  That decision will only pigeonhole .Net itself as a RAD environment for in-house projects that aren't required to stand up to commercial scrutiny.

Yes, C++/CLI has a more complicated syntax.  So what?  It's a more complicated language.  The nice thing about that is it doesn't hide so many details from the programmer.  When performance matters (and it almost always does), it matters if you are boxing or unboxing, passing by value or by reference, and if you're using an automatic variable, a pointer, or a reference.  And that's why Hungarian notation IS a good thing because what happens underneath IS important.

If Microsoft starts placing more emphasis on native C++ development and leaves C++/CLI to languish in obscurity, then why use .Net at all?  There are some great tools and technologies in MSVC 2005 and .Net and it would be a shame to limit them to fluff languages that hide details from the programmer.

C# was Microsoft's answer to Java.  Java never lived up to its hype.  So, let C++/CLI be the killer language it could be for ALL Windows development.

re: "I'd vote for a tick box to remove all managed (.net framework) help from the help,so if you're developing native it doesn't even try and look for .net classes etc"

The feature you're talking about is called "filtering." If you look in your local documentation, you will see the "Filtered by:" text box in the upper right of the Contents and Index panes. Ideally, each topic is tagged with attributes that enable the filter to include or exclude topics. The filter is actually just a query string.

In future releases we will add more and better attributes to topics, and improve the options in the "Filtered by:" box.

I really liked working with VS2005 until I stumbled upon lots of bugs and broken features. The dependency settings is broken. While debugging, VS locks the built executable. When I try to rebuild the application, the linker is unable to update the exe (access denied) . Grrrr. The VS 2k5 sp1 installation is just too painful. On the third time I tried to install it it crashed and the only way I could fix my visual studio installation was by a clean windows install. You guys are unnecessarily bloating the IDE, and releasing revision upon revision where none of them is any good. I see good improvements in the compiler but the IDE tends to get worse. I don't see why a company should waste money and developer time in upgrading to newer versions of VS, when the returns are very minimal. Until a couple of years ago I used to feel that VS was the best app from MS. Don't feel so anymore.

1. I like to see functional intelisense (like in c#). often it dont work properly or at all (*.ncb file has more than 40mb)

2. IDE should be faster (like in VS .NET 2003)

3. fix annoying bug with cooperation of source safe and VS IDE (right click on solution ->get latest version, than you switch to another app (not VS nor VSS) and if you have confirmation dialog from VSS you can not choose anything but to hit escape key

4. VS has problem with resources wich are modified by external program. you have to manualy recompile resources

5. sometimes code generated by VS is wrong and rebuild is needed. why?

As pointed out by many people:

*Intellisense

The exact problem -- If you change a header file, the IDE will often freeze for quite some time. Also, when first loading a project, the same happens. Number One pain point.

*Clipboard ring

Where did it go? It was in the toolbox in VS 2003.NET.

I realize leaving out the clipboard ring discourages "cut and paste" programming... but it was quite useful to be able to cut and move large sections into different source/header files, or to copy sections to utility files.

It was also useful to select and paste the same comment into multiple places in the code

Thanks.

Chad Lehman

Chad

The clipboard ring still exists in VS2005 and VS2008, it just no longer publishes the text to the toolbox.  If you use Ctrl-Shift-V, you can cycle through your recent sections of copied text.

-Meghan

1. support C++ TR1

2. enhance intellisence at least at the level of c# editor even exceed Visual Assist^^

3. class diagram like it has been in rational rose but not in visio

I like to see the dialog editor as competent as the Window forms designer.  I don't see why this functionality wasn't a part of VS as far back as 2002 or 2003; After all the interface is separate from the code it generates.  The auto guides alone would greatly improve the dialog editor.

Hello, Jens Winslow, Dwight and Kirchhoff,

Thank you for your interest in C++ Class Designer. In 2008, the scope of support for C++ is restricted to read-only visualizationis. That is, C++ classes can be viewed in the diagram, however they cannot be created or modified in the diagram. We'll do improvement in the future.

Hello, lxxxk,

re your comment "3. class diagram like it has been in rational rose but not in visio", I'll reflect this to the feature team. Thank you!

I would like the profiler to be available from the Pro version upwards.  (Even if only in a restricted version - eg function timing/coverage.  That is so useful to find which bit of code is slow).

What I would also find useful the the resurrection of the component gallery AND a vastly extended 'wizard' for generating a class stub.

eg.

I want a property sheet/3 pages, modal, not wizard style, no apply/cancel/whatever buttons...

or

I want a new class, called Cxxx, it is to be a singleton wrapping a text file.

or

I want a new object, pure virtual, and I want to use a linked list collection to contain it...

1. Fully agree with all the guys here about the IDE - it has too much memory leaks as well...

2. The Team System Profiler is terrible. not intuitive and practically useless.

Strange it might sound usely performence problems are not(!) 'for' loops...

If you would like to see how profiler should be I sugget you look at the new "bounds checker" profiler - graphically and easy to use. We are using it and it's a tool that really solve performance problems.

I’ve been using Microsoft C++ development environment since 1.0, both in large team development and for solo projects .  Every so often I look at the competition to Visual Studio and end up saying “what competition?”  

I used to use Intel’s compiler engine with MS’s IDE because it produced slightly faster code.   But the continual good relationship with Intel means that MS’s compiler is still near as damnit as good.

I agree with the other comments here about focusing less on managed C++.   Don’t worry, guys: We hard-nosed C++ hackers all use C# too, and know when it’s the appropriate tool.

So:  A wish-list.

1. Handle multiple monitors better:  VS should support two full-screen MDI windows, not just one, which you either have to stretch across the monitors, or else have undocked windows on the secondary monitor.

2. Tightly integrate XML doc (with pretty XSL stylesheets for those of us who are lazy) for C++, not just C#.

3. “Push/pop” cursor caret:  So I can “Go to Definition” of a symbol, then “pop back” to the reference.   I shouldn’t need to code this basic IDE functionality in macros.

4. I should NEVER, EVER, have to use Google or Google Desktop to find MSDN documentation, but it’s usually more effective than using MSDN’s own navigation and search facilities!  Get it together, guys!

5. size_t should be blue in the source code editor (optionally), like wchar_t is.

6. Configuration manager should load/unload projects too, or at least indicate clearly in the Solution Explorer which projects are going to be built and which are excluded fro the config.

7. Better error reporting from the compiler for templated code.  Just ask anyone who uses BOOST.

Josh Greifer

[Stephan T. Lavavej]

>>That's a missed chance to detect invalid code.  [...] There is a second, more lethal type of nonconformance: the type that causes you to rewrite perfectly valid code in order to work around a compiler's deficiencies.<<

I know that your emphasis was on making VC compile conforming code, not to reject non-conforming code and I understand this policy and think it was sound as long as you were so far behind std C++. However, AFAICS VC by now doesn't give us any more such problems than the other compilers we use. You have done a pretty good job over the last couple of years and have caught up a lot. How about now moving your emphasis regarding std compliance more towards what hinders productivity? The lack of two-phase lookup severely does (and so does export, as I explained earlier).

<pre>re: "I'd vote for a tick box to remove all managed (.net framework) help from the help,so if you're developing native it doesn't even try and look for .net classes etc"

The feature you're talking about is called "filtering." If you look in your local documentation, you will see the "Filtered by:" text box in the upper right of the Contents and Index panes. Ideally, each topic is tagged with attributes that enable the filter to include or exclude topics. The filter is actually just a query string.

In future releases we will add more and better attributes to topics, and improve the options in the "Filtered by:" box.</pre>

But the current 'Visual C++' filter gives you managed and unmanaged documentation. If you select 'Platforms SDK' then you only get the platform SDK and not the C++ language stuff [basic, but sometimes necessary].

A 'Visual C++ [unmanaged]' filter would work fine...

I’ve been developing 24x7 telecom server solutions with C/C++ a far has I can remember. My main development platforms, in the last 10 years have been VC++ 6.0 (a lot of time here) and (VC++ 2003 and VC++ 2005) others have passed by me but I will focus on the experience with these 3 compilers/ide/….

Main development in native code with some incursion’s into managed code.

Missing:

- More Native ATL type libraries examples:

o Some WS infrastructure that I can use instead of DCOM (great but doesn’t play well with others out of fashion) or WCF (great, but not a native technologie, so not upgrading to .NET just to use this). My current solution is to use ATL Server with some changes to be able to use it has a HTTP/TCP server or use gSoap. Not “upgrading” the communication layer for native apps causes “stress” in development of distributed native apps.

o Keep up with trends in development. For example a good and fast XML library. We already have XMLLite that’s great, but  how about a little more functionality and a class that integrates the API with STL programming concepts!?

- Key technologies missing, don’t want/need C++/CLI to keep up with C# innovation but I want to keep programming in C++ instead of having to use C# (ex: WPF)

Must have:

- C++0x

Please do more:

- Static analysis

- PGO

- OpenMP (still using Win32 threads, but see a lot of potential here)

- C++/CLI (a little hard to swallow at first, but comparing it to MC++ and to C# no reason for me to use C# anymore)

- STL.NET (just great, how about keeping the non supported VS2005 compatibility?!)

-

Problems with the IDE:

- A lot slower & buggier

Problems with the help system:

- Have to crawl through a lot of .NET stuff to be able to find Win32 API stuff. Other stuff simply has just vanished from the local help (for ex: some OLE…. APIs)

Forget ...

vastly improved ... experience, rich-client user interfaces, Windows platform innovation,

just make it fast.

My fully loaded multi-core machine running VS 2005 IDE today is slower and less stable than my 100 Mhz single core machine running VC++6 IDE was in the 90s.

VS IDE is ...

- slow to launch

- slow to shutdown

- slow to open a solution

- slow to close a solution

- slow to start debugging

- slow to stop debugging

- crashes more than it should

- is a resource hog.

BTW - the comments refer only to the IDE. The compiler is excellent.

Josh -

Regarding your request above

<3. “Push/pop” cursor caret:  So I can “Go to Definition” of a symbol, then “pop back” to the reference.   I shouldn’t need to code this basic IDE functionality in macros.>

Have you tried the "Go Back" functionality?  There is a drop down on the main menu bar that will allow you to go forward and backward in time from where you have visited and there is also a key binding associated with it.  For some profiles this is Ctrl + '-'.  I think this will do exactly what you want.

-Meghan

Meghan - thanks for the 'Ctrl -' info.  (frantically revises project timeframes...)

Since posting, I've watched Bill Dunlap and Steve Teixeira's webcast.   It was good to hear that the MSVC team are focussing more on native and interop support.   Having Herb Sutter so closely involved is also a good sign that MSVC will keep up with standards development.

Generally, if my source code in C# doesn't have any blue wavy lines, it will at least build ok.  C++ would benefit from  this important productivity gain.

So When I'm coding C++, I'd like the IDE to do something similar to C#'s reference binding intellisense feature, e.g. If I type

socket s;

The IDE should prompt to insert "#include winsock2.h" -- I shouldnt need to compile code to find this kind of error.

In fact, better management by the IDE of #includes, #imports and namespaces presents a lot of potential productivity gains.

I should be able to inject code design patterns (e.g. pimpl).  I don't think of this as refactoring or source code tempates.

I guess C++ needs a smarter internal representation of the program at code-time -- the "compiler" needs to be active, and to "know what I'm coding" *while* I'm coding.

Josh

Heres a simple request (tweak):

Starting with VS 2005, if you try to clear all bookmarks in the document you will be asked "Are you sure you want to delete all of the bookmark(s)?" It would be great if there was a way to turn this question off.

Same for breakpoints as well - delete them all without being asked are you sure.

Thanks

dig

Want to know the single dumbest thing about the Visual Studio IDE?

If you are using Microsoft's TFS for source control, the IDE knows a simple one-to-one mapping between the working directory on the file system and paths within TFS. This is how it is possible to type 'tf get' from the command line with no other arguments, and it just works. Great.

So why, when I open a file from Source Control Explorer and start editing it, is the IDE so dumb that it can't automatically check out the file for editing? The inevitable answer is that all the headers should be "bound" to projects, but what about very large numbers of headers for shared libraries? What's the point? Why not just make the IDE marginally less dumb?

Note that by right-clicking on the tab for a file, I can choose 'Open Containing Folder' - a very helpful feature. So why not 'highlight in Source Control Explorer'? That would be a step in the right direction. But seamless automatic check out would be better still.

Currently I'm working solo, and the "solution" I'm working on contains 48 projects (of which 17 are unit-test applications).  I'm doing my best to manage it, but VS could make it a lot easier for me:

Better integration with VSS, please.

I still need to launch VSS (6) to label projects.   I should be able to do that from a context menu.

C++ development would benefit from more target- focused concepts:  There should be a VS entities called "Applications", "Executables" and "Libraries" , (between "Solutions" and "Projects"?).   E.G. For an Application I want to --

Deploy/Create Installation

Update Version (no editing of VERSION resources)

Update Version History (Readme)

etc

Applications, Executables and Libraries (source, object, dll, COM), not "Projects" are what we build in C++.  

Josh

Hi guys,

Theres a lot I love about the IDE, its still the best out there - but there are things I want and need that it cant do right now.

Firstly, we write in C++ to get performance and control - threads, management of small resource pools (such as WinMobile) and access to lower level libs makes the job a necessity - managed code is bloated, the overhead is just too big for some platforms.

Thats my justification out of the way, now what I want is:

1. I know this sounds simple and dumb, but its often the case that theres a library out there that does something I want but I wont know unless I move in certain circles. XMLLite being a case in point. Improved help - make it component centric, not function centric - i.e list anything to do with networks, under networking.

2. MAKE WHAT YOU HAVE MORE ACCESSIBLE ! - trying to incorporate something like a simple SAX XML reader into a C++ project is, to be honest, a nightmare. I'd love to see a better component library so I can add a reader without having to read pages and pages of web. Easy in managed, not in native.

3. Update your sample code - you rely too much on CodeProject. Most dont build under VS2005/8 and theres no upgrader.

4. The property editor for dialog design drives me nuts - its a pain. I spend half my time looking up and down the list for something simple thats badly named.

5. You ditched VSS - huzzah!, well done.

6. The IDE could be better, a better image and icon editor, more support for 24/32-bit colour, transparency and image types. The text editor is decent (although I'd like section expand/collapse to be off by default). And its slow.......

7. Whilst I realise Vista is important, most people still and will use XP - targetting specific features for XP and Vista is hard work.

Rant over, you're doing a good job - we're here to stay BTW...

Chris

I would like better support for environment variables. That is, in addition to the built in variables like $ProjectDir for example, I would like to be able to use environment variables. For example to set additional include $ENV{MyProjectRootEnvVariable}/include.

Also when starting devenv /useenv, it would be nice if variables could be set separately for different platforms. Perhaps instead of just INCLUDE, LIB and PATH one could have INCLUDE_x64, INCLUDE_x86 environment variables.

One suggestion the the next Visual Studio 200x editor: like Outlook it could uses the Word as code editor; so it will be possible to mix code with objects (tables, images, formulas and so on....). This features allows an high level code documentation.

Thanks.

While I agree VC6 was really good,  and VC8 is OK,

I still want to have more features.

Some while ago, I used Eclipse + Java.

This was heaven - of course not everything was good,

but following features stood really out.

1. Quickfix (Ctrl+1)

2. Refactoring ... renaming a java class in eclipse is no problem - it takes me less than a minute.

In C++? Renaming a class? I won't do it without a very very good reason... it's just too painful.

Good refactoring support, really changes how you develop programs! So please add it.

3. Intellisense that just works... in VC8 and VC6, sometimes it doesn't work. And there is no feedback - why it doesn't work...

other wishes:

4. Of course C++ 09 support. ;)

5. Fix the .NET Framework Distribution problem.

Nobody has the latest .NET framework installed.

The binaries are too large to distribute with your product.

And telling customers to download 20MB + from microsoft.com, is also not helpful convincing customers of your product.

JE

I develop Console-based/compulational intensive (3-4 hour run times) programs for 32/64 bit Windows and Linux systems.  The same code must compile on each operating system seamlessly.  VS2005 is my develop platform and it does what I need reasonably well.  We would like to move this application to a multi-threaded / computer cluster environment, but Windows/Linux code compatiblity is frustrating our efforts.  I like how C# does this, but the performance of C# is a major drawback.  

C++ needs to be a full citizen from now on.  When I was at a recent MSDN event, the question was asked how many VB programmers do we have here, then how many C# programmers, and that was it.  I wanted to yell out C++.  I still think 2005 (VC8) is better then 2003 (or 2002, yuk) as far as C++ is concerned.  

The help seems broken compared to VC6, and the integration of C++ is not nearly as seemless as C#.  Interop with managed code is a must as is more tools to do the same stuff in unmanaged C++.

Keep fighting the good fight!

I second Glen's comments regarding C++ being a full citizen.  With C++/CLI, why should we have to bother with annyoing C# syntax?

Here's a simple one: The Find In Files output should not be cleared at the start of each search operation. Yes, we have two Find Results windows we can alterante from, but we wouldn't really need them if the search results were simply appended to the results of the previous search. Appending search results provides a very useful search history. I often find myself using Textpad's file search mechanism for this reason alone. And if possible, please include this in the next service pack for VS2005. Thanks. :-)

Beside inteli-lack-of-sense being too slow, I find it "digs" too deep.

90% of time the function I want is "in" the current class not some parrent class level, but intellisense insist on listing all functions, making it impossible to find function you want - unless you already know it's name (and hence do not need intellisense)

I would love to have intellisense list the current class member functions, then a line, then all the "other" parent stuff. I.e. for class B, intellisence:

  MyB()

  -----

  MyA()

  ...

for

Class A {

int MyA(void);

}

Class B : public A {

int MyB(void);

}

I wanted to respond to recent comments by Glen and Cygnus...

>>I hope the decision not to make C++/CLI a "first class .Net language" is not based on someone's personal affinity for a homegrown language (C#).<<

The Visual C++ team is responsible for determining how C++/CLI fits into the overall Visual C++ product strategy.  Please rest assured that this issue has absolutely nothing to do with any emotional attachment for C# and everything to do with the feedback we receive from Visual C++ customers.

What we have heard from an overwhelming majority of customers is that C++ is most important to them in native code and multiplatform scenarios.  We also find that C++ developers are perfectly comfortable working with C# for .NET-specific parts of their application, such as UI code generated by IDE designers.  We on the VC++ team feel that we can offer customers far more value by focusing on those native code scenarios that ONLY the VC++ team can deliver on, as opposed to diverting resources to provide C++/CLI experiences for designer-oriented scenarios that are already handled well by C#.

>>That decision will only pigeonhole .Net itself as a RAD environment for in-house projects that aren't required to stand up to commercial scrutiny.<<

I'm going to have to agree to disagree with you on this point.  My feeling is that the success of .NET as a platform does not rest on whether or not certain .NET designers or features are surfaced with C++/CLI support.

>>Yes, C++/CLI has a more complicated syntax.  So what?  It's a more complicated language.  The nice thing about that is it doesn't hide so many details from the programmer.  When performance matters (and it almost always does), it matters if you are boxing or unboxing, passing by value or by reference, and if you're using an automatic variable, a pointer, or a reference.<<

I agree.  This is why C++/CLI is an important piece of our product strategy.  C++/CLI offers by far the best native/managed interop experience as well as the greatest control over runtime characteristics.  I encourage everyone to leverage C++/CLI in cases where these things are important.

>>If Microsoft starts placing more emphasis on native C++ development and leaves C++/CLI to languish in obscurity, then why use .Net at all?<<

Hopefully I'm helping to paint a more accurate picture of the role of C++/CLI.  In a nutshell, we're focused on areas where we can add maximal value, and we're deliberately avoiding investments in "me too" areas where we can offer little value beyond a "C# with a preprocessor" experience.  In practical terms, this will often mean leaving the UI designer space in the capable hands of C# and VB.NET while VC++ focuses on ensuring developers can get the most out of the "guts" of their software.

>>C++ needs to be a full citizen from now on.  When I was at a recent MSDN event, the question was asked how many VB programmers do we have here, then how many C# programmers, and that was it.  I wanted to yell out C++.<<

Assuming you mean a full citizen of Visual Studio, I wholeheartedly agree! I also agree with you that the message that goes out through our field-focused organizations can be overly .NET-centric.  However, we're working with these field-focused organizations, such as Developer & Platform Evangelism, to provide more balanced managed/native messaging going forward.

Thanks!

Steve Teixeira

Group Program Manager, VC++

Clean solution/ rebuild solution - delete the .aps file!!!

Steve, thanks for your comments.  They are appreciated.  Can I ask, then, if you intend to leave new .Net UI development to C# and VB but fully support C++/CLI where system performance matters, why don't you support Web Services and WCF in C++/CLI like you do C#?

Also, I do think there is a silent group out there that thinks like me and is not happy with the VB/C# approach to UI development.  Coding techniques matter.  Code maintenance matters.  Rapidly-developed UI faulters under stress.  I've never known any kind of large-scale project written in VB (or C#) that was successfully deployed and survived.

And besides, we have enough technologies out there to keep track of.  It makes it much easier if we can work with them all in the same language.

[Josh Greifer]

> 5. size_t should be blue in the source code editor (optionally), like wchar_t is.

Remember that size_t is a typedef, while wchar_t is an actual type.  The distinction occasionally matters, such as when overloading.

Stephan T. Lavavej

Visual C++ Libraries Developer

Hello Digby

Re your question: What IDE/compiler tools does the VS Dev team use?

Although Jonathan (Caves) answered you above, he has just posted a much more specific description of his setup on the VC blog if you are interested in much more detail. See here: http://blogs.msdn.com/vcblog/archive/2007/09/04/what-compiler-does-the-compiler-team-use-and-decoding-version-numbers.aspx#comments

Thanks

Damien Watkins

Visual C++

Hi Cygnus,

>>Can I ask, then, if you intend to leave new .Net UI development to C# and VB but fully support C++/CLI where system performance matters, why don't you support Web Services and WCF in C++/CLI like you do C#?<<

I think it's fair to say that this is a hole today.  I agree that we need to improve the VC++ web services story.

>>Also, I do think there is a silent group out there that thinks like me and is not happy with the VB/C# approach to UI development.  Coding techniques matter.  Code maintenance matters.  Rapidly-developed UI faulters under stress.  I've never known any kind of large-scale project written in VB (or C#) that was successfully deployed and survived.<<

While RAD tools may make it easier to write bad UI code, there is nothing inherently bad or inefficient about writing UI in C# or VB.NET.  One can certainly write good UI code in C# and VB.NET as well, and I work with a lot of customers that do this on a very large scale.

>>And besides, we have enough technologies out there to keep track of.  It makes it much easier if we can work with them all in the same language.<<

My first response to that is, yes, in a perfect world we'd offer everything in C++/CLI that is available in C# and VB.NET.  The business questions that we on the VC++ team have to answer, however, is whether this is enables us to offer customers the most value for our investment.  Because the majority of VC++ customers we have spoken and worked with have not had a problem with using C# in certain scenarios, we feel that we can offer the best value by focusing most of our efforts on solutions for those problems that only C++ can solve.

Thanks again!

Steve Teixeira

Group Program Manager, VC++

I see lots of comments about the filter for C++ - Gordon mentioned that in the Orcas release has a new C++ (native) filter.  I will see if we can put out a file and registration for a filter to fix-up your earlier releases/libraries.  If so, I'll post back here and also on my blog.

April

Our application area is CAD and with 10 million lines of code in C++ & C#, Visual Studio 2005 is good, but it's not great. Some improvements that we'd like to see:

In contrast to some of the comments here, interoperability, improved C++ standard support, esp. C++0x, and STL improvements are high on the wishlist. That said, we often find ourselves using STLport rather than Dinkumware, as it's faster and offers debug support. Further improvements to C++/CLI are also high, as we'd rather use a proven language as a basis for .NET over one of Microsoft's invention that we continue to experience fundamental flaws with, such as non-deterministic object lifetime (vs non-deterministic memory cleanup which is much easier to manage).

Help separation: If I want to search for a class in Win32, finding 100 .NET uses of the word is really irritating. The same goes for C++ vs C++/CLI. They're two different languages, can we please avoid mixing them up?

On top of that, knowing what features apply to what codebase is so important and yet glossed over by the help. Often a given function or setting is listed as 'this applies to the .NET framework 2.0' - when it's a C runtime function, I worry! A clear separation between native and managed is critical. I can remember looking up manifests and assembly configuration file settings and nowhere did it cover the absolutely critical differences between managed and native settings.

Help improvements: I end up using Google for most of my help, it searches MSDN far more effectively. I think that safely covers how effective the searching is in the current help. The Visual Studio 6 help by comparison actually finds what I want in a tenth of the time.

Downloadable/cacheable help: The Internet is cool, but please can we have a feature that has help on the hard drive? Something simple like a help equivalent of offline files would be nice, where I have a cached copy available when the Internet is inaccessible, or slow, or MSDN is down, again.

IDE performance: VS2005 is very very slow when you give it large solutions (100 projects, each with on average 100 source files). Intellisense kicking in when you least expect usually still freezes the application, even after the Service Pack supposed to stop this, is also deeply annoying. The general responsiveness of the application seems to drop dramatically with this amount of loading.

Text editing: Can we please not have managed keywords highlighted in native code? It's really disconcerting when you happen to name a variable 'property' and have it go blue, when you're writing native code only. It's things like this that present an appearance of a focus by Microsoft on managed code only.

IDE integration: How on earth did we end up with two totally different IDEs within one, one for C++ and one for .NET? In C++ I get a separate window for project properties, I get property sheet support, and generally the feel of a fully fledged IDE. In C# I get a docking window with a minimal set of properties and only half the features that the C++ IDE offers. Please integrate these so we can get used to a single set of actions.

Property sheet support: When dealing with hundreds of projects, being able to use property sheets to define common settings is a godsend. Sadly, the IDE only partially recognises these useful features. There's no proper support for saving them, for source control over them, making a useful feature a pain to work with. Worse, .NET doesn't use them or property user macros at all!

IDE Properties: Back in VS6 when I selected multiple configurations, I'd get the valid combination of things like libs, preprocessor, and if I edited those, I didn't lose everything else. Today, if I select All Configurations, far too many boxes go empty, instead of displaying the valid intersection of the configurations.

This means that if I need to change a single preprocessor entry in 12 different configurations, I have to go through each and every one manually and pray that I didn't miss one.

On top of that, can it please display by some means in the main IDE properties window, inherited libs, preprocessor settings etc. Often someone will say, how come this project doesn't have X defined - in fact it is, it's just buried 3 levels down in a property sheet that the project inherited. Worse, someone will say 'it can't do that, it doesn't have that setting set' and in fact it does have it inherited. The user should be able to see the result, not just the project-level settings, in the main properties window.

Crashes: Despite sending hundreds of error reports when the compiler or linker crashes, we're still getting common repeatable crashes with incremental compilation and linking. Sadly we can't send the reproduction information to Microsoft, as it's all our copyrighted source code!

Debugging: Getting debugging to work with managed/native transitions, and crash dump processing with managed code present is still very complex and doesn't always work. In particular, the Auto feature of debugging doesn't seem to work out when a startup project is native, but the launching exe is managed, that it needs Mixed mode, and that the exe (even when it's in the same solution) needs to have unmanaged debugging turned on. In short, what should be a single click debugging session turns into a hunt-the-checkbox game which usually ends up not working anyway.

Runtime checking: Please make the various checks such as stack corruption faster. It took an enormous amount of political battling to get these turned on even in debug only because they slow the process down so much. I know debug is for checking, but when senior developers who claim they never write buggy code are wanting a fast debug experience, it's hard to convince them to have the checks on, and I'd rather we found bugs during development than later. Btw, if anyone hasn't used these, do so, they can be a lifesaver.

Files: It's all very well having the .proj and .sln files in XML, it's a marked improvement over the old unreadable VS6 files, but please can you stop rearranging them every time there is a simple edit? A single change in dependencies in a solution reorders almost everything. Clearly whoever designed this never subsequently had to look at these changes in source control. Have a simple rule - one change, one line in the file changes (ok, it might not be this simple, but you get the idea).

Source control: Please provide better support (which may be to the vendors rather than users) for other source control products. Far too often one cannot use the source control plugins written for VS because they don't work in the way the source control application expects. If it requires liasing with the likes of CVS and Perforce, then please do it.

Replies to some comments:

'One can certainly write good UI code in C# and VB.NET as well'

Sure you can, but that UI has to do more than just be a UI, it has to call non-UI code. Therein lies the problem and it's just too much of a pain doing this interoperably at the moment.

'4. Native (unmanaged) C++ should have access to all the OS capabilities that managed C++ does.

5. Native (unmanaged) C++ should have access to the new UI technologies like WPF so that existing applications can be updated to use them without having to be rewritten in a proprietary language.'

Hear hear. This is so important it ought to go top of the list.

Consider that quite a few developers are creating portable engines that then have an OS specific bottom and top (system and GUI) and having to somehow have managed transitions for all of the GUI is an incredibly costly process in terms of maintenance and design.

Asking someone to rewrite everything in a different language is just a non-starter, so something somewhere has to enable this concept to work.

Just stick to the standard.

Ask yourself what can you do to fulfill it.

I am really glad you are making this opportunity available for all users to provide feedback. There will be lots of personal pet peeves of course, and you can never make everyone happy, but there is always hope for a company that listens to its customers.

I also want to say I'm very happy with the move towards full public betas and the express editions. This allows small developers to anticipate and prepare for API changes just like the big boys.

I'm a busy C++ developer. I don't have the time or inclination to spend hours in the registry or installing scripts etc. I really don't have time to write this note, but I feel I can't complain if I don't vote!

So here goes (VS 2005 feedback):

1) Make the most common tasks fast and reliable. Here's a secret trick: try to develop the classic asteroids game using the latest VS, but on an old 386 or 486 system. If you can't stand it, find out why. Performance really does matter.  No, really do this. Take a week and do it.

2) Less integration, more inter-operation. A simple example: the start page has html links (I got to this blog via one of them). That's great. But when I click on a link, the page is displayed inside VS. Isn't it more likely that I already have a preferred web browser, and in fact am already an expert at using it? The problem with integrating such functionality into the IDE is that you don't automatically integrate the user's domain knowledge of how to use that functionality. The user has to learn new ways to do things he already knows how to do. I'd prefer that all context sensitive tools could be unbundled this way (the help system sort of works like this, but I'm not allowed to choose a different help program).

3) Make all dialog boxes re-sizable, and remember where I last put them and how big they were. You do this sometimes (Window->Windows...), but not always (Project->Properties). I like big dialog boxes for text fields and scrolling lists.

4) The task list window should show comment tasks from the file, project, or entire solution. VS 2005 only displays them from the current file. I don't use this feature because of that.

Stephan,   yes, size_t is not a keyword like wchar_t.   Which is why I added "(optionally)".  For me, the syntax coloring of typedefs which are essentially aliases for built-in types leads to easier to read code.  I guess I'm looking for something similar to the useful cyan coloring you get when you make aliases in C#:

using size_t = System.UInt32;

I'd like to see the ability to skip comments in search & replace.

I think you are missing a lot of potential users.  I like to build platform neutral apps with ACE.  But VC++ is always tough to make work with makefiles.  It would be nice to support both so I could drop eclipse and EMACS and all of that stuff on the Linux side.  I would love to be able to just scp and build on Linux once I'm done testing on NT.

Also, make the heap faster.  It gets too slow when apps get busy.  For a lot of my high-performance apps I am afraid to use std::string too much, which is a shame.

[Jeff H]

> STL improvements are high on the wishlist.

Which improvements, specifically?

> That said, we often find ourselves using STLport

> rather than Dinkumware, as it's faster

If you find specific test cases where STLport (or libstdc++, or whatever) is significantly faster than VC's Standard Library implementation, please file bugs in Microsoft Connect.  We've already gotten two bugs from this thread, one of which appears to be a real problem that we're investigating, and the other one appears to be a place where we're actually significantly faster than libstdc++ (at least on the same OS, which is all we can ask for).

> and offers debug support.

How, specifically? VC8's Standard Library implementation enables _HAS_ITERATOR_DEBUGGING by default in debug mode, which performs powerful correctness checks. Additionally, we've taught the IDE debugger to visualize STL containers and iterators. What does STLport do better?

> please can we have a feature that has help on the hard drive?

Doesn't Visual Studio come with a copy of the MSDN docs?  (I've never installed them myself.)

> Can we please not have managed keywords highlighted in native code?

That's a bug - file it in Microsoft Connect, please.

> Please make the various checks such as stack corruption faster.

You mean /RTCs? /RTC is documented as slowing down code by 5% at most. If you've found a case where it's more expensive than that, please file a bug (at the very least, the documentation would have to be updated).

[Josh Greifer]

> For me, the syntax coloring of typedefs which are

> essentially aliases for built-in types leads to easier to read code.

Makes sense. If I regularly edited with syntax highlighting, I'd want that level of customization. I think you can file suggestions in Microsoft Connect.

(Aside: I implemented hit highlighting in Outlook 2007, so any sort of highlighting has a special place in my heart. :-)

[Josh]

> But VC++ is always tough to make work with makefiles.

How so?

> Also, make the heap faster.

I'm going to sound like a broken record, but please file a bug in Microsoft Connect. "Make the heap faster" is not as actionable as "here is a test case that demonstrates how your std::string is slower than it should be".

Thanks,

Stephan T. Lavavej

Visual C++ Libraries Developer

I can't help but comment on:

"My first response to that is, yes, in a perfect world we'd offer everything in C++/CLI that is available in C# and VB.NET.  The business questions that we on the VC++ team have to answer, however, is whether this is enables us to offer customers the most value for our investment.  Because the majority of VC++ customers we have spoken and worked with have not had a problem with using C# in certain scenarios, we feel that we can offer the best value by focusing most of our efforts on solutions for those problems that only C++ can solve."

That is the very attitude that will eventually kill VS for C++ users.  If the majority can use C#, then some can't.  And who writes code that some coworkers can't maintian or upgrade.

The biggest problem with intellisense isn't in the CPU cycles - we know that is done in background thread at low priority.  Its the fact that it uses a lot of memory (either directly or indirectly by the OS during the file caching), which will cause paging which will slow devstudio and everything else to a crawl.  This is on a 2 gig ram machine with dual procs.  Along this same line, I had devstudio take over five minutes to shutdown.  Again with a 2gig machine and nothing else opened.  Why, again its because of the paging that devstudio frees every memory thats been allocated.  Now I'm in the habit of using task manager and kill process.  Bam - less than a second.  How about adding a command to do that!

echoing others, help has gone down hill ever sense you moved to html help.  With no perceived benefits that i see, help just got more and more useless and much to slow.  I now use google for pretty much all my help needs.

Bring back the profiler!  What a crock that you made it only for the team system.

We work with dual screens / desktops, and it would be really nice if devstudio worked nicer on very wide screen.  Now when you open a file, the default window is way to wide.  How about and option to set the default width & height.  Even better, let us move the text windows outside of the devstudio like other windows (output,call stack, etc)

Thanks,

Leigh Stivers

Still about Intellisence.

In VC 2003, when I press F12 on a member function declaration in a base class, a dialog will pop up listing the function definition of the base class as well as the  function definitions of all the descendant classes so that you can choose one from them. This may be not accurate for the reason that Intellisence cannot determine which class we want. But this is a great feature. We are often faced with virtual member function invocation via a pointer of the base class and we don't know in what class this member function will be invoked when reading the code. To better understand the code, it is quite useful for us to see all the possible implementations of the virtual function. And VC 2003 provides this great feature, that is when we press F12 we can see a dialog listing all the possible implementations. While VC 2005 makes Intellisence more accurate (that is when you press F12 on a function declaration of a base class you will be navigated to the definition of the base class), it fails to recognise the purpose of reading code-- to understand code. I hope this feature be considered in future.

Thanks,

John Tang

Bring back Brief emulation.

TIA :)

I develop my applications in VS C++ mixing managed and unmanaged code. Only the presentation layer is written in VS C#. That is because VS C# always has better design support then VS C++. The superiority in power of the VC++ language over the C# language is indisputable (for those who know both).

The biggest problem of VS C++ right now is the lack of support for designer tools like the ones for VS C#.

A small feature I'd like to see improved on is the Configuration Manager in VC++.

It would be great for us who develop on multiple platforms to be able to add new platforms easily without having to write a VS-plugin for every one we want to build on.

Right now, with the default config, only Win32 and x64 are available in the choices. It'd be nice to be able to manage our GC, Wii, PS2, PS3, etc. project the same way, easily.

Perfect feature to fix for an internship!

Thanks,

Fred

Daniel,

re: support for TFS versioning of files that are not in a versioned solution/project.

Yes, I agree, this annoys me too and we plan to address it in the future.  The IDE integration for version control has historically been focused around projects and solutions and we did realize until late that this was thinking about the problem too narrowly.  I hope to get this addressed in our Rosario release.  Thanks for the feedback.

Brian Harry

Product Unit Manager, TFS

Hello Feri T.

Re your comment: The biggest problem of VS C++ right now is the lack of support for designer tools like the ones for VS C#.

If your comment is specifically about designers/tools/features for targeting .NET, then we agree that languages like C# and VB that specifically target .NET provide incredible features for working with .NET. Our advice is definitely to use these tools from these languages whenever you need/want to. Going forward our goal will not be to provide parity with these languages/environments when specifically targeting .NET.

If you comment is about providing such functionality but for native development then we would also agree that we do not have parity today (Intellisense being one such example often mentioned in this thread) but rest assured that our goal going forward will be to provide similar (or better!) functionality for targeting native code development.

Steve and Bill cover our motivation and reasoning in their Channel 9 video, referenced above but I will included it here again: http://channel9.msdn.com/Showpost.aspx?postid=281987

Thanks

Damien Watkins

Visual C++

In deflecting the requests for more C++/CLI support, a lot of references have been made to "feedback" or a "survey".  Was the sampling scientific?  That is, did you account for the fact that a lot of developers are too busy to take part in such things or don't need to go to all of these conferences that highlight new technology?  I didn't even KNOW about C++/CLI until about 6 months ago, and it was just by accident that I found out.  Prior to that, I had just tuned out .Net development because I knew C# and VB wouldn't cut it where I work.

Hello Eric

Re your comment: “I am really glad you are making this opportunity available for all users to provide feedback. There will be lots of personal pet peeves of course, and you can never make everyone happy, but there is always hope for a company that listens to its customers.”

And there is absolutely no hope for a company that does not!

Re your comment: “I also want to say I'm very happy with the move towards full public betas and the express editions. This allows small developers to anticipate and prepare for API changes just like the big boys.”

Thanks, nice to hear that these initiatives are working well for you.

Re your comment; “I'm a busy C++ developer. I don't have the time or inclination to spend hours in the registry or installing scripts etc. I really don't have time to write this note, but I feel I can't complain if I don't vote!”

Absolutely, the only way to be heard is to speak up – further more please feel free to use our VC blog on occasions too. And I hope you do not always have to “complain” too :-)

Re your comment: “So here goes (VS 2005 feedback):

1) Make the most common tasks fast and reliable.

2) Less integration, more inter-operation.

3) Make all dialog boxes re-sizable,

4) The task list window should show comment tasks from”

Thanks for taking the time to tell us about these. A number of us are reading this blog almost daily and we are recording the suggestions. We are already addressing some, such as the amply identified Intellisense issue(s), but this thread reiterates why completing that work in particular is so vital. For other issues mentioned here, customer feedback helps us decided what priority order to put things. As you say above, we unfortunately cannot address every issue for every customer but we have to make sure we address the right ones first and foremost.

Thanks

Damien Watkins

Visual C++

I'd like to have a way of choosing which function/method to step into when debugging a line of code. Example line of code:

myclass.DoSomething(someObject.ToString(), someOtherObject.GetValue());

When debugging this line of code and pressing F11 to step into it, I always end up in the calls made to get the parameter values and I have to step out of those and then eventually I can step into the outermost call (DoSomething).

It would be nice to have some way of choosing which call to step into. Right clicking the method or parameter and choosing step into is an option. Also having some shortcut key "step into outermost call" could be an option.  

This goes for all languages, manged or unmanged, it would always be useful.

Thanks

Fredrik Stahre

Standard conformance is critical.

It would also be nice to have implementations of the new tr1 and standard features out quickly.

Frankly, most of the opinions expressed here are ignorant.  You have a lot of moronic customers who have no idea a) how to get best use out of the toolset and b) who plainly feel a sense of entitlement based on their experiences with earlier versions such as VC6/7.  Half of the recommendations on this page are for features that are already supported, or to fix performance issues that are only an issue on sub-standard hardware.  I've been with VC++ since the beginning and each version is a tremendous improvement on previous versions in almost every area.  Developers whine about a lack of support for native development when VC++ is the single most capable native development platform in the world, bar none.

And the developer who suggested you take VS2005 and develop asteroids on it as a way of demonstrating the need for "performance".. he's out of his mind.  These little kiddies need to learn that new operating systems and new development environments require new hardware PERIOD.

Responding to Chris Hansen's message about our stated on to not seek parity with C# and VB.NET in the .NET designer space for C++/CLI:

>>That is the very attitude that will eventually kill VS for C++ users.  If the majority can use C#, then some can't.  And who writes code that some coworkers can't maintian or upgrade.<<

The recommendation we're making here is that if you're going to make a technology decision to build a user interface using one of the managed UI frameworks, you need to invest in building C# and/or VB.NET expertise on your development staff.  I've yet to talk to a customer for whom this is a serious problem, but I admit I haven't talked personally to all of them.  :)

The bigger picture here is that leaving this space in the capable hands of C# and VB.NET gives us the ability organizationally to focus on the native UI space (which I fully admit we haven't done a good job at in recent versions).  I fully expect that we're going to take some heat for stating our intentions and recommendations in this space so bluntly, but I believe it's the right thing to do because it enables customers to plan their technology investments accordingly .

And replying to Cygnus' message:

>>In deflecting the requests for more C++/CLI support, a lot of references have been made to "feedback" or a "survey".  Was the sampling scientific?  That is, did you account for the fact that a lot of developers are too busy to take part in such things or don't need to go to all of these conferences that highlight new technology?<<

We rely on a number of sources of customer input, ranging from the very anecdotal (e.g., meeting customers at conferences) to the semi-representitive (e.g., discussions in broad-reach forums such as this) to true statistical instruments (we have a few internal market ananlysis tools  that we've been using and refining over many years).

BTW, I really hope you don't feel we're deflecting requests about C++/CLI.  Our intent is to be very up-front about our plans for C++/CLI and to help everyone understand how our plans for C++/CLI are informed by the realities of our business.

Thanks!

Steve Teixeira

Group Program Manager, VC++

+ try to break the speed (and responsiveness) of Visual Studio 6.0. The responsiveness of Visual C 2005 is way too slow.

+ get better stability of the editor, like it was in Visual Studio 6, and less resource consuming

+ change back to the help system of Visual Studio 6.0. current "dexplore" is too slow, too much flickering and too resource consuming.

+ show relevant help items when hitting the F1-key,

   for all relevant C / Platform SDK / WDK keywords

   (sprintf, SHCreateFolder, IoCreateDevice)

My desired improvements:

1) True long double support (not an 8 byte typedef) when extra precision is required for engineering & scientific applications.  Optimizations and enhancements for floating point intensive applications.   Most of your competitors are far ahead of you in this area.  It seems like not much has been done recently for those of us who develop these applications yet they really are computationally expensive.

2) Improved IDE performance, esp. debugging large solutions with many projects and files.

3) Improve C++ IntelliSense.  I think it is actually worse in 2005 than earlier versions.  IntelliSense rarely works on my large solution.

Standards conformance has come a long way since VC++ 6.

Better configuration of multi-target projects.  We have projects we want to target to Win32, Win64, and various different Windows CE and Windows Mobile platforms.

Unfortunately, this requires a lot of manual work.  When creating a new project, you can't choose all of the above, so you must add the other configurations later (this is also the case for existing projects when expanding what they target).  When you add a new configuration, you can make it blank or copy setting from an existing configuration, but you can't copy from the default settings that you would get if you created a project from scratch with that configuration.  That means, to create (for example) a Windows Mobile Pro config, I must either start from scratch and manually change all the options or I must copy from Win32 and then fix all the defines and other options that aren't appropriate.

It turns out that the easiest way is actually to just create another project and then manually edit the XML of the original project file to add the new configuration, copied from the new project...

Small, but powerful, feature from the old Smalltalk days:

Right-click paste has a sub-menu off of it that shows you a list of your last, say, five clipboard contents (up to the first 20 or so characters of each).   Much more intuitive and friendly than the clipboard ring.  One often gets sidetracked when about to paste something; this allows one to easily dig back out without starting over.  All text editing widgets should do this...

improve the editor. last the editor was destoryed my project and compiler couldn't build some of the pages of my project . i've just think that if i had a big proj and the compiler burned my proj what shall i do !!!!!!!

make a list of events of controls as parameters in editor pages(like as VB or C#) so it don't need to type the events by keyboard.

don't change the symboles . for ex the symbol of pointer on vc++ 2003 is * but in 2005 is ^ . at all i think that the V.C++ 2005 has many problem than the last version.

I really agree with the people that keep missing VC6.

It was the IDE that was really superior to all others at that time. Now with VS2005 I'm not so sure anymore... I've worked with 5/6/2003/2005 and simply can't say that 2005 improved much for me...

- It is slow(er).

- Intellisense is slow, a CPU-hog and often simply doesn't work (SP1 improved that a bit)

- Caller graphs and "find all references" simply don't work.

- The are still quite a few errors in it!

- for the docs: If space allows it, bring back the Win32-API documentation. proper.

- Where's refactoring?

Why not improve 2005 first? VC6 had 6! service packs afaik and 2005 only got one, still has errors and is already being replaced by 2008... I'm not a friend of switching IDEs and installing redistributables on numerous machines. I'd only do that for serious improvements...

Imo there's lots of people (including us) that use C++ and need to keep it that way because they're doing cross-platform development (Win/Linux/Mac) and/or need highest possible performance...

Nice of you to provide VC++ Express. Though it lacks some stuff of the regular version it is a really powerful IDE.

regards

Kim Rosenbohm

I use both VS2005 and VC++ 6.0. At our company, we make most of our applications in C#. However, for our embedded devices (we have both CE and XPE flavors)  they are totally in native code, and I don't expect that to change.  However, if MS could provide a toolkit to help communicate with WCF services straight from native code, it would be great.  Then we can make all our communications the same. We have moved some of our managed code to use WCF. The only stopper to using it across the board is having to use it in our embedded applications (and it has to support the same code base for both WinCE and XPe).  So by providing a standard C++ toolkit that doesn't have many dependencies, you could possibly use WCF from native code on any windows platform, and that would be the coolest !

   What about "#define" (macros) debugging? I have a lot of C++ code inserted as #define because I have a lot of similar methods, but It's very hard to debug and find any error when it resides in macros. It would be nice if we have to debug #defines as if they were methods or any alternative way, such as automatic code expansion of them (like C++ preprocesor does in compile time).

Regards,

Sen

I’ve been using Microsoft’s C and C++ compilers since 1989 and I’m currently the only developer on an application with with around 450k lines of C++ and MFC code.  C# is not an option.  Last year, I enrolled in the Empower ISV program expecting great things from VS2005, but was thoroughly disappointed and removed the compiler from my PC some weeks after installing it.  I did not renew my Empower subscription.

Two comments which echo Stephen Kellett:

1. Bring back the Class Wizard – it is a fast and efficient way to manage an application’s boilerplate code and can be driven entirely by the keyboard.  The VS2005 property-based UI is slow, buggy and requires me to remove my hands from the keyboard, grab the mouse, issue multiple clicks, some of them over tiny areas on the screen.  I estimate it’s around 10% or 15% of the speed of the previous interface and it’s annoying as hell.

2. Throw away the broken CRT and MFC library installation procedure, or fix it.  Many of my clients are banks who run isolated or locked down PC’s which are rarely up to date with service packs and almost never have internet access, and frequently, not even administrator access.  I cannot install VC2005-compiled software on these machines.

I look forward to the promised update to MFC – what’s planned here, folks?  Other than that, I really hope that the next VS can provide the efficiency of the 1998 environment together with the newer compiler’s runtime checks.

Try to make it worth my while to upgrade, folks.  Please!

Intellisense/Autocomplete and Help needs to be more tightly integrated.  When I type a function or object, and hit F1 on it, it should take me to THE (not one, not many) page that documents that function or object.  

Also would be nice: an "Assist" pane in the VS IDE.  When Intellisense/Autocomplete sees that I'm typing a function, the assist pane is a little HTML document that shows:

1. The function I'm typing, with up-down arrows for all the overloads.  

2. Documentation of the arguments. (See Excel's function wizard, for example).

3. Hyperlinks to THE MSDN documentation for that function (don't bother with links to communities).

I know, Help and documentation is mind numbling boring. But this is something Microsoft should start investing more heavily on, despite what Charles Petzgold says about Intellisense.

Wish #2, related:

Wish #1 is really an alaboration of the tooltip that is part of Intellisense.  The problem with this tooltip is that it "gives up" on me.  Expecting the customer to keep the carat in the argument list as a requirement to see the tooltip is too limiting.  It needs to come up whenever I place the carat

in a function, not just when I'm actively entering arguments.

Wish #3:

Please keep J# alive, and support 64-bit. If you can't support intellisense, etc on it, for the time being, then disable those features.

Wish #4:

Please make configuration management more intuitive and robust.  This Any CPU/Mixed Platform/x86/x64 stuff all has its reasons, but it's just too complicated.  (Fix J# 32-bit-onlyness.)  I should be able to always code under "Any CPU" and enjoy the safety of not accidentally switching configurations.  

Related to this: the configuration dropdown is lying to me.  If I have a multi-project solution, the Configuration management dropdown is where the actual configurations per project live.  As per paragraph #1, I really don't care to be managing my experience at this level in the first place.  I don't really care about configurations!  

Make debug/release a separate project property, and stop trying to cartesian-product-out your configuration matrix with the debug/release dimension. Managed code doesn't have as many Debug-specific settings as native code does, but that doesn't have to mean it inherits the messy configurability.

Other than that, Visual Studio is simply awesome that will keep my loyalty for a long time to come.

i'm agree with brian . the MSDN have so many problem . it doesn't have a good organize . some times while i can't work with new controls i refered to MSDN but i can't get a clear answer. i think that the microsoft must be think about it .

I second the suggestion Michael H made. Please include true support for long double in Orcas.

Alright, I'm late on the wagon.  But here are some things I'd like:

(1) More C++ standards support (but forget 'export').  TR1 should be fully supported by VS2008 and should be part of VS2008 when it finally is out of Beta.  

(2) The parts of C++0x that look to be frozen should be implemented too.  One of the things I keep reading in articles and on comp.std.c++ and comp.lang.c++.moderated is that existing practice is one of the keys to getting new features standardized.  While VC++ is by far the best C++ IDE I've used (despite its many shortcomings), it is really sad to me that gcc is more innovative in terms of new ideas, C99-interoperability, more quick to implement TR1.  I would expect MS to be more competitive here.

(3) C99 pre-processor support.  Variadic macros are just too useful.  C99 lanugage support is less important.  While it would be nice, I think there are other higher-priority items to focus on.

(4) 80-bit long-doubles.  If someone is using long doubles, it usually indicates they *want* the extra precision.  This used to be supported in old versions of MS compilers.  I really don't understand why this was dropped.

(5) Please add #region statements like C#.  These are useful for collapsing and navigating code.  Right now, I simulate this via #if statements: '#if 1 //REGION: Some Region'

(6) I would also like to see some new useful libraries for C++ that are not tied to MFC, ATL, or some other package.  They should be independent of eachother, usable in console applications, and provide good C++ abstractions.  Examples: A Windows C++ threading library, a C++ filesystem class, a typesafe C++ printf and scanf library ala Alexandrescu (iostreams makes internationalization extremely difficult), a light-weight Windows XML class, something like boost RTL (currently in the boost sandbox).  I know there's a lot of useful knowledge inside MS Research -- let's see some of this come out and help the rest of us developers.  Having libraries like this would also allow something for the standards comittee to see what can be implemented and what people like.  This is the one of the key ways to keep moving the C++ language forward.

NOTE: These libraries don't have to wait for Orcas+1.  They can be provided as seperate libraries for download or made available via service packs.  If there is something useful, get it out there!

(7) An built-in garbage collector.  This could be something entirely new or something with the same interface (and heopefully optimized version) of Hans Boehm's collector.  I don't beleive this is a cure-all.  I think good memory management is still key and the the RAII idiom has really helped reduce the amount of memory leaks.  But there are a few situations where having a garbage collector would really help optimize code.

(8) A way to create a FILE* that works on a buffer located on the stack or heap.  There are a number of legacy projects that access files that my company would like to now allow in-memory access to.  Having something like this would be really helpful!

(9) Built-in help is useless to me.  It takes too long and doesn't return good results.  Google is much better.  MSDN online is OK, but it is still difficult to find the right information sometimes.  I suppose that's half because the library is so big.  But I do think something could be done to help navigate it more quickly.

Alright, I'm late on the wagon.  But here are some things I'd like:

(1) More C++ standards support (but forget 'export').  TR1 should be fully supported by VS2008 and should be part of VS2008 when it finally is out of Beta.  

(2) The parts of C++0x that look to be frozen should be implemented too.  One of the things I keep reading in articles and on comp.std.c++ and comp.lang.c++.moderated is that existing practice is one of the keys to getting new features standardized.  While VC++ is by far the best C++ IDE I've used (despite its many shortcomings), it is really sad to me that gcc is more innovative in terms of new ideas, C99-interoperability, more quick to implement TR1.  I would expect MS to be more competitive here.

(3) C99 pre-processor support.  Variadic macros are just too useful.  C99 lanugage support is less important.  While it would be nice, I think there are other higher-priority items to focus on.

(4) 80-bit long-doubles.  If someone is using long doubles, it usually indicates they *want* the extra precision.  This used to be supported in old versions of MS compilers.  I really don't understand why this was dropped.

(5) Please add #region statements like C#.  These are useful for collapsing and navigating code.  Right now, I simulate this via #if statements: '#if 1 //REGION: Some Region'

(6) I would also like to see some new useful libraries for C++ that are not tied to MFC, ATL, or some other package.  They should be independent of eachother, usable in console applications, and provide good C++ abstractions.  Examples: A Windows C++ threading library, a C++ filesystem class, a typesafe C++ printf and scanf library ala Alexandrescu (iostreams makes internationalization extremely difficult), a light-weight Windows XML class, something like boost RTL (currently in the boost sandbox).  I know there's a lot of useful knowledge inside MS Research -- let's see some of this come out and help the rest of us developers.  Having libraries like this would also allow something for the standards comittee to see what can be implemented and what people like.  This is the one of the key ways to keep moving the C++ language forward.

NOTE: These libraries don't have to wait for Orcas+1.  They can be provided as seperate libraries for download or made available via service packs.  If there is something useful, get it out there!

(7) An built-in garbage collector.  This could be something entirely new or something with the same interface (and heopefully optimized version) of Hans Boehm's collector.  I don't beleive this is a cure-all.  I think good memory management is still key and the the RAII idiom has really helped reduce the amount of memory leaks.  But there are a few situations where having a garbage collector would really help optimize code.

(8) A way to create a FILE* that works on a buffer located on the stack or heap.  There are a number of legacy projects that access files that my company would like to now allow in-memory access to.  Having something like this would be really helpful!

(9) Built-in help is useless to me.  It takes too long and doesn't return good results.  Google is much better.  MSDN online is OK, but it is still difficult to find the right information sometimes.  I suppose that's half because the library is so big.  But I do think something could be done to help navigate it more quickly.

I've read a few more comments from other users.  I'd like to re-iterate a few of their requests:

* The 'assist pane' is a great idea.

* Once intellisense doesn't lock the GUI, have intellisense pop up whenever the carret is placed in the argument list.

* macro debugging would be really nice.

* An easy way to store stack-frame information would be really nice as well.  Stack frames in .NET exceptions are ver useful when debugging.  Some way of easily storing the same information in C++ (and C) would make life a LOT easier!

* C++/CLI support is key for .NET interop.  It is so much easier (and maintainable) than C# p-Invokes.  Please get tool support for C++/CLI up to par with C# tools.  And don't let C++/CLI fall behind technologically as a .NET language.

* Please support C++/CLI on Windows CE.  I hear there are technological reasons that this isn't possible.  Please fix these thechnological problems on the next CE OS, then get compiler support for C++/CLI for WinCE.

Small request: more than two "Find Results" windows.

Mixed debugging of 64-bit code.

I'm part of a game development team that has just started to migrate to a C++ / C++/CLI / C# workflow (writing our engine code in C++ and game code in C#). We think that C# and C++/CLI are excellent, but there is something we'd really like -

Native/CLI code IDE improvements. The C# intellisense is amazing, and we'd like even a fraction of the improvements to be backported into C++. Things like the context sensitive list suggestions that you get in C# would be a godsend to C++ development.

Oh really? I'd like to see Intellisense working, without hanging VS.

In VC6 is possible to share pch across projects (in my case ~60 projects from libraries to exe) In VC 2005 after a long war i realized that is not possible to do this. Please share pch across project's for two reason:

1 speed-up compilation time

2 decrease disk usage (each pch is mant MB and is the same in every project !)

Pepito Sbarzeguti, I opened a bug on supporting shared pch's.  But I think the IDE should just do the right thing and automatically use pch's without user involvement.

I would like to see such basic IDE usability improvements as

- Switching between header/cpp with a keystroke, regardless if they're in the same directory or not.

- The ability to add a new header/cpp pair to a new project with a single click. Newly added units should not be completely blank. It would be nice to customize the content, but every unit needs some kind of a header guard, a namespace, and the cpp usually needs to include stdafx and the corresponding header. It is currently too painful to add a new C++ unit/header pair, it works so much better with C#. Sometimes I wonder how people add new units to a project, because the IDE's usability is poor when it comes to C++.

- It is a major pain that the IDE renames files to lowercase. ThisIsMyFileName.cpp is easy to read; thisismyfilename.cpp is not. It's annoying that I have to constantly rename files back. Save should never rename, that's what Save As is for.

- The C++ forms editor is not a first class .NET citizen. At the minimum, it shouldn't litter the header file. Partial class support would be even nicer. I gave up on doing GUI development in C++/CLI.

Like others have mentioned, C# intellisense is so helpful. I love C++ with a passion, yet I enjoy writing C# code, because it's so fluent.

Keep up the work on the ever improving C++ standards compliance.

I apologise if this has been mentioned, but I really would like to see an easier way of changing the compiler itself, but retain the IDE and (most) of its features.  All of the projects I work on are cross-platform, requering either special VS integration to compile the different binaries, or our own error-prone makefile projects, or even in worst case, editing in VS and building offline.

The "Makefile Project" gets us about halfway there but it does require hand-maintaining the makefile itself.  If that part was automated (generating a makefile from the file/project/solution properties), and being able to swap out with a different compiler, it would make things go much smoother.

If there is an (easy) way of doing this already, I have not found it.

My wish list? only ONE thing: my main and only problem is the slowness and clumsy interoperability between Windows Forms and native code. The new marshalling functions of Beta 2 are a good start, and I would finally move to .NET without hesitation if the performance was OK, but it's just not. When do we use C++? When performance matters. Why then is a C++ Windows Forms application so much slower than its counterpart in C# or C++ with Codegear's VCL?

Right now, I still have to use CodeGear's vastly inferior solution as my main tool, with VC used only to develop the core high performance libraries.

I can see I'm not the first or the only one here to mention that... Maybe there's a reason?

Did you guys consider offering as a new alternative to MFC, basically a native version of Windows Forms? (hint: buy CodeGear's C++ VCL - it's not like they're gonna ask for real money hehe).

I fully understand the .NET rationale, and agree with it 100%. But I can't bear the performance hit, nor can I go back to MFC.

My top complaints about VS are IDE related, this is where I spend most of my time. All of my code is in C++, and I don't see this changing in the foreseeable future.

Gripes:

#1: Splitter window support when using dual head displays: I used the tab views and find it very annoying that the splitter keeps moving around. I set the splitter at the inside edges between my dual screens, but entering the debugger changes the position, so now my break point marks are on the left screen. Using the toolbox, solution explorer, class view, and other auto hideable, dockable views also keep moving the splitter. Let me pin the splitter to the inside edges of my dual heads and don't move it!

#2: Problem introduced with the SP to VS2005: VS fails to open all windows when re-opening a solution if you had a resource open in the IDE at exit. When VS2005 with the SP applied (and the beta Orcas) reopens a project it only loads the files you have opened until it hits a resource, like a dialog or menu, and then it stops restoring the windows.

#3: Icon and toolbar editing is very painful, need to work on this. Better support for colors.

#4: Also agree with comments inf favor of the old ClassWizard. Attaching messages is much clumsier now.

I agree with many of the comments on VS6 being the pinnacle of VisualStudio. I do think things have improved from VS2003 to VS2005.

I am using VS2005 because of code generation that I need. It took my group a long time to move from VS6 to VS2005 because of all of the things that broke in VS2003.

Thanks for asking for the feed back. I really hope you use it.

Hey John,

With reference to your F12 issue, I'm happy to let you know that we have fixed it in VS 2008.

Hello

For everyone who expressed an interest in the future of MFC I just wanted to point out Ale’s session at TechEd Developers - 05-09 November 2007, Barcelona, Spain.

The details are:

Title: MFC Updates for Visual Studio 2008 and Beyond    

Presenter: Ale Contenti  

Abstract: This session will demonstrate the new features added to MFC in Visual Studio 2008, including support for Vista Common Dialogs, Vista Common Controls, the Microsoft Office 2007 Look and Feel (including support for an Office Ribbon style interface), Office and Visual Studio style Docking Toolbars and Tabbed Documents. We will also talk about our plans to evolve the MFC library for Visual C++ 10 and beyond. This is an in-depth session designed for experienced C++/MFC programmers. (C)    

Please drop by and say hello to Ale!

Thanks

Damien

Hello

Re: Monday, September 17, 2007 4:33 AM by anonymous

> Oh really? I'd like to see Intellisense working, without hanging VS.

Firstly, I just want to say that we hear all of you loud and clear on Intellisense. Just to reiterate what Marian (Luparu ) said above:

“C++ Intellisense is a topic that came up several times throughout this thread. I agree with you that today’s experience with Intellisense is poor, both in terms of performance and scalability. As Bill Dunlap noted above, we are working on a rewrite of our compiler front end that will provide Intellisense functionality at least as good as any other compiler for the our Orcas + 1 release. Of course we also realize that we need to address some of the pain-points with Intellisense in the immediate future.”

A working Intellisense “without hanging VS” (as you put it) is a top/major priority of ours going forward and with the work on the front-end rewrite that is already underway we are confident that Orcas +1 will be a different experience.

Thanks

Damien

This is answering Peter Westerström regarding mixed debugging on 64bit. We are aware of the importance of such feature and is a high priority on our interop feature list & investments.

Thanks,

Ayman Shoukry

Lead Program Manager

VC++ Team

Hello

Re: Tuesday, September 18, 2007 4:17 AM by Phidias

> I fully understand the .NET rationale, and agree with it 100%. But I can't bear the performance hit, nor can I go back to MFC.

Always after a little feedback/understanding of our customer’s requirements – so I am just curious what prohibits you going back to MFC?

Thanks

Damien

one word: metaprogramming

IntelliSense is a great option, and works perfectly in languages like C# so it would be extremely helpful if you could get IntelliSense working as perfectly in C++. When I add a dozen new members to a class, I have to keep switching back to the class's header file to remember what I named them! I would love if IntelliSense would update straight away.

I think a GUI interface (Just like C++/CLI designer view) for developing MFC applications would be extremely useful if possible. I cannot imagine how fast and easy it would be to develop programs with this powerful tool. Right now something like this is possible just for dialog boxes in MFC. Doing the same with MFC programs would be nice.

Also managing the resources have some problems in VC++, when I rebuild the solution sometimes all of my resources go with the wind :D

E-Mail: alirezanoori@hotmail.com

I think a GUI interface (Just like C++/CLI designer view) for developing MFC applications would be extremely useful if possible. I cannot imagine how fast and easy it would be to develop programs with this powerful tool. Right now something like this is possible just for dialog boxes in MFC. Doing the same with MFC programs would be nice.

Also managing the resources have some problems in VC++, when I rebuild the solution sometimes all of my resources goes with the wind :D

E-Mail: alirezanoori@hotmail.com

I'd love to see a 1sr class visual SQL designer for any ODBC source. Personally the more cross platform database support the better.  Embedded SQL and the works.

I use a lot of DB2 and DB2/400 and feel it would be nice to have better support tools in VC when working with databases.

I use VS2003 for native C++ code, and are moving to VS2005.

Improve remote debugging.

1) the compiler should automatically transfer the executable when I make changes to the solution and rebuild. Why does it also check and say, debugging information is invalid, whenever I change files.

  This should be transparent to me. Maybe copy the file to a temporary file on the remote system and run it.

2. Make JIT (just-in-time) compiling better. Usually I just change some source lines, and continue debugging. Provide some kind of capability to add variables when using JIT. Make the buffer for adding code larger, so I can continually make changes and not eventually run out of memory.

3. JIT (just-in-time) is not usable when remote debugging, and you are using the network to contain the source files.

---> I've seen where you suggest to transfer the WHOLE source directory to the target, to enable. But this is silly, in the NETWORK connected world. Why not make JIT work with the network access to the source files.

-----------------------------

Give the capability to use the VS200x interface to create VS2003, VS2005, VS2008 code, which will run with those libraries.

---> This will allow me to use the current environment to continually support legacy code.

---> For this feature, I just want to the ability to setup the libraries built with to be VS200x, so I can be run on a system with the same VS200x "dll's"

------------------------

As everyone else has said, Speed up the IDE.

I'm just an old time systems prgrammer (IBM SDD) who would like to find a C++ compiler (and: link-editor, loader, debugger) which has a learning curve whose slope is considerably less than TAN[PI/2].

I've purchased Visual C++.net 2003 and find myself looking at an IDE which has been designed to do almost anything for almost anyone. In complexity it can be compared to the console of an F-15 (whose original software I helped to design and implement using multiple 8080's). Don't you guys have something that resembles the dashboard of a Volkswagon Beetle?

I already know what I want to do; know how to do it and require a simple tool that I can easily and quickly use. A Swiss knife is a beautiful thing, but not if what you really need is a very strong screwdriver.

Can you help me? I'd be glad to purchase whatever simple development tool you've got available.

Eric (learning_one@msn.com)

My issues are:

1- Why doesn't help default to the gigabytes of crap that MSDN has installed on my machine.  I can't make it work.  It always goes to the web???  I have messed with the settings and I can't make it work.

2- Intellisense is horribly flakey.

3- Compiling is horrifically slow.  So is debugging.  It would be acceptable if I was getting some great functionality for this cost but I recently came from VC ++6 and I don't feel like I have done anything but slow down.

Nobody really cares about new features when the current ones don't work or work poorly

We have multiple large applications in native C++, many with ATL and MFC.  

First, all the speed/correctness mentioned before. This is necessary, but not sufficient for continued use of MS products and platforms. (MS wake up-- the pressure from open source and other platforms is very real.)

What we would like would be:

- Actual real reasons to upgrade tools, not for "not wanting to be left behind", but for real productivity gains. Make our customers notice that we must have upgraded because we develop better/faster/prettier, not because we disappeared for 6 months trying to get stuff just to work again.

- Make it easy for us to get snazzy interfaces without suffering.  Note that this does not mean nonsense like HTML dialogs, but things like resizeable dialogs or decent printing support.

- Don't make use drink the koolaid for whatever the MS push du jour is.  Seriously, we cannot by fiat make our customers install .NET, move to Vista, etc. To the extent new features require these things, any time MS spends on them is wasted from our perspective.

- Keep our developers from writing code that should be delivered in libraries-- parsings, plumbings, wrappers. These just waste development, build, and testing time.

Thanks.

One thing I'd like to see in Visual C++ going forward is support for data breakpoints in managed, or at least mixed-mode projects.  I have an application that uses IJW to allow me to use the .NET XML facilities for input/output, and a native C++ kernel which does computational fluid dynamics calculations.  The "Set New Data Breakpoint" dialog is grayed out, even in my native code.  I've seen from Help (http://msdn2.microsoft.com/en-us/library/350dyxd0.aspx) that this feature is only supported for native C++, but apparently not for native portions of IJW projects.  I've tried setting them in files compiled with and without /clr: no dice.

Additionally, I hope this feature will work smoothly with OpenMP.

parkzone -- the Help setting you want is in the Tools -> Options -> Help -> Online

Try local only, not Online

in VS 2005.

Many good features of VC++6 are missing in the newer versions of VS, including VS2005, such as (1) Cannot use debugger to examine the content of each class array element (e.g., class matrix A(10,10), then debugger cannot see A(0,1), A(1,1), ...); (2) More difficult to customize the editor (now it is very difficult to customize the editor and many customizable features of VC++6 are gone); (3) Very difficult to activate the Watch 2, Watch 3 in debugging window. People can list more ......

Responding to Eric Roll - have you tried Visual C++ Express?  This is a free tool that's designed to be a slimmed down easy to use version of Visual C++.  It doesn't have a lot of the useful features you get with other versions like ATL, MFC, the profiler etc, but it may be just what you're looking for.

Ben Anderson

Visual C++ Libraries QA

I'm not sure this is C++ or not but the Debugger when in C++ mode.

I'd really like much more official support for the autoexp.dat file (maybe even take it out of that file and give a UI for setting this stuff globally and per project)

*) the ability to stop the debugger from stepping into certain things (like string constructors). Maybe a pragma for this instead of autodat.exp?

*) the ability to get it to print more useful info when in the watch window or hovering the mouse. (for example right now if I hover over an STL map all I get is ???

Supposedly those things are handled by autoexp.dat but I've never had any luck with it.

Also, Array inspector windows (like CodeWarrior) and the ability to cast a memory window to any type or array of types (like CodeWarrior)

When parsing files with extensions that don't match the expected file format (make.inc for example, or any .x file from a unix ONC/RPC code base), some of the parsers choke up and go off into never-never land. Give me a button or some other way to stop the parsing, so that it doesn't hang the interface.

When I hit "save all", please save all; including my window and tab layouts in the editing pane. Save the entire solution. Every time the above parsing problem happens, I smack my forehead, because I know that all of the work I've put into opening a file set, and arranging my tabs and such will be lost.

Put the intellisense parser into a background thread and set the priority to "low". When I create a new project that parses a large code base (which I do about 3 times a week), the intellisense parser consumes so much CPU that the interface becomes unresponsive. I now create those projects before I go home for the evening, hoping that it will be done by teh time I get back in the morning (and that it hasn't crashed before completing that too).

I keep running into lost delayed write issues because my projects are stored on a Network Attached Storage system which can sometimes close my CIFS connection. Other applications deal with this just fine, but Visual Studio doesn't. When it happens, the intellisense database that is kept open ends up causing lost delayed writes. Does that database need to stay open all day long? Can't the updates to it be batched up and committed all at once, or something? This may be a CIFS redirector problem, not necessarily a VS issue, but it could also be something that VS is doing differently than many other office-type applications.

I have small improvement in mind that would solve the annoying thing which many people here complain of. The problem is when you are debbuging code and stepping into functions, you usually want to skip all uninteresting things like string constructors or own already debugged functions.

In eclipse (despite it is terrible IDE at all) is a smart feature that you select by doubleclick the name of the function which you want to step into and hitting F11 will step directly into this function. Why not add this feature into VS? When nothing selected the old behaviour could be preserved.

Responding to Ben Anderson - RE: simplified programming environment.

Thanks Ben. I'll take a look before going over to gcc altogether.

If some of Microsoft's compiler writers (programmers) would sit down and design a simple development package which caters to designer/programmers like me -- there are lots of us -- then I believe that they could consider starting up their own business into a ready-made, profitable market niche.

Eric Roll

I would like to see a simpler way to handle File I/O.  Such as creating outlines of files, and the connected classes to fill them, then creating functions to easily write to these files.

.

.

.

.

.

Proper Multiple Monitor Support

.

.

.

.

PLEASE

.

.

.

I have filed soo many bugs concerning multiple monitor support with VS2005 and they all have been closed as "will not fix".

It is a real pain in the ass to use multiple monitors with VS2005. Windows forget their position, you get "invalid property" dialog boxed, etc...

I would like to see a servicing plan more responsive than "release one service pack two years later and fix all other bugs in the next product." When I am experiencing bugs in Visual Studio that are causing major pain in daily development, I can't wait two years and I don't feel I should have to pay several hundred dollars in upgrade fees to get bug fixes. Upgrading also doesn't work because there are always new bugs and new features, breaking changes in the project formats and IDE, etc.

I write native code applications in C++. Looking at the feature list for VS2008, there is very little added value for me, and yet I don't know if I can wait until Orcas+1 for a dialog editor that selects the control I actually click on, an editor that doesn't constantly thrash my disk while rebuilding the Intellisense database, and a project system that doesn't reorder the file list in the .vcproj file every time someone edits it.

I realize that Visual Studio is a huge application and doing bug fixes and QA is a massive undertaking, but it really hurts to see my favorite development environment have a constantly high level of problems from version to version. I still think Visual Studio is the best IDE for what I do, but since seeing what has happened to it since VS2002 I am seriously keeping an eye out for alternatives.

My number 1 wish would be a complete C99 support.

A working TR1 implementation wouldn't also be bad.

C++/CLI isn't so important for me since I rarely mix C++ and managed code.

It would be useful if Newer versions of Visual C++ could recognize older versions of C++(All the way back to the first version)

I think you can look at text processing languages like Perl and Python and try to do similar capabilities.

Thanks

Pain points :)

1.  Library pains

     a. Native windowing library? MFC is antiquated, period.  It doesn't make full use of the language, and its quite limited.  Wheres the next application framework?  Right now the only modern libraries are oriented around non-microsoft platforms.

     b. Fix the dynamic CRT (which is the default).   The CRT will crash the app on startup - intentionally I might add,  if it wasn't loaded via native-fusion (SXS).  Being able to xcopy deploy applications is a requirement for most internal tools at companies.

2.  IDE pains.  

     a. Intellisense reliability.  Its slow, it uses a lot of CPU horsepower, and its not 100% reliable.  

     b. Intellisense on projects not built using the project system. (Why can't intellisense figure everything out from a PDB?)

3. General feature requests

   Time-travel debugging!  You get a crash, you want to know how things got to where they did, you can step backwards, run backwards, see state the program was in when it last wrote to a memory address, etc etc.  

A COM Visualizer!

It is a pain now (as we have been put into so much luxuries like support for STL while debugging native unmanaged code) :)

I was desperately looking for it in the current release :D

Hi,

Just a couple of aethetic points:

- Bring back tabbing of code files. I know the VS 2005 has its own unique way of organizing code files that you open in VS 2005 and after a certain number you have to use the drop down arrow (or CTRL+Tab to see the same list) and choose a file from the list. Major annoyance! Sometimes its good to keep what worked well from a previous version (VS2003)

- Intellisense support. VS 2005 has had a LOT of intellisense issues and I have personally tuned it out now and exclusively use VAX. Personally, I have great faith that MS can produce intellisense which can match or surpass VAX.

Thanks and best of luck for the project!!

I write native code in C++, although I can see us using C# and .NET for GUI in the future. Our application uses compute intensive proprietary algorithms that are implemented in C++ and assembly language, and this code will likely be married to the hardware for the forseeable future. We need Microsoft to pay attention to native C++.

And, we don't want weird extensions that aren't portable either, we want the C++ standard.

We don't need the "export" keyword, but most of the rest of the standard should be met. On that note, kudos for Microsoft for already meeting this requirement, the compiler is very good both in compliance, and in generated code. I only mention this because I fear that the big push towards .NET will result in Microsoft dropping attention to the importance of these features for many users (despite marketing claims to the contary - I never believe such claims unless they come directly from product managers - tides shift!)

I agree with the comments about Intellisense. Perhaps this feature should run out-of-process? It's incredibly annoying.

Given the complexity of maintaining the help system, which must allow adding help for addins and new SDKs, I can understand why it is the way it is. You obviously won't be able to go through your help system and find all the inaccurate data. You could add a "simple" way for people to report errors over the Internet and implement a simple way for help to be updated automatically (perhaps once a day, or once a week, during off hours.

The Blogs from Visual C++ group are very definitive in stating a renewal in development of MFC, and a dedication to development on interop between native C++ and C++/CLI.  However, they are not definitive in stating a committment to further development of WinForms.  

Question:  Will WinForms continue to receive active development in C++/CLI land?  If I am starting a new app for .NET and native C++ 'interop', would I be wrong in deciding to build it using WinForms?

1. C++ 0x! I know that writing a compiler for such a language is not an easy task, still it would be great if in re-writing the IntelliSense you kept in mind the upcoming changes in C++ such as new 'auto' semantics, so when the compiler comes, you would just "uncomment" the piece of code you already had at hand.

2. If not C++ 0x at this time - maybe some code-snippet-like support for "auto" or "decltype"? It would be great if IntelliSense, which is already capable of interpreting types, could resolve:

map <int, int> m;

$auto i = m.first(); // a suggestion for the code-snippet syntax

to

map <int, int>::iterator i = m.first(); // code expanded at newline, semicolon or compile request.

3. Simple automatic code generation tool like "implement methods" - user selects some code in the header file and VS generates the displaced implementations for selected member function headers in a user-defined .cpp file. Much developer's time could be saved for more important tasks.

4. I would VERY much like to see a C++/CLI for non-win32 platforms. For me it is a bit of a misunderstanding, that mobile devices, where resources are far more critical than on normal desktop machines, are missing such a great technology that would allow to easily put memory-efficient unmanaged code in operation.

C++ compilation time is a major strike against the entire language.  The solution on two big projects has been to get Xoreax's Incredibuild.  It makes my current project compile in 10 minutes, down from 45 minutes.  I also believe that Incredibuild saved Madden 2006 for XBox 360.  It made Madden's compile time go from 1.5 hours to 20 minutes.

I have fought the compilation time problem for most of my career and would love if distributed building was an integral part of developing for C++.   Instead I have to convince each individual project to buy Incredibuild and that takes lots of time and effort.

Suggest improvements to the user experience to be able to get into the source, make a change, and get out quickly. Some very simple examples, I'm sure you can think of others:

- be able to create a cpp/h pair and (optionally) keep them in sync -- so if I add a function or change the declaration in the cpp  the h is updated (like refactoring, but just make it work).

- make an option to "correct" the case of variables I type in to match the declaration (like VB6).  In most cases I don't want to be case sensitive, and it just wastes my time to figure it out.

- In MFC, the old class wizard wasn't the greatest, but now it's much worse.  Simply adding a menu item to existing code just took me an hour when the same thing could have been done in VB in about 10 minutes.

Also, I would like to see a managed version of MFC.  Might be hard, but I have a legacy product that is heavily Doc/View in MFC, needs to go to managed code, and will cost too much to rewrite from scratch in VB or C# WinForms.

Some bugs?

In the IDE, the "find next" across documents often does not work right (not finding things that I know are there).

You can't set a breakpoint on a goto statement because the compiler emitted two jumps and the debugger maps to the second one.

I'd love to see the class wizard back in action. it was so much better then, right clicking a grey looking graphic and selecting a method and property, and then manually having to add events and such. Were as the class wizard I could add events and even select timers button down events etc etc… fast and easily. Now I’m forced to create applications in vc6, add all the events methods and props there then import into 2005.  i do like 2005's attach to process way better then vc6's and tabs :)

So please, please bring back the class wizard :)

why is it if you have 40 projects in the ide, it takes days to open, but if you look at the task manager the cpu is hardly getting hit.???

why does the ide crash so often when opening the form editor?

We are prevented from making full use of an excellent third-party toolkit because of VC++'s implementation decision on initialization of local static variables in a multi-threaded application.

I realize that one can argue the C++ legalisms either way (and I believe an extremely strong case can be made for multi-thread safe initialization) but the key points are that (1) only the compiler can do this without changing the variable's scope, and (2) non-multi-thread-safe initialization violates the principle of least surprise.

Please restore the profiler.  It has been part of this product since it was C under DOS.

If you want to make better tools for extra cost, wonderful, but don't take away a tool that has been there for, what, 15 years?

I don't know if the following topic is posted or not!

Hardly I have time to read all the comments.  Sorry, if my comment is irrelevant or redundant.

I would like to see some extension, which is specific to GPU based computers.  

something like

GPU float4 texture(1024,768);

which makes an array of 1024x768x4 float array in the GPU memory, which can be used, just like any other array

like

texture.setColor(x, y, RED);

texture1 = texture2 for deep copying etc

1) Allow pasting of pictures into the code pane.

Give the developer the option of externally linking images so that source-control isn't screwed up, but also the option to encode the images as text (ala email) has the benefit of never losing your images with your code - plus still works as a text source control file.

2) Allow developer to have his/her own meta-data area within the code window (which is currently done via comments)... however, various products all want to use the comments area for their own special markup. Let's formalize the meta-data/comments area  and make it much more useful... and leave the comments - just for comments.

3) Don't add new features until existing bugs are sorted out.

[Stephan T. Lavavej]

>> STL improvements are high on the wishlist.

> Which improvements, specifically?

Apologies for not replying sooner. Aside from the obvious (hopefully continual) performance improvements, things like unsorted hash_maps (requiring an operator< is actually quite a problem, when third party code only provides a hash and equality method) and the further TR1 improvements come to mind.

[Stephan T. Lavavej]

> What does STLport do better?

This blog was the first I'd heard of the VS STL having a checked mode, so without having time to sit down and compare each feature by feature, it's hard to say which is better. Perhaps such things get lost in the deluge of C# marketing.

That said, by STLport being a portable plug-in, it offers extras that enable unusual usages, such as not using the std:: namespace, which can be incredibly useful in cases where third parties have (probably incorrectly) exposed STL in their public headers and you want to maintain a separation between your internal STL and the one you're forced to compile and link with in std.

One related really obvious advantage STLport has over the VS STL is that it can be used with any compiler, so where we have no choice but to use VC6 or VC2003 etc. (again, unsurprisingly, due to third party code) it offers something that is compatible, yet maintained with bug fixes and improvements, whereas the only way to use the latest VS STL is to upgrade compiler (or at least that's what's been communicated).

I suppose a long-term goal that comes to mind that would solve both of these is to arrange matters such that C++ results from older MS compilers e.g. LIBs and DLLs are compatible and usable with later MS compilers and libraries. However, this would be quite a sea-change for Microsoft, so I'm not going to hold my breath :)

[Stephan T. Lavavej]

> Doesn't Visual Studio come with a copy of the MSDN docs?

Good question - it's possible our default install simply assumed Internet-only, but I've not seen an obvious option for a local copy on reinstalls. However, the help options that someone else pointed out (which I would never have found myself) inside VS itself imply it can be done.

[Stephan T. Lavavej]

> ...mentions various things being bugs and to put them on Connect...

Will do when I get time, but the hard part (as it always is in debugging) is giving precise reproduction information. For example, the RTC issue I mentioned; we've struggled to identify where the problem arises, but have been able to observe that commonly run code can take up to 50% longer.

[JMD]

>These little kiddies need to learn that new operating systems and new development environments require new hardware PERIOD.

Not quite sure why you're bothering flaming, but your flame is also inaccurate. We're running VS2005 on top of the range machines, well above the advertised recommended system specifications, as the applications we design need a lot more than VS2005 does. We still experience slowdowns, mysterious delays, and the various other issues others have reported. Simply blaming these problems on older hardware is just plain wrong.

Another issue that have come to mind since my first post:

Whatever happened to OLEView in VS6? I've not been able to find an equivalent in any later Visual Studio. If it's there and I'm just failing to notice it, please point me to where it is, it's such a useful tool; if it's not there, please consider re-adding it.

Other than that, I have to say, well done on the continuing conformance to the C++ standard, and despite the pains, Visual Studio still beats other IDEs out there, so keep up the good work! It's gratifying to see people at Microsoft listening :)

1) Add distributed build feature (just like Incredibuild). Building time may take hours in HUGE projects without it.

2) Integrate a wrapper generator (such as swig).

We maybe the exception or minority, but our team DUMPED our prior development environment for Visual Studio C++ so that we sould migrate our existing native C++ applications to .NET managed applications.

1) I was extremely disappointed that the Beta1 of Orcas and Beta2 of Orcas didn't have (for C++ anyways) any designer for the latest platform GUI.

2) Additionally, I was disappointed that Orcas Beta1 and Beta2 didn't include performance improvements in the designers.  Compared to our prior drag and drop environment that we dumped, our developer on NEWER and horsier machines are LESS productive... Why?  Because they spend more time WAITING on the GUI to even render in the designer so they can make even trivial changes.  I really hoped that this would be addressed in Orcas but doesn't feel like it from what I looked at.

3) I'm excited (can't really express HOW excited) to hear that Orcas+1 will have refactoring, I've longered for this for a long time and HOPEFULLY improve on performance of the IDE and GUI designer and add support for WPF, etc.

 Keep up the good work with the tools...

I personaly would appreciate to see shorter compile time by having VC use more then one thread to compile 'large' projects without installing third party software.

No 'huge' distributed build system, anything that can use more then 25% of my processor would add to productivity.

Also it seem that VC8 dont do much parallel Disk IO? because 25% disk usage is absolute best case and its more often lower.

Thanks,

I only write native C/C++ apps. What I find particularly lacking is a profiler. There used to be one in VC6. I would like to see it returned.

I am especially interested in profiling floating-point code, as I do lots of signal processing.

I would also like a tool to help write MMX/SSE code based on intrinsics. The tool should analyze dependencies and warn me if there is a pipeline stall (for multiple CPUs), or give hints where there might be performance problems. Of course, this has nothing to do with C/C++, but many signal processing developers use MMX/SSE intrinsics intermixed with C/C++.

Kind regards,

Niels.

I never EVER want to see assembler when I step in to a function.  This happens every time any of the functions parameters is passed by value.  The only work around I have found is to pass const X& instead.  This obviously can't be done for 3rd party code.

Hello,

our project has a few sets of project arguments that launches the app in different modes during development. We currently have to copy paste from a text file the desired set of command line arguments.

would be great if the command arguments field was an mru combobox instead of an edit box, so we can get a list of recently used arguments.

If possible allow us to add pictures to code window (like you do in word). It makes it easier to visualize the problems when writing games. I guess this would be a lot of work but am sure people will appriciate :)

cheers

Pranay

I'd like to see a couple of things:

Sometimes after I stop debugging and I try to do a build, the linker cannot save the DLL to disk. Process Explorer shows me that devenv has a handle to the DLL opened. Sometimes I can hit build again (once or twice) and the DLL can be saved. Other times I have to close VS and reopen in order to link. I do a lot of edit&continue debugging and I won't swear it but I believe I only see this problem when doing E&C.

Speaking of closing ... The time to close a project in 2005 can be atrocious. It is much faster in 2003 and dang near instantaneous in VC 6. I blame part of the slowness on the TFS integration but that is just a guess.

Intellisense can become intelli-non-sense. Sometimes it just quits working for no apparent reason. Also sometimes the update just never finishes as it seems to enter a never ending cycle (90 files to go .. 20 files to go ... 120 files to go .. 90 files to go ..). I have to exit, delete the ncb and reopen the project and hope it finishes. I have sent gigs worth of full dumps to MS support and all that was determined is that it appears to be in a constant loop.

Where is support for 24 and 32 bit (alpha channel) bitmap files in the resource editor? Png? I want to see this message go away: "The bitmap imported correctly, but because it contains > 256 colors it cannot be loaded in the bitmap editor". Please, the bitmap editor needs to leave the 20th century. In the very least I know these bitmaps could easily be displayed so I am guessing that the only reason this has not been updated is due to the lack of editing tools. At least allow me to view the images if not edit them.

Fix the MSDN search tool. How bad does it look when I do a search for something using the MSDN search command and come up empty only to go to google and do a search and find the entry ... in the MSDN!

Some of this is more IDE than VC++ and some are just bugs (that rarely seem to ever get fixed as there rarely seems to such a thing as a visual studio service pack). But just as bugs in Windows or MFC are bugs in our products ,as far as our customers are concerned, so too are such non VC++ bugs VC++ bugs.

By the way, there is lots of features in 2005 that I love. "Ask a question" is great. Well except when a reply is posted telling me I should use "connect.com" or "this belongs in a newsgroup". My thoughts are along the lines of "I clicked the button and this is where I was taken. If it belonged somewhere else, tell that to the IDE developers. Besides, I have yet to discover the window in the IDE that shows newsgroups. Perhaps a newsgroup command (and view) is in order.

[Dan Konigsbach]

> Please restore the profiler.

[Niels Moseley]

> What I find particularly lacking is a profiler.

VC still has a profiler.  It's just in the uber Team SKU (along with /analyze, etc.).

[Jeff H]

> unsorted hash_maps

VC8 already has <hash_map> and <hash_set> in the stdext namespace.  TR1 will bring <unordered_set> and <unordered_map> in the std::tr1 namespace.

> third party code only provides a hash and equality method

Usually, operator<() is easy to write, while a hash function is more involved.  (I am continually amazed at how people always think "hash" when they hear "associative container" - I know that in other languages, associative containers are usually implemented with hashes, but it remains surprising.)  Still, the stdext containers should serve you well until TR1 arrives.

I have not used hash_map and hash_set myself, but they are supported and the compiler itself uses them.

> This blog was the first I'd heard of the VS STL having a checked mode

I've written a couple of posts about STL checking on VCBlog (linked at the end of Soma's post above), which you might like to read.

> the hard part (as it always is in debugging)

> is giving precise reproduction information.

Agreed, but a precise repro is necessary to investigate anything.  (We can deal with complex repros, although simple ones are nicer - but we need one to begin with.)

Stephan T. Lavavej, Visual C++ Libraries Developer

[Dan Konigsbach]

"I realize that one can argue the C++ legalisms either way (and I believe an extremely strong case can be made for multi-thread safe initialization) but the key points are that (1) only the compiler can do this without changing the variable's scope, and (2) non-multi-thread-safe initialization violates the principle of least surprise."

Actually given the current C++ Standard you can't argue both ways - the Standard assumes a single threaded environment. Also I am completely certain that given the strong C++ principle of "If you don't use it you don't pay for it" making the assumption that every application would run in a multi-threaded environment (and hence the initiialization of local static variables would need to be guarded) would not go down well with a lot of developers.

I don't even think that the new C++ Standard (which does include multi-threaded considerations) is considering changing this aspect of local static variables. They want users to be explicit about the guarding and unguarding of variables - after all if the compiler does this automatically then 50% of users always going to be convinced that the compiler made the wrong choice of implementation.

Hi Dan,

>>Please restore the profiler.  It has been part of this product since it was C under DOS.<<

Actually, we do have a profiler.  It works for native, managed, and mixed code and is available in the "Team System" edition of Visual Studio.

Steve Teixeira

Group Program Manager, VC++

[George P Boutwell]

> I'm excited (can't really express HOW excited) to hear that Orcas+1 will have refactoring

We're glad that our reinvigorated interest in native code is something that will add value to your development scenarios.

> I've longered for this for a long time and HOPEFULLY improve on performance of the IDE and GUI designer and add support for WPF, etc

Adding WPF designer support is not happening in Orcas and is unlikely in the near future. To fully allow us to focus our efforts in native code and native/managed interop scenarios that are unique to the C++ developer, we're deprioritizing the scenarios for using C++ for pure managed development.

[PranayKamat]

> would be great if the command arguments field was an mru combobox instead of an edit box, so we can get a list of recently used arguments.

This is indeed a great idea. I'll see what we can do to enable this scenario after Orcas.

many new improvements :)

but witch version of VS?

because if in TS, that is it not improvements...

what will be in stadard/professional version?

Separate Intellisence and Class wizzard.

As any of us who uses 3rd party libraries I am not able to work if Intellisence is turned on, so I have to delete(rename) feacp.dll. This causes Class wizzard to stop creating C++ classes.

IDE configurations are a mess.  We have a large C++ workspace that contains about 70 related projects and we have configurations that build a subset of the projects (this was ported from VS6).  When I add a new project, the new project gets added and enabled in every configuration, and I have to go through manually and disable the project in all configurations where it doesn't belong.  I'd much rather have the project be added to all the configs, but disabled and then I can turn it on in the configurations where it belongs.  Alternatively, another configuration view from a project's point of view might be useful -- a grid listing all the configurations that a project belongs to.  That would be ideal.  I get more griping from co-workers about the configuration system than anything else, since I'm the one that championed moving from VS6 to VS8.  I've even resorted to editing the .sln files manually.

One thing that really upsets me in several recent releases of VC++ is the deteriorating support for browse info. First, the call graph view was gone, then it became impossible to do searches for symbols prefixed with the class name using browse info. Why?! How do you expect me to look for CMyClass::Initialize in a project of 5M LOC? The search for Initialize takes minutes and returns hundreds or thousands of results.

Including all files into the project to generate ncb (which I suspect is being touted as "replacement" to browse info) for the product I work on is completely impossible - there are 10s of thousands of them spread over a crazy dir structure. Go try to add them 1 file or 1 directory at a time as VS UI forces you to do.

Oh, and if I do include some files in ncb, I get duplicate results when I search for symbols that are declared in those files (one hit for ncb, one for bsc). This is very annoying.

Please provide a nice, working, performant and easy-to-use symbol browsing solution with your next version. I really hate switching to Source Insight which the majority of my colleagues have done already.

I concur with many on this thread on that VC++ has become a "poor parent" of C#. Really, my productivity as a C++ developer has not improved since version 4.2. Man, I miss it.

Hi Pavel Ivlev,

We realize we have Intellisence issues. As a matter of fact, we already have plans to focus on such issues since we do believe these affects the overall productivity of VC++ developers.

Feel free to contact me directly at aymans at microsoft dot com and I can connect you to the owners directly.

Thanks,

Ayman Shoukry

Lead Program Manager

Visual C++ Team

C99 complete support

Is there support (planned) for Extension Methods in C++/CLI? It appears that VB and C# will both support it, but I can find no mention of it for C++/CLI

I simply find handling C# a nicer experience.  Refactoring support, intellisense always correct, etc.  If the VC++ IDE could just close the gap a bit more I would be happy.  Oh, and the SxS stuff tends to make me link everything as static to work around it - shame.  Surely the CRT updates could go out on Windows Update?

Hello

For those interested in VC++ Documentation (and we have seen many comments on just that here), you can view a Channel 9 video with  Gordon Hogenson on “Documenting Development Technologies” at: http://channel9.msdn.com/Showpost.aspx?postid=308206

Thanks

Damien

Although a 'Studio' sounds nice to marketing folks that somehow still desire feature-bloated can-do-all software, productivity-enhancing software doesn't work like that.

I'd vote for somehow separating all the non-C++ nonsense into a different software package. There's so much stuff that is in the way (judging from the memory & resource use) that even on a fast machine things are so much slower than VS6 was. Hardly progress.

I think it's hard to convince MS folks of any improving designs though, since the basic rule seems to be: "every next version more complex and bloated" (see Office & Vista for example). Still, there has to be some smart people there who can see that all these complex solutions for simpler problems (SxS for example) lead us to none other than other OSes and other software. Unbelievable.

Revert back to a compliant C++ compiler with a VC6-like IDE in terms of memory usage and performance, make that compatible with the Platform SDK and you're back in business.

Somehow how though, I think MS' future is doomed in the software department. Too much marketing pressure to do the wrong thing. :(

One more pain we endure is with the resource editor. It needs to allow one to specify the ID BEFORE writing to the include file.

So for instance, I do not want to create a bitmap and then go to the properties window to change the ID from, e.g., "ID_BITMAP1" to something meaningful like "ID_CANCEL_BITMAP" only to have the include file insert definitions for both ID_BITMAP1 AND ID_CANCEL_BITMAP.

The issue we have is that we have to manually edit the include file and remove ID_BITMAP1. Failure to do so can result in compiler errors.

It seems like this is something easily done. Don't update the include file until I compile the resources or otherwise save the resource changes.

Also, again today I have a project that intellisense simply cannot update. Give me a command to turn it off in the current project/workspace so I don't have to endure the update constantly hogging my cpu as I try to modify code in this project. A fix for the problem would be nice but in lieu of a fix, let me turn it off and on without hiding the fecap.dll file. Even with a hotfix we got (two actually) from MS support to run with a lower thread priority, it still causes the IDE to stutter as I try to edit or navigate thru files.

For MFC coders, there could be a lot more support by the dialog editor. In VB/Foxpro, for years, it was easy to write static text in multiple fonts. Doing this in an MFC app requires custom coding. It would be great if:

-static text could either go beyond 255 characters or the edit box for that property was limited to 255 characters (so you know when to stop typing and create a new static text item).

-static text could support full font properties.

When a dialog box is created, it is possible to copy and paste it from one project to another. Unfortunately, only the dialog is copied. Why not copy the resources involved (both resource.h and res files) to the other project as well? This would save time for this operation and make reusable dialog components more practicable.

The help search engine constrains the developer to "OR" searches for each keyword typed. This only expands the results. Developers are able to understand boolean algebra and certainly bringing back AND, OR, NEAR, and NOT would save a considerable amount of time.

Also, the ability to save searches as "help favorites" would be useful, and in the encapsulated browser, it would be great if excellent browser plug-ins like IE7Pro would function.

Compiler performance is definitely affected by adjusting the priority of the IDE/CL.exe under task manager. It would be handy if there was a way to control the priority of the compiler from within it. Somedays you need to multitask during a long compile, and somedays you need to compile as fast as possible (or the machine might be dedicated to compilation at that time).

Remember the "turbo" button on 1980s PCs? It was popular! Why not do the same with software priorities?

Debugging apps without having a debugger is problematic because it's non-trivial to get the context of the crash. It used to be possible to enable a number of critical error interrupts or traps, get control in a critical error handler, and dump out developer-produced contextual information.

This is hampered now because:

   1. common calls such as sin() unconditionally produce floating point critical errors each time it is called.

   2. MFC calls Dr. Watson by default and this typically produces standardized output that does not offer any opportunity for developer-produced contextual information.

   3. The call stack is not available from a function call as it is for .NET applications.

Note: I can still create a critical exception handler that bypasses Dr. Watson, but there's no support for getting context data which is so important at that time.

It would be great to ship self-diagnosing applications. A little help from the CRT/MFC to walk the callstack would go a long way here.

If there's a problem with the read only attribute on the resource files and a resource is attempted to be created, there is a warning dialog that says the files are read only. However the .ncb file is now corrupted because it thinks the resource got created and it is added to that file. Deleting and re-creating the .ncb file is now necessary, as well as making the resource files r/w.

How about heading off this issue "at the pass" by offering to make the resource files r/w?

VSS 6.0 still sells. I own a personal license, my company owns many licenses.

The IDE interacts with VSS more than ever before. I think there are more warning dialogs than in the VSS IDE itself. There are many problems with the VSS interface, partly due to limitations within VSS.

For example, one cannot have different projects within a workspace on different drives. I am frequently forced to check out a project though I don't want to make any changes in it.

Looking at project file "changes" directly by diffing the file, I frequently see useless numeric ids that have changed that really have nothing to do with the project from a developer sense. This data should be removed, moved to an external file, or otherwise gotten out of the way so that only when the developer changes a setting on the project is it ever checked out.

Other issues happen with dialogs that offer choices like: fix the server bindings or keep the server bindings and allow local files to be overwritten. There's no data presented that indicates what would change -- how many files are affected, etc. This makes it a little scary to make a decision without any further information.

Sometimes one cannot continue without checkout. If I want to make local changes only, then I save the file, the VSS interface sometimes pops-up and forces me to check out a file -- I can't remember the specifics of the context, but it's there.

Lastly, the "pending check-ins" are often well confused. States like "content" and "add file" are often totally incorrect. Many times I've used VSS diff on "apparently different" files and the dialog "files are identical" comes back. I've also seen files checked in initially into an odd VSS project folder configuration that doesn't match the rest of the project. Right now I have a file showing with Change Type "File not available" but the file is neither on my hard drive in the indicated location nor does it show up in the VSS IDE in the indicated location. Looking at a file history of the folder (an include file folder), the file doesn't even show up. What's most likely is that it was deleted at some point, however, why should it show up on the "pending checkins" screen?

I have seen bindings labelled as "invalid" but that's not very helpful as to determining what's wrong and how to fix it.

Ever seen this? "Microsoft Visual Studio needs to reopen source control database connections for projects in the solution. Your source control provider may prompt for your credentials." Just hit cancel after looking at the "change source control" dialog. Why this comes up I have no idea. The project is already connected and valid in this case.

You have controls on some VSS dialogs to "not show this dialog again" -- but is there any interface to change one's mind about these dialogs?

If a project is in two workspaces, each with different relativized locations to the project, this information is stored in the project file itself. Changing the project relativization may suit developer B on workspace B, but not developer A on workspace A. In addition to potentially causing a problem between development configurations because of differences in locating a project, it is completely unnecessary to keep this data in the project file -- couldn't this be moved to the .vssscc file or .sln file, and thus be individualized per workspace?

There are more problems with the interface than I am reporting here -- I kind of hate to just say "could you test this interface further and resolve more issues and limitations with it," but could you test this interface further and resolve more issues, make it easier to use, and not require redundant, unnecessary checkouts and checkins on files that shouldn't, or haven't changed?

These are all on the dialog editor & its code generator:

Could you change the Dialog Editor such that overrides are available while in the main editor, rather than (or in addition to) having to have the class selected in the Class View?

While dialog units and twips are admirable solutions to resolution independence, I think I can safely represent most native C++ programmers in saying we deal in pixels. Would it be possible to add this as a unit of measure in the dialog editor? Right now it's a pain to create a dialog box that is exactly 1024x768 pixels. I use a custom overlay created in a program like paint that is sized how I need it, then just scale the DU-based dialog until they match in size. Then I can create my layout based on the intended final resolution of the dialog.

Also, would it be possible to have an "Add Item" in addition to "Add and Edit" so we can add a bunch of interface items and THEN go and code?

Typically, the dialog editor adds a "public:" statement always. Can the editor call somewhere into the code state machine and find out if the permissions are public and intelligently add a public just once (or not at all)? If this is not easy, what about changing the editor to add a feature to eliminate this redundancy automatically?

Would it be possible to actually delete a deleted message handler rather than commenting it out?

Would it be possible to eliminate obsolete properties ("3D Look")?

Also, does it make sense to you to integrate contextual help editing into the dialog editor?

Alpha transparency is a bigger part of windows than it used to be. Some basic bitmap tools to assist here would be invaluable. When editing images, would it be possible to add support for at least screen-door alpha transparency, even on a file that doesn't have it in the native format (there would of course need to be a conversion to a format that supported alpha or to create an independent bitmask file).

And lastly (but not least), the set of MFC controls has been relatively unchanged compared to C#. It would be great if there was "official" support for a data grid and other basics that aren't covered yet in MFC, yet have been around for years in Microsoft's other windows-based languages. The WYSIWYG support is also weak (perhaps the proper term is "ancient") compared with other languages. WYSIWYG is perhaps the chief benefit of the editor, however merely placing controls is different from laying them out, which if done through coding, can be quite a trial and error process. The more complex the control is, and the more customized the dialog, the less WYSIWYG support there is for the details in layout, at least in native C++.

I only work with unmanaged code, and as of now I've got to deal with tedious tasks everyday, tasks that could be highly simplified.

1. Simplify the choice between standard and secure SCL. This could be easily done while creating the project having a tickbox (even enabled by default, if you will) to make the choice. The average Joe will just leave that on or google for its meaning, while people who know what it means will make their choice.

After all you're developing a programming environment for an unmanaged language, so your first goal shouldn't be saving users from their own stupidity like it happens in Office or Vista etc.

2. Improve process creations through wizards. There's no reason on this world not to create a quick wizard to let the project creator select between UNICODE and MBCS quickly, same goes for C++ vs. C (in fact - weird as it seems - some people still use pure C, from time to time...).

3. Improve F1 searches in MSDN. It often happens that searching for STL functions via F1 leads to finding homonyms in other classes/namespaces etc. Code samples for advanced constructs on MSDN could be improved/increased too, but that's a minor I wouldn't really die for.

4. Release more frequent updates, rather than one massive Service Pack ages after the release and then abandoning the product.

5. Offer native compilation as an option for C++.NET and make it a visible one, not one hidden by 55 prompts. Why? It's the only way you'll get more standard C++ developers to move over to the .NET version, because native compilation would eliminate interpretation overhead and decompilation ability (which is a concern of *EVERYONE* I've ever heard talking about .NET for consumer applications - and please don't reply talking about obfuscators, because obfuscated code is still 1000x more readable than plain assembly, let alone a well packed program). I'm pretty sure this thing won't even be taken in consideration, but hey, I had to let you know that it's something desireable.

Along with the above, all that you've already pinpointed as on your list is surely something that, in my opinion, deserves quite a lot of attention. Finally, try to keep in touch with the developers' community as much as you can, and all along the development and testing phases, because it's not by closing 5 clever people in a room thinking of improvements (which seems what you've pretty much done in the last 3 versions of Visual C++) that you'll meet real-worlds demands and requirements.

While doing the above may help and strengthen Visual C++'s position on the market, failing in doing it may result in a loss of a great market share.

Best regards

I would like to see an option to preserve the clipboard content's formatting when applying formatting by pasting.

A simple request, and then a more complex one:

Simple>  Provide the option to ignore comments when searching files for specific text or replacing same.

Complex> Add the option to search for:

1> real (none comment) identifiers; that is names which in the C++ syntax are identifiers.

2> type names; that is, locate only real (non-comment)names which would be interpreted by the compiler as the name of a type.

Thanks.

A dark, dreary night, with but a pale sliver of moon occasionally sneakig through the deep, dark clouds. Her face was still in my thoughts, sending a cold chill down my spine; so cold that the frigid wind seemed warm in comparison. She had seemed so kind, pleasant and gentle back then, as did her request. "A simple project wizard, That's all I want. Just something with a few linked pages to create a c++ project in vs 2005. I'm sure you can have that ready in a couple of days?" Her smile was endearing; no so much that of the attractive young woman she once was, but something almost motherly, in spite of the nearness of our ages.

"But what kind of mother would put me through this!", I howled in anger into the vast emptyness that was that night. It had seemed such a simple thing. Just do it in c++ instead of c#, like I usually do.

"Sure Karyn, 'l hve it for you Friday morning."

After all, I just need to click on another option or something, and the UI of the wizard will all be done for me. It's not like I will need to learn an entirely new programming language, double my knowledge of html, and scan vainly through MSDN for real documentation on how some obscure feature works to do something that is trivial in c#. I had once laughed in my head at the absurdity of such thoughts. Now I laughed loudly, and bitterly into the night at the horror of their reality. There I had sat, alone in the darkness with my lap top, malevolently about the task of violently tearing app wizards apart in the hopes of figuring out how they worked. Having long ago given up on real understanding, like Frankenstein building his monster I was now blindly stiching together the severed remains of my cyber-victims in the hopes that some how the monstrosity I was creating, with java script guts prodruding from html lesioins, would somehow live, call me master, and do my bidding by morning.

I pondered in horror the fate of my app wizard vicitms that I had sacrificed in my relentless efforts to appease my colleague. "Why couldn't they have at least given an example of something more useful than a one page console wizard!" I cried in anguish before collapsing in overpowering sobs tor the third time in as many hours.

I have one request.  I recently made the transition from Visual Studio 6 to 2005.

One of the features I really miss is the ability to browse to a method that is within commented code.  In VS 6 you could comment out a block of code, but still use F12 to browse freely.  Now you can't.

I don't know why VS 2005 had to get rid of this feature.  I used it all the time, for example in the method header comments I would have a See Also: section to document the significant callers or other methods of interest.

Please add this back if you can.  It was a mistake to consider commented areas as not browseable.

Thanks for the opportunity to comment.  I've been using MS dev tools since the IBM PC was first introduced.  I used to be very happy with them, but not any longer.  I have to eat what you serve, but I'm here to tell you I'm not enjoying it any more.  

I've been working for ISVs for the last 17 years.  I only code C++, un-managed, no MFC, and I use STL and ATL.  I've written or contributed to over a dozen retail Windows products in that time.  Several have won industry awards.  Thanks to MS I've been making a nice living.

VisualStudio quality is down (crashes, bad behavior, bugs, second-rate tools).  MSDN grows steadily more pathetic (really my biggest complaint).  Platform SDK samples diminish when they should be burgeoning.  Complexity of the target platforms continue to increase yet the dev environment doesn't keep pace.  Its obvious MS has almost abandoned the C++ community.  That translates into lower productivity, lower quality products, frustration and anger.

Some comments from MS employees in this blog seem to indicate a renewed commitment.  Unfortunately, MS has a history of talking optimistically in public, but the delivery has usually not matched the words.  Not that it matters.  You'll still collect your tribute, no matter what you deliver.  We peons living outside the wall are at your mercy.  And the white shining knight that is Linux rides a gnu, so i won't be joining his crusade.

Most of the dozens of things that bother me have already been mentioned in previous comments so I'll just contribute one that I didn't see in the comments I read -

I use a pretty high end workstation for development.  Compiles with VS2005 VC++ are slowwww.  I've investigated and watched TaskManager as the compiles runs on one processor while the other processor sits idle.  It appears that the granularity of the compiler threading is at the .vcproj level, not the .cpp level.  After some testing I discovered I could improve my compile performance significantly by removing all the dependencies from my project and doing multiple passes on my solution (yet I want dependencies because using them avoids debugging red herrings if I forget to build enough times).  So, I'd like to see the compiler's threading granularity designed in a way that results in the saturation of all my machine's resources.

First, after using VS 2002 and 2003 I really feel 2005 is a step up from previous versions and I look forward to the future versions.

Second, one word I did not see in any of the other comments is "Agile."

Unfortunately, I am not old enough to have written anything in VC++ 6 so I do not have a favorite feature that I would like reinstated and I have no benchmark on what the compiler performance used to be like, but I really think that if VS wants to be the C++ IDE of the future it has to move to another level.  There is more than compiling, linking, and debugging now:

http://en.wikipedia.org/wiki/Test-driven_development#Test-Driven_Development_Cycle

The features that I find lacking the most in VS2005 are those that enable me to be a more agile developer, which I really believe is the future development style no matter what language you work in.  I think several posts have already touched on the missing features for native C++ to enable agile developers: Integrated Unit Testing and Refactoring.

I went to a conference a couple weeks ago and saw some Java developers do things in Eclipse that just made me drool.  Right-click on a failed test and get a new class or method created for you! Holy-crap!  Now you write tests to generate code; that's the way it is supposed to be.

There do exist third party tools to enable some of this, but I don't think they can compete at the same level as the things Eclipse (and oter Java IDEs) can do.  Plus, VS integration would have saved me tons of time trying to find and implement the third party solutions.  And I know that C++ is a much more complicated language than Java (which is why even Eclipse doesn't have those features for C++).  Despite this complexity, there will have to be some innovation that enables the C++ developers of the future.  Someone will make the next C++ IDE, the Agile C++ IDE.

During the Visual Studio 2005 beta, I posted the following to microsoft.public.vc.language:

// Start of quote

> Jerry Coffin <jcof...@taeus.us> wrote in

> news:MPG.1cab3ccbcfa1a79698981b@msnews.microsoft.com:

> > While VS 2005 _does_ seem to be better than 2003, at least the betas

> > I've seen so far are still _clearly_ inferior to VS 6.

> Jerry - I work on the Visual C++ IDE and my main goal in life now is to

> make VS2005 a great release for those who loved the VC6 IDE :)

> Can you elaborate on why you find VS2005 clearly inferior to VS6?

I'd love to.

For the moment, I'll try to stick to a reasonably short list of the

most crucial items.

1) creating a blank file: right now, I go to File | New | File... |

(on the left side) Select Visual C++ | (on the right side) Select C++

file. This is a common enough operation that I think I should be able

to do it with ONE button press, just like I can in VS 6.

2) compiling that code: right now, I have to save that file, then

create a new project and then add that file to the project to compile

it. In VS 6, I could just click the compile button, and it would

create a new project that included the file, so I could compile it

with two mouse clicks, where the new IDE requires a dozen or so.

3) finding and replacing is sufficiently common that it should NOT be

hidden in a sub-menu -- it should either be available directly in the

Edit menu, or else put into a Find menu (or whatever) of its own.

4) I'd like to see the settings for the tools (e.g. compiler, linker,

etc.) go back to a skeleton format something like PWB used to use. To

go with this, I'd like to be able to create dialogs and link them up

with these skeleton files, so I could run tools of my choice without

having to write macros or add-ins to do the job. Granted, this one

can be worked around, but it's currently much more work to add a tool

than there's any real reason for.

5) in the help system, specifically the index, the drop-down list box

in the "look for" entry is (much) worse than useless -- without it, I

could get close to the right spot in the index, and then use the

cursor keys to move to the right entry. Now, using the cursor key

instead goes back to some previous search, which is essentially NEVER

what I wanted to have happen. I'm not sure I've EVER wanted what this

drop-down does, but hardly a day goes by that I don't end up opening

something I didn't want because of it. If this "feature" was dropped

completely, I, for one, am pretty sure I'd never miss it, but if it's

retained, it should be moved to a separate button where it isn't a

constant irritation.

6) once upon a time, we could make up our own filters for the "filter

by" used in the help index and/or searching. I.e. I could pick out

whatever sections I wanted in the TOC, give a name to that group, and

from then I could use that filter just by picking that name. Now in

the index, I get a small set of filters that are, quite frankly,

mostly useless. In the search, as far as I can tell, I don't get any

named filters at all -- each search, I have to manually pick the

language, technology and topic type.

7) Once I can add my own filters to the index/search pages, I'd like

the named filters to be saved with the project, so anytime I open

that project, I get those filters again. I should also be able to

make a filter global, so it's visible at all times.

8) I also think it was better when the search window opened as a tab

along with the contents and index -- right now, when I start to do a

search, it covers up the help page I'm currently looking at. I often

look something up in the index, then do a search on some terms in the

page I brought up, to find everywhere those things are mentioned.

Covering up the page I'm looking at makes that unnecessarily

difficult.

9) (Something VS 6 didn't have either). I think the default for

internal help should be that the help window open as a separate tab

group from the source code (etc.) windows. I can make it a separate

tab group, but anytime I close and re-open it, it comes back in the

same tab group, so looking at the help covers up my source code, and

vice versa.

10) The profiler is still needed. I know the compiler has profile-

guided optimization, but this isn't really a replacement.

11) The Add Member Variable Wizard is currently quite poorly laid

out. In particular, selections should be more or less hierarchical

from left to right, top to bottom. Right now, the "Category" drop-

down is off to the right of the "Variable Type" drop down that it

controls, which is quite counter-intuitive.

Personally, I see little point in a separate "Category" drop-down at

all -- I think it would be better to just have a Control class (e.g.

CEdit) as one of the types that could be selected from the Variable

Type drop-down.

12) In the AppWizard, it should be made more apparent that the list

down the left really is a list of items that control the selections

available on the right -- perhaps this changes with the color scheme

chosen, but at least with the colors I have on my machine and the IDE

in (I believe) a default configuration, it's essentially impossible

to tell which item on the left is currently selected except by

reading the label at the top and matching it up with the item on the

left.

13) Right now, when I right-click on a class in the class view, I get

an 'Add' sum-menu that currently has entries for Function and

Variable. IMO, another entry should be added for "Message handler"

that would bring up a dialog much like the VS 6 ClassWizard where I

can add a message handler. Alternatively, add a "messages" list to

the dialog that comes up to add a function, so when I add a function

I can also select a message for it to handle.

// end of quote

As far as I can see, the same problems all remain in the Orcas beta...

As an in-Microsoft user who develops exclusively in C++ but has to debug managed code, all I want is improved performance in booting, loading symbols and attaching to a process.

1. I would like to see a new GUI model other than MFC (which is broken and cumbersome). Perhaps whatever is in C# can be ported to C++.

2.  A new prepocessor token __FUNCTION__ which translates to the current function name in the code like __FILE__

Thanks

NATIVE CODE SUPPORT WOULD BE AWESOME!

If I want to write something for C#, I'll use C#.  But, if I want to write my own hardcore application, I'll write to C++.  I just love performance.

1) There has been a discrepency between intellisense and the compiler.  Often, intellisense will show a type for a variable, yet the compiler will say it's undeclared.  It's difficult to locate the missing declaration when it shows up as being there in intellisense.

2) With VS2003, the Solution Explorer would track the current file.  If I had 50 files open, opening the project would bounce the Solution Explorer between all 50 of the files.  That was wasteful.  The really annoying part was closing a file would bounce the Solution Explorer to some other file, hardly ever the one I wanted to look at next.  Then in VS2005, the Solution Explorer stopped tracking the current file, but the problem there was it's harder to locate the current file.  Ideally, the Solution Explorer could have a trigger, such as a double-click in the current file or an item on the right-click menu that would bring the current file into focus on the Sollution Explorer.

Thanks so much to everyone for their comments.  It's great to see the enthusiasm you all have for Visual C++.  We'll definitely take your thoughts into account as we plan the next release.

To summarize what we've heard, I'm providing the following consolidated view:

* IntelliSense doesn’t work

     Performance is slow and results are spotty

* Help system doesn’t provide useful information

     Loads of irrelevant hits

     Far too many topics don’t include sample code

     API content is “minimally reformatted headers"

     Content isn’t helpful

     Want a powerful local help solution

* IDE is slow and buggy

* Build speed is slow

      Many people asking for distributed build/link

* Better debugger stability

* Improved scalability in IDE and debugger

* Improved ISO standards compliance / TR1 implementation

While the points listed above were mentioned so many times they receive top ranking, there’s a “second tier” of issues that were repeated more than once.  These include:

* Improve interop support & kill interop support <g>

* MFC enhancements

* Bring back the Class Wizard

* Better dialog editing

* Better support for parallel programming

* Round-trip support for project files between versions

* Refactoring

* More static code analysis features

Thanks again for the comments!

Bill Dunlap

Visual C++ Development Team

The ability to mark and hide lines in the find window. I often do a find, and then investigate each hit quickly, and then revisit the ones that need further investigation. It would be nice to filter the list as I go.

And more than 2 find windows (let me name them and keep them around).

>> * Refactoring

>> * More static code analysis features

in team system or professional?

> Content isn’t helpful

I would say the content is actually extremely helpful, at least in terms of the Win32 API. Most of the functions I've looked at were rather well documented.

Also, the Index feature in the local help lets me instantly find any function/windows message/constant I'm after with no hassle. Don't see what people are complaining about.

If you know exactly what you are looking for, the index is way faster than the search.

I hope you guys don't just throw away all the good documentation you have in the MSDN and start rewriting it all.

Note: My comments only relate to native win32 API as this is the only aspect I use.

* IDE performance is poor, more if I compare with other C++ IDEs.

* Better conformance of C++ Standards

* C++ 0x support

* I do remember old help files with VC++ used to be more useful because right now I get thousands of alternatives when search for something. Versions before a clear and simple definition plus a sample when required fullfilled the request.

a really nice C++ feature has been the chance of platform portability. That's why native code support is a definitive  must.

The installer should install at least native languge help. MSDN is cool but it has more material that needs to be filtered carefully for not to waste time.

Years ago we decided to have a front-end using VC++, it was a pain to have all the features that a windows application based on VB was able to do with a few simple lines of code. Today those things have not changed and I see VC++ oriented to other scenarios as always been.

I see a greath challenge ahead for you guys, try to have a good balance between managed and native code.  But let's face that native code modules are for specific purposes just like managed code is. I'd like to see the IDE behaving quickly as with C# and VB.

Other things:

- A pattern wizard or advisor will be a nice help.

- Refactoriong

Last week I decided to go back to VC++ 6 and wrote a native code application because IDE is faster and help is quite better without lots of extra stuff that steal my time.

Provide the ease of use of the .Net FW in native C++ by writing useful high level libraries. XML serialisation may be a useful topical one - even if only done in a similar way to MFC's serialization facilities.

Hi Norm,

>> Simple>  Provide the option to ignore comments when >> searching files for specific text or replacing same.

>> Complex> Add the option to search for:

>> 1> real (none comment) identifiers; that is names which >> in the C++ syntax are identifiers.

>> 2> type names; that is, locate only real (non-comment)>> names which would be interpreted by the compiler as >> the name of a type.

These are great ideas and we hope to make searching way better and way more customizable in the next release.

Regarding the GUI in CLI,

I dont know what is the problem when we change the header file of the form and it's so slow when we come back the the designer, while my 2 core cpu, 2gb ram are still free, but my hard disk keeps reading 5 minutes for that.

Is there anyway to use all my 2 cores and 2gb ram to speed up this. otherwise adding 1 button or 1 event in to the form is too painfull.

Anyway, CLI C++ is the super feature of VS, at least for game developer. Most of the code for game is C++, and we really need CLI to build the tools that support the game.

CLI C++ please keep moving.

Thanks.

Regarding Visual C++ changes

I would like to see an improved linker options page within the IDE. The compiler options should actually be  switches (checkbox style) in the IDE.

Linker option help descriptions should be easily available from these switches via a F1 help key. Perhpas switch conflicts could be identified within dynamic help.

also the improvement of entering paths to third party libraries could be improved. Perhaps a separate pop up form for each library to be linked. To describe path and comments about library versions used in the build.

A working "sourcesafe" system. Something like svn. Because sourcesafe is not as safe for your code as you would expect. Especially when used by a team of developers it hurts. it hurts. it ehm well you know it doesn't work. I don't want to check out files. I want to check them in (like svn) and if the file in de database is newer... hey tell me (like svn). You know what. Just make a svn compatible implementation. btw with compatible I mean compatible not "compatible + ms extra's to break compatibility".

Would be nice.

For the rest I like VC a lot.

Keep up the hard/good working.

2 things:

1. incremental linking in mixed code

2. edit & continue in mixed code

The #1 thing I'd like to see is hierarchical project settings.

I have a product with approx 1m lines of legacy C++ code. To keep it managable and portable, I need to be able to restrict where project settings are applied to be mostly global. I was forced to use gmake because VS2005 project configurations do not seem to share settings.

For example:

1. I want our comany-specific defines done globally.

2. Next, I want project-specific settings to merge with them (add defines, override defines, prepend/append include paths)

3. Next, per-file settings, if present. I'd rather restrict those

4. Perhaps at each stage have it be shared+coniguration-specific (i.e. global+globalDebug or global+globalRelease)

Now, if someone sets preprocessor includes on an individial file for Debug, they don't get set for Release and the build breaks.

I would love to see the following:

- Working forms designer with event hook-ins like we used to have

- integration of third party single user source code control. My biggest gripe here is an easy way of version stamping executables (both numerically and in text) so that the MSI can self update and the process of turning release build into distribution is easy.

- integrate code signining into the IDE for EXEs now it is so important for vista.

You are completely right choosing native development as a 1st priority. C++/CLI, WPF, LINQ and other cool stuff are important from marketing point of view, but the real work is in native code. I’d like to note, that I rarely see problems with Intellisense, crashes and similar things, but that’s because I work very carefully: delete ncb, when it’s big, have very neat project settings, all files in the project are writeable and so on. Also I preventively restart VS when I’ve worked too long. I delete Intermediate directories periodically. IDE is pretty fast for me but other people, who do not care about tuning, experience terrible delays and slowness. Why developers should bother disabling last access bit in NTFS system and other similar staff?

0.  More bugs should be fixed

- My company legally purchases us all tools and it’s bad that you don’t service them, as, for instance, we service our products. There are pretty many bugs in VC++ 8.0, but we got only SP1 after which your team switched to Orcas and Orcas + 1.

- There is one particular not C++ related bug  http://blogs.ugidotnet.org/Franny/archive/2005/12/08/31303.aspx (Find does not work) which, if I were at Microsoft, I would like to fix myself: it’s so intriguing that VS Team cannot fix it.

1. Tools performance

- I have everything tuned, antivirus not installed, optimized and overclocked with RAID 0 and 2(yet) cores CPU. It works pretty fast, but some things just don’t scale well in VS. Here we have bad handling of huge workspaces and lengthy tasks which block all IDE without ability to cancel.

- It’s simple: preinitialize dialogs and other facilities in background. Macro engine is slow to initialize. Many IDE dialogs are slow when opened first time. Second time they are fast, preinitialize and the impression will be that VS is very fast.

- Compiler is slow. 50 MB of C++ code with medium-to-heavy template usage and MFC containers reimplemented via STL (workaround for Windows CE 4.x-5.x HeapAlloc). And we use /Zm in some places. It’s a pain to compile. But VC6(==EVC4) is 2+ times faster for same code.

- Local F1 is slow (probably because it does find anything when it finally opens). It’s slow, I don’t understand why. It’s only help system. I have almost empty RAID 0 and defrag it every night.

2. Intellisense-related

- Want folder browsing tooltip when typing in include paths.

- If I change configuration or platform, Intellisense reparses all the files, but it could have parsed them beforehand for all configurations/platforms (drive space is cheap, my time is not)

- Add open this file’s header/cpp pair command (I have a macro for this assigned to Ctrl+’)

- Order F12 hints by likelihood, not by ABC

- VS2008 Beta2 Intellisense support for heavy template usage is better but it fails anyway

- Improve Find All References. Ideally, I would like to be 100% sure that it lists everything so I don’t have to double-check with grep.

- My application is being debugged, CPU consumption is only 1%, Intellisense thread is stuck. Why?

2. Project settings

- PLEASE, PLEASE backward/forward compatibility between VS version N and N+1. I work on N+1 version for 6-8 months after VS update while all other team works with VS N. It’s a pain for me to merge their changes to N+1 vcprojs.

- DO NOT (X) reorder vcproj files. Aaaaaaargh!!!! Aaaaaaargh!!!!

-  Options intersection like in VS6. But, on the other hand, also leave an ability to clean setting in all multiply selected projects/configurations.

- Drag’n’drop and clipboard support for vsprops. Want to add a vsprop to multiple projects with 1 click. We have to edit xml manually.

-Macro API to manipulate vsprops (didn’t find one).

3. Compiler and libraries

- We have Rational Purify, it complains about uninitialized memory read (UMR) inside MS STL or crtl. I debugged crtl complain and yes, your vsprintf series (harmlessly) do UMR in some conditions (the bug is in Connect)

- PREFast – more warnings, naming rules, better control

-Standard: Exception specifications, and forget about export templates.

- ARM binaries are larger than ones compiled with EVC even without RTTI and exceptions. Hard to squeeze into Windows CE virtual memory.

- C++/CLI support (or better interop support) on Windows CE 6.0 and above.

4. IDE

- IDE is a face of the product. But MS delegated its development to lower-class, less-educated people. I understand that: I would rather like buggy Resource Editor than buggy Debugger or runtime, but it’s a face of the product anyway

- More abilities to drag’n’drop items within VS IDE. It is very important. I don’t use drag’n’drop between applications, but within IDE it’s natural and it does not work most of the time.

- There can be a lot of suggestions about the IDE but you have lots of C++ devs and I’m sure you can get feedback pretty easily.

- Wizard generated code MUST generate forward slashes, not back slashes in C++ code include paths.

5. Licensing

- Consider Professional+ edition with PREFast and Profiler. Add only $100-200 to Prof price. This will make Microsoft(!) Windows(!) applications better.

What:

Typeof operator for compile time time evaluation (not typeid). Often implemented as a compiler extension (IBM XL C++ V8, GCC) and likely for C++0x.

Why:

Valuable for templates, safer macros, and refactoring.

Examples:

Safe max that evals params only once:

#define max(a,b) \

      ({ typeof(a) _a = (a); \

          typeof(b) _b = (b); \

        _a > _b ? _a : _b; })

Declare pointer to whatever X is:

       typeof (*x) y;

Iterators (until auto keyword appears in c++0x)

       std::vector vec;

       for (typeof(var)::iterator i=vec.begin(); ...

Current workarounds:

Combination of template specialization, function pointer overloading, and a macro, as shown by Steve Dewhurst on Dr. Dobbs Journal, Bill Gibbons in 2000, and in the boost library. Lack of built in compiler support currently forces that each type be preregistered before use.

Feasibility:

Realistic, since the parser already knows the types of each expression.

Thank you

Guys,

A few comments regarding VC++ 2005.

I think MS should focus on fixing bugs in VS2005 instead of offering another buggy IDE. I have been using it for about 6 months and honestly I haven seen such crap in my live. Before I used vc6.0 and it was 10000x better, I had to switch to the newer IDE just because I have changed the job. Comments are:

+ linker is increadibly slow. same solution which took no more than 15 secs to link under VC6.0 TAKES NOW up to 20 MINUTES under VC++ 2005. I cannot believe how MS could release such crap, really. I had to rise an incident with MS just because it was not possible to work with the new IDE. No fix so far, of course,

+ ide is buggy - floating windows jumping around, suddenly changing positions. Guys, if you do not have means and abilities to develop decent software, please do not introduce new ideas. Test more!!!

+IDE crashes very often - not sure why. I have been using VC6.0 for about 6 years now and it has never ever crashed. I have about 5-6 crashes with VC2005 EVERY DAY (about 10 hours dev a day). This is unacceptable.

+IDE is very, very slow, again comparison to VC6.0 - a quad core computer with 3 GB of RAM has difficulties coping with two instances of VC2005. Takes up to 2 mins to close a solution with 50 projects. just few secs for VC6.0.

+Once you decide to add new features - to it properly. Look at class viewr and code competion and comare it with Visual Assist X (Whole Tomato). Perhaps you should send a couple of guys for consulting there. Same with "PARALELL COMPILING" - learn from Incredibuild guys, a simple light plugin which doeas magic.

Conclusions - focus on fixing the existing bugs intead of trying to cheat on developers selling them beta software.

One more thing - make sure you distribute the next version of VS as a trial version, our company is not going to risk 60 licenses paying for ....

Lex

Layout/UML, it's in the managed as view class diagram. Symantec had it in 1996 or earlier.

Edit and continue in debug. As someone said about native DLLs, we still need depend.exe.

Find and Replace, go back to the VC6 format with the original key commands. The current version is too much like the VB6 version that was to mouse dependent.

I would like to see optimizations around inline assembly, as well as inline assembly for x86-64 and ia64 (Itanium). The C runtime library could use a few optimizations in some of the basic functions such as memcpy(). In fact, it took me all of five minutes to produce a version of memcpy() that performed sigificantly faster than the SSE2 implementation in the CRT.

Micro-optimization? Perhaps.

Almost 25% faster? Definitely.

Considering the almost global use of the CRT, making some of the components faster may add a slight performance boost to most applications in a small way. Again, not big, but everywhere.

I would personally enjoy seeing a better integration of DirectX into VC++. Seems after all these years when installing the SDK it doesn't integrate into VC++ the way it would have been expected to do. For example, lack of templates and lack of linking to the correct libraries with out manually adding them. For the libraries I suppose a wizard that lets you select which libraries you want to have linked in would be very nice as well as a reconfiguration to change them via a wizard rather than manually changing them would also be very helpful.

Lex, if you have a specific solution where you can show linker regressions please use this guide to get us a reproducible case.

http://support.microsoft.com/kb/134650

and http://blogs.msdn.com/mlacey/archive/2006/07/25/678452.aspx.

If you have already filed a bug please give me reference to it so I can follow-up.

Rick Benge

Visual C/C++ Program Manager

Dwayne: this feature will be added to C++-0x - though the syntax will be decltype(x) instead of typeof(x). We are currently evaluating what C++-0x features to implement and when and this feature is definitely on our list.

Jonathan Caves

Visual C++ Compiler Team

I am satisfied with the compiler (good job!), but the IDE and frameworks are horrible.

1. Intellisense just plain doesn't work. Each release is worse than the previous. It is too slow, often doesn't find anything and messes up the project definitions if you have multiple projects in the solution.

2. Performance of the IDE. Again, each release is worse than the previous. What exacly is VS2005 written in? I am really curious. It's way too slow and unstable.

3. The resource editor has been a joke for many years. Could we not at least be able to _look_ at bitmaps with over 256 colors?

Also, put me on the list of people that want a viable GUI framework/designer for native code. MFC is old and had design problems from the start. WTL looks interesting, but there is no official support so I dare not even consider using it commercially.

To use two languages (C#/C++), or two different "paradigms" (managed/unmanaged), in the same application is NOT ideal IMO. I totally fail to see the advantage of managed code, and I can't pay the performance price even if I wanted to.

Why don't you make a native framework and put a managed wrapper on top of it instead of doing it the other way around? Makes no sense to me except from a marketing perspective.

Oh, and frameworks need to be able to statically link. I can't force customers to upgrade. Many big organizations are _very_ conservative and are still running Win2k. They also don't appreciate downloading and installing the latest version of an enormous runtime. Many of their computers are not even connected to the internet for security reasons.

I really feel that MS entire idea has been to bring programming to the masses and lock them into a proprietary language. The professionals with large projects that need performance and interoperability are left out in the cold. I am sure it's easy to write a widget (gadget?) or some standard database front-end in C# though.

Thanks for listening; I hope something comes out of it.

Hello

Many people on this thread have highlighted issues with MSDN Documentation. The VS Documentation Team is currently conducting a user survey. Since we know that many of you have strong feelings and innovative ideas about what we need to do to move the documentation system forward, please feel free to take the survey and let them know how they can best serve you: http://go.microsoft.com/fwlink/?LinkId=102169

You can find more information on the survey at Kathleen's blog: http://blogs.msdn.com/kathleen/archive/2007/10/11/wanted-feedback-on-visual-studio-content.aspx

Thanks

Damien

Why don't you release the new Orcas +1 version as a service pack to Orcas (Visual Studio 2008)? The fact that we need to wait for another 2-3 years to get the next _most_issues_fixed Visual C++ doesn't sound exciting for me.

Thanks,

Arun

Hi,

I tried the class diagram feature of Visual Studio 2008 for C++ (managed as well as native) and it didn't work very well.

Could you please enhance the class diagram feature for C++ so that it will work with managed C++ as well as native C++.

I write all my code in C++, since I need to interface with device drivers as well as do quite a bit of native Win32 calls.

regards,

Yogesh

Hi, Yogesh,

Thank you for your interest in C++ Class Designer.

For some reason, managed C++ was not supported in VS 2008. However we did take that into consideration and we know it's an important feature for C++ users.

We will do our best to make C++ Class Designer better in the future.

Thanks again!

Yang

I like VC but I but two things would make it much better.

1) It sometimes allows you to write code that is not exactly ANSI C++ complient; allowing 'bad' code to compile that would not compile with other compilers such as GCC.

2) a data-display debugger that made graphical representations of the data and/or an omniscient debugger such that you could debug back in time.

Thanks

Ardavon

good integrated (configure?) with msdn!!!

e.g.:

i write native code in winapi

write ShowWindow and press F1

what is open in msdn?

COleControlSite::ShowWindow !!!

i know... in "f1 options" i can select correct function

but i MUST select it...

possibility to configure search durign "f1 press"

e.g. - only in win32, not in mfc, not in dot.net, not in atl, not in...

I'd like an IDE that didn't keep forgetting my settings of where the windows and panes go.  About 20% of the times I launch an app for debugging, VS.NET squishes the build/debug area to an unreadably thin strip across the bottom of my screen.  Very annoying.

I posted before, but forgot one item I've always wanted. It is a relatively simple feature compared to many things asked for here

I wish, "Find in Files" and the general "Find" command, had a language-sensitive checkbox named, "Ignore commented out text." Even when commented out code has the C++ style commenting, making it possible to tell the line is commented out, where I work, there is a huge amount of code like this, which makes it very difficult to find what I'm looking for.

While I like that the "Find" commands allow RegEx searching, it's not easy to use, and it would be slower than a built in feature.

Some thoughts, based on a 1+ million line C89 codebase:

- I echo comments about F1 help - it is way too slow to start. Also, it's too hard to restrict the results to the area of interest: e.g. try looking for info on Win32 calls and you're bombarded with info about SQL, or about managed functions. If nothing else, provide a flag saying "native, managed, both" in the help.

- I work with 1million+ lines of C code - not C++. There's little chance of this being updated to even C++ let alone C#. It would be great to see the C99 and C0x standards fully supported, and more work on C-capable browsers (rather than just class-based).

- Managed interop is of almost no interest to us.

- I frequently get tripped up because the C compiler is more forgiving than other compilers (esp. gcc 4), and it would be nice to have a "strict" setup that complained, for example, about // comments in C89 files, or about various typecasts. I do understand that you can't "emulate" gcc, but there are things that could be done here.

- Please make Intellisense work in C mode. When I used to use C# it was great. In fact, make the C/C++ VS setup work as well as C# setup, (other than where it's impossible :-) )

- I frequently work in an environment where I have one of my own projects (a DLL) has its solution open, but the overall app involves code from other DLLs (which have their own solutions) and the main executable (with its solution). When I'm debugging I usually open "my" solution, and the debugger will happily let me set breakpoints, etc, in the other source files, but various other things (e.g. Find All References) dont work. It would be great if you could tell the debugger about all the components involved.

Note: each solution here is an _individual product_ with its own config and branching, so its not appropriate to have them all bound together in one solution. I suppose I'm asking for the ability to create on the fly super-solutions, consisting purely of other more detailed solutions.

- Provide improved ways to copy/duplicate subprojects from one solution to another where there are common libraries.

- when adding items to projects, have the open / add dialog remember previous settings - especially the file type. I frequently add "non-C" files to my projects, and find it irritating that I have to keep setting the file type to All files.

For that matter, adding a subtree would be great, too. That is, point an "Add Existing Tree" dialog at a root dir, and it adds all files found, using "Filters" to represent directories.

- STANDARDS - I hate it that on Mac, Linux we have C89 compatible functions (e.g. snprintf, ftime), but on VC we have _snprintf, _ftime. Why?  When I learnt C, the convention was that leading underscore represented an internal, system function that you never call, but snprintf is a standard C library call!  Please don't say "but you're supposed to use ..." because we are constrained by the other platforms too.

- Improved visualisation support in the debugger. It's got better over the years, but how about something like a visual graph of the call stack, or dynamically created & updated data relationship diagrams?... think out the box here!

Oh, and by the way can we have this all for last Tuesday :-)

HTH,

Ruth

The two things that get me are speed of opening a project and stability.

My machine is relatively new <1yr, but whenever I open a project I'm dead in the water for a minute while my disk spins and intellisense does its stuff.  (I defrag my drive daily.)  We do  use boost, so there is a reasonable amount for intellsense to handle.  If I touch my machine during this time, apart from being totally unusable, the interaction appears to hang VisualStudio which never completes the open process.

Earlier this week I tried very hard to debug a problem in an exe containing 1 cpp that linked two a couple of small static library files and a reasonably large dll.  Every time I stepped into the dll VC crashed.  I tried all the usual, deleting the solution file, the ncb, the Debug directory to no avail.  I keep hitting the send to Microsoft, so you should have plenty of dumps for this :)

When I exit VisualStudio, the devenv.exe process hangs out forever until I reboot my machine or crush it in task manager.  When I notice things getting really bad I'll go into task manager and see 4 or 5 instances of devenv.exe just sitting there.

VisualStudio routinely crashes on me.  Usually when debugging, but not always.

Other annoyances are:

Help.  This must get worse with every release.  When I go to the help for an API call I end up in CE or MFC land.  We don't use CE and chastise anyone who writes new code with MFC.  Ideally I'd like to prioritize the order since we do have legacy MFC.  Otherwise I'd wish to disable MFC and CE help and never see them again.

I see the Visual Studio is waiting for some internal operation to complete dialog far too often; daily.  Please complete this operation in a timely fashion.

On a good note, I am constantly surprised when I discover some new feature that is a joy to use.  Alt-O is my latest joy.

Thanks,

Steve

Game developer here, pretty much only C++ dev for engine stuff.

I may not have looked hard enough, but I would like to see per-solution settings that can add/modify things in individual projects.

For example: I'd like my solution file to be able to #define UNIT_TESTS for all the projects present. gcc and make can do this with "-D UNIT_TESTS" but I haven't found a way yet to do it per-solution.

Anything you can do to better manage 10 different projects with 16 different cofigurations per-project on 3 different platforms would be nice.  It sucks having to add an include path 180 times.

Other things:

- Make the platform|config name show during builds and when you're running. Seems like a small issue, but it's weird how many times I forgot while building or debugging something what I had selected.  Instead of hiding those combo boxes (e.g. for "Debug, Win32"), just grey it out.

- Maybe not a VS thing, but perforce plugin integration does all sorts of weird checking out strange files and not modifying them.  Just make sure the VS integration is tight with this stuff.  Also, adding a new .cpp/.h file to a solution does not automatically add it to source control, which is really annoying and is the highest cause of broken builds around here.  Could be a perforce plugin thing though.

- Echoed sentiments on the Visual Assist X, the find files.. (shift+alt+O) has made going to the solution explorer completely unnecesary.  Check this out, seriously.  You go there, start typing part of the name of a file, scroll 2 or 3 down the list, and you're in.

- Edit+continue == SUPER important with games.  Make the output be a bit clearer when it can't change the code instead of the dreaded "your 2 line change needs template ridiculousness XYZ..." insane output.

Also forgot the most important thing:

When I press Ctrl+Break, stop the freaking build.  Don't keep going, stop.  Also, if there's a syntax error in one project, stop everything right there, don't keep going.  At least make this an option.

00:00 Me: ctrl+break

00:01 VS: hang on hang on I'm doing something

00:05 Me: ctrl+break ctrl+break ctrl+break

00:10 VS: ok fine!.....

00:25 there! done.

00:26 Me: good work, now throw that away.

Ruth,

I represent Microsoft on the C standards committee.  Visual C++'s C99 standards compliance has be driven primarily by user interest, so it's great to hear from C users like you.  Where we've received many requests for specific features, we've gone ahead and tried to implement them (or analogous features).  A couple examples of these are variadic macros, long long, __pragma, __FUNCTION__, and __restrict.  Apart from your general interest in seeing Visual C++ fully support C99 and any future revisions to the standard, are there particular features you would find most useful in your work?

Arjun Bijanki

Microsoft Visual C++ Team

My requests that are different than those already requested:

1) A code prettifier built in with options.  This should be integrated into SourceSafe so that when a programmer checks out the code they automatically see it formatted the way they like it.  Code checked in should be formatted according to a company standard (if specified) so that if it is pulled out outside of VS it looks correct.  This feature would make many a manager not have to listen to their employees whine endlessly about how their co-workers format their code.

2) Integrated documentation like doxygen, but with intelligence about parameters, return values, etc. like in C# XML documentation.  The output should also always be present as if it were part of MSDN documentation.  Libraries built by the company are just as important as Microsoft and other standard libraries and coders should have quick access to the documentation.  Integration of links to MSDN documentation (types, classes, etc) should be present.  If code is manually refactored by a coder, a //TODO: comment should be added to update the documentation.

3) Several individuals have requested image insertion in code.  I would take this a bit further.  It would be really cool if you could embed a Visio document, e.g.  I would want editing the embeded object integrated with SourceSafe, as well.  Of course with images and and other embedded objects you should have a +/- option to collapse it or expand it.  An alternative would be to do this within the documentation generated by 2).

4) Definitely one that was mentioned once that should be repeated over and over: Make the task list global across the project and not just relevent to the current file.  Have the ability to prioritize the tasks and group by file or custom defined grouping.  For example Bug #555.  The format could be something as simple as:

//TODO: <BUG #555> Fix blah, blah, blah.

I'd definitely agree on that native code should be a priority in Visual C++. Personally, I'd prefer some kind of plug-in handling for C#, VB, etc, since Visual Studio becoming increasingly bloated. It would be really nice if the plug-in system could be configured by simply deselecting the plug-ins that you don’t want to load.

I also think that most experts that use Visual for building performance-intensive or low-level development is much more interested in IDE improvements rather than seeing more of the CLI features. There are two simple reasons for Visual to be as popular as it is: 1) a great editor/IDE, and 2) a great debugger. Don’t screw it up!

Some practical IDE suggestions:

- Drag and drop files to the solution explorer to add files to a project stopped working in VS2003? VC2005? I’d like it back.

- When working on larger projects one often finds that it would be nice to have a project merger/splitter. Imagine that you could select some of the files in a projects and click “move to new project”. All include file paths would be adjusted according to some basic rules (I did not say ‘wizard’). This feature could be huge if you also add refactoring to it, so that namespaces are automatically changed, inserted and removed where applicable! Without this tool one has to do these steps manually, which takes hours for larger projects with hundreds of files in.

- Help for Win API should load instantly (“F1”). Now it takes 10 seconds, which is totally unacceptable! Some kind of plug-in handling for the different help systems could ensure this (se above).

If you guys aren't careful, you are going to get smoked by the Linux people.  

KDE is already better than Visual Studio for pure C++ development.  The source formatting is better, the project management is better and the source control integration is better.  Even their intellisense is getting pretty good.    If they ever got KDE to run on Windows, you'd lose for C++ development...

It's that, you haven't done anything real with Visual C++ in a long time, and other people are catching up.  C++ for some people means, C++, and actually having portable code that is compiled and works on different platforms.

1) Get rid of the ads in the environment.  The start page is stupid.  If you are going to keep the start page, then, have a button to clear the recent projects -on the page-.

2) Get your documentation in order.  For C++, the F1 key is now basically useless under VS 2005.  I am shocked, after installing VS Pro, to find that F1 on CreateWindow doesn't work.  How'd you manage that?  In fact, MS help is now so useless that most people I know use intellisense to find things to google on.  It's terrible.  And where did the OpenGL documentation go?  There in VS 2003, gone in 2005.  

3) Having the windows bound to the coding activity was a nice idea, but, it ultimately fails.  In general, the VS IDE is a train wreck of icons and blinking things... what I really like, is the way KDE does it with their bars on the side.

There is something that I really would like to see in a future version of VC++ and that's a debugger for built exe files.

That is because I am currently in a project that cannot be debugged because it depends on another application's data input that cannot be sent manually...! Frastrated ha? Ask me, in the development!....

I agree with most people here that VisualC++ 6 was the pinnacle. It was lean and mean.

Here's a couple of features I would love to have.

* Customizable syntax highlighting. Let's say I want syntax highlighting for ASM files and nvidia CG files. As a workaround I add all the keywords to usertype.dat and then add the extension to Options->Text Editor->File Extensions->C++. The problem is that all the keywords are enabled for all cpp file. It's annoying to see mov eax highlight in a C file.

* Documentation for autoexp.dat. There's so much good things you can do with it but it's a shame that you have to rely on internet searches and arcane experimentation to achieve anything.

* The MASM support is now better than ever in VS2005, but it would be great if it was a first class citizen and popped up in the New File dialog.

* I would like so see folder support for the Solution Explorer. It would help a lot if you have lots of projects and they can be grouped in categories.

Thank you and keep up the good work!

Cheers,

Peter

Todd,

Thanks for your excellent feedback.  I can't address all of your concerns with this reply, but I thought I would mention a quick tip regarding the Start Page in case it improves your experience at all.  If you find that the Start Page isn't useful it can be disabled.  First go to Tools then Options in the menu.  Then, see Startup under Environment in the tree.  Under "At startup:" choose "Show empty environment" and click OK.

To many others whose comments I read and could not address directly,

Thanks very much for your insightful feedback and taking the time to write it up.  I'm hoping that we can use it to improve Visual C++ in the future.

Thanks,

Richard Russo

Microsoft Visual C++ Team

I think improving c++ is a complete waste of time.

We have an enterprise c++/mfc application with a large code base.

Ideally we would want to restart the application in .Net, but we would never get the authority to do this from our management.

Therefore what I want from c++/c# is to create a new nice .Net application shell and plug all the old c++ dialogs and views into it.

I don't want to have to write a load of code to do this or convert each dialog.

I then want to write all new "dialogs" as windows forms.

I'd hoped to be working exclusively in .Net by now, but the interop is so poor, in my opinion, that this has held us up for ages.

As well as the actual difficulty of interop, there is the speed of building, linking and debugging.

It's so slow its unbelievable. Its always doing unnecessary full rebuilds/links (this may be addressed in 2008). Its also incredibly slow to debug.

We have to create all new c# forms in a simple test project as trying to do it in our main project is just too slow. I can't sit and wait for a full rebuild every time I want to check the line of c# code I've just added.

I'd also like some work done on CWinFormsDialog to ensure that it does actually work with the more complex .Net features.

In particular I'm talking about Visual Inheritance where the user control the CWinFormsDialog can be a derived one. I'm not convinced this works well.

I think the .Net designer needs to handle Visual Inheritance better to further encourage people to completely move to .Net.

Perhaps the fact that there are separate c++ and c# teams is why interop is so hard...

I think there is a certain brand of programmer who wants life to be unnecessarily difficult and would like to still be writing code in notepad/emacs if they could.

I just do not see the problem some people have in things being made easy for them in the new .Net languages.

In summary, having easy interop would completely remove the need for other c++ improvements.

Better debugging for compile-time issues.

Today I'm tracking down two different issues:

We have a dependency problem in the main source tree that is causing massive rebuilds.  And I've got a #ifndef guarding some code that intellisence shows as active even though the guarding symbol is defined.  No idea why, but the guarded definitions appear to be in force since code that uses them compiles when it shouldn't.

Nothing I've found gives me any visibility into these problems at all: the only tool I have is Zen.  And I can't even do trial-and-error debugging on the dependency problem quickly because there is no analogue of the unix make "-n" or "-t" options.

While we're at it, for configuration control I'd like to be able to see all my project settings for all my configurations and platforms in some kind of master view that helps with "which of these things is not like the others" analysis.  As it stands I'm going to have to parse the XML and write a bunch of design rule checking code.

As a research guy, I would like the see the following:

1. OpenMP 3.0 support

2. OpenMP thread tracing & debugging

3. Less painful 64-bit migration

Hi,

I would appreciate this feature - in C++ debuger watch window to be able to sort the members also in alphabetical order. We have some classes with really long list of members.

Even more advanced function would allow filtering the members :-) for substrings for example.

Best Regards,

Petr

You know what would be really nice?  Increasing the string literal limit from its current 2k limit so that compiler error C2026 isn't hit all the time.  A quick search shows that alot of people hit this limit.

A post on microsoft.public.vc.language from a VC++ MVP indicates that the C++ standard suggests, but does not require, a 64k limit.

Meeting the 64k limit suggested by the standard would be really nice.

I am glad to hear the MFC is going to be updated in VC2008.  It is such a sad story for Microsoft that we serious C++ programmers have to wait for several major releases for such an update.  Meanwhile, you Microsoft has invested so much for producing all kinds of shitty .NET managed stuff (C#, Managed C++, C++/CLI, Interop, Workflow) that seem forever half-finished.  IDE crashes for no apparent reason.  Design views of forms won't open, etc. etc.  You should be ashamed of yourself because you are wasting precious time for people on a large scale.  Seriously, some key people at Microsoft should be fired for producing so much junk in the past several years.

My advice to Microsoft:  Do not spend your time to produce all kinds of products/technologies that are unreliable or half-useful.  Focus your attention to a few products/technologies that are useful and make them robust.

By the way, stop calling native C++ unmanaged C++.  Instead, call managed C++ or C++/CLI you produce bastard C++.

Well, in the 6 weeks since I last commented here, I've implemented CLR hosting in my native C++ DSP application, to support 3rd party .NET plugins.  

The most obvious shortcoming in Visual Studio is the inability to debug managed code called by  ExecuteInDefaultAppDomain() and

ExecuteInAppDomain().  These are the key functions used in unmanaged hosting.

The whole unmanaged hosting area needs to be rethought out and given first-class citizenship.  It looks to me pretty ad-hoc (I guess most of the documented functionality is there because of the  SQL Server team's enhancement requests).

Josh.

Our application have arround 60 different modules(dlls) each managed aby a different development team. We still use the NMAKE utility for building our application and the modules beacuse we can specify a similar setting for all the projects and control it from one shared file that provides all the optimization and compiler switches. This way we can ensure all modules compile with same compiler switch and optimization. We definitely want to retire this system and embrace the new world but if there was a way to provide a template vcproj file that would specify the compile time switches and other option and all the project file have a link to this template file. During compile time they pick up the settings as mentioned in the template file. This will be a huge help for every large scale application that are modular.

abhijit said:

> if there was a way to provide a template vcproj file that would specify the compile time switches and other option and all the project file have a link to this template file

We added this feature in VS2005. The feature is called "project property sheets". Here's a link to how it works: http://msdn2.microsoft.com/en-us/library/a4xbdz1e(VS.80).aspx

Thanks

Tarek Madkour

Microsoft Visual C++ Team

I 'd like to see in next Visual Studio release a designer for window in native c++ code. Simil to Windows Forms designer but with WINAPI function and classes. I hope it will be possible. Thanks

Dear Friends, I have been a developer since Microsoft began. I am currently finishing the development of a very large program. It has to be composed of about 280 dialogs. When I use the Professional C++ ver 5.0 debugger everything is OK. However when using the final EXE. every so often a message appears on the monitor saying that Microsoft has found an error and that the program will have to be started from the beginning again, this does not happen when using the debugger. I have searched to find out what this error could be, and I came finally to the conclusion that this fault is the making of Microsoft's programmers and I would like to see it corrected as soon as possible.

Will you do the correction of this error as soon as possible?

Yours

Frederick Post

Please make visual studio capable of producing identical binary (.obj, .lib, .exe )files when compiled from identical sources. The current state is that if a person checks out the source code from version control and builds everything, the binary will be different from the one that another user gets, preventing proper checks for build consistency, detecting what changed, etc.

I would also like to see an alternative to date-based dependencies - they don't interact well with version control, and theres a lot of ways for them to screw up. I would like to see:

 .objs, .libs, and .exes contain md5s of the source files and .libs (as well as compile options and compiler version number) which were used to produce them. When they do not match, that causes a build to happen. This information should be strippable from dlls, exes, and libs.

In addition, there would be a tool, which could look at a .lib, .dll, or .exe, and would check these checksums for errors. In particular, it would complain if a .exe was built out of source files which had been compiled with a different version of the same .h file.

It has probably been said before but I'll say it again.

The help system needs to get alot better. It used to be great in the good old days of MFC but these days it has gotten terribly hard to find what you are looking for. The information is often in there somewhere but for some reason you keep getting help about everything but the thing you are looking for. Even pressing F1 on a method in code doesn't work well anymore.

If I'm in a C# code file with the cursor on a .NET Framework Method and press F1 I'm probably not interesed in some FoxPro documentation, right?

I have been recently working on a project involving managed/unmanaged code interop. Few thoughts:

1) There is no simple/elegant way of "marshalling" events from native C++ code to the managed C++ (in VS 2003 one would write a nested unmanaged class - overwriting virtual methods of the base native class, inside managed one and invoke managed class' methods when unmanaged class' virtual method is invoked). The VS 2005 does not allow nested unmanaged classes within managed ones. This is a BIG PAIN.

2) Managed C++ classes do not allow multiple inheritance. I would welcome at least a way to inherit from one class and multiple interfaces (or pure virtual classes) - the way it is done in C#.

3) Would it posiible to "unify" exceptions in the next release of the VC++ (native code)? Right now one must handle C++ exceptions and SEH exceptions separately (not to mention that SEH do not allow proper destruction of the classes instantiated locally within the same method that uses SEH - one has to write method "wrappers" to use SEH and smart pointers in the code). It would be nice to have a compiler switch that would cause automatic translation of Windows SEH exceptions into native C++ exceptions before they reach the code proper.

4) I would really appreciate native-code version of the XML parser library included with the future VS C++ compiler.

5) The wizard generating C++ projetcs always uses managed runtime libraries (DLLs). It would be a nice touch if native runtime libraries were used by default when generating native-code binaries (exe, dll).

6) It would be an advantage if future VS included option (a compiler switch) to support writing code that is POSIX-compliant. It would help writing portable applications. (Is it just a dream???)

Thanks,

Peter

I have not read all the comments above but feel that my requests might be unique.

1) I use MSProject with the team to develop clean outlines of effort. I would like to put the project file in the solution and have it open in a tab.

2) I would like to open VSS in a tab in the IDE.

3) I would like to have a sound play at the end of a compile/build when it is success and a different when it is in error (this is a BIG deal to us!!).

4) I would like to have an editor I can use in DOS. I know this sounds antiquated but for the most critical systems we have telnet/ssh running and using a telnet option is something real we have to deal with. IDEs are cool, but C++ in a terminal has it's up sides too. No intellisense, excellent performance ... so very awesome! Please just kick this idea around.

beginthreadex, you can use EDIT.EXE to edit text files in DOS, or you can use *any* third party editor you want, such as vim (for dos).

Unfortunately, EDIT seems to be a 16-bit application, as such runs in some sort of virtual machine under windows, as a result it's slow.

But you can use VIM for dos or MicroEmacs etc, and they should be fast.

Beside the obvious mentioned several times above:

* better C++ conformance, keeping pace with TR1, better

* *much faster* intellisence (our largest's solution .ncb is 100MB!)

There are 3 main things which would make us more productive. When working on maintenance of a quite large C++ product, we often have to jump from one bug to the next, awaiting code review of a proposed fix, or input from a key developer, or whatever. In the mean time, you must move to another bug, but then all the breakpoints and open windows related to the previous bug either interfere with the next bug, or you must close/remove them.

The ability to save and restore "sessions", which would remembers windows positions, breakpoints / watches, documents open, etc... would definitely help. Keep these around, and when a bug is reopen by testing, you jump right back into the thick of it, which helps a lot with the mental context switch required.

In the same maintenance-developer POV, and general debugging, more powerful and robust custom views/viewers of app data types would help a lot during debugging. AutoExpand and the new visualizers help, but they're almost not documented, break the IDE if improperly defined, and could be much better. Similarly, tutorial and more in-depth examples of writting more useful viewers (od-like, with byte-swapping features) in Add-ins would help.

Finally, stop assuming a monolithic app that fits in a single solution. We have a main solution that weigh in at more than 500 KLOC, and over 30 small to mid size other solutions which are plugins for the main solution. And that's not even counted the hundreds of plugins developed by our clients using our SDK. We've had to write scripts to generate startup .bat script for the IDE to properly configure the inter-solution dependencies. Intellisense doesn't work across solutions (loading .ncb manually is too cumbersomes), and dependencies between solutions have to be declared outside the IDE.

We need to have better inter-solution interoperability, and a way to declare some kind of SDK descriptor for a library or set of libraries to automatically adjust compile flags, include paths, lib paths, etc... for using this sets of libraries as a dependency in a project, i.e. a level of abstraction above raw settings you have to manage manually, similar to what you can do within a solution's projects.

Thanks for hearing me out ;-) --DD

   I have encountered a problem that the low efficiency in VC++ 9.0 nearly make me crazy!

   For instance,when we use sort function in stl that sort 200000 numbers,the time elapsed is nearly 6 seconds!But in VC 6.0,the time is only 0.2 seconds,that's why?

Displaying iterator values in the "watch" window would be great.

1. Tooltip values for the reverse iterators are invalid.

2. "#pragma region r" doesn't work - it is not collapsed

   when the file is being opened.

3. It will be usefull to go to the form from the class.

I'm a native developer, but most of the time developing can be easier and faster with just some new features( as I know you you are doing one of them for Icon designer )

but what about new new features to design dialog box, for example more properties for controls or any other controls that should be created with APIs not dialog editor...show bitmap for buttons , changing their colors and etc.

Add drag and drop feature to allow to add a new source file to the Solution Explorer window _from_ the main Visual Studio container where a file is currently open. (user would select the tab containing the filename and then drag/drop it ).

Thank you.

MSVC 2005 is slower than V6, but I would never go back. I don't find it that much of a burden.

I'm a native code developer. The stuff I write has to run flat-out all the time, so I can't accept performance compromises like CLR and garbage collection. (Plus I don't find memory management all that tough in C++). I won't be going managed any time soon.

Standard compliance (especially around templates) is very helpful to me. Otherwise I can't do all the nifty template tricks I read about.

I have some specific gripes, mostly about the CRT.

1. I use the debugger routines to print a stack traceback on structured exceptions. With each release I have to re-write this code because you change the linker, the debuglib, the api. Please stop doing that. Even better would be to make it a standard tool. Stack trace is really useful!

2. I write server apps in C++, and I want absolute control over anything that attempts to halt my app. There are a lot of these things. There are C++ exceptions (handled with a handler), structured exceptions (handled with SetUnhandledExceptionFilter().

Then there's abort(), which by default puts up a #$@% modal dialog. In the 2005 version I can turn that off. But there's runtime checks, which do everything abort() does without calling abort(), and there's another(!) mechanism to handle *that* too. Would you PLEASE standardize the stuff that terminates my program and allow me to control it so it doesn't hang me and put up a modal dialog so I can't even kill the process from outside!!!

3. I like to autoincrement the version number in my resource for each compile. I had a tool for that in V5, and a different and not quite working tool for that in 2003. I havn't gotten around to finding or building a tool for 2005. I can't believe everyone wouldn't like access to this tool. Maybe you could include one in the next release?

MSVC 2005 is slower than V6, but I would never go back. I don't find it that much of a burden.

I'm a native code developer. The stuff I write has to run flat-out all the time, so I can't accept performance compromises like CLR and garbage collection. (Plus I don't find memory management all that tough in C++). I won't be going managed any time soon.

Standard compliance (especially around templates) is very helpful to me. Otherwise I can't do all the nifty template tricks I read about.

I have some specific gripes, mostly about the CRT.

1. I use the debugger routines to print a stack traceback on structured exceptions. With each release I have to re-write this code because you change the linker, the debuglib, the api. Please stop doing that. Even better would be to make it a standard tool. Stack trace is really useful!

2. I write server apps in C++, and I want absolute control over anything that attempts to halt my app. There are a lot of these things. There are C++ exceptions (handled with a handler), structured exceptions (handled with SetUnhandledExceptionFilter().

Then there's abort(), which by default puts up a #$@% modal dialog. In the 2005 version I can turn that off. But there's runtime checks, which do everything abort() does without calling abort(), and there's another(!) mechanism to handle *that* too. Would you PLEASE standardize the stuff that terminates my program and allow me to control it so it doesn't hang me and put up a modal dialog so I can't even kill the process from outside!!!

3. I like to autoincrement the version number in my resource for each compile. I had a tool for that in V5, and a different and not quite working tool for that in 2003. I havn't gotten around to finding or building a tool for 2005. I can't believe everyone wouldn't like access to this tool. Maybe you could include one in the next release?

[Kevin]

"You know what would be really nice?  Increasing the string literal limit from its current 2k limit so that compiler error C2026 isn't hit all the time."

MSDN documentation indicates that the limit was 2K chars (or 1K wchar_ts) in VC7.1, but it is about 16K chars (or about 8K wchar_ts) in VC8 and VC9.  While this is not the 64K suggested by the Standard, it's certainly "pretty big".

[Sapphire]

"For instance,when we use sort function in stl that sort 200000 numbers,the time elapsed is nearly 6 seconds!But in VC 6.0,the time is only 0.2 seconds,that's why?"

I was unable to reproduce this. I compared VC9, VC8 SP1, and GCC 4.2.1 std::sort() performance on a vector<unsigned int> of 200,000 values produced by Boost/TR1's mt19937 random number generator seeded with 0x17012161UL.  VC9 was 5% slower than VC8 SP1, and 36% slower than GCC 4.2.1; these are minor and significant, respectively, but nothing like 30x slower.

Are you comparing VC6 to VC9 in release mode with optimizations enabled?  Note that if you're compiling through the IDE instead of through the command line, there's a bug in VC9 that drops the /O2 flag in Release configurations when a project is converted.  (This will be present in VC9 RTM but fixed in VC9 SP1.)

Please post a self-contained repro to the MSDN forums, Microsoft Connect, or directly to me at stl@microsoft.com .

Thanks!

Stephan T. Lavavej, Visual C++ Libraries Developer

It would be nice if Visual C++ developers concentrated more on making it a RAD Development tool for native code. C++ does not really need CLI and managed code. C# works great for that! The Borland Turbo Explorer C++ is currently the best tool for fast native WIN32 application development. Next to that is VB6. (Assuming non-trivial GUI on a well polished application)

Writing GUI code in WIN32 or MFC is no fun at all. Scrap MFC and come up with a FAST, LIGHTWEIGHT, NATIVE win32 library. Otherwise .NET apps will start be written just to run on other O/S'es.

Load different language Windows created solution don't crash. I don't want change OS localization setting when I build project each time.

-- Fix the bugs!  Especially the long lasting annoying ones. E.g., there has been a minor but annoying bug from day one of the IDE where it miscounts errors, especially in the link phase.  It would not take a genius to correct this one.  I suspect all it does is count the word error in the output.  This is much too simplistic and reflects badly on Microsoft's ability to implement technology.

-- Each version is slower than the last -- perhaps you could try rewriting it in C++ rather than the current C# to speed it up.

Bring back floating editor windows. Perhaps they are there, but I cannot find them (then it is a UI bug).

It has been said often, but I say it again:

- Please fix intellisense! This is such a major pain in VS2005. I have VAX and renamed feacp.dll to get rid of that uber-parsing. But this can only be a workaround, w/o that dll you cannot atl objects to atl projects etc.

- Again an often mentioned topic: Even better standard (TR1, C++0x)

- Iterator debugging/slowdown in release builds via SECURE_SCL. I think it is a great thing in debug builds. But I agree with the others that it is dubious to have it enabled as default on release builds.

- The resource editor/class wizard: I wonder that no one in our UI team went postal yet. That piece of the IDE just got *evil* with 2003. I do not know how much the guys of the UI team investigated or if they just resigned. But it seems to be nearly unuseable when you want to add new dialogs to a old MFC project that has a separate resource dll.

- Please give an option to use 'standard' regular expression for search/replace.I hate it that ':' is used for keywords. Try search for ClassName::Method, or even namespace::classname::method. Having to prefix ':' with '\' is really annoying.

- Refactoring  for native c++ would be really great. But please a refactoring tool that can cope with large projects.

- The same for unit testing.

- I would really like something like ccache.

- Resource (CPU/memory) consumption of the IDE went from good (VC6) to 'so so' (2003) to insane (2005).

- An option for the debugger: Deferred loading of pdbs, much like windbg.

- The help system really has it quirks.

Haven't tried Orcas yet but from a 2005 perspective this is what would be most important for me.

* TR1 support.

Really important features.

* Faster IDE.

It is bloated and slow, not like eclipse-slow but still.

* Better and more generalized build tools.

MSBuild is a step in the right direction but build tools are generally quite primitive. It was quite a while ago projects only included source-code. Most companies need to have their own resources that needs rebuilds on dependancy.

Not so much c++, but I'd like to see the capabilty of dropping in a sqlexpress instance in a project that would make it painless to distribute with app.

I don't know how representative I and the C++ developers I know are but most seem to think these points are the most important ones:

>Standards compliance.

The visual studio compiler has been improved continuously. Good job and please continue.

>IDE speed.

It has got even worse in every release of visual studio.

>Intellisense is a disaster.

Both clogging the computer and the progressive worse search relevance in each release are frustrating.

>Customized build and dependency handling.

One-source-to-one-destination

Several-source-to-one-destination

Company specific build steps are so common (most products has them) so it should be possible to handle completely within visual studio.

I know it can be handled with prelink/custom build, nmake and msbuild but it's cumbersome and unintuitive, it would be nice to just add files in the filelist inside visual studio and set the dependencies. Add the destination file and then specify the build tool and a list of the source files it has dependancy to.

Thank you for your time.

I'd like to see support for inline assembly for 64-bit. Honestly, I'm surprised this was disallowed in the first place.

Have very large legacy C++ app. Love many of the changes in 2005/v8 - especially the ease of using managed objects in C++.  Like using WinForms controls to enhance MFC dialogs, but would really like it if you would figure out how to allow us to use the designer for these controls. In our legacy app, its rare we get the opportunity to convert to a WinForm dialog. We do some new assemblies in C#, and love the ease of such integration, but will probably never be able to convert our C++ code entirely to C#.

Really, really hate the speed of compiling and linking large C++ projects. Its almost intolerable and very expensive. Rebuilding Intellisense is nonsense and is costs unacceptably large amounts of programmer productivity. Please, please allow us to set the priority on the intellisense thread. Truely hope 2005/v8 was the quick and dirty version and the next will be much more efficient. Would be very happy if performance improvement was all that happened in the next version.

See what is Softvelocity doing with Clarion 7, aplication generator with lot of wizards, templates, diagramer.

I would like Visual C++ for development of both business and system aplication needs.

Thanks.

I would like Visual C++ to produce native compiled code

without need od MFC libraries or ATL, lightweight code

directly calling windows API functions, native code similar

to Clarion or Delphi aplications ( no need of MFC or ATL).

Create scripts, macros or better libraries for faster development - 5 generation RAD tool.

Up until now, I had used MFC/ATL to develop native C++ applications for the Windows platform.

However, I have finally given up on Microsoft and doubt they will ever again give serious priority to C++ developers.

I now happily use Qt from Trolltech for all my development (and I can code for UNIX/LINUX and MAC OS, in addition to Windows).  

Both Bob and I are using Visual Studio 2005 ( not the .Net version).   When an application runs and terminates

'abnormally'  ( which may mean to us deliberately ....such as clicking of the execution window)

then Visual Studio thinks that we have a memory leak, and starts dumping info which ( even if it made sense)

is still useless to us, and the only reliable way we can terminate the dump to the output window is ctrl/alt/delete.

There seems no know way to shut off this useless and annoying feature.

"It's "when you use Standard algorithms, the bounds checks are lifted out".  Even in the absence of _SECURE_SCL, it's a really good idea to use Standard algorithms whenever possible."

Oh, I agree with that, but one of the main points of std::vector in particular is random access. The standard library algorithms are of limited use for that particular scenario. if I need to access element #216 in a vector, no algorithm can really help me. So expecting people to use the std algorithms instead isn't much of a solution in the general case.

"> I think the whole "Secure SCL" is a mistake, at least by default.

There is a tradeoff here.  Performance is very, very important, but so is security."

Of course, I didn't mean that security wasn't important.

Rather, I think you're *reducing* security with this approach.

Why? Because I have personally seen far too many C++ developers go "Hmm, my std::vector is too slow. That sucks. I'm gonna use an array instead.

How safe is that?

And then of course, the logical followup is "I've already determined that the standard library is too slow. Guess I'll use char* instead of std::string too, just to be on the safe side."

I'd much rather have people use std::vector without bounds checking, than resorting to C arrays (which degenerate to pointers half the time). The former isn't perfect security-wise, but it's far better than the alternative.

The best (only) way to improve security in C++ is to make the standard library attractive to use. True, it's not terribly secure, but it's a hell of a lot better than what most people would write if they didn't use it. If developers see it clearly outperformed by old-fashioned C constructs (C arrays, C strings), then at least some proportion of them will (and already do) take the easy way out, and switch to old buffer-overflowing, insecure, fragile C-style code.

I've seen this happen countless times already, and it worries me, because I quite like security too.

But when people program in C++, they also expect performance, and if they don't immediately get that.... they might just stop using the "secure" C++ constructs entirely.

Which sucks for everyone.

If you used a less heavy-handed approach (perhaps only enabling SECURE_SCL in debug builds, by default), then developers would still see at least some of the benefits, but without the nasty side-effects that scare them completely away from the standard library.

Especially as C++ gets more and more relegated to performance-intensive applications, while everything else moves to .NET or other (vastly more secure) platforms, you shouldn't underestimate the backlash you'll get from slowing down C++. The slower its secure features get, the less they'll be used.

That's from a practical "I want secure C++ code too" point of view.

There's also the much more fundamental "It goes against the principles of C++" approach.

One of the most fundamental ideas of C++ is "you don't pay for what you don't use". Why do I have to pay for bounds-checking on vectors, if I didn't ask for it? If I specifically wanted it, I could use at() (or I could define _SECURE_SCL myself), but if I didn't do those, why should I pay for these features being enabled?

Hello

Re: Tuesday, November 06, 2007 1:47 PM by Bill Buklis

>> I'd like to see support for inline assembly for 64-bit. Honestly, I'm surprised this was disallowed in the first place.

Thanks for taking the time to post your comment. There was a VC blog post on this topic recently which contains more specific details: New Intrinsic Support in Visual Studio 2008 - http://blogs.msdn.com/vcblog/archive/2007/10/18/new-intrinsic-support-in-visual-studio-2008.aspx, however, in summary, there are no plans to support 64-bit inline assembler at the moment.

Thanks

Damien

Hello

For the many who respond to this post and requested “updating MFC” and “adding TR1 support”, for some good news please see the flowing posts:

http://blogs.msdn.com/somasegar/archive/2007/11/09/visual-c-libraries-update.aspx

http://blogs.msdn.com/vcblog/archive/2007/11/09/announcing-a-major-mfc-update-plus-tr1-support.aspx

http://blogs.msdn.com/vcblog/archive/2007/11/09/quick-tour-of-new-mfc-functionality.aspx

http://channel9.msdn.com/showpost.aspx?postid=355087

Thanks

Damien

Hello

And for all those who mentioned Intellisense performance pain-points, this post on the VC Blog may be good news:  http://blogs.msdn.com/vcblog/archive/2007/11/12/performance-improvements-in-visual-c.aspx. Unfortunately we realise that this will not solve every issue and I should repeat that more improvements are planned for VS10 too.

Thanks

Damien

I'm developing mostly high-performance code and interested in advanced code optimizations like:

1) support for vectorization (as Intel Compiler or gcc) using SSE/MMX, etc instructions ( i never saw bswap being generateg for ntoh series of functions). MMX registers can be used as general-purpose registers to avoid spilling in memory...

2) multi-target compilation - say code with SSE2 support and generic branch for compatibility (also as in Intel Compiler for C++)

3) Advanced debugger with support for multi-threading - context for each thread, TLS, support for fibers, etc.

4) Tools like Intel Thread Profiler & Intel Thread Checker being integrated in profiler with support for C++ & .NET

5) Scalable CRT library - multi-threading friendly implementations of memory allocation, I/O, etc.

6) support for multi-threading in STL - unfortunately not part of standard, but very useful. Say, like Intel Threading Building Blocks.

Thanks,

Vadim

Some recent observations on small points of irritation for large solutions in VS2005:

When you want to apply a right-click operation (eg compile file or compare with SCC) to an open file you have to locate it in the tree view.  This can take a while in a large project.  There should be a way to jump to the file's representation in the current "Explorer" or "Manager" view from the edit window's title bar or tab.

On a related point, when you right-click and "compile" a C++ file you get "build only" behavior; it does not build dependencies.  But when you right-click and "build" a project in the same tree view you get a buld with dependents; you have to navigate to "project only" build to get a broken build.  This is particularly irritating when the PCH is out of date or non-existent.

When you create a solution-specific property sheet file, SCC integration is badly broken.  "save all" does not save it, attempting to close the solution does.  By then it was too late and I'd lost my changes.  Subsequently I discovered that you can right-click-and-save in the property manager tree view but it won't automatically check the property sheet out for you, even if it is assigned as an "owned file" to one of the projects and resided inside the tree covered by one of the projects.

Finally, when you've created the solution-wide property sheet and you want to go through about a zillion projects and make almost all of each project's properties inherited rather than overridden you discover that the UI for doing that is ridiculously inconsistent.  The "<inherit ...>" context menu item is sometimes first, sometimes last, and sometimes not available.

Also, you can't tell the difference when you have all or multiple configurations selected between "inconsistently inherited", "inconsitently overridden", "inherited null", and "overridden null" value states for a property.

While we're at it, when the origin of a symbol or the source of an error is in the property sheet jungle rather than the source it would be very nice to have right-click navigation link to it.  I recognize that this is hard but it would help with discoverability as well as reduce the Zen koan quality of the experience:

symbol defined in project settings "preprocessor settings' page appears in header.  Hover over it and it has a value in the tooltips.  Right-click goto definition and the symbol is undefined.  Ah, grasshopper, the definition that is undefined is the effemeral definition ....

I have recently had to do more c++ programming after having used primarily c# on windows. I understand that c++ is just not going to be treated as an equal NET citizen because you don't want to replicate what is being provided by other languages, and want to concentrate on tools for native developers fir c++. But the differential in tools between c++ and c# is horrific. Why can't a c++ developer have code snippets, a built in refactor tool (that third party tool from your web won't install on my machine properly) and a decent class diagram? Decent (that is working at least 60% of the time) intellisense would be nice as well. And even if you aren't going to add to c++ forms support, why can't the built in features (such as application settings in the designer) at least work? I am orders of magnitude more productive in C# just because of a lot of these features.

And please make it reasonably (seamless) to attach to a gcc or some other compiler. I have to program for Linux quite a bit, but certainly don't want to work in that @#%$# forsaken #$^# operating $$%^@ system any more than I absolutely have to.

Matt Brown

Please allow us to comment on your documentation. I spend so much of my time helping colleagues with undocumented "features" of Microsoft SDK's or caveats, or providing the missing example code that they need to get the job done. Let us in there to fix your documentation, it's so bad that as a previous post mentioned it's more useful to use google or krugle to get the answer.

You can contribute directly to our documentation using the MSDN Wiki (http://msdnwiki.microsoft.com).  Within a topic, you can click "Add Content . . ." to jump to the Community Content section, or you can just scroll to the bottom of the page and click "Add new Community Content" (you'll need to log in with your Windows Live ID).  

If you prefer to just let us know about an error/omission or any suggestions you have for improvement, you can send us feedback from within a topic (see http://blogs.msdn.com/kathleen/archive/2007/10/11/wanted-feedback-on-visual-studio-content.aspx for more information). Also, please consider participating in the Visual Studio Content Survey (http://go.microsoft.com/fwlink/?LinkId=102169), if you haven’t already done so.

--Kathleen McGrath

Please bring back the Class Wizard!

Five small requests:

1. When selecting bunch and of lines and hitting the tab/shift+tab to indent the code please do not mess with the spacing, simply add/subtract a tab from the beginning of the line (Today all the lines must has tab+1 indentation ).

2. I know that VS2005 optimizer is much much better than VC6 and enables whole program optimization.

Tough, it would be nice that even when /GL is turned on (whole program optimization) you could step through the code (F10, F11) in the debugger and not the debugger jumping into crazy places or not advancing at all and you are playing the game: "What line is executed now?".

3. Seconds the request: change only one line in the .sln/.vcproj if a one action has been changed in the soultion/projects.

4. Please fix the bug when adding a single .def file to a project, please make it the default export definition file. (Yes, even if it is in the headers folder).

5. When working on a solution with a lot of projects (~100 most of them are unitests). Please, could you make changing the build configuration from 'debug' to 'release' and from 'win32' to 'x64' not last forever.  

Thanks.

You guys should be coming to Zumobi in Seattle and do a case study.  Wr'e a mostly ex-Microsoft employee shop, and even still, we have neverending religious wars on how to best have Nant (or another 3rd party build systems) and Visual Studio co-exist in a multidev environment.  It's not obvious to use VS more, or use VS less (as in just a debugger).  VS really can be picking up the slack in making using VS the choice obvious over alternative build systems.  

You guys should be coming to Zumobi in Seattle and do a case study.  Wr'e a mostly ex-Microsoft employee shop, and even still, we have neverending religious wars on how to best have Nant (or another 3rd party build systems) and Visual Studio co-exist in a multidev environment.  It's not obvious to use VS more, or use VS less (as in just a debugger).  VS really can be picking up the slack in making using VS the choice obvious over alternative build systems.  

Reverse debugging, The ability to step back through code from the point of a bug would be nice.

First of all, thanks MS that you guys finally decided to do smth to better support C++. You have to realize that most old C/C++ developers (DEVELOPERS, not leads/mgrs) hate .NET crap and with further C++ abndoning push us away from MS platforms towards Unix, at least in our hearts & minds...

I may add only one stupid question to the above: have you guys ever thought of adding support for other object file formats and target platforms?

Thanks

I haven't read everyone's comments, so maybe it's already been posted, but please work on fixing error messages to be better.  When I'm developing code and I get it to work fine on my development machine, upon delivering it to another machine to be used on a research experiment, most of the time I get a stupid error message to the effect that the application cannot run, please reinstall it or see a system administrator.  I think it has to do with manifest files.  Is that "managed code?"  Anyway, it's wasted a lot of my time.  with VC++ 6.0 I never had these problems.

If you're going to force this stuff on your users, you need to have better error messages and good resources to explain what the heck is going on and how to fix it.

I don't think we should be forced to create some kind of msi just to allow an executable to run.  I don't know who came up with this but it's very frustrating to the user/developer experience.

  thanks.

I think it'd be valuable to have an integrated unit testing plugin in Visual Studio. Right now there isn't a true heads-above-others solution (UnitTest++ is pretty good but...) so it's an opportunity for MS.... for example, you can look at how well junit has done in Java.

Using VS2008 Beta 2 via VS2005 Express, VS2003, and VC 6

VS2008 seems to bring back the speed and elegance msiisng from VS2005 Express and to a lesser extent in VS2003. However, nothing beats VC 6 for speed not just in compiling but also in IDE performance. (I run both on a 2.8GHz dual core Pentium1GB RAM under WinXP - so hardware speed is not a factor - what hardware platforms do VS developers use?

My biggest gripe though is reserved for what has happened to BRIEF editor support within the IDE. The VC 5 & 6 implementation was correct as far as I was concerned, and the editor is very responsive. VS 2003, 2005 and 2008 have all got damaged implementations in varying degrees. The most frustrating of these is the highlight and copy function. Once a selection is made, it is impossible to turn off the selection until either text is copied, moved or deleted. In VC6 clicking outside the highlit area was enough to switch off the highlight (and this is how I remember it from using real BRIEF under MSDOS). In use, this "feature" occurs regularly when I accidently click the mouse at the wrong point in source code whilst source sits in the clipboard. The only solution seems to be to modify the source code and then undo the change, or to overwrite the clipboard and then return to the original point and copy the original source code back into the clipboard.

OK, rant over. I like VS 2008 and the promise of updated MFC. (I like .NET but I still have to overcome a mental hurdle to some of its assumptions.)

Pro: style, class diagrams

Con: Incomplete BRIEF emulation

Thanks for listening.

Class Designer anybody?

This would be about the most useful thing you could finally put in.

- NOT bridge BUT not using c#,VB.net Only using C++/CLI for developing WPF,WCF,WF and Silverlight like another language( delphi, c#, vb.net ... ) please! I don't want to use ActionScript with mxml (Flex)

- Future Standard C++ 0x 's new language feature and libraries suppport as fast as possible.

- Expand and Extend MFC (not ATL) for native highlevel applications not lowlevel application(driver,service,game ...)

* Improve Intelisense.  See Whole Tomatoe Visual Assist X.

* Add more macroing ability in the IDE.  Kinda advanced autocomplete for code like if I type if give me the options to chose from.

* Code Beautification - I'd love to see a feature that could clean up coding standards like brace placement, tabs, etc.  There are a number of 3rd party tools that do a 3rd rate job.  Particularly I'd like to see the idea of code conforming to my coding preferences and then being able to translate it in to something that conforms to the coding standards of the organization.

* C++ Refactoring.  Must Have.

* Allow for a non manifest deployed Sxs version of the the libraries.  We have to support old version of Windows that don't support side by side distribution properly so it would be nice if there was a way to compile my app to support old versions that don't understand manifests.

* Cross compiling.  Our code base is built on Windows and Linux, and in the future Mac.  It would be great if there was a feature that would be able to check the compilation on the other compiler via a ssh or some other manner. Pretty pie in the sky.

After switching from VC++ 2008 Beta 2 Express to the final release Express: projects using dynamic RTL won't run and even rebuild with the new release doesn't help. Please test these things.

The most annoying problem with 2008: a bug in application locks debugger and the whole OS (XP SP2). I cannot use even the Task Manager. After the reboot the IDE starts to crash immediatelly and I need to uninstall and reinstall it. Happens about once a week, with Beta 2 and the relase.

I run into at least two code generator bugs in release mode. The happens with a large systems and it is not practical to reduce the problem to a few liner (the project depends on dozens of libraries and has dozen of MB of sources). I wish there was a debug or logging version of the compiler/linker, something what produces a trail sufficient for later analysis.

Other wishes:

* Better C++ compatibility.

* automatic background check for invalid file names in #include - why do I need to wait until compilation?

* Search and/or filtering capability for file names in Solution, ability to see which files were modified recently.

* Better tool-tip help. The IDE documentation in HTMLHelp became practically useless (for me) - too complicated, no clear structure.

* Rename of a configuration in Configuration manager is buggy - it does not get not reflected in project properties dialog.

* Improved debugger. Now it is almost useless with access violation errors - doesn't give any clue about location, stack is not shown. Also ability to use debugger only for selected threads would be nice - now debugging threaded code is nightmare.

* More frequent patches, even unofficial "use on your own risk" ones would be useful.

* Ability not to bother with certain IDE propeties. I'd like to state somewhere: this project doesn't use XML or databases, don't show options about these, I don't care.

* Visible ability to quickly switch between header and *.cpp file where this is unambiguous. It is probably available somwehere but I never managed to find out the right shortcut.

* Background transparent and automatic constant recompilation/relinking of changed source files. With a huge project this would be a killer feature.

I've been using Microsoft IDEs for a ...long... time. I was at the Programmer's Workbench (PWB) launch at the Boston Computer Society many years back. I finally switched from VC6 to VS2005 because I needed Vista support.

I agree with most of the comments already mentioned.

and I'd like to add:

1. Let me perform Find Declaration or Find Definition on words in comments and #if sections and, PARTICULARLY, on words in the find box in the toolbar. All of these worked in VC6.

2. Document the various keybindings. There are several tasks mentioned in comments here that are possible to do with existing keybindings, but you only find that out if you read one of the "VS Secrets" web pages. Examples include View.PopContext" (after go to definition, for example) and "open file name under cursor" (Ctrl-Alt-G - you'd never guess this from the shortcut name.) Make sure these are documented somewhere that I can read linearly. Trying to browse through hundreds of keybindings four at a time in the current dialog is fruitless. I still can't find the binding for "go to matching #ifdef/#endif/#else".

3. Speed up symbol loading when debugging. My app loads Extended MAPI, so loads over 50 DLLs during startup. It takes a LONG time to start up on a Core 2 Duo machine, and this is a small 1.5MB EXE.

4. Rethink how projects work. At least for me, VC6 did it right. I keep multiple projects in my solution that are tightly coupled, but each is a different product. It drives me nuts that changing to a different configuration doesn't change my startup project (it did in VC6.) It also drives me nuts that adding a new configuration adds it to project and I have to go fix all projects.

5. Help me with the pain of WinSxS and remote debugging. I need to do it one way with Win2K (Put the MFC/CRT DLLs on the PATH), another way with WinXP with debugging symbols (copy some undocumented directories to me EXE's directory), another way with release (everything should be installed properly in WinSxS), and let's not even discuss Win98. It took me days to figure all of this out the first time.

6. I *love* the debugger support for STL in VS2005, but I really need STLport support for consistent cross platform use. Pease add debugger support for viewing STLport containers. Also provide better documentation on the language used in autoexp.dat.

7. Put back support for DELAYLOAD in pragmas. This worked in VC6 and hasn't worked since. For example: #pragma comment(linker, "/DelayLoad:MAPI32.dll") Without this feature, I can't create library modules that automatically set the right switches when linked in.

Thanks!

The F1 help has been beat to death, but let me add some thoughts.

First, the original help on Multimedia Viewer (Look at the MSDN Library betas) was incredibly fast. You hit F1 and the help opened. Almost no pause, even on a lowly 486. Every new iteration of viewer since then has gotten slower when running on faster hardware. 'Nuf said.

Today, when I hit F1 on a keyword, I just want it to go to the online web page for that word. IMPORTANT - that page should include the Wiki discussion so I can have some help dealing with under-documented functions and classes.

I don't want it to search for alternatives. I don't want it to find community information. I don't want it to open a table of contents that takes ten seconds to download. I just want to see the reference page. Immediately, if not faster.

Finally, this is the interesting part:

Tie the F1 help into the XML documentation for the current project. Really. (That does, of course, require you to implement XML documentation for C++.) And don't make me wait 10 minutes to integrate changes into the help system. If I don't need full text search, then opening the correct page should take a fraction of a second.

In addition, allow me to define a "search server" within my company. If I have dozens of developers on my project, then F1 should be able to query the server for a keyword and get a response back almost immediately.

Thanks.

One thing I think needs to be improved in the interop solutions is the annoying LoaderLock exception/breakpoint (from the Managed Debugging Assistants).

It can be disabled while you are debugging using the VS2005, but when using the VS6 debugger it cannot, and in our older projects I get those very frequently.

We need to be able to turn off this "feature" for good and system wide, so it will never fire again ever.

I agree that the IntelliSense platform that you seem to be developing will be a great improvement. But just in case at least provide a way to disable it.

Also, I do not like the Visual Assist approach and I think you could do it so much better. The C# IntelliSense could be the idea to follow; I find it comfortable and simple.

Interop will be needed and to be improved, no matter some folks are not and will not be using it.

It needs to be able to handle big and I mean really big projects.

And I think the MSDN help currently is having mostly automatic method skeletons grabbed from the source code, and not real help reference.

Juan,

Can you tell me what you mean by "really big projects?"  

How big are the projects you're currently working on?  And how big do you anticipate them being in the future?

What are your biggest concerns / problems in working with big projects?

You can reply here, or e-mail us at DevPerf@Microsoft.com.

Thanks,

David Berg

Microsoft Developer Division, Performance Engineering

Hi David,

We have developed a developing framework which is basically a main MFC executable with a lot of COM based dependencies some of which are optional (plug-in like components).

At some point last year we came up with the idea to update the main executable to allow .Net assemblies to be attached as if they were COM components via interop.

But since most of the components need some sort of UI the main application had to be ported to C++/CLI in order to use the interop features of the new MFC.

Well several things were difficult: We had to turn off IntelliSense, because it was continually parsing all the time, another thing is that since we have lots of classes we could not organize classes into folders like we could in VC6. Finding a class in ClassView now takes a lot of time.

So what I meant is that the IDE needs also a system in which we could organize our classes (in ClassView mode) and not only the files into folders. Also the VS2005 ClassView has two areas: one for the classes and below the methods and properties of the selected class; I think it was more comfortable when we had the simple tree in VC6 ClassView.

I cannot foretell how big our projects will become in the future, but we have learned that we have to keep projects small for compiling time issues and maintenance.

Thanks.

Ability to write macros in a language other than VB, particularly C++ and maybe C#. Because the ability to parse C++ and run programs on the AST is a brilliant feature (well done) and ought to be made full use of.

I know that I am echoing the comments of many others, but these are important careabouts to us. If we don't speak up, you can't know what's important to us, right?

We have a large commercial application...16 years of legacy...with ~50 projects and lots of code. Started life under VC++ 1.5 on Win 3.11. Feeling old...

1. Our late model 4G QuadCore systems labor under the burden of Intellisense when we load our master build solution. Gigs of data...yikes.

2. Porting to C# simply isn't in the cards, but we would dearly love to have the UI improvements available to native code through MFC.

3. I drug my feet as long as I was able in moving to VS2003 and VS2005 in large part due to the loss of the VS6 style Class Wizard. Others here disagree with me, but I found it far more intuitive and easier to use.

4. Similar feelings about control properties in dialog editing. Old dogs and new tricks perhaps, but I do not find a textual listing of 30 properties nearly as easy to use as the VS6 property pages.

5. Commercial application developers are probably in the substantial minority relative to corporate developers or web centric developers. It would therefore make sense that Microsoft would concentrate heavily on the tools and technologies appropriate to those functions.

For us in the first group however, our products are literally our financial lifeblood, not simply what I do at work. The apparent de-emphasis on native development leaves us feeling a bit...vulnerable. It would be a great encouragement to see some renewed investment in native development.

Thanks for your efforts and willingness to listen!!

Hi Juan,

you can organize your C++ code in namespaces and the class view will show your class hierarchically in the namespaces. You can also put namespaces in namespaces and see that in the class view. Very convenient!

--

SvenC

I would like the possibility of printing debug data like arrays, multi-dimensional arrays directly from the debugger.

Also printing memdumps would be usefull.

I would like to have MFC support in the Visual C++ Express edition.

I would like to see

=> improved performance of the build time in VC++ such as  Increditbuild - distribued build tool (http://www.xoreax.com/download.htm)

=> Memory leak detection in the native and Managed runtimes via APIS

=> Heavy support for Web Services via APIs

=> features that are unique to Visual C++ as compared Managed world.

Srinivas

I agree that C++ is there for native development, for managed development C# is a much better choice.

If Microsoft would have understood that sooner, we probably wouldn't need 3rd party software just to make our native applications look good.

But there is something else I would really like to see improved: The help. When I press F1 I really need instant help on the identifier I'm on. On line help costs me a lot of precious time. It takes like 10 seconds and then the quality of the help is poor sometimes. I really hope you are able to provide us with local help, the sooner the better.

Jos

Absolutely, 110%, I would love to see a more open approach to cross-platform compiling, mixed build systems, and above all, the development of a "native" .NET framework.

I don't want to use C# and .NET to make a simple GUI frontend.  I don't want to use WinAPI directly.  I don't want to use WxWidgets, or 1000 other frameworks I dislike.

Make us a GUI designer for native C++ using WinAPI.  I don't like MFC, and I don't think I ever will.  I am not an old-school C++ programmer like some developers, being only 22, but I love C++ and I think managed code is a horrible mistake in this industry.

Apart from that, improve the GUI, and add support for SVN/CVS without forcing me to use AnkhSVN and other such plugins.

Oh, and before I forget: refactoring and intellisense MUST get better, like Eclipse meets Tomato Software.

Thanks a lot for accepting our feedback.  I'm looking forward to Orcas+1.

Hi Michael,

so you don't want managed and don't want WinAPI and don't want WxWidget and don't want MFC and you do want to build the best UI ever with a GUI designer? Can you give us or Microsoft a few details on how you want to things and not only how you do not want to do things.

I get the feeling that you want to build Office like apps by clicking and dragging some controls together. And my guess is: building those apps is more complex than you think...

--

SvenC

>> 4. Support for POSIX (I know I'm asking too much) libraries: libc, libstdc++

>VC already has implementations of the C and C++ >Standard Libraries.  If the programs you are working with >specifically require glibc or libstdc++, then they contain >nonportable assumptions.

>This is why we have International Standards.

And you're claiming that POSIX is not? It's defined by IEEE.  And the "I" stands for?  

I've been porting code back and forth from Win to *nix for 10 years and lack of POSIX is the biggest problem -especially for threading.

Do some homework please.

Hi SvenC,

Sorry if I wasn't clear enough.  I know it may sound like I am a newbie programmer who wants the next best thing since sliced bread, and while my GUI work is limited, here are my views of what I want to see:

- .NET style WinForms GUI designer.  This makes snapping together the basic GUI fast and easy.  The only problem is I don't like the 20% performance hit my entire application takes from being inside the CLR.  If there is some way to create a WinForms-like native C++ library, I think you would find a lot of people who would love it.  I hear people tell me all the time, "Making GUIs in .NET is so nice.  Wish it was that easy in C++."

- Lightweight GUI library.  While MFC is a powerful framework, I have read many opinions on it, seen many example programs, and I feel the entire library is too large, has an outdated programming model, and has too many dependencies.  I admit I have not tried ATL or the new WTL, but I am actually going to give WTL a try sometime.  I've heard good things about it.

- Exception-based programming model.  I think that modern libraries should make use of exceptions.  I read an excellent blog entry on exceptions versus return values and I have to agree with it.  While I (and many others) are comfortable with traditional programming models, I think that modern libraries should use exceptions.  It's something that makes Java and .NET both very nice to use, even if exceptions aren't perfect.

Also, let me clarify a few remarks:

I would like to see a library that makes it easier for us native C++ programmers to make GUIs because doing straight WinAPI / MFC is difficult for most beginner/intermediate programmers.  It's not even about the learning curve, so much as, designing the entire GUI in code is slow and unproductive.  It's the same reason I dislike making GUIs in Java: no GUI designer that is worth its' lines in code.

About the 'building Office apps' comment, I agree with you.  It's surely not as easy as I made it sound.  Making such complicated software takes a lot of work, but when the tools to create the GUI aren't nice to use, this is only so much harder to do.

I've recently started programming in templates in C++, and am really loving C++.  I've also done work in ASP.NET 1.1, C#/VB.NET, and Java, and I still keep coming back to C++ as my favorite language.  RIAA, stack-based variables, templates, and performance are some of the reasons.

So, sorry for not being as clear as I could of been.  Sometimes I don't feel like writing up a storm during finals week :)  I know there are other priorities, but a nice GUI framework would really give C++ on Windows and edge it has been missing for a long time.

Thanks for replying and thanks for letting us give feedback.  It's a really nice thing to see.

The VS Debugger is the best and ever was on Windows! Debugging is much fun. Especially to learn how things are working.

- IntelliSence must be enhanced (False hitting is annoying). Maybe a way to go - VAssistX from WholeTomato Soft.

- Speed improvements as said

- most omportantly the editor -> just make it like in C#, code folding which is working like in C# and so on

In-Place parding and better code formatting like in C# with syntax check and correction. I know it's not that simple but you should end there where C# began concerning this.

cu

Martin

What I would like to see in future versions of Visual C++:

Continue to track the C++ standards.

Continue support for native Windows SDK applications.  I want to stay away from NET and managed code.

Continue to provide great documentation.  Currently I rate the documentation as awesome!

Thanks for doing a great job.

Thanks for VS2008!

I just have a comment... Why C++/VB are not a first-class citizen programming Avalon/WPF/Silverlight? I see you can currently program it using C# ...

Like other people,

1) I would like to see a new GUI designer for native C++ using Windows API without wasting 5 times more than .net just becasue of designing its interface. I want to stay away from managed code.

(yeah, but I think in my dream)

2) a new search engine for Local MSDN library.

sreaching a a disaster in local searching, Can you find any word with undescore ( _ ) or a combination of more than one words, No I can never do that.

using Google and typing msdn plus what you want will solve that but it is not local.

Two simple requests of IDE:

1.A short-cut to open corresponding .h/.cpp file,eg, if current text window has manager.h, open manager.cpp if it exist in the project.

2. An open project file dialog. A lot of time, source files are arranged in hierarchy instead of flat, so navigate the solution explorer tree or file directory is not so convenient.

Both these two feature exist in visual assist.

Maybe these can be done by some macros?

Thanks for your time.

to clarify the 2nd request:

open a file in side solution without have to type the full path name.

wish list:

- intelli-sense that is actually working

- better utilization of project dependencies while building in parallel (compile every project regardless of dependencies, only link as stated by project dependencies)

- link-time performance improvement (link-time >10min for release-builds of bigger projects is a pain)

- improve setting breakpoints in often instantiated template functions (setting a breakpoint can take >1min if instantiated often with many different template function parameters)

- no feature crap, this is c++, c++ developers choose it because it is rock-solid

Intellisense sometimes follows a different include path to a declaration than the compiler

VS2005 often crashes when closed (onExit by clicking the X in the top right corner) and ALWAYS defaults to restarting even when you are trying to close VS.

Debug runs too slow to be useful for debugging so we have been trying to build a Release_with_Debug hybrid like we had in Studio 2003.  Linker just fails with a LNK1106 error and there's no indication as to which file it doesn't like (there are tens of thousands of them in the link).

I love the tooltip displays of the data structures in VS2005 debugger but sometimes when one is very very wide and only 1 line tall, it's really really hard to run the mouse straight along it to the + at the beginning of the line to open the next level without the whole thing dissappearing when you get the mouse about half way over to the +

Often setting up a new Release_with_Debug configuration gets incompatibility issues between LibCmt and LibCmtD or maybe between NafxCw and NafxCwD or some combination of those.  It would be very helpful if the correct libs were automatically inluded based upon the current link project settings, rather than on including wrong libs based upon how other libs from other projects were built.

There also seems to be an ordering issue between NafxCwD and LibCmtD where the auto gets them backwards so you get a duplicately defined error and have to exclude them both then re-specify them in the correct order.

In some cases while debugging, if the code throws an exception, the call stack gets wiped out (maybe caught vs. not caught?? not sure).  Anyway, when that happens there's no way to find who threw the exception.  When running in debug, don't EVER wipe the call stack on an exception.  I had to track one of those down and it was about 47 levels deep in recursive Boost serialization code before I found it.  It took days of debugging to get there.  With a call stack intact, it would have been seconds.

I found a performance issue when debugging where if I open a solution on the local C: drive vs. opening an identical solution on a network drive we get about a 100 X increase in debugger performance when debugging the same executable (by setting the executable path on the debugger property page).  Task Manager identifies the devenv.exe as doing hundreds of thousands of IO other operations when the solution was opened from a network drive that disappear when opening the solution from the local C: drive.

I see others complaining about the long time it takes to switch between Debug and Release configurations.  I also have that problem, although I identified that the problem only exists if Intellisense is enabled.

I have many projects which I use Intellisense with and many which it does not apply to because they are in another language which is unknown to Intellisense and are built via Custom Build rules.  Intellisense can only be enabled/disabled at the application level so I can't turn it off for projects it doesn't apply to.  It should not only be enabled at the project level, but also be able to be set to only apply to a list of user specified file extensions (types).

Right now I often have to wait for it to update in projects it doesn't apply to.  It also takes from 5 minutes up to 15 minutes to update so it can really kill my productivity.

What happened to the help compiler?  I had to copy if from VS2003 into VS2005 and it's working again, but it was missing from the VS2005 installation.

With VS2003, you could hover over a word in a comment and it would display the value for that variable name.  With VS2005 it seems to ignore the comment lines.  I had gotten used to altering a comment line by typing a name on the end of the comment line then hovering over it to see it's value.  Now with VS2005, I have to move down to the watch window to type in a name and it distracts from the code I am studying.

HELP: The help normally fails to tell what #include is necessary when you are looking at how to use a method or function.  Then you get a compile error and it's obvious looking at the documentation that I did the call right, so I figure out that I need a #include to prototype it, but I have no idea which one.  The only way to find it is with google looking outside of MSDN.

HELP: There are several groupings in the help and you can supposedly filter on them but all that does is gray out some of them... It doesn't really filter them out and you can't search only C++ or only SDK or a multiple selection of C++ and SDK together.... I keep getting hits in other areas like VB, C# or some other product I've never even heard of.  Can you make the help filters actually work?  and allow multiple selection also?

When I set a break point with VS2005 in a template, it lockes up the machine for several minutes.  Most of the time I don't realize it's a template until after I am forced to wait for those many minutes.  In those cases, I want to abort the setting of the breakpoint and instead maybe open the file that will be called from the line I'm setting the breakpoint on.  Maybe have an option in the VS settings where the behaviour of setting a breakpoint in a template can be selected as 1) set it 2) prompt first.  Granted, VS2005 is far better than VS2003 which prompted for which one of the 600 breakpoints do you want to set (by memory address so you couldn't possibly know which was which).  Keep the set the breakpoint in all instantiations of the template... Just allow a prompt first (yes / no)

In the debug window "Locals" you need to be able to click the title and have it sort the entries, just like explorer sorts file names.  Without this feature, it's impossible to locate a variable in the "Locals" window which renders it totally useless for any but the simplest source file.  It forces the use of the "Watch" windows as the only way to view a local variable.

I think it would be great if there were a "realloc" keyword that could be overriden the same way "new" and "delete" can be overriden for custom memory allocators.  The default "realloc" behavior could just use the CRT.

With VS6, VS2003 & VS2005 every time you open the edit dialog for a custom build rule (or any other edit window from the properties page) the window shrinks from the previous opening by the size of the window frame.  After a few times, the user has to manually enlarge the window again.  It's pretty annoying when copying settings from file to file in a large set of projects.

I would like to see the ability to combine projects that come out of different source safe repositories into the same solution file.  I don't need more than one repository per project, that restriction is fine, but the restriction of one repository per solution causes me to have to duplicate code into 2 repositories which means any code modifications have to be manually performed duplicately in each of the 2 copies of the source code.

David: I not completely sure what you are asking. My first thought would be why don't you use placement new for this? That is a pretty close C++ alternative to realloc.

[James Balster]

"When I set a break point with VS2005 in a template, it lockes up the machine for several minutes."

Please open a Microsoft Connect bug and provide precise repro steps. You can post the bug ID here.

Thanks,

Stephan T. Lavavej

Visual C++ Libraries Developer

I agree that most VC++ programs are targeted for native code, but I still do some things in VC++ where I want a managed output.

I have recently transitioned back to VC++ from C# and C++ Unix and embedded development.  I am using C++ native features for multimedia.  This is a different application domain than many of the comments above.  My last heavy Windows experience with C++ was using VC6.

Since I am using a large body of VS languages, I like the integrated aspects of the environment.  This does raise the complexity, but the integration benefits are great.

While digging heavily into VS2003, VS2005, and VS2008 features, I have noticed that sometimes the best improvements in VC++'s are easy to miss.  A set of overview documents (not detailed change notes) on the significant differences between Visual Studio versions would be a great help.  Suggestions of best practice changes between these tools could help alleviate many frustrations that occur when developers use new tools in old ways.  Topics could include:

1. New managed/unmanaged C++ interop approaches, and how things have changed since VS2003.

2. How to manage large code bases using project and properties.  This would include the Team system and the Pro series of tools.  

3. How to migrate large code bases over to newer best practices.

4. How to configure stable portable GUI build systems between developers, that also port to a command line build.

The documentation is available, but VERY difficult to find in one place.

For some detailed changes (some of these have been documented elsewhere)

A. Support dOxygen better (and integrate Sandcastle with native code).  This would allow current best practice documentation with a transition to new practices.  A tool to port between the two would be useful for a transparent experience.

B. The XML documentation form for .Net is ugly.  It makes the code more difficult to read.  If you want to look to better (easier approaches) look at the lightweight markup language ideas.  XML may be a standard, but for just reading code it's obtrusive.  Support a simple markup form (Textile, markdown with a few tags, or use doxygen**) and make it easy to port to the XML monstrosity.

C. Better refactoring tools.

D. Get an HCI set of experts to look at switchable simplified coding views in Visual Studio.  The current tool tries to place everything in view.  How about some encapsulation in the tools?  Make a very simplified view where the following tasks are easy, with little visual overhead.

 - just plain coding

 - just plain constructing code

 - project setup

Do not use 500 screen wizards, do not have a billion GUI features on the screen.  Just have simplified interface (without the visual clutter).  C++ programmers can support a larger memory overhead than a newbie VB programmer.  Just make it lean and mean (and transparent), with the option to toggle into the kitchen sink view we now have.

99% of the time, this would be the environment I would work in.  Why clutter this to make the 1% tasks easier?

I wish the tool were more stable.  I should not be able to cause it to crash.  I experience a crash once every three days.

Closing VS has gotten slower and slower.  

The interplay between tabbed source files and the solution explorer needs to better engineering.  Clicking on one should activate the other.

The algorithm for selecting which tabbed source files remain visible needs to be improved.  VS seems to remove the ones that I access frequently.

Would like to see much faster on-line help.

If I get a linker error, e.g., 1106, I shouldn't have to Google the Internet to fine the solution.

Almost any application these days has need for a grid.  While there are several third party options available, it would be a significant improvement to have a grid option in MFC classes for use in dialogs.  

Similarly, it would also be a significant improvement to have a set of reporting classes built in.  While one can make the current CView derivatives work, it would be relatively straightfoward to extend a set of grid classes to incorporate reporting functions.  Again, almost any application has need for reporting-- why make developers everywhere reinvent reporting extensions of CView.

Thanks,

I agree with everyone else:

1.) Don't eat every clock cycle and megabyte for gobbs of usless "features" like forums, start pages, internet help, flashing lights and sirens in the IDE.  When programming, I need a few of the clock cycles myself and if I want to surf, I'll use a browser.

2.) HELP AND DOCUMENTATION

Provide help and documentation - not little sprinkles of this-n-that scattered throughout hundreds of thousands of pages of unrelated stuff.  

In examples, make them as small and to-the-point as possible.  Don't add a bunch of unnessary code that needs explaining as well.  

Categorize the help based on required functionality - not on class names that don't seem to correspond to it's functional purpose.  

Don't rename algorithms and processes that already have been identified prior to Microsoft's existence - I don't know how many times I've been confused by concepts I understand well simply because Microsoft decided to create a new name for it.

3.) Provide options to the C++ developer to control the formatting of the source code.  Borland C++ Builder does this well (but VSs Intellisense is better and quicker that Borlands) - let me define how to indent and where to place curly braces.

4.) Don't push C# and managed code - it's rinky dink - good for database/web page programming but that's about it.  I'll take it more seriously whenever I see Microsoft use it to write an operating system.

When I check in my source code, Source Safe properly alters my source code by replacing the "$Revision: $" tag.

That string is in a source code line, rather than a comment and it is parsed and used as the minor version number for my application.

The problem is that after doing the check in, VS2005 thinks my source file is up to date so I have to do a REBUILD instead of a BUILD, even though Source Safe has altered the source code since the prior build.

VS2003 and VS6 had the same problem.

Although I very rarely crashed VS2003, I find that with VS2005, I crash it almost on a daily basis, sometimes 2 or 3 times a day.  The most frequent crash (over 90 % of the crashes I have encountered) occur when a solution is being closed.  With VS2005, it also takes a VERY long time to close a solution... at least as long as it takes to open it, possibly longer.  

I'm wondering if possibly intellisense is kicking off during the closing of the solution and trying to access data structures that are no longer valid?

Good idea Thor!

The grid control as a built in sounds like a great idea.  

We also use a 3rd party grid control and it's just one more repository/solution/project that has to be carried around and built repeatedly.

In the VS2005 debugger, the values displayed in tooltip format when you hover over a variable sometimes are lacking in info.  

For certain pointers to classes, it only displays the type of the class and not the address contained in the pointer.  

This makes it difficult to determine if the pointer being looked at is valid or not.  

I was just looking at one and I busted open each of the + signs to look at all of the class heirarchy and found no information indicating for certain that it wasn't a valid class pointer, yet it also didn't contain any data values.  

Finally, I entered the variable into a watch window and discovered that my pointer had a value of 0x00000000.  It would have been far quicker if that was displayed in the tooltip window along with the type information.

How about always including the address in the display as well?

Debugging VC++ application that contains nested objects is not easy & productive. For example when an objects internal object(s) is modified locals/watch windows hightlight those with RED color. But the tree in the locals/watch window needs to be expanded to see which objects are changed.

This is very tedious, time consuing and distracts from solving the actual problem. I used to Product Routing algorithams that contain many nested objects (bredth & depth wise).

It would be much more productive if the VC++ debugger UI supports some sort of settings to automatically display the inner objects when they are changed.

Srinivas

I would like to be able to edit and sort the RECENT PROJECTS list shown on the Start Page.  I'd also like to be able to lock it  to prevent accidential changes (similar to how the quick launch bar on the start menu can be customized).

The limit of 24 solutions on the RECENT PROJECTS list is too small for our instance.  Our source code base has 20 solutions for one contract and 7 more for another contract and we have both a shared version on a network drive plus a personal version on the C: drive of each solution.  (24 + 7) * 2 = 62 solutions.

The large number of solutions being dealt with increases the need for being able to sort the RECENT PROJECTS list.

Hello James

Re your comment: Monday, December 17, 2007 2:20 PM by James Balster

Thanks for taking the time to post to us on your experiences.  Recently we have done some work on Intellisense performance and correctness, have you seen these entries:

http://blogs.msdn.com/vcblog/archive/2007/11/26/q-a-about-the-vc-intellisense-qfe.aspx

http://blogs.msdn.com/vcblog/archive/2007/11/19/controlling-intellisense-through-macros.aspx

http://blogs.msdn.com/vcblog/archive/2007/11/12/performance-improvements-in-visual-c.aspx

Have you installed the GDR? Was this an improvement?

Thanks

Damien

I would like to be able to include comments with both text and graphics in the source code, with a graphics editor something akin to Corel Designer or Corel Draw.

It would be ok (possibly better) if the actual graphics resides in a separate file or database, but it should appear seamless to the developer.  Perhaps a GUID would be included in the source that references the graphic.

It amazes me that the best tools I have today for including diagrams in the source code is blocks of characters.  It makes maintaining source code difficult when complex geometries are involved.

Hi Steve,

integrating a graphics editor so that a graphic does show up directly in your code seems a bit odd to me. But you could do something like this: add a comment with a URL. URLs in comments can be left clicked when you hold down <ctrl> and they will be opened in a new tab in VS. So when you can assign a URL to your graphics they can show up in VS. Try it - put this in your code, press <ctrl> and left-click the URL:

// http://msdn2.microsoft.com/library

--

SvenC

How about integrating the "Find Results" windows better.  If you could search the code base for a string, then edit the results to delete ones from files you are not interested, then using the remaining results to drive a partial rebuild of the code base would be very useful.  

Either a "Build all files in find results" or a "Build selected files in find results" are 2 choices I'd like to have.

Now with C++ it may seem silly, but for those of us who still have some Fortran code, there's no automatic dependency checking to know if a file needs to be rebuilt....

I also do miss the (handy) keyboard control of VC6.0.

Ctrl-J, Ctrl-K for jumping to the matching preprocessor directive was very convenient (I don't even find the command in VS 2005).

Pressing Esc cleared out all the find-output-build results off the screan... Now it requires much more movements (and it's quite hard to do without turning to the mouse).

And the opportunity to disable the "Copy without selection" thingy... it appears strange to me, that it's gone... :(

One more thing already mentioned above: F12 (Go to Definition) worked from everywhere (even half of a token in a comment), now it is much more scrupulous.

shared_ptr

-Improve IntelliSense's reliability. It keeps on breaking with any larger project.

-The "Edit and Continue" feature also tends to break.

-Slow linking time is an issue with large projects, even with incremental linking.

-Make "Copy without selection" optional, as it was in the VC6 editor. I wouldn't like the actual  line to be copied to the clipboard if I accidentally press ctrl-c instead of ctrl-v. VS's behaviour is not consistent with other applications.

I would like to see a more powerful scripting interface in the VC++ Immediate and Command debugger windows. I would like to be able to write scripting loops and function calls on the fly (maybe it's possible and I just don't know how). Something similar to how Python's SWIG or Lua can integrate and cooperate very well with C++ code, but at the debugging level. Ideally, after a breakpoint is caught I would like to be able to manipulate the current scope of the breakpoint any way I want via a scripting language. And, possibly, navigate the stack as well (I wrote my own separate thread that can provide stack navigation in the debugger, but it needs code instrumentation and re-compilation; I obviously don't want to recompile, hence the scripting language features). Don't get me wrong, I like the Immed/Cmd windows, but they can be much more powerful (either that or I don't know how to make the best out of them, maybe something similar might be achieved with VB?). Thanks.

Regarding BRIEF support, Philip Taylor (UK) is correct about being broken since VS2003. Another problem is the 'column block' cut/copy and paste. Copy a column and then attempt to insert at end of line. It inserts after CR/LF instead of before. Therefore inserted column begins at beginning of next line between current line where cursor is placed to do insert and what now is the next line prior to the insert.

Also, same problem with highlihght not turning off after after double-clicking on a word. Next time you place cursor somewhere, highlight extends from last hightlight to current cursor.

Annoying for MS. I know BRIEF is 'really' old, but I know that people that use BRIEF are probably the fastest typists on the planet. At one time, I could do over 130wpm easy (obviously not always when writing code) as BRIEF is truly the most ergonomic 'touch-typist' key combos anywhere (minimal contorsionist key-combos as prevelant in other editors). Obviously many others may disagree, and since support has continued, why not keep it? What could it hurt until all us old-timers croak? Otherwise, VSxxxx has always been the BEST!

Currently VC++ has no IDE support in Visual Studio for programming these CLR technologies:

1) ASP .NET

2) WPF

3) WCF

4) LINQ

while of course C# supports all of them. Clearly you, and Microsoft, could support all of these using C++/CLI in pure/safe mode modules. If you are not interested in supporting .NET, and just ceding .NET development to C#, just drop C++/CLI and stop pretending that you are creating a level field for all .NET languages.

You did an excellent job of creating a first class .NET language with C++/CLI and you have done a general good job in interoperating between C++/CLI and standard C++, but you have done a terrible job of bringing .NET technologies to C++/CLI.

I believe there is a big miss in thinking that developers, especially c and c++ developers, want to "find a way to integrate" with .net technologies.  

These developers want a way to get it done w/o using garbage collection in any manner ( or in the words of the verbally esquisite, "non-deterministic finalization").  

These technology partners want to control memory, threads and processes and that is what they are paid to do.  

Opening up new technologies both current and future with a c/c++ api would see these technologies achieve a faster market saturation.  Failure to do so, will in fact limit their adoption and see competing products take your market.  As has been done currently.

I'd like to see all the Visual Studio debuggers capable of supporting highlighting which of the calls on a line will be stepped into next.

I frequently find many "trivial" function calls on a line (often these may become inlined in the release code) that can be really annoying to step through. The problem is further compounded when "fluent" style approaches are taken to classes or interfaces.

It would be nice if you could right click on the file in the editor window and select "compile" rather than have to hunt for it in the Solution explorer.  

Coming from VS2003, At first I liked the fact that VS2005 solution explorer didn't follow the file selected in the editor... that was great while editing, but once I needed to compile the file, I had to hunt and hunt and hunt for it in the solution explorer.... I ended up having to turn the follow option back on... and I lose the other benefit.  If I could launch the compile without having to use solution explorer then I can turn that follow option back off.

I see Rob Grainger asking for highlighting the next call on a line, but that won't really address the problem... The problem is you want to be able to step over just one call, but not over the entire line.... For instance, if a call is passing 2 std::string variables as arguments to a method, then each of the 2 arguments will end up generating a call into <string>... both of which I want to step over before stepping into the main method call on the line.

I've been using VStudio since it was version 3.0 and while a lot has gotten better, we have some issues:

1) Intellisense (as many people have noted) doesn't work well. I have a batch file on my desktop to delete the ncb file to cause a rebuild that I run almost daily.

2) The CArray constructs have run-time checking in release mode that you can't turn off that just kill performance. We've had to subclass the arrays to get decent performance and that's dumb.

3) The fact that everything you're inside selects when you click in the dlg editor is crazy. Try sliding six radio buttons to the right without sliding the enclosing box.

4) Improve the task manager stuff. You don't even have a filiter option. We're trying to use this for task tracking during checkin and it's just awful. Primitive would be kind.

5) Make it easy to generate custom workitem reports. The current report management is impossible. Why am I trying to figure out how to create SQL data readers?

6) Improve assert. There's no robust way to report issues to the programmer other than the primitive assert function and in release mode they have zero value.

7) Track memory leaks. What you have works ok for DEBUG_FILE stuff (most of our source) but is useless for GDI and runtime library stuff.

8) Allow the mfc dialog wizard stuff to work with inheritance. Now if you don't have resource.h included in the header and it's not based on CDIalog or CPropertyPage you have no wizard.

9) Have some way to view hierarchy other than generating UML for the entire project.

10) Refactoring tools.

11) Code style enforcement tools.

Thanks,

Mark

I have used Visual C++ since 2.0. I read all of the people complaining about standards, but I have 1.5 million lines of C++ code that is very old and ported from UNIX to Windows for the "core" of the application. (All the UI is new of course, but that is the smallest part of the application). The main item for me is don't break stuff that worked in the past, even if it was a "Microsoft-ism", we still have a significant amount of effort in our applications, I understand the need for standards, however you also need to understand that we have applications that do a little more than "Hello World".

Visual Studio 2005 is much better than past versions, in 2003 we actually used interop to our old 6.0 C++ dlls because it was pretty painful to convert to the new environment. With 2005 the conversion took about 1 week for all the C++ code, including interfaces to FORTRAN (it isn't dead yet for structural analysis).

The biggest complaint I have is the slowness of stuff like ClassView, even though it is probably no slower than 6.0, I wish the "updating of SourceSafe status" was more transparent, intellisense & updating the sourcesafe status really take over your machine, to the point we go for a coffee break after opening a project. They also tend to "wake up" at times and take over, it would be nice if they were more of a "background" update and less intrusive.

Keep up the good work. I'll wait until the Beta's are real before trying 2008.

Thanks

Alan Anderson

Dir Applications Development

Varco Pruden Buildings

With VS2005, I tried disabling intellisense yet after doing so, I still end up waiting at least 10 minutes at a time for an hour glass mouse cursor while the status bar shows "updating intellisense".  Why is it still rebuilding and updating the intellisense database after it's turned off??

I've been working 4 days now, trying to do a single rebuild of all of our code, using 3 parallel machines.  The intellisense updating continually locks up each workstation and makes it totally non-responsive.

I also found what appears to be a problem....One of the projects is working with a pre-processor and once the preprocessor finishes, the custom build rule executes the command

DEL *.h+

The prior line before the DEL command is running a program that merges 10 files matching *.h+ or more specifically $(InputName)*.h+ into a single file $(InputName).h

This operation works just fine on one of our networks, but on the other one, the DEL command acts up ONLY IF there is a 2nd copy of VS2005 running on that PC, even if the 2nd copy of VS2005 is idle and has not even loaded a solution file.  What happens is that after a pause of about 10 minutes from the start of the DEL command, I receive a  message something like this

   Cannot access file - locked by another process

Once I receive that message, I went to another PC and with windows explorer, I also tried to delete the file and indeed I received the same error message.   As soon as I close down the 2nd copy of VS2005 on the machine doing the build, the problem disappears and the compile speed picks back up to about 10 seconds per file.

I don't know what kind of logging is enabled on that network, but I do know that there is some enabled as our IT guys have complained to us asking machines to be shutdown when not in use because of the size of the log files being up to a million lines per day from 10 to 15 workstations being booted up, even if they are not logged into.

Our other network does not have the logging enabled and the problem cannot be reproduced there.  Our workstations are running XP on both networks and are kept up to date with service packs and updates.

As an interm solution, I have commented the DEL command out of the custom build rule and I am leaving the clutter of tens of thousands of intermediate files for a later date.

Linq to work with native STL  

WHAT VISUAL C++ LIBRARY THAT TARGETS THE WEB?  

Currently VC++ has no IDE support in Visual Studio for programming these CLR technologies (why???):

1) ASP .NET

2) WPF

3) WCF

4) LINQ

while of course C# supports all of them. Clearly you, and Microsoft, could support all of these using C++/CLI in pure/safe mode modules.

If you are not interested in supporting .NET, and just ceding .NET development to C#, just drop C++/CLI and stop pretending that you are creating a level field for all .NET languages.

What is the real reason of releasing the only Web library ATL Server on CodePlex.com? Is it to hard to ingrate some of sophisticated web components like in ASP. NET to make our only C++ Web library ATL Server web developpement easy to use?

MFC will support BCG controls bar but it is only for desktop application and not for web application.

Can we built 3-tiers application entirely in VC++?

You did an excellent job of creating a first class .NET language with C++/CLI and you have done a general good job in interoperating between C++/CLI and standard C++, but you have done a terrible job of bringing .NET technologies to C++/CLI.

WHAT VISUAL C++ LIBRARY THAT TARGETS THE WEB?  

I would want to say that www.hotmail.com still use *.srf web page to open connection in the mail box. And *.srf pages are built using ATL Server technology. It 's the same for .NET passeport web pages.

Can you explain this?

WHAT VISUAL C++ LIBRARY THAT TARGETS THE WEB?  

With Silverlight 1.1 we can build interaction web application using C# or VB .NET with the .NEt Framework and C++/CLI is not a .NET language?

Is ASP .NET only for C# and VB.NET?

But it is not all of .NET language?

Can you explain the real Visual C++ Futures?

WHAT VISUAL C++ 2008 LIBRARY THAT TARGETS THE WEB?

WHAT VISUAL C++ 2008 TOOLS THAT TARGETS WPF?

WHAT VISUAL C++ 2008 TOOLS THAT TARGETS WCF?

WHAT VISUAL C++ 2008 TOOLS THAT TARGETS LINQ?

WHAT VISUAL C++ 2008 TOOLS THAT TARGETS ASP. NET?

WHAT VISUAL C++ 2008 TOOLS THAT TARGETS SILVERLIGHT?

WHAT ABOUT THE FUTUR OF VISUAL C++?

WHAT KIND OF VISUAL STUDIO 2008 FOR C++ DEVELOPPERS?

I posted earlier, but I neglected to mention that my number 1 desire is that Intellisense only makes me wait when opening a solution. I never, ever, should have to wait after that. Never!

Here are some ideas. Not all of them are well thought out. Some of this is already possible, but I think it should be improved.

Visual Studio:

* more relevant results with F1

* refactoring

* better designer support

* separation of user generated and computer generated code

* only show relevant items in intellisence (no private members when you can't access them)

* SVN integration?

* Allow lower level development with VS (like developing and debugging an OS kernel in a virtual machine)

* make it easier to work with assembly (especially NASM)

* improved code size optimization (if I don't use a particular class in MFC or a few of my functions, don't compile them in)

* managed code interop is low priority for me

C++ in general:

* more libraries (such as something like System.AddIn in .NET)

* switch to exceptions as the error-handling model

* make it easier to develop high performance web applications in C++

Also, LLVM is show real promise in the Apple/open-source world. Interoperability with LLVM would be great, or you could compete with them if you want.

I would like to see a list of the files which VS thinks are out of date and need to be rebuilt.  When it takes hours (or even days) to do a full rebuild, but only about 9 minutes to compile a single file and relink, the decision as to whether or not to do a build or to try to use the debugger to stop at a breakpoint and then manually try to do a workaround could be based upon how many files would get rebuilt...  

This could possibly be a separate window, such as the "pending checkins"  window, or it could be integrated into the solution explorer much the same way source safe is integrated....  Maybe a very light gray background around the filename text if it would get rebuilt, rather than an icon next to it.  That could prevent it from getting confused with the source safe icons.  Hovering on the file could still display the tooltip like it does now, but rather than saying

    "Checked-in"

it could say one of these

    "Checked-in, up-to-date"

    "Checked-in, out-of-date"

If done with highlighting, then The out-of-date highlighting should be propogated up to the project and solution level as well.

I would like a code tidier similar to the Rearranger/Code reformat in JetBrains IntelliJ Idea for Java.

It puts methods in a controllable standard order. It gives you very fine control of indenting and spaces.

This gives you a standard format before checking.  If everyone uses the corporate standard, you don't get false deltas.

I saves you so many keystrokes not to have manually align code.

Hello everybody

I am using c#.

I want to know to programatically change my C# code in order to get it compiled by distcc.

does any body know how to use distcc with c# sample program ?

or maybe how to change the compiler in C# and use the distcc instead.

please help.

* Have a switch to allow exploring system include files in Class View. This was a life-saver for iostreams in VS2005.

* allow storing pin_ptr in a class for those who want the higher-level abstraction of .Net without the security. Maybe add an 'unsafe' switch for that. Or is there some other way of holding a reference to a CLR class?

Re. docking windows, allow 'splits inside a page' as well as the current 'pages inside a split'. eg. so you can have one page with small windows like call stack/autos/locals visible together and then just flip the page and get the output window on its own page. Maybe allow duplicate windows too so that you can have different layouts of the same things.

I have worked for a week with VS08 and I have run into two designer showstoppers; showstoppers that I have no way of working around.

I am going back to VS05. It is far better to limp along, with the designer crashing the IDE every ten to fifteen minutes when I work with form layout, than to be dead in the water. I may play with VS08 again when, if ever, the first service pack comes along.

To me, that a product works properly and as documented is far more important than anything else. I can work around the lack of features and that the compiler mishandles some source code; I cannot work around error messages such as the two I have encountered with VS08. Note that it only has taken me about a week to run into an impasse with VS08. If my experience is representative, VS08 is going to be one of the more outstanding lead balloons in Microsoft history  --  if possible, even worse than Bob.

I have made a DVD with a snapshot of the present state of the project. Should Microsoft be interested in improving the abysmal quality of the designer in VS08, they need to provide me with a snail-mail address to which I can mail the DVD. (My connection does not have a good enough upload speed to make uploading a large amount of information practical.) Please note that the code is proprietary and copyrighted; do not disseminate it beyond Microsoft and do not use it for any purpose except fixing bugs in Microsoft software.

Hello

Re: # re: Visual C++ Futures

Sunday, January 06, 2008 12:25 PM by Peter Bergh

Please open a bug report at Connect (http://connect.microsoft.com/ - customer reported bugs receive a high priority). They will take your information and send it on the relevant group to look at.

If you have any problems/issues/questions after opening the bug report then feel free to contact me directly via email - “my first name” at MS.com.

Thanks

Damien

i have a small sugession, we can have a clipboard in IDE also so that we can copy and paste more than one code snippets at a time

Over all I have very mixed fillings about VS. First of all it is the best integrated environment(debugger, editor etc.) out there for native c++ development. Linux does not have anything that can compete, eclipse is a jock, KDEDevelop and Anjuta are plain useless. Sun studio is too bulky and too out of date to be useful. Macintosh’s XCode is probably the only real competitor you have but even it is not as useful as VS. So for native c++ development there is only VS(it is even used in many places to develop Linux applications). You are the best, which is unfortunately not much if you do not have real competition. Since we switched to VS 2005 I am straggling to understand why Microsoft decided to cripple the application, and I dread the day we will have to switch to Orcas.

UI in 2005 is not just slower it is border line useless.

1. Find and replace dialog takes seconds to show up. It is show case for bad Windows UI. For that matter any new  UI operation takes visible effort on the part of VS. Amount of Windows resources used by an instance of VS 2005 is mind buggling

2. Look up functionality (F12) works 30% of the time. It used to work (2003) even in comment block, now it hardly works in existing code. All of that with ncb sizes in 10-s of megabytes.

3. Somebody decided to switch nice tree view of class’s functions into hardly usable small window under the class view.

4. Source control integration with 3-rd party providers (Perforce) is very ugly. While I do realize that provider is at fault here – you integration API is the source of the problem.

5. Very nice and intuitive XML editor introduced in 2003 is replaced with something that is not much more useful than notepad.

6. Resource editor has the same problems it used to have since version 1.52. If it is edited through UI it replaces custom macros into hard coded values, it removes custom sections it pretty much forces us to use text editor to edit complex resource files.

7. If you have solution with several projects in it and some projects have 64-bit configuration and others don’t, there is no way to add 64-bit configuration to projects that do not have it because “configuration already exists”.

8. using forward slash in include dialogs pretty much disables look up directory functionality – it used to work in 2003.

9. Macro substitution dialog works 40% of the time (OutDir, TargetDir etc.)

10. Manifest generator interface with WTL projects that need common controls 6.0.0.0. I am yet to figure out how to make it work with 64 bit AMD. Again it is my ignorance that is at fault here, but VS is of no use in this case, it is actually aggravates the problem.

11. Crush dumps can not find appropriate symbols 1/2 of the time with SymbolServer setup according to instructions from MSDN.

12. MSDN (F1) takes several seconds to show up, but when it does it usually finds nothing but bunch of .Net references on the WEB(yes I tried filtering) – try to search for “operator overloading” with “Visual C++” filter

13. Search for native WindowsApi or Windows message either finds nothing or points to MFC/.Net article. – try SendMessage or WM_SIZE

14. Search for stl help does not work 1/2 of the time.

I can continue the list, but the main point is that if Orcas will match VS 2003 in performance and usability it will already be huge victory for your team. Adding new features is probably not that important, especially considering the smashing work your compiler team did. If we can get that new compiler with robust and fast UI I am almost sure most of the native developers will be happy.

C++ .Net has very limited value to native developers, and .Net people mostly use c#, so you might be wasting your time on that. Interop enhancements are useful , but again if they stay where they are it is good enough.

P.S. Please change the behavior of  deprecated macro to _CRT_SECURE_NO_DEPRECATE – it is really insulting for native programmers to be forced to use sprintf_s instead of sprintf, considering

TJ - There is the feature called the "clipboard ring" that allows you to copy multiple items at a time and then paste.  In some profiles the key combination is Ctrl-Shift-V but you can bind it to whatever you would like.  Just keep holding down Ctrl-Shift and pressing V multiple times will cycle through your clipboard content until you find the item you want to paste.

problem

>>> 8. using forward slash in include dialogs pretty much disables look up directory functionality – it used to work in 2003.

>>> 9. Macro substitution dialog works 40% of the time (OutDir, TargetDir etc.)

Explain plz.

Hey, I really like the VS2005 IDE and have pushed for the last year at work for a switch from Borland-based apps to VS.  We're talking about it, so there's progress.

I think that Visual Studio is the best MS application available.

The MSDN help leaves something to be desired, though; it's difficult to navigate and it doesn't always keep my filter settings.  

Keep up the great work.  I haven't run into many problems with VS2005.  

allow functions from the program being debugged to run from the debugger auto-expand rules!

I need to port a bunch of VC6 projects to VS 2008.  Please make it "pain free".  

I would be happy when VC++ comes whith full functional GUI Designer like in C#. I have experience with C++ Builder from borland and now I have troubles with GUIs for native applications.

P.S.: MS Visual Studio is more  comfortable in use then C++ Builder

I would be happy when VC++ comes whith full functional GUI Designer like in C#. I have experience with C++ Builder from borland and now I have troubles with GUIs for native applications.

P.S.: MS Visual Studio is more  comfortable in use then C++ Builder

# re: Visual C++ Futures

Wednesday, January 02, 2008 12:41 AM by Gabriel Litsani

> WHAT ABOUT THE FUTUR OF VISUAL C++?

Thanks for your posting. Not sure I quite understand all your questions but if you want to understand the future of VC++ (and how it relates to some our managed technologies) then this is a good place to start: Steve Teixeira and Bill Dunlap: Visual C++ Today and Tomorrow (http://channel9.msdn.com/Showpost.aspx?postid=281987)

Thanks

Damien

To VeroMaxx

thank for paying attention to my complains

problem

>>>Explain plz.

>>> 8. using forward slash in include dialogs pretty much disables look up directory functionality – it used to work in 2003.

1. Select Project in the solution explorer

2. Properties->C/C++/General/Additional Include Directory

3. Click on editable part, button appears - press the button

4. type ..\.. - at this point of time drop-down shows all available subdirs in "..\.."

5. repeat with "../.." - nothing happens even though it is valid compiler syntax

>>> 9. Macro substitution dialog works 40% of the time (OutDir, TargetDir etc.)

This one is very annoying since it papers to work out if the box, but stops working from time to time

same as 8.

2. Librarian OR Linker/General/Output File

3. Select edit from drop down

4. press "Macros<<" button

5. At this point of time if you press Insert  it might or might not insert selected macro into output string.

It usually happens with big solutions (10-15 projects) –that is the only consistency about this item.

ASP.net support for C++/CLI

This is a must !! The lack of this ability is simply a major hindrance to C++ adoption on the new platform. Because the web front end is forced to be written in C#, often the rest of the tiers also get done in C#.

Any project type that is creatable in C# should be creatable in C++/CLI. Wether if it is the new game programming XNA projects, Silverlight or what have you. Thats the only way C++ can be a fist class in the .Net world.

Please innovate by adding a time-travelling (reverse) debugger.

Today, when I set a debug point or analyze a crash, I get at best:

1. The line (and instruction) at which execution stopped.

2. The call stack.

3. Registers and memory state of the process.

This is all great until you get into a situation where you are analyzing the state of your application (or crash dump) and start to wonder - "how did my program arrive at this point in the code?.  What was value of x,y,and z prior to this function getting called?"  It sure would be nice if I could debug in reverse to see what the state of the app that lead me to where the app stopped.

I realize the technical compexity of this feature request... but it sure would be awesome.

Please innovate by adding a time-travelling (reverse) debugger.

Today, when I set a debug point or analyze a crash, I get at best:

1. The line (and instruction) at which execution stopped.

2. The call stack.

3. Registers and memory state of the process.

This is all great until you get into a situation where you are analyzing the state of your application (or crash dump) and start to wonder - "how did my program arrive at this point in the code?.  What was value of x,y,and z prior to this function getting called?"  It sure would be nice if I could debug in reverse to see what the state of the app that lead me to where the app stopped.

I realize the technical compexity of this feature request... but it sure would be awesome.

When your end product is a DLL, you quite often need to test it with many different executables.  It would be very nice if there was a sticky list of the last 4-8 executables (and the associated arguments) on the "Command" and "Command Arguments" in the Debugging section of the project properties tab.

Quit trying to turn C++ into .Net.  Give us even better support for C++ standards.  Quit trying to one up the standards bodies with Microsoft's custom interpretation of how things should be.  Change C++ enough and native C++ programmers will eventually get fed up and leave forever. Eclipse is becoming a rather feature rich IDE with decent support for C++.  We're not always going to eat the dog food you feed us.

Rich

"...Quit trying to turn C++ into .Net. .."

John Selbie

"...Please innovate by adding a time-travelling..."

Could not said it better my self (no really - I could not, because my English is not that good :) ). But if I could I would have signed under both of the posts.

Please, keep in mind us poor programmers that need to type every letter with our own fingers ;)

C# is nice in that it is a bit easier to write, automatic code formatting is good, but still cannot match eclipse.

#1: I would like to see } on next line whenever I type {

#2: I would like to see "for (|;;) {\n}" whenever I type "for " and those ";" marked as "overwrite-me-if-typed" as eclipse does for quite a lot of things.

#3: "do {\n\t|\n} while ();" for "do " or "do\r".

#4: Change "ptr.field" to "ptr->filed", "class.method.." to "class::method", "nspace.class" to "nspace::class" if you can figure (IntelliSence) what is needed (...why is C++ defined like this? ...ahh yes, for easier parsing... poor programmer.)

#5: REFACTOR!!

#..: Just look at eclipse ;)

Integrate CCFinderX (or any such great tool) with your Refactor - Do you know about CCFinderX? If yes, try using it as the first step to show duplicated/cloned source-code pieces, and suggest to convert them into functions in Refactoring stage... Currently, Extract-Method in Refactoring is done manually... It can be converted to semi-automatic method better with CCFinderX.

How about a multithreaded compiler, or at the least the ability to have it run on multiple files at a time, kinda like the way make -j4 does.  Would be nice for large projects.  Incremental builds help, but on fresh checkouts from code repositories, the build time can just be so painfull!  

I'd like to be able to optionally exclude comments from the search feild while doing a search or a search/replace.

CamelCaseDetection :)

If I use ctrl to skip words, I want it to stop 3 at C then C, then D i nthe above example.

Other word detection:

CLSID_MYCLASS should stop at the C, then at M, not assume that whole thing is one word.  

More customizeable syntax highlighting!  I want to use VS for all sorts of other editing.  

Multithreaded compiling:  We have these 4 quad core machines out there, why can't we get all those 16 cores busy?  At the very least somethng similar to that of make -j4 in gnu's make utility would be nice.  Incremental compilation helps a lot, but when you first check out a large project from source control it can just be painful to wait for the initial build.  

hmmm it said it failed on yesterdays, so I posted again, only to see todays work just fine, then see yesterdays.  Odd....

I'd like to see a Selectable Undo:

Highlight a block of code.

Select Undo (or ctrl-z).

It starts undoing only changes made to that block of code.

Microsoft can certainly add a new dimension to their VS IDE by supporting "image/video" insertion. Just like Microsoft Word, the users should be able to insert any video clip, or image file into the source code file. That will greatly improve the code readability, and by allowing programmers to insert diagrams/program design sketch, the source code will become more comprehensive.

I believe this is certainly possible. =]

My opinion

- VC++ need the same poowerfull Intelisense like VC# have.

- Powerfull Class creator for native C++ code

- An option that permit rename functions and variables throught entire code with 1 click.

- And the same as othe people, faster compilation times, and more powerfull code optimitzations :)

Thanks for all.

LLORENS

- I'd like to know where linker dependencies are coming from.

- I'd like Visual Studio's Build option to be able to do parallel compilation like "make -j" since operating system and CPU architecture is making that significantly more efficient.

- I'd like to be able to have multiple precompiled headers per project.

- I'd like a way to have the editor insert the current tooltip/prototype, e.g. if I type:

 MemberFnName(

and the compiler hints

 MemberFnName(int numRounds, const char* itemName, const Window* outputWindow)

I can insert the proto and/or insert the typeless proto

 MemberFnName(numRounds, itemName, outputWindow)

If you're good about naming consistency this could be a huge help.

- I'd like a way to "Go to definition" and have the editor remember the file AND line I jumped from. Consider:

file1.cpp line 250 -> file1.cpp line 42 -> file3.h line 50 -> file3.cpp line 99 -> file1.cpp line 300 -> file3.cpp line 28

With the VS editor I can shift-tab back to the previous file but if I am following code, I've lost my track. (So as a result, I do my code analysis in vi)

Hello

RS: Saturday, January 26, 2008 9:12 AM by LLorens Marti

Given your priority list, you may find this recent channel 9 video by Arjun of great interest: http://channel9.msdn.com/showpost.aspx?postid=376182

Arjun covers our work on the new Intellisense functionality and mentions a number of items in your list.

Thanks

Damien

VC++

One thing that's driven me nuts for a couple of versions is the the Wizard bar; at least, I think that's what it's called -- the bar  that has one dropdown that shows namespaces and another that shows methods & functions within the selected namespace.

It used to work nearly flawlessly for me, but I suspect it stopped working right when I started working with a codebase that had multiple namespaces & nested namespaces. I'll open a file that contains something like the following:

------------------------

#include "foo.h"

namespace foo {

   void someFunction();

}

------------------------

The wizard bar, unfortunately, won't list anything though. It lists all the namespaces in the solution it can see, and it will denote that the current file only actually has code from one of those namespaces, but it won't default to that namespace :P Which means the function listing is never populated, and therefore I can never use the functionality.

Any chance that widget could start figuring out that if all the code in a file is inside a single namespace that it should probably default to that namespace?

Here's a suggestion.

For God's sake optimize the IDE. It's painfully slow. Help also takes forever to load. I'm on an Athlon 64 X2 3800+; there's NO excuse for the IDE being slow as hell. Visual C++ 6 is far more responsive, and I'd use it instead if it supported standards better.

Next thing. Make the core runtime libraries smaller, and move less-used functionality to an auxiliary library. I always compile as "Multithreaded DLL" as my game has many, *many* libraries, and there's no reason the runtime should be adding a megabyte to my download.

To sum it up: Make the IDE faster. A lot faster - you should be ashamed of yourselves how slow it is. Make the runtime less bloated. Oh, and speed up your STL implementation.

Forgot one thing. When I'm trying to type something and IntelliSense doesn't understand it, it shouldn't mangle what I'm entering.

Oh, also, speed up the compiler. It's slow. :P

James Bellinger,

We made a number of performance improvements in the IDE in VS2008, and have more planned for the future.  If you're seeing performance issues that we didn't adequately address in VS2008, then please e-mail me with details (DevPerf@Microsoft.com) or file a connect bug with details.

Thanks,

David Berg

Developer Division, Performance Engineering Team

You have been heard - see my great news about the plan to improve your help experience in Visual Studio and MSDN!

http://blogs.msdn.com/aprilr/archive/2008/01/28/help-is-getting-help-the-long-overdue-makeover-for-visual-studio-and-msdn-help.aspx

- AprilR

Many of these comments relate to individual programmer and task productivity; instead, we would like to see more focus on project level productivity.  

Much of this clearly depends on what VC is being used for.  We use it for developing rich clients and server extensions.  So, for us, many of these issues around writing code would be moot if we could avoid writing code in the first place.  

So, we would like to see extensions (primarily to MFC and ATL) which allow us to develop richer interfaces with less code.  For example, I noticed a forum post asking writing code to save a dialog position between sessions.  Rather than making this code easier to write (through clipboards, intellisense, autocompletion, etc.), it would be preferable to include written code (through attributes?) to do this.  That way we are not writing and testing code, but are able to deliver the functionality within our product.

So much of MFC/ATL seems like it hasn't progressed from a thin wrapper around the Windows API when it could be much more.

I spend all day using Visual Studio to create and edit VB script files with the VBS file extension, and pseudo C source files with a BDS or BDF file extension.

I have added these file extensions so that my source code is formatted correct as VB for those with the VBS extension and C/C++ for those with the BDS or BDF extensions.

However, whenever I want to open a file, or add files to a folder in the project explorer as a means of organisation and quick reference, I have to scroll down through the file types pop-down  to select All Files before the files with my file extensions are displayed and can be selected, which is a regular pain.

I would like to be able to add my own group of file extensions to the list of recognised groups of file extensions in the File Open and Add Existing Item dialogs, for example,  *.VBS;*.BDS;*.BDF. I would then like to be able to customise the order of these file extension groups so that my preferred grouping is at the top of the list and is the default one used by the File Open and Add Existing Item dialogs.

This would mean that whenever I go to open a file or add files to a folder in the Project Explorer, I would immediataely see the files I want to use, and life for me would be so much easier.

Thanks in anticipation of a favourable outcome to this request in due course.

I'd certainly like more support for useful technologies (such as LINQ) added to C++ .   It always seems to be left behind C# and VB.NET in these matters (similarly, example and help short-change C++ as well).

I started to play with LINQ and decided it will be very useful - but I had to play in C# - and resent it.  I feel like I'm being herded by 'your' grand designs into what programming should be and how it should be done.  While your at it, get that LINQ group to finish up that ODBC access.  There's a lot of legecy everything out there.

A small aside:  VS2008 should have also supported .NET 1.1.  From what I can gather, most users still are there.  Updating nearly 400 systems is not a prospect anyone is looking forward to.  If they do, it may go differently than MS had hoped:

Let me give you a simple (and true) visualization:  I can look outside my office and see the system management area - and a monitor with a single word spread across it: UBUNTU !   That would have been unthinkable just a year ago.

Admittedly, this seems to be a reaction to VISTA as much as anything else, but there are options.  Possibilites, such as LINQ and interoperability with Excel, Word, etc., are a draw - but only if they are available.

Stop treating C++ as an also-ran technology.  That's really the ultimate bottom line of it all.

I'd certainly like more support for useful technologies (such as LINQ) added to C++ .   It always seems to be left behind C# and VB.NET in these matters (similarly, example and help short-change C++ as well).

I started to play with LINQ and decided it will be very useful - but I had to play in C# - and resent it.  I feel like I'm being herded by 'your' grand designs into what programming should be and how it should be done.  While your at it, get that LINQ group to finish up that ODBC access.  There's a lot of legecy everything out there.

A small aside:  VS2008 should have also supported .NET 1.1.  From what I can gather, most users still are there.  Updating nearly 400 systems is not a prospect anyone is looking forward to.  If they do, it may go differently than MS had hoped:

Let me give you a simple (and true) visualization:  I can look outside my office and see the system management area - and a monitor with a single word spread across it: UBUNTU !   That would have been unthinkable just a year ago.

Admittedly, this seems to be a reaction to VISTA as much as anything else, but there are options.  Possibilites, such as LINQ and interoperability with Excel, Word, etc., are a draw - but only if they are available.

Stop treating C++ as an also-ran technology.  That's really the ultimate bottom line of it all.

F1 Help is shocking in VS2005.  Spent an hour figuring out I can't do things by just using the keyboard.  Rubbish, slow and in accessable to the keyboard powerusers.