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 portable code, is there some form of 'strict' switch that will disable all Microsoft langauge extensions
Thank you!
Visual C++ 2005 compliance with The C++ Standard
Hot Topic
- a lock system problem
- Use Native COM Servers with CRCWs ??
- Error in windows app. but not in console(same code)
- Wizard Migration to VS .NET
- Standard C++ library linker error
- Writing MMC Snapin in Visual C++ 2005
- CListCtrl
- Problem where a managed C++ dll returns values via parameters to a C# application
- msvcr80.dll Problem
- msvcr80.dll Problem
Visual C++
- When is operator void* invoked.
- Module handle in C++/CLI library
- Hex Format in Edit Box
- VC2005 %50 Slower then VC2003
- how can i use the type struct in VISUAL C++??... i'm new in visual c++
- ultra fast binary writes
- Checkbox problem
- i/o streams
- .NET Framework - why does my program require it?
- Repedative Syntax error : missing '=' and ')' and ';'
Visual C++ 2005 compliance with The C++ Standard
AratiR
In Visual C++ 2005 in project proprties:
C/C++->Language->Disable language Extensions
Critcho
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
Anders L
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).
dredrunde
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
We 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
dronick
<p>I'm not a Microsoft employee, but I thought I'll respond anyway...</p>
<p>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++.</p>
<p>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.</p>
SarahBurgess
- 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.
marla
Big H
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.
jinjun
> 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.
spillai
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.
Seb_london
"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.]
Robert Fontaine
I don't know where to turn off all MS extensions - I assume you want sth like "-pedantic -ansi" in gcc.
Rory Becker
ppppppppeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeep Dont forget me! ^^^^