Visual C++ 2005 compliance with The C++ Standard
Despite a boat-load of documentation on Microsoft extensions to the C++ language, I have been unable to find a single page describing how VC++ 2005 differs from VC++ 2003 (7.1) with respect to the serious
non-compliance issues that plagued users of VC++ 2003 (7.1).
This document
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/vclrfNonstandardBehavior.asp is available for Visual C++ 2003 (7.1). Does anyone know which, if any, of these non-compliance issues have been fixed in Visual C++ 2005?
Is there an equivalent document for VC++ 2005 -- somewhere? Something that says, in plain English, in what ways, if any, Visual C++ 2005 still fails to conform to
The C++ Standard (BS ISO/IEC 14882:2003 Second Edition) -- the international standard definition of the C++ language?
This would seem to be a necessary beginning point for using the compiler -- before we get into discussions of 'managed code' and all the other non-standard extensions.
Finally, for use by those of us who like to compile
portablecode, is there some form of 'strict' switch that will
disable all Microsoft langauge extensions?
Thank you!
I cannot provide you a link(can't find it :P) but I read that most of those bugs have been fixed and that compiler is almost 100% ansi compliance. I'm talking about not-managed code(native).
I don't know where to turn off all MS extensions - I assume you want sth like "-pedantic -ansi" in gcc.
Ok, now I know :)
In Visual C++ 2005 in project proprties:
C/C++->Language->Disable language Extensions
What does disabling extensions do, and I also saw under platform there is Win32 and Active Win32. What is the difference?
Thank you, but we still need an actual list of nonconformance bugs for Visual C++ 2005. Can someone from
Microsoft respond, please?
Does anyone know if these bugs from VC++ 7.1 were fixed (our most pressing issues):
- is
std::uncaught_exception() implemented now, or is it still stubbed to return 'true'?
- does the compiler bind
nondependent names in templates as per the standard, or is template processing still broken in this way?
- are there any remaining
template-related non-conformance issues?
- do
covariant return types of virtual functions work when
virtual base classes are involved, or is that still broken?
Thank you (in advance).
David: here are answers to your specific questions:- is std::uncaught_exception() implemented now, or is it still stubbed to return 'true'?
This is now implemented correctly
- does the compiler bind nondependent names in templates as per the standard, or is template processing still broken in this way?
The compiler does not implement two-phase name lookup for templates. In or defense I have to say that even the C++ Committee is now not 100% convinced that two-phase name lookup is a good idea and there are papers on how to avoid two-phase name lookup in your code.
- are there any remaining template-related non-conformance issues?
I know that we have issues related to mixing templates and friends: especially mixing a class template and a friend function template.
- do covariant return types of virtual functions work when virtual base classes are involved, or is that still broken?
We have done some work in this area for Whidbey but developer who did the work won't promise that every last issue is fixed: there are problems when you throw variable-argument functions into the mix.
 Fixxer wrote: |
What does disabling extensions do, and I also saw under platform there is Win32 and Active Win32. What is the difference?
|
|
ppppppppeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeep Dont forget me! ^^^^
Jonathan,
Thank you! I greatly appreciate your reply.
RE: std_uncaught_exception() -- that's great news, as a workaround for its absence was virtually impossible. (I use it in a class of Transaction sentry objects to decide whether to commit or abort the transaction on exit from the block; normal exit commits, exceptions abort.)
RE: two-phase name lookup. I am unsure what is being checked per the standard and what is deferred until instantiation time. I will try GCC for comparison and see what happens -- typically GCC gives me earlier, and more standard-compliant, error messages which reveal what MSVC is doing in a non-standard way (or is not checking at all). But some learned words on the subject would be wonderful. Can you point me at any? The papers you mentioned re: ongoing debate about two-phase lookup would also be interesting if you can point me at them.
RE: friends: I also noted that 7.1 did not accept certain friend declarations that the standard allows; in fact I often found it difficult to use friend declarations in templates and had to resort to 'public' members. Since you seem to imply some work has been done in this area for 8.0, I will try again.
RE: covariant return types with virtual base classes. I will try using them again; I do not require the '...' construct.
Thanks again!
I really feel as if I am part of a neglected minority that uses MSVC strictly as a standard-compliant C++ compiler, and does things that push the edge of the standard's envelope, particularly with templates. It is great to get a bit of support.
Thank you.
It's tricky to use, because it breaks most platform sdk include files. Although I never include any directly, I do depend on a portability layer (APR, the Apache Portable Runtime) which needs some of them of course. The APR include files break when 'Disable Language Extensions' is specified.
Do you know if there is pragma support to turn this on and off in sections of code? If so perhaps I could bracket the APR includes so it would work, or better yet, get the APR folks to do so inside their include files.
It really would be comforting to know I'm getting the C++ language without any of the Microsoft special sauce.
| David Christie wrote: |
| - is <b>std::uncaught_exception</b>() implemented now, or is it still stubbed to return 'true'?<br /> <br /> - does the compiler bind <b>nondependent names in templates</b> as per the standard, or is template processing still broken in this way?<br /> <br /> |
|
I'm not a Microsoft employee, but I thought I'll respond anyway...
std::uncaught_exception is useless, or let's say: It most likely doesn't do what you want it to. See Sutter02, More Exceptional C++.
Non-dependent names in templates are checked more strictly in the VC++ 8.0 compiler, but only if you set "disable language extensions" in the project properties. Unfortunately, this causes compiler errors in STL headers, which use names that implicitely depend on template parameters. You might have to resort to an alternate STL implementation, like STLPort.
Non-dependent names in templates are checked more strictly in the VC++ 8.0 compiler, but only if you set "disable language extensions" in the project properties. Unfortunately, this causes compiler errors in STL headers, which use names that implicitely depend on template parameters. You might have to resort to an alternate STL implementation, like STLPortWe are working on standard headers. Here is relevant part of library development lead post(http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=5970):... in Whidbey beta 2, various headers do not always compile under /Za. This is a bug we are fixing. We still completely support /Za, and expect our Standard C++ Library and other headers to compile when it is enabled.
Thanks,
Eugene
If you could elaborate on your comments re: std::uncaught_exception() I'd be grateful. I don't possess the Sutter book you mention. All I need it to do is exactly what The C++ Standard says it does (see 18.6.4), which is very useful, indeed essential for my purposes:
bool uncaught_exception() throw();
"
Returns: true after completing evaluation of a
throw-expression until either completing initialization of the
exception-declaration in the matching handler or extering unexpected() due to the the throw; or after entering terminate() for any reason other than an explicit call to terminate().
[Note: This includes stack unwinding (15.2). --end note.]Eugene Nalimov wrote:
> We still completely support /Za, and expect our Standard C++ Library and other headers to compile when it is enabled.
Thank you, Eugene. That's very good to know. Can you answer my question re: whether there is pragma support to selectively enable language extensions?
Also, by "other headers", do you mean to include the PlatformSDK headers in particular? Since they make liberal use of language extensions it seems to me that they would require such pragma support before they could be made /Za compatible, correct? Is there a plan to make it possible to include PlatformSDK headers while using /Za (perhaps within appropriate pragmas), or is that considered unreasonable?
I would like to see the headers for the portability layer I use (the Apache Portable Runtime) fixed so they can be included when compiling /Za. That does not appear to be the case with the version of APR I am currently using (1.0.0), but I need to upgrade to the latest APR release (1.1.1) to see if they have addressed this yet. However, the 1.1.1 release notes say it has not yet been built with the MSVC Express Edition compiler, so perfect integration with your beta 2 at this point is unlikely. Rather, just knowing what the Microsoft compiler team intends in this area would make it more likely that the APR team could adapt their headers appropriately -- and perhaps meanwhile I could insert pragmas (if they exist) around my APR includes to make things work.
Obviously there are ways to make the APR headers for Win32 compatible with /Za without such pragma support, but they are more elaborate, because all use of types defined using language extensions must be purged from the headers. Let us know what will eventually have to be done, and it will probably happen sooner.
First, let me say that for the base Visual C++ library headers (e.g. stdio.h - CRT, and iostream - SCL), we should be clean for /Za. We have fixed all the bugs there were in beta 2. We do try to keep ourselves clean and conformant. In fact, we've made a bunch of fixes in Whidbey to increase our conformance, such as changing the parmeters passed to swprintf (which were wrong in VC).
Unfortunately, the Platform SDK (and by implication, MFC and ATL) still requires language extensions. There are quite a few places where it uses anonymous constructs, and fixing them would involve quite significant changes. I did look at trying to persuade the PSDK teams to make the changes this time around, but the backwards compatibility cost and risk were simply too great. It's something we'll look at again next time there is a major Platform SDK release being planned, but that probably won't happen until after Windows Vista ships.
Martyn Lovell
Development Lead
Visual C++ Libraries
