Linked by David Adams on Sun 14th Aug 2011 22:41 UTC, submitted by subterrific
General Development The final ISO ballot on C++0x closed on Wednesday, and we just received the results: Unanimous approval. The next revision of C++ that we've been calling "C++0x" is now an International Standard! Geneva will take several months to publish it, but we hope it will be published well within the year, and then we'll be able to call it "C++11."
Thread beginning with comment 485011
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Yet another standard...
by sukru on Mon 15th Aug 2011 07:06 UTC in reply to "Yet another standard..."
sukru
Member since:
2006-11-19

You should do some research, before bashing Visual C++ blindly. While they are not the best, they are actually in top-3 in C++0x standards compliance:

http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport

And do not forget that Herb Sutter (lead software architect in Visual C++ group) used to be the head of the ISO C++ standards committee for many many years. He has done significant work to change the culture in the company.

Edited 2011-08-15 07:07 UTC

Reply Parent Score: 2

RE[2]: Yet another standard...
by gilboa on Mon 15th Aug 2011 07:40 in reply to "RE: Yet another standard..."
gilboa Member since:
2005-07-06

You should do some research, before bashing Visual C++ blindly. While they are not the best, they are actually in top-3 in C++0x standards compliance:

http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport

And do not forget that Herb Sutter (lead software architect in Visual C++ group) used to be the head of the ISO C++ standards committee for many many years. He has done significant work to change the culture in the company.


Wow... so many assumptions in such a short post.
I'm not bashing VS because I enjoy bashing MS (even though its fun) - I am bashing VS because 20% of my cross platform development time is spent on getting C and CPP code ported through the abomination that you call VS.
E.g.
A. Microsoft decided, for no good reason not to support in-line assembly in x86_64 (even though its has been supported in 16 and 32bit since MSDEV 1.5 in the mid 90's!) forcing anyone that relays on in-line assembly to jump through hoops to get the in-line assembly compiled and linked. (I'm mixing mingw and VS, thank you very much)
B. Lack-luster pre-processor that makes writing complex macros more-or-less impossible. (vargs? return value? Pffff!)
C. Try this for size (pun intended):
short s_number1 = 1;
short s_number2 = 2;
s_number1 += s_number2;
D. nmake. nuff said.
E. Safe C runtime "extensions" (Do I hear EEE)?

Now, they may decided to support the latest Cxx standard without EEE it, but in the end, using VS for anything outside C# will mostly generate grossly non-portable code.

- Gilboa

Reply Parent Score: 7

moondevil Member since:
2005-07-08


A. Microsoft decided, for no good reason not to support in-line assembly in x86_64 (even though its has been supported in 16 and 32bit since MSDEV 1.5 in the mid 90's!) forcing anyone that relays on in-line assembly to jump through hoops to get the in-line assembly compiled and linked. (I'm mixing mingw and VS, thank you very much)


The place of assembly code is in .s/.asm files.

Regarding the other complaints you will find similar issues with other compiler vendors.

Reply Parent Score: 3

RE[3]: Yet another standard...
by dpJudas on Mon 15th Aug 2011 08:23 in reply to "RE[2]: Yet another standard..."
dpJudas Member since:
2009-12-10

If you are spending 20% of your cross platform development time on VS you're clearly doing something wrong. As the main author on a cross platform game SDK (clanlib.org) I've personally had the experience with cross platform coding between Windows, Linux and Mac. And I do not use 20% of my time getting code to work between the platforms.

A. Microsoft removed in-line assembly because they want you to use compiler intrinsics instead. They have several advantages over custom written assembly such as allowing the compiler to actually optimize your assembly. And the best part is that even though these intrinsics aren't part of the C++ standard, most of them are part of an Intel standard that all the different compilers support. Truly write once use everywhere (for the x86 platform). So why are you using hand-written assembly again?

B. I don't use vargs or much complex macros, so I really wouldn't know. However if you are trying to write something cross platform its rather stupid to insist doing things you can't do cross platform, isn't it? Maybe you should reconsider your coding style to be more compatible with multiple compilers.

C. Not sure what you are trying to say here.

D. Why are you using nmake? Self torture? Nobody uses nmake. Maybe you should try something like CMake if you want to only use one build system for all your platforms? Or if you insist on using a MS technology try maybe a normal vcxproj or perhaps even msbuild!

E. I assume you are referring to the strcpy extensions and so on. First of all, WHY would a C++ developer even use these functions? Self torture again? Secondly, you don't HAVE to use the extensions if you don't want to (hint: a simple define will disable the warnings it issues about using the unsafe versions). Thirdly, there's a very good reason why Microsoft want you to stop using them. They were the primary source of buffer overruns in their own software.

Just because you don't know how to write portable C++ code doesn't mean it is the fault of Visual C++. Most of the things you complained about isn't even part of any C++ standard (i.e. assembly and nmake).

I agree a nice cross platform build system would be nice, but so far I like the MS solution system a lot better than any unix alternative I've seen (make, automake, qmake, cmake). But 20% of your time? To add the .cpp files to a makefile? That's just trolling.

Reply Parent Score: 4

RE[3]: Yet another standard...
by f0dder on Mon 15th Aug 2011 21:13 in reply to "RE[2]: Yet another standard..."
f0dder Member since:
2009-08-05

A. Microsoft decided, for no good reason not to support in-line assembly in x86_64 (even though its has been supported in 16 and 32bit since MSDEV 1.5 in the mid 90's!) forcing anyone that relays on in-line assembly to jump through hoops to get the in-line assembly compiled and linked. (I'm mixing mingw and VS, thank you very much)
I personally find inline assembly to be bothersome. Why use inline assembly when you can write a module in external assembly with a cross-platform assembler (yasm,fasm,nasm,whatever) that can then be used with your compiler of choice? If you're doing little enough assembly that an external module seems like too much work, then you should probably be using intrinsics instead.

B. Lack-luster pre-processor that makes writing complex macros more-or-less impossible. (vargs? return value? Pffff!)
I personally prefer using the preprocessor as little as possible - there's often a better solution. Inline template functions have less nasty surprises and are easier to debug, and if you're doing large amounts of complex preprocessing you might be better off using a code generator instead? Hard to tell without knowing your use cases, though ;)

C. Try this for size (pun intended):
short s_number1 = 1;
short s_number2 = 2;
s_number1 += s_number2;
Try it and... what? Buggy code generation, warnings, sloppy code, what? And which compiler versions(s)? For VS2010, there's nothign weird.

D. nmake. nuff said.
Why, when there's msbuild? Alternatively, cmake or scons. I wouldn't write makefiles in GNU make either. Autoconf/make is a big barrel of yuck - unless you need to support really broken platforms, just write portable code ;)

E. Safe C runtime "extensions" (Do I hear EEE)?
It's been submitted as a standard, but you almost have a point - I haven't found a non-MS implementation of it. Haven't looked hard, though, since I stay away from the yucky C strings as much as possible.

but in the end, using VS for anything outside C# will mostly generate grossly non-portable code.
How so? Nobody forces you to use strsafe. And if you look at *u*x source, there's a fair amount of it using proprietary GCC extensions ;)

Reply Parent Score: 1

RE[2]: Yet another standard...
by ebasconp on Mon 15th Aug 2011 22:50 in reply to "RE: Yet another standard..."
ebasconp Member since:
2006-05-09

Actually, Herb Sutter is promoting a C++ renaissance inside MS:

http://herbsutter.com/2011/07/28/c-renaissance-the-going-native-cha...

Reply Parent Score: 4