Archived

This topic is now archived and is closed to further replies.

MSVC7 non-compliance list

This topic is 5790 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

quote:
Taken from dotnet.languages.vc in a post by Ronald Laeremans [MSFT] Remaining non-compliance issues with VS7 (VS.NET) - 2.2 Unicode Identifiers - 3.4.2 Full Koenig Lookup - 8.5.1 Empty Aggregate Initialization - 9.8 Symbol Lookup for Local Member Functions - 11.4 Friends in Class Templates (also 14.5.3) - 13.3.1.1.2 Implicit Invocation of ptr-to-func Conversions - 13.3.3.2 Ranking of Derived to Base conversions - 14 Export Keyword - 14.1 Reference Non-Type template parameters (also 14.3.2) - 14.5.2 User-Defined Conversion Templates - 14.5.4 Partial Specialization of Class Templates - 14.5.5.2 Partial Ordering of Function Templates - 14.6 Dependent Names - 14.7.1 Nested Classes in Class Templates - 14.7.3 Explicit Specialization of Member Templates - 15.4 Exception Specifications - 15.5.2 The unexpected() function
These issues will not be addressed in service packs (due to whiney customers that don''t like new functionality being added in SP) Some of those issues will be addressed in VS8... Magmai Kai Holmlor "Oh, like you''ve never written buggy code" - Lee "What I see is a system that _could do anything - but currently does nothing !" - Anonymous CEO

Share on other sites
quote:
Original post by Magmai Kai Holmlor
..due to whiney customers that don''t like new functionality being added in SP

WHAT!?! Who are these whiney customers and when can I kick their cans!?

Share on other sites
Actually, I find it kind of funny that they didn''t implement unexpected() in the expected way.

Share on other sites
quote:
Original post by Stoffel
WHAT!?! Who are these whiney customers and when can I kick their cans!?

IT is all that comes to mind

Magmai Kai Holmlor

"Oh, like you've never written buggy code" - Lee

"What I see is a system that _could do anything - but currently does nothing !" - Anonymous CEO

Edited by - Magmai Kai Holmlor on December 10, 2001 12:50:04 AM

Share on other sites
You are all right : who are those customers????????

But it still prove my point : MSVC is an horrible C++ compiler.

Share on other sites
Shouldnt that be "MSVC is a horrible compiler"?

Fantastic doctrines (like Christianity or Islam or Marxism) require unanimity of belief. One dissenter casts doubt on the creed of millions. Thus the fear and hate; thus the torture chamber, the iron stake, the gallows, the labor camp, the psychiatric ward - Edward Abbey

Share on other sites
quote:
Original post by Arild Fines
Fantastic doctrines (like Christianity or Islam or Marxism..

...or (in the case of Gorg's post) Microsoft-bashing...

Edited by - Stoffel on December 11, 2001 7:43:49 PM

Share on other sites

Fantastic doctrines (like Christianity or Islam or Marxism or Microsoft-bashing) require unanimity of belief. One dissenter casts doubt on the creed of millions. Thus the fear and hate; thus the torture chamber, the iron stake, the gallows, the labor camp, the psychiatric ward - Edward Abbey

Share on other sites
quote:
Original post by Arild Fines
Shouldnt that be "MSVC is a horrible compiler"?

a sounded weird, so a used an.

But MSCV is not an horrible Compiler. It is an horrible "C++" compiler.

Now to stop the rumor that I am the guru of some sort of anti-microsoft cult I have to admit I exagerated. I find MSVC is simply sub-par compared to gcc, Kai, Codewarrior, Borland and sun workshop(those are the compilers I work/ed with). All those guys already have support for the majority of the non-compliance issue listed.

I will agree that those feature do not affect too much the average C++ programmer, but if you software uses template a lot(Scientific computing with blitz) MSVC just does not cut it.

Edited by - Gorg on December 11, 2001 8:42:49 PM

Share on other sites
These are the same customers who wanted IE integrated into Win98, and Messenger into XP.

And Gorg, I''ll join your cult as soon as I can beat you in foosball.

Share on other sites
When is MSVC++ 7 coming out? I am thinking of buying Visual C++ 6 Std, but not sure should I wait 7, since it is released shortly..

Share on other sites
quote:

MSVC is simply sub-par compared to gcc, Kai, Codewarrior, Borland and sun workshop

<wonders off to find this obviously superior Kai compiler>

MSVC is a nice IDE - the compiler is completely seperate. Which makes me think it should be possible to use gcc with it. Trivial if you know how to use make files? (which I have yet to use...)

quote:

I will agree that those feature do not affect too much the average C++ programmer

Arrrrrrrrrgggggggghhhhhhhhhhhhhh!!!!!!!!!!!
That''s because MSVC doesn''t support them! If it did, the average program would be using them in the STL implementation. They might not be writing libraries destined for The Standard, but they definetly would be using them.

How can you use a language feature, thus create popular demand for it in the popular compiler, if you can''t ever use with your compiler!!!

Whether you should use a or an before a word like horrible or herb depend on who you ask (the h is technically silent, but it''s almost always pronouced in practice).

...
quote:

I am the guru of some...anti-microsoft cult

So, where do you meet? (jk)

Magmai Kai Holmlor

"Oh, like you''ve never written buggy code" - Lee

"What I see is a system that _could do anything - but currently does nothing !" - Anonymous CEO

Share on other sites
quote:
Original post by Magmai Kai Holmlor
<wonders off to find this obviously superior Kai compiler>

You''re the third person I have to correct . You know how you type "&lt"? Well, it shows up as &lt in a compliant browser. You must type "&lt;" if you want it to work correctly in a compliant browser. Leaving off the semicolon doesn''t seem to matter if whitespace follows it, but it''s still improper HTML.

[Resist Windows XP''s Invasive Production Activation Technology!]

Share on other sites
quote:
Original post by Magmai Kai Holmlor
MSVC is a nice IDE - the compiler is completely seperate. Which makes me think it should be possible to use gcc with it.

Since no one has mentioned Intel''s C/C++ compiler, perhaps I should. It integrates very nicely with the MSVC IDE, and the standard support is much better.

Share on other sites
quote:
Original post by Magmai Kai Holmlor

Arrrrrrrrrgggggggghhhhhhhhhhhhhh!!!!!!!!!!!
That's because MSVC doesn't support them! If it did, the average program would be using them in the STL implementation. They might not be writing libraries destined for The Standard, but they definetly would be using them.

How can you use a language feature, thus create popular demand for it in the popular compiler, if you can't ever use with your compiler!!!
...

I agree. That is why I don't use MSVC anymore.(horrible...)

quote:

I am the guru of some...anti-microsoft cult

So, where do you meet? (jk)

Magmai Kai Holmlor

Every tuesday in an(a) hidden location. I have already been arrested twice by the FBI for ... let say stuff against microsoft

btw, here is a link to the Kai compiler :
http://www.kai.com/C_plus_plus/

BigB :

It will be difficult to beat me now: I actually play 3-4 times a day and with 2 balls! A couple of months ago, Costa stole the balls because it thought we were playing too much. He put them back because the project cancelled and we were move to a new one and we had nothing to do for a while

Edited by - Gorg on December 12, 2001 6:29:54 PM

Share on other sites
I often hear people saying that no compiler sticks completely to the standard. Does anyone know in what ways gcc fails to comply, when "-ansi" is specified? I''d be interested to know.

Share on other sites
Off the top of the head, GCC does not permit the following (str is a std::string object):
std::ctype<char>().toupper(str.begin(), str.end());

I''m still looking for a viable workaround without digging into the std::locale<> specification.

[ GDNet Start Here | GDNet FAQ | MS RTFM | STL | Google ]
Thanks to Kylotan for the idea!

Share on other sites
So it''s taken them years to make VS7, and the templates are still broken beyond belief. Nice.

Share on other sites
I thought GCC did not support the export keyword. Does any compiler support the export keyword?

Share on other sites
Ladies (it''s possible) and Gentlemen: if there are two words that just don''t belong in the same sentance, it''s MICRO\$OFT, and COMPLIANCE. Just slightly less well-known than the fear and hate, torture chambers, iron stakes, gallows, labor camp, and psychiatric ward are the Court Battles, Market Monopolies, and "Invasive Production Activation Technology".

-------------- Tok --------------
~The Feature Creep of the Family~

Share on other sites
here''s the latest word:
quote:

VC++ 7.0 does support template template parameters but it does not support
partial specializations. The next version of Visual C++ will contain a
highly conformant C++ compiler that will support partial specializations,
partial ordering, and a host of modern C++ class libraries, like Boost.

We are very confident that this compiler will be released (much) sooner
rather than later - i.e. you will definitely not have to wait 3 years for
this release.

--
Jonathan Caves
Microsoft Corporation

Share on other sites
quote:
Original post by spock
Since no one has mentioned Intel's C/C++ compiler, perhaps I should. It integrates very nicely with the MSVC IDE, and the standard support is much better.

It also has an astonishing habit of breaking code.

Simply put, the compiler is broken. There are a number of occasions under which it simply *does not generate any code* for a function, and it does this in error. It also has issues whereby it incorrectly generates (esp. floating-point) code.

MSOC 13 -- assuming it can compile the code -- is more likely (IME) to actually generate *correct* code. And this is far more important to me, to be honest. It's far easier for me to work around a feature the compiler doesn't support than to hunt through asm dumps looking for bits the compiler screwed up.

It also speed optimizes very well (much better than its predecessor), such that the Intel compiler no longer has any significant advantage (the areas the Intel compiler still has a benefit is the auto-vectorization, which can occasionally be useful, and slightly better P4 code generation -- however, those are rarely of use to me, particularly the P4 code generation).

As for the non-compliance issues... a lot of them simply aren't that important. I mean... unicode identifiers? What, because ASCII doesn't give enough ways of having near-identical looking identifiers, you want to add some more subtly accented characters into the mix?

Other things which are sometimes useful -- being able to 'export' templates -- have equivalent mechanisms in MSOC anyway.

Would it be nice if MSOC were 100% compliant? Sure. I'd really like a C99-compatible preprocessor (I know C++ doesn't have a C99-compatible preprocessor, but I'm sure if their preprocessor were C99-compatible then C++ would use it too). But then again... it's more important to me that it can (a) generate correct code (which rules out Intel) (b) generate fast code (which rules out g++ 3.x) (c) generate Win32 binaries (which rules out Kai) (d) be standalone (which rules out Comeau -- the reason I want something standalone is because Comeau has some restrictions on the features it offers that reflect the underlying compiler).

I wouldn't like these things to be fixed in a Service Pack. The Service Pack should fix things they say they've implemented, but it shouldn't fundamentally alter the compiler's behaviour. However, I would like to see a 7.1 release that fixed such things.

Though I still have doubts about some of the features. Koenig lookup, for instance, whilst essential for overloaded operators (and implemented in MSOC for overloaded operators), seems very iffy for non-operators.

Edit: nested quotes apparently do not work.

Edited by - DrPizza on January 13, 2002 9:43:06 PM

Share on other sites
The most troublesome aspect of non-compliances issues was that the list didn''t get much shorter going from MSVC6 to MSVC7. They added template template parameters (which is very nice) and addressed a couple of other issues.
They responded that there wasn''t pressure from customers to implement the other features - and well that statement bought about a bitch-fest. The last I''ve read is that v7.1 will addresses almost all non-compliance issues. Previously they had indicated the next major release would address them, not the next minor one.

I wouldn''t want them to alter the default behavior of the compiler either - it doesn''t bother me at all that
for(int i=0;

incorrectly gives i greater scope than the spec defines.

Adding a missing feature shouldn''t break any old code that uses work arounds though. Like if/when/since they allow inline const int declaration in classes, the enum trick will still work.

Partial template specialization and specialization of member templates are gaping holes in thier template support - they''re way more important than candy like export (though it would be sweet, it''s not essential). Their STL implementation is limited because the compiler lacks these features. It also precludes you from using modern template libraries, such as Boost or Loki. I''m sure there''s many more.

Some of the other things there are work arounds for, like no nested template classes and no friend in templates, etc... but there''s no work around for lack of class specialization - you just can''t utilize those features.

Share on other sites
quote:
Original post by Magmai Kai Holmlor
The most troublesome aspect of non-compliances issues was that the list didn''t get much shorter going from MSVC6 to MSVC7. They added template template parameters (which is very nice) and addressed a couple of other issues.
They responded that there wasn''t pressure from customers to implement the other features - and well that statement bought about a bitch-fest. The last I''ve read is that v7.1 will addresses almost all non-compliance issues. Previously they had indicated the next major release would address them, not the next minor one.

I''ve read mixed things on this -- at the very least, it seems that either 7.1 or 8 will fix the issues.

quote:
I wouldn''t want them to alter the default behavior of the compiler either - it doesn''t bother me at all that
for(int i=0; ; )

incorrectly gives i greater scope than the spec defines.

I would like to see much finer control over the way the compiler works, in a similar vein to this.

For instance, there''s a switch to turn MS extensions on or off on a wholesale basis, but I''d prefer to be able to turn them on or off individually. Some extensions I always want on; others I don''t (unless I''m trying to compile code that needs it). They do this for some things (e.g. proper for scope conformance) in MSOC 13, and I''d like it extended.

And the documentation ought to be improved. They need to list somewhere in detail each and everyone one of the extensions, and what it does.

Share on other sites
Individual non-compliances should be toggleable (is that a word?)

I know that the for loop scoping thing annoys the hell out of me. I don''t want to have to use i, j, k in a function just because they couldn''t be bothered to edit the compiler a little. The extra typing this has caused me is probably more work than it would take MS to make this into an option.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]

• Forum Statistics

• Total Topics
628769
• Total Posts
2984592

• 13
• 10
• 25
• 12
• 9