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 485014
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Yet another standard...
by gilboa on Mon 15th Aug 2011 07:40 UTC 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[4]: Yet another standard...
by gilboa on Mon 15th Aug 2011 08:06 in reply to "RE[3]: Yet another standard..."
gilboa Member since:
2005-07-06

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

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


You got to be kidding. Have you actually read your own comment before pressing "Submit"?
If the place for in-line assembly is .asm/.s files (says who exactly?), why do ***ALL*** major compilers, including visual C itself, support in-line assembly, outside that is, Visual Studio 64bit (2K5/8/10)?

As for the rest of my comments, nice going! instead of answering them point to point you simply waved, mumbled something about "everybody does that" and continued. You *really* showed me!

- Gilboa

Edited 2011-08-15 08:08 UTC

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[4]: Yet another standard...
by gilboa on Mon 15th Aug 2011 08:50 in reply to "RE[3]: Yet another standard..."
gilboa Member since:
2005-07-06

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.


My original intent was 20% of the *porting* time and not development time. Miss-wording on my end.
Now before you start spewing the normal "why not use autobuild/automake/cmake" bullshit, keep in mind that you *don't* know what I do and why.

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?


I hate when people assume that they know best about problems other people are facing.... *Sigh*.
I do *not* *want* the compiler to optimize my *assembly* code. I relay on specific code order to ensure memory barriers and the last thing I could possibly want is to have the compiler mocking around with my code.

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.


Re-read my previous post. I do write cross compiler code (read code that's compatible with the brain dead VS pre-processor)... I simply do not like it (E.g. using inline functions instead of macros due to VS's lack of macro-return-value support).

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


Try it with -w4.

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!


No, I'm not using nmake. I'm using GNU make.
... But to me (feel free to disagree), the lack of good make alternative is a good show-sign as for MS "commitment" for C/Cxx.

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?


Because all the "normal" functions are marked as-soon-to-be-deprecated?
E.g. "http://msdn.microsoft.com/en-us/library/2029ea5f(v=VS.100).aspx"

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).


See above.

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.


Sure. they only want whats best for us.
Why use standard size-secure functions that are supported by world+dog when you can invent a completely incompatible C-runtime.
I assume that this is the first time you hear about EEE, right?

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).


Hey boy, drop the I know best attitude.
Making such bold claims without knowing who I am and what I do for a living (and for how many years) may make you look like a complete condescending asshole.

- Gilboa

Edited 2011-08-15 09:07 UTC

Reply Parent Score: 5

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[4]: Yet another standard...
by gilboa on Tue 16th Aug 2011 12:06 in reply to "RE[3]: Yet another standard..."
gilboa Member since:
2005-07-06

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


As I said in another post in this (far-too-long) thread using inline assembly functions and/or macros is far easier both for me and my downstream users, as they are only forced to use an H header file and they are done - No matter what build environment and/or compiler they are using.
Plus, at least to me (and this is purely a personal preference) in-line asm to C interaction is far easier to debug compared to using full blown ASM compilers such as nasm. (No need to mock around with db / sections / parameter passing, compiler constraints are glued to the code, etc).

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 ;)


Macros are harder to debug, no doubt about it, but offer far better flexibility when it comes to accessing the caller function local parameters and symbols. Plus, and this is purely personal experience, I found that in some cases, the compiler optimizer manages to chew out better code when dealing with macros - mostly when it comes to loop unrolling and dead code removal. (Come to think about it, the best example inline assembly within inline functions compared to macros)

Try it and... what? Buggy code generation, warnings, sloppy code, what? And which compiler versions(s)? For VS2010, there's nothign weird.


I've yet to test under VS 2K10, but under 2K3/2K5/2K8 this generated *mounds* of warning due compiler error.
Having to replace 500 lines of A<+-/*>=Z with A=A<+-/*>Z just because MS refuse(d) to fix a bug is very annoying.
Though, as you suggest, I might be nit-picking. (I actually faced this problem a couple of weeks ago so the pain is fairly recent...)

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 ;)


Assume that you have a good build system that works (written around GNU make and to some extent, nmake) that uses a (very) thin client-side Makefiles.
Using msbuild requires complete rewrite of the Windows side and the configuration files are anything but portable. Option deleted.
Switching to cmake will require a complete rewrite of both configuration files and build system, and cmake integration with kbuild is anything but clean (call it personal preference), especially if the same project is designed to run in both kernel mode and user mode.

... In the end, I forced a decision to use GNU make in Windows, but my life would have been far easier if MS would have simply decided to release a working make.
Plus, when you are forced to use native tools only (sometime I faced in the past) - having to choose between msbuild and nmake is like choosing between death by stabbing vs. death by hanging. You may suffer less (or more) but the results will be the same...

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.


It was pointed out in another post, I wasn't aware of the accepted ISO.

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 ;)


Microsoft has a very annoying tendency to make CRT code non-portable.
E.g. WSAStartup, closesocket, begin/endthread, _<function>, printf types (unicode, 64bit, etc), 64bit int instead of long, etc.

Sure, one should use native CreateThread/WSAFunction/etc, but unless you know in advance that MS CRT code is **not** portable, and use an OS abstraction layer (my_thread_create -> pthread_create/CreateThread, my_socket_close, etc) and abstract types (__i32, __q64, etc) you are royally f***ked.

YMMV, but the past couple of years I ported a number of Windows only projects that fall right into this trap. (My favorite being 64bit int and socket functions, of-course).

- Gilboa

Edited 2011-08-16 12:14 UTC

Reply Parent Score: 2