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 485023
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Yet another standard...
by dpJudas on Mon 15th Aug 2011 08:23 UTC 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[5]: Yet another standard...
by grendel on Mon 15th Aug 2011 09:19 in reply to "RE[4]: Yet another standard..."
grendel Member since:
2011-08-15

"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*.

You seem to be quite bitter in general - this kind of attitude doesn't help to get your point across, even though you might be right at points.

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.

Then you should *really* consider moving that code outside the compiler's control, shouldn't you? Also, how really cross-platform code with inline assembly is? Sure, you can use the preprocessor macros to shoe in inline assembly for a dozen of CPUs, but why?

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

Then this is a matter of taste, not really superiority/inferiority of this or that compiler, isn't it? And de gustibus non disputandum est...

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.

It's considered good mannered not to comment on things you don't use or know - doing that will gain you more ears than bitching.

"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?

And there we go again - why offend somebody who writes without bad intent? What is your point here? That *YOU* know what EEE is? Everybody's clapping hands, granted.

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

Personally, I see it quite the opposite. We know what he does (clanlib is out there, you can look at it) and we don't know at all your code so, for what we can see, he's the person with some credentials and title to write about cross-platform C++ while you, kind sir, are not. Show us the code and let's keep discussing.

- Gilboa [/q]

Edited 2011-08-15 09:27 UTC

Reply Parent Score: 1

RE[5]: Yet another standard...
by dpJudas on Mon 15th Aug 2011 09:20 in reply to "RE[4]: Yet another standard..."
dpJudas Member since:
2009-12-10

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.


Oh I see. And you haven't heard about the memory barrier intrinsic either that guarantees just this. And why is it so dangerous for the compiler to improve your code? You want it to run as slow as possible?

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


So you write cross compiler code, except that you use one specific feature not supported by all compilers. Which makes it not cross compiler code after all.

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.


The build system is not part of C++. So it says absolutely nothing about their commitment. But if you like GNU make so much (not that I understand why), why don't you just compile your program with GNU make?

Because all the "normal" functions are marked as-soon-to-be-deprecated?


So the message scares you. And the scary message takes 20% of your time. I'm shaking in my boots!

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?


I do not use any of these C functions. I code in C++ with the C++ features such as string classes which ensures I don't do buffer overruns of this type. So yes, I haven't heard about EEE, which I assume is some solution to a C developers problem which does not apply to me. The only reason I know about this warning at all is because I compile C dependency libraries once in a while.

Not that its particular relevant since it can't be from this warning message you spend 20% of your development time..

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.


Takes one to know one?

But here's some more I know best attitude for you: If I can target 4 platforms (Windows, Linux, Mac and iOS) using 3 different compilers (MSVC, GCC, LLVM) doing high performance multi-core software rendering and only spend a fraction of my time on differences between the compilers, then what am I doing right that you are doing wrong?

Reply Parent Score: 1

moondevil Member since:
2005-07-08

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?


It is so incompatible that is part of the C standard process, ISO/IEC WDTR 24731, TR 24731-1.

http://www.open-std.org/jtc1/sc22/wg14/www/projects#24731

And was actually contributed to ISO by Microsoft.

Reply Parent Score: 2