tags:

views:

233

answers:

3

I read that MSVC is not fully compilant to the ISO C++ standard (German Wikipedia and several Tech sites).

  • In which ways isn't C++ standards compilant?
+1  A: 

Well, I think it depends on your definition of compliant. There are several things that have not been implemented in the standard by almost any compiler company (several suggestion from the 98ish revision and template definitions in implementation files). MS has extended the language somewhat also. However, if you write code in basic c++ without the MS extensions or libraries, it will most likely be portable to another compiler with very, very minimal work (if any).

Steve
+1  A: 

It's been a while since I've looked into this, but the C++ library that I work on uses quite a lot of template metaprogramming (nothing horribly complicated, but still beyond the simplest levels), and for quite a while it wouldn't compile under MSVC due to bugs or missing functionality in their template resolution code, although it works fine in GCC and Intel's C++ compiler.

I don't think we've tried it in the latest couple of revisions of MSVC, so they may have fixed those bugs.

Also, IIRC, MSVC does not turn on run-time type information support by default (for performance reasons), and support for that is required by the C++ standard.

Brooks Moses
That hasn't really been an issue since VS2003 or older. They don't implement two-phase name lookup properly, and sometimes allow you to leave out a `typename`, but that generally just makes it more permissive than it should be. It doesn't usually rule out valid code.
jalf
RTTI is now on by default as of VS2008
Steve
jalf: FWIW, I'm reasonably sure that the problems we had were with VS2003. Presumably there were other issues involved. (I do fully recognize that this is hearsay, though, especially as I don't know exactly what the errors that we obtained were!)
Brooks Moses
+1  A: 

Actually no compiler is fully standard compliant, but MSVC gained its reputation for implementing everything that the standard didn't explicitly state in a profoundly stupid and unportable way.

I would say that the latest releases are relatively good when it comes to standard support, at least when you try to compile standard compliant code in MSVC.

But MSVC is still very lazy when it comes to pointing out code, that doesn't follow C++ standard (even on the strictest settings), so porting code from MSVC to anything else is always huge pain.

But there are still many flaws/bugs/etc... for example unlike GCC, MSVC will allow you to modify a set/map iterator.

Let_Me_Be
Please elaborate on your last statement.
Dennis Zickefoose
If you have a set/map iterator you cannot modify the value because you might break the ordering. MSVC allows you to do this, GCC doesn't.
Let_Me_Be
This is not true. You can change the value however you like. You can not change the key. This of course refers to maps. Sets are slightly different.
Dennis Zickefoose
When I wrote set/map with conjuction with value I thought that it was clear what I meant. Obviously not. Yes, I'm talking about key in map and value in set.
Let_Me_Be
I remain unconvinced. I can't double check at the moment, but Dinkumware's documentation suggests the library is fully compliant in this case, and MSDN agrees. In fact, from http://msdn.microsoft.com/en-US/library/y6ec19ye(v=VS.80).aspx: "value_type is declared to be pair <const key_type, mapped_type> and not simply pair <key_type, mapped_type> because the keys of an associative container may not be changed using a nonconstant iterator or reference."
Dennis Zickefoose
If they fixed this, it must be a very recent fix, I checked it several months ago.
Let_Me_Be
The current standard ISO/IEC 14882:2003 §23.3.3 says std::set / std::map iterators are implementation defined, i.e., not necessarily const. MSVC's implementation is not wrong in this regard. In fact, I consider it a step backwards that C++0x forces the iterators to be const_iterators.
Sebastian