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."
Permalink for comment 485032
To read all comments associated with this story, please click here.
RE[5]: Yet another standard...
by dpJudas on Mon 15th Aug 2011 09:20 UTC in reply to "RE[4]: Yet another standard..."
Member since:

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