As we wrap up Visual Studio 2010, we are starting to plan the next release of Visual C++. Our goal is to make Visual C++ a product that meets your needs. Thus we need your help.
We would like to better understand what you do. Please take a few minutes and answer the survey below. The survey is totally anonymous and the data that you provide will help us build a better product for you.
Visual C++ Team
I would like c99 support for C
We (http://www.petitiononline.com/mod_perl/signed.cgi?SWE4DKTP) would like to have the C++ version of Silverlight (present on Windows Embedded CE 6) also for the desktop.
MFC is so 1990's.
I wish that a virtual pc can move under Internet Explorer 10 for c++ native apps.
the virtual pc provide a MiniWin with:
1 C runtime;
2 virtual memory space;
3 virtual disk;
4 a simple gui/graphics interface;
5 simple process/thread,and other kernel object;
6 interactive message with other common web page;
7 a good sandbox for security;
8 a law for auto downloading C++ complied bins to sanbox to run;
I would like that very advanced GUI elements that are layed over windows low level graphic API (currently directx) be maked. These elements must be as neer as to underying layer and as easy to users as possible.
This requirment from performance point of view is also important for microsoft database tecnology SQL Server, microsoft can create a library of API's that dirctly calls DBMS's API's.
My biggest pain ? That visual studio, after almost 10 years (from .Net), still needs extensions to be usable.
Seriously, it is done on purpose ?
VS2005 not to crash when I press F8 on a link error.
"When calling methods, do you prefer using pointer syntax or value syntax?"
This question doesn't make sense at all.
Thanks for the survey!
(no criticism today)
(( well, ok, the choices for "how much time do you spend on" were strange, only one option between "not at all" and "50%"?))
(((Sorry. Thanks for the survey. Really.)))
The main thing I feel is that you've lost the aim.
You said VC++ 2010 was going to be the new "Visual C++ 6" (because you knew how we loved it back in the day!)
Thus I was expecting, the power of Visual C++ 2008 with the responsiveness, performance and focus that Visual C++ 6 had.
In the end, this feels like a EVEN slower version of the bloated mess that Visual C++ 2005 was, with yet more obscure features that I rather suspect will lie unused by most of us.
Are the _majority_ of C++ programmers going to be using the lambda stuff? Is that what they've been waiting for?!? Somehow I doubt it.
-- C99 support in C/C++ native code compilers
-- pervasive && painless UTF-8 support in C/C++ standard libraries
-- external code generators considered first-class citizens (i.e. cl) in all ways
-- allow native debugger visualizers to call code in the debuggee (ala the WinDbg command)
mixed-mode debugging on x64 would be HUGE.
More of C++0x
More responsive UI.
Fixing reported bugs and other things that neer get fixed but instead are buried for the sake of some obscure thing some company no one else cares about wants.
And not just fix a few things then call it a SP, never to return again. If that thing you call VS is so fragile that you are afraid to fix things, you are in for a world of hurt around the next turn.
Can't make a 64-bit version of it? Muhahahaha. Just goes to show you are in a world of hurt.
Edit & Continue for x64 debugging
@Mike: I certainly hope most C++ programmers will use lambdas. That's what they're for. And I don't see how striving for standards compliance can be considered "losing the aim". I agree that a lot of other things in VC10 turned out less impressive/ambitious/nice than the impression we were given a year ago, but those are more IDE issues. The compiler is in pretty good shape, and trying to keep up with the standard is only a good thing.
Enhanced C99 support. Some parts of C99 (esp. library support) could be added so easily that I can't believe they still aren't there. Other parts would certainly require more work, and I can understand a dealy, but it's been 10 years! I can understand the hesitation to mess with the front end for things like complex, tgmath, and struct initialization, but _Bool? inline? Why can't we get those? (restrict might have a conflict with __declspec(restrict), but there are workarounds that aren't too painful.)
- complex.h: Ok, I admit that this one would require a lot of work. It'd be nice to have, though.
- fenv.h: Nearly all of the library support is already present in the CRT under a different name, so this could again be done mostly in a header (perhaps with inline calls to existing library functions). #pragma STDC requires front-end support, but I think all of the STDC pragmas map onto existing pragmas. Again, just a header update would get VC 90% there.
- inttypes.h: Add support for an hh or i8 precision for integers in printf/scanf, then it should be no problem. In the meantime, even without a library change, you can do an inttypes.h that doesn't define PRI_8 and SCN_8, and again get 90% there with just a header.
math.h: Same as fenv.h. Just expose the existing CRT's functionality with the C99 standard names and you'll make 90% of the people happy.
- stdarg.h: Add a va_copy macro. It's easy.
- stdbool.h: Real support requires adding the _Bool type to the C front end, but you can get 90% there with just a header that defines _Bool as an unsigned __int8 or unsigned char.
- tgmath.h: Again, understandable since it would take a fair bit of work. But the intrinsic support is already there, so it seems like it wouldn't be too hard to define a bunch of __tgmath_NAME intrinsics that do the right thing, would it?
- Other misc. missing functions -- just add them. Even if they're not 100% optimized.