Indeed, it seems that MS is pushing as hard as they can to phase out languages that compile directly to machine code, and in stead would prefer everybody write in Managed Code (witness Longhorn).
daerid | Legends | Garage Games | Spirit | Hapy | Boost | Python | Google
"Doomed to crumble, unless we grow, and strengthen our communication" - Maynard James Keenan, Tool
Does Visual C++ .NET implement C99, more specifically does this compile in VC.NET?
They(MS) say there isn''t much of a demand for C99. Maybe they''re right?
--
AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.
[Project site] [Blog] [RSS] [Browse the source] [IRC channel]
--
AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.
[Project site] [Blog] [RSS] [Browse the source] [IRC channel]
Since they''re working quite hard on making their C++ compiler better than ever I''m not convinced that they want to phase out all such languages.
Author
I saw something on the 'net that is apparently directly from whoever is in charge of MS Visual C++ and they do intend to implement C99 as fully as possible, they just don't have it on the market yet.
I think there is enough demand that they should be willing to do it. Being incompatible with the rest of the world's compilers isn't to MS's advantage. It isn't MS's style to not support something if it doesn't mean a gain in market share. Their style is to embrace and extend everything they are allowed to as long as it makes them money, lol. I just wish they wouldn't be such slugs about implementing C99 in their compiler because it IS their style to force me to wait and buy a totally new version of their software in order to get the feature rather than to give me a service pack that lets my existing software have the feature.
Fortunately, I think I have come up with an acceptable if not optimal solution.
Newfound Ajarn: I would look at your link but it no worky.
[edited by - Igilima on January 8, 2004 5:03:03 PM]
I think there is enough demand that they should be willing to do it. Being incompatible with the rest of the world's compilers isn't to MS's advantage. It isn't MS's style to not support something if it doesn't mean a gain in market share. Their style is to embrace and extend everything they are allowed to as long as it makes them money, lol. I just wish they wouldn't be such slugs about implementing C99 in their compiler because it IS their style to force me to wait and buy a totally new version of their software in order to get the feature rather than to give me a service pack that lets my existing software have the feature.
Fortunately, I think I have come up with an acceptable if not optimal solution.
Newfound Ajarn: I would look at your link but it no worky.
[edited by - Igilima on January 8, 2004 5:03:03 PM]
I don''t see C99 gaining them market share. The number of people who want it are just too few.
quote:Original post by Magmai Kai Holmlor
Right, if you can/are willing to to C99, why not just use C++?
restrict pointers. With restrict pointers there is a class of optimizations available that are unavailable to plain pointers because of aliasing issues. For certain classes of numerical algorithms this makes C99 preferable over standard C++.
Also __STD_IEC_559 offers cross platform consistency guarantees that you can''t get with standard C++.
And FAMs are a nice syntactic addition that are inconsistent with C++''s type system.
quote:Original post by SiCrane
restrict pointers. With restrict pointers there is a class of optimizations available that are unavailable to plain pointers because of aliasing issues. For certain classes of numerical algorithms this makes C99 preferable over standard C++.
Not compelling to VC++ users because they can control aliasing assumptions already, albeit in a non-standard way. restrict also has some issues.
quote:Also __STD_IEC_559 offers cross platform consistency guarantees that you can''t get with standard C++.
Again, of negligible importance the majority of VC++ users.
quote:And FAMs are a nice syntactic addition that are inconsistent with C++''s type system.
Already supported as a non-standard extension, so not a compelling upgrade for the VC++ user.
C99 does have some nice bits and pieces; the POD literals and new initializers I like, for instance. But it''s also got a lot of shit -- the complex numbers, the type generic maths (truly abominable), "long long" -- and some rather dubious things such as the array parameter qualifiers and VLAs
It simply does not represent a compelling standard for VC++ users.
quote:Original post by DrPizza
Not compelling to VC++ users because they can control aliasing assumptions already, albeit in a non-standard way. restrict also has some issues.
#pragma optimize("a") applies to compiled code, it doesn''t affect function signatures, which means certain program correctness checks can''t be done. Moreover, you can''t mix potentially aliased and known non-aliased pointers in the same code block without disabling the aliasing pragma.
quote:quote:Also __STD_IEC_559 offers cross platform consistency guarantees that you can''t get with standard C++.
Again, of negligible importance the majority of VC++ users.
I work in numerical simulations for medical devices. Floating point consistency across platforms is *very* important to me.
quote:#pragma optimize("a") applies to compiled code, it doesn''t affect function signatures, which means certain program correctness checks can''t be done.
No checks are done with C99''s restrict, so it''s not immediately clear to me what checks one loses.
I mean, you do understand that the compiler needn''t actually generate different code in response to a restrict, right? They could "support" it by making the compiler automatically #define restrict.
quote:Moreover, you can''t mix potentially aliased and known non-aliased pointers in the same code block without disabling the aliasing pragma.
This seems frankly insigificant.
quote:I work in numerical simulations for medical devices. Floating point consistency across platforms is *very* important to me.
You do understand what "majority" means, do you not?
And much like performing restrict-based optimizations, defining that symbol is optional. MS could make VC++ support C99 and not support that symbol. Merely being C99 is not adequate to provide the guarantees you want.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
