Like many developers we maintain and develop an extremely large enterprise MFC application. All in all about 1.5 million lines. Asides from the addition of ribbons and a few extra controls we have had very little improvements in how we can work with MFC or native Win32 apps (in fact, the speed has gone down and classwizard seems to have gone from bad to worse to gone). Can you consider:

1. Improving the Dialog editor so that we can lay out dialogs with guides and the extra alignment options that are standard with C# - automatically spacing items correctly and so on.
2. Introduce a standardised feature for resizable dialogs, somewhat akin to C#'s docking or attaching.
3. Please, please, please allow us to work on the tabs of a tab control directly. Tab controls are a real pain to work with.
4. Change the class wizard so that a dialog header file doesn't contain its resource ID in the header. Having '#include "resource.h"' in the header of every class is a pain and causes numerous conflicts in applications that have many dialogs.

Essentially I'm asking to have the MFC functionality brought up to line with what we have in Windows Forms. Developers who are still using MFC are almost certainly like us in that they are using it because they have a large enterprise solution to maintain. Such developers are professionals using Visual Studio to build big, serious, expensive applications. Whilst improvements in C#, WinForms, WPF, SL and so on are great, MFC has been woefully neglected for years.

The C++ project properties dialog is a pain to work with. Just try to enter a set of preprocessor defines for a serious project.

This has been vehemently complained about by users as long as I'm working with VC (1999), and you haven't managed to flip the resizable switch on it. Yet, in the same decade, you have found the resources to create a bunch of whole new languages and a VM to run them in, put a form designer into the IDE, spend incredible amounts of man years on the compiler used for Intellisense...

At least since VC7, that dialog contains nothing but property grids and (read-only) edit fields. Really, how hard can it be to make that resizable?

Particularly in the world of C++, where the delta between what the compiler accepts and what the standard says is quite large, it is common for people to report bugs against the compiler.

Often, however, these are met with refusals to fix the compiler, and claims that there are workarounds.

I would love you to change this policy.

Yes, sometimes there is a zero cost workaround to a particular flaw. But that's not a reason to not fix the bug. I write code that I wish to compile in g++, VC++, and sometimes even clang++. Being forced to avoid standard constructs just because they provoke a VC++ bug is aggravating in the extreme.

Please stop treating workarounds as if they were good enough. We want to be able to use the best possible C++ compiler.

Now that WinRT has been unveiled, a lot of people have criticized the C++/CLI-like quasi-C++ that is the recommended way to interface with the API. And honestly, it looks reasonably nice. If we're willing to give up all hopes of using another compiler than VC11, and don't mind non-standard code in our C++ application, it seem a nice way to interface with WinRT.

But how about an alternative?

How about offering a "best effort" library-only ISO C++ wrapper to make WinRT usage as simple as possible without relying on library extensions? It doesn't have to be as clean and pretty as the language extensions, but it could be a lot prettier than the raw COM interface.

Right now, we have the choice between the (basically undocumented) underlying COM, or the nonconformant language extensions. Both options obviously have their uses, but I'd love to see an intermediate layer: something that makes WinRT as easy as possible to use from ISO C++.

Please?

In VS2010 and subsequently in VS2010sp1, many features of C++11 was implemented. But it is still far from covering the full spec. And we can assume that the full spec will not be available even in VS2011(or v.next). Because, MS is polling developers for prioritizing certain features of C++11. May it will take some time to have a fully supported C++11 with VS. And that is true for almost all the C++ implementations. And probably, the C++ compiler supplied with VS v.next will not be usable with VS2010.

We can see, C++ compiler releases(full version or service packs) are coupled with VS releases. So, it becomes cumbersome and sometimes impossible to use later versions of C++ compilers with earlier versions of VS. So, I suggest decoupling these two releases. So, that developers can enjoy latest implementations of C++ without further hassles of upgrading VS, sp or full release.

Every few years this suggestion emerges and I think now is the time for next iteration.
In C++ the order of class/struct member initialization is determined by the order of member declaration and not by the order of their appearance in member initialization list. It is therefore extremely easy to to write a code that is very hard to find, e.g.:

struct S {
int a;
int b;

S( int i ) : b(i), a(b+1) {}
};

int main()
{
S s(42);
}

and we have garbage in s.a what might be not obvious for a novice programmer.
GCC issues a warning here:

f:\>g++ -Wall test.cpp
test.cpp: In constructor 'S::S(int)':
test.cpp:3:8: warning: 'S::b' will be initialized after
test.cpp:2:8: warning: 'int S::a'
test.cpp:5:4: warning: when initialized here

But Microsoft compiler doesn't spot any problems:

f:\>cl /Wall test.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

test.cpp
Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.

/out:test.exe
test.obj

Please. Add at least level 4 warning for this.

Among the most challenging problems in a financial system is dealing with numeric precision.

Take this example for instance (using the double data type in C++):
We have a number 4.3599999999999994 which we withdraw the same negative number from (4.3599999999999977), we would then end up with the number 1.7763568394002505e-015. Hence, if we were testing if the number added up to 0, we would get "False", or "True" if we were testing if the number was greater than "0".

This could easily get the system into an unwanted "IF" statement,
and tracking down these unwanted "IF" statements can be difficult.

Since C++ is used in many financial systems where accurate numeric precision is required, it seems reasonable to add "decimal" support to the standard C++ library.