Thanks for you input.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
If you look at http://boost.sourceforge.net/regression-logs/, you can
see how various compilers are doing with the Boost libraries.
Clicking through to the VC++ 7.1 beta tests, they are passing all the
Lambda tests, plus a whole lot of other tests that failed on older
versions. That's a big step forward for that compiler because it is
getting good results without a lot of workarounds. The older VC++
versions had a lot more failures in spite of many, many, workarounds
to try to get Boost libraries to compile.
Note that the Boost tests are designed to test the Boost libraries;
they aren't designed to test compiler conformance. It is only
incidental that their innovations drive many older compilers to the
point of self-destruction.
--Beman
http://boost.sourceforge.net/regression-logs/
Jonathan Caves, Herb Sutter, and Jason Shirk will be hosting a webchat
on C++ conformance in VC7.1 (aka Everett) tomorrow (2/27, 1PM PST).
See http://msdn.microsoft.com/chats/ for details.
/Pavel
Will it say that interoperability of Microsoft's C++ solutions
is ahead of the interoperability of their web solutions? It
seems that this webchat is only accessible to recent versions
of Windows, not to any other platform. Ah well, maybe someone
will post a summary to this newsgroup, or a link to where such
a thing might be found.
-- James
>From the Boost website: "These tables are not a good indication of a
particular compiler's compliance with the C++ Standard. The Boost
libraries often contain workarounds which mask compiler deficiencies."
It's not just that Boost isn't designed to test conformity...it's
specifically written to compile on non-conforming implementations.
But it doesn't appear there yet.
Jan
> of Windows, not to any other platform. Ah well, maybe someone
> will post a summary to this newsgroup, or a link to where such
> a thing might be found.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Well no more. As a happy user of the "Everett" I can tell you that dark ages
of MSVC are finally history.
>MS recently released
> the newest version Visual C++ .Net 2003,
I'm not sure they actually released it, according to
www.microsoft.com/vstudio the final beta is an MSDN download, but no release
yet. Supposed to come out this spring along with .Net Server OS.
> that it compiles "boost" and "loki". I was wondering
Have not tried Loki yet (though have quite a bit of my own code with
comparable use of partial specializations). _All_ the stuff from boost and
STL I tried compiled after removal of the MSVC kludges from the
configuration files.
> how does it do with (the Everest of ISO compatability) the
> Lambda library?
Yes, lambda works.
VC++.Net 2003 officially does not enforce exception specifications other
than throw() (non-throwing is verified and enforced) but it does parse the
syntax (older versions did too). I am not positive whether the standard
library they ship with it is compliant since I use STLport and plainly do
not care. Iostreams are still implemented badly in terms of performance, but
I'm not aware of a single "good" (that is, zero-overhead when compared to
stdio.h) implementation.
....Max...
RC3 is currently in limited circulation. Official release is expected in
mid April, together with Server 2003.
>> that it compiles "boost" and "loki". I was wondering
>
> Have not tried Loki yet (though have quite a bit of my own code with
> comparable use of partial specializations).
The original (un-hacked) Loki sources compiled just fine when I tried them.
Boost 1.29.0 compiles cleanly. I haven't tried 1.30.0 (which is currently
being prepared for release) yet. Spirit 1.5.1 (parser-generating template
library) compiles cleanly.
>> how does it do with (the Everest of ISO compatability) the
>> Lambda library?
>
> Yes, lambda works.
>
> VC++.Net 2003 officially does not enforce exception specifications
> other than throw() (non-throwing is verified and enforced) but it
> does parse the syntax (older versions did too).
Nothing's changed in exception specification handling for the 2003 release -
they are parsed, but not enforced (unexpected() is never called). As in
past versions, VC will interpret throw() as a promise that the function
never throws, and may optimize away exception handling in a caller. This is
a non-conforming extension that will be removed in a future version of VC
(there's a conforming extension, via __declspec(nothrow) that does the same
thing). A future version of VC will call unexpected() exactly as mandated
by the standard.
> I am not positive
> whether the standard library they ship with it is compliant since I
> use STLport and plainly do not care. Iostreams are still implemented
> badly in terms of performance, but I'm not aware of a single "good"
> (that is, zero-overhead when compared to stdio.h) implementation.
The Standard Library is reported to be 100% standard compliant. I've
abandoned STLport for the VC-supplied library in all new development.
-cd [VC++ MVP]