VC++ vs C++

[Marco]

Where can I find a document outlining the main differences between
Microsoft's Visual C++ and ANSI C++?
Thanks,

Marco

[Victor Bazarov]

Marco wrote:

Where can I find a document outlining the main differences between
Microsoft's Visual C++ and ANSI C++?

You should probably ask in microsoft.public.vc.language. They know
all the specifics on what makes current VC++ compiler still not
perfectly compliant with the Standard.

AFAIK, it's very close, though. Something like 98%. I've read it
somewhere.

Victor

[beliavsky]

What does it say about the 1997 ISO C++ standard that in 2004,
arguably the dominant C++ compiler, Microsoft Visual C++ does not
fully implement the language? Is this primarily due to the complexity
of the standard or Microsoft's placing a lower priority on standards
compliance? I have read that g++ is getting slower as ISO C++ features
are being added.

Victor Bazarov <v.********@comAcast.net> wrote in message news:<hk****************@dfw-read.news.verio.net>...

Marco wrote:

Where can I find a document outlining the main differences between
Microsoft's Visual C++ and ANSI C++?

You should probably ask in microsoft.public.vc.language. They know
all the specifics on what makes current VC++ compiler still not
perfectly compliant with the Standard.

AFAIK, it's very close, though. Something like 98%. I've read it
somewhere.

Victor

[Victor Bazarov]

be*******@aol.com wrote:

What does it say about the 1997 ISO C++ standard that in 2004,
arguably the dominant C++ compiler, Microsoft Visual C++ does not
fully implement the language? Is this primarily due to the complexity
of the standard or Microsoft's placing a lower priority on standards
compliance? I have read that g++ is getting slower as ISO C++ features
are being added.
Please don't top-post. If you don't think the conversation up to
the point when you're replying to it, is relevant, don't quote it.
If you think the quote is needed, put your text _after_ the quote.
Thank you.

Now, regarding the Standard-compliance, Microsoft has a few areas
that they are still non-compliant, and those are listed in

http://msdn.microsoft.com/library/en...sInVisualC.asp

Please read and decide to yourself whether it's because Microsoft
implementors are lazy or too busy to implement everything.

As for G++, it's now a second-grade compiler, as far as I'm concerned.
It used to be good, but not any more. The main reason is motivation
(or rather lack thereof) of the participating developers.

V

Victor Bazarov <v.********@comAcast.net> wrote in message news:<hk****************@dfw-read.news.verio.net>...

Marco wrote:

Where can I find a document outlining the main differences between
Microsoft's Visual C++ and ANSI C++?

You should probably ask in microsoft.public.vc.language. They know
all the specifics on what makes current VC++ compiler still not
perfectly compliant with the Standard.

AFAIK, it's very close, though. Something like 98%. I've read it
somewhere.

Victor

[Mats Weber]

In article <zX****************@dfw-read.news.verio.net>,
Victor Bazarov <v.********@comAcast.net> wrote:

Now, regarding the Standard-compliance, Microsoft has a few areas
that they are still non-compliant, and those are listed in

http://msdn.microsoft.com/library/en...ComplianceIssu
esInVisualC.asp
This is incomplete. e.g. VC++ does not support nested templates.
As for G++, it's now a second-grade compiler, as far as I'm concerned.
It used to be good, but not any more. The main reason is motivation
(or rather lack thereof) of the participating developers.

Which one(s) do you consider good ?

[Rob Williscroft]

Mats Weber wrote in news:ma*************************@sicinfo.epfl.ch in
comp.lang.c++:

In article <zX****************@dfw-read.news.verio.net>,
Victor Bazarov <v.********@comAcast.net> wrote:

Now, regarding the Standard-compliance, Microsoft has a few areas
that they are still non-compliant, and those are listed in

http://msdn.microsoft.com/library/en...StandardCompli
anceIssu esInVisualC.asp
This is incomplete. e.g. VC++ does not support nested templates.

Do you mean like this:

#include <iostream>
#include <ostream>

template < typename U >
struct X
{
template < typename T > void f();
template < typename V > struct Y;
};
template < typename U >
template < typename T >
void X< U >::f()
{
std::cout << "T\n";
}
template < typename U >
template < typename V >
struct X< U >::Y
{
V get() { return V(); }
};
int main()
{
using namespace std;

X< int > x;
x.f< double >();
X< double >::Y< int > xy;
cout << xy.get() << '\n';
}
That I just compiled with VC++ 7.1.

As for G++, it's now a second-grade compiler, as far as I'm concerned.
It used to be good, but not any more. The main reason is motivation
(or rather lack thereof) of the participating developers.

Which one(s) do you consider good ?

I have to disagree with Victor, so far (*) I think gcc (g++) 3.4
is better (read more conformant to out beloved standard) than VC 7.1.

YMMV.

*) 3.4 was only releasd reciently and the windows version I'm
currently using is a prerelese.

I got it from:

http://www.thisiscool.com/gcc_mingw.htm#gcj34

However www.mingw.org have a more uptodate release candidate:

http://www.mingw.org/download.shtml

For other platforms:

http://gcc.gnu.org/releases.html

Rob.
--
http://www.victim-prime.dsl.pipex.com/

[Gianni Mariani]

Victor Bazarov wrote:
...

As for G++, it's now a second-grade compiler, as far as I'm concerned.
It used to be good, but not any more. The main reason is motivation
(or rather lack thereof) of the participating developers.

Why do you say this ?

Every time I have posted a g++ bug, it seems like the developers are
motivated.

[Prateek R Karandikar]

> What does it say about the 1997 ISO C++ standard that in 2004,

arguably the dominant C++ compiler, Microsoft Visual C++ does not
fully implement the language? Is this primarily due to the complexity
of the standard or Microsoft's placing a lower priority on standards
compliance? I have read that g++ is getting slower as ISO C++ features
are being added.

If some C++ compiler doesn't implement standard features, it's the
compiler's fault. It doesn't say anything about the standard, but it
certainly says something about the compiler.

Why would MS want programmers to write perfectly standard-compliant
and thus portable code? They would want everyone to use only their
proprietary products.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
To iterate is human, to recurse divine.
-L. Peter Deutsch
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[Steven T. Hatton]

Prateek R Karandikar wrote:

What does it say about the 1997 ISO C++ standard that in 2004,
arguably the dominant C++ compiler, Microsoft Visual C++ does not
fully implement the language? Is this primarily due to the complexity
of the standard or Microsoft's placing a lower priority on standards
compliance? I have read that g++ is getting slower as ISO C++ features
are being added.

This was in my inbox from the gcc developer mailing list this morning:
"Today the automatic POOMA tramp3d-v3 tester caught a 10% compile time
decrease (congrats!) for the leafified version on ia64-linux!"
If some C++ compiler doesn't implement standard features, it's the
compiler's fault. It doesn't say anything about the standard, but it
certainly says something about the compiler.
I can't fully agree with that. There are features in gcc-3.4.0 that bring
it into better conformity with ISO/IEC 14882:1997. I believe the C++
standard has been difficult to implement. That may in part be due to the
fact that it reads, in some parts, like a leagal contract drawn up by
lawyers, not a technical document written by engineers.
Why would MS want programmers to write perfectly standard-compliant
and thus portable code? They would want everyone to use only their
proprietary products.

--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Mats Weber]

In article <Xn**********************************@130.133.1.4> ,
Rob Williscroft <rt*@freenet.co.uk> wrote:

Mats Weber wrote in news:ma*************************@sicinfo.epfl.ch in
comp.lang.c++:

This is incomplete. e.g. VC++ does not support nested templates.

[...]
That I just compiled with VC++ 7.1.

You are right. Version 7.1 compiles nested templates. My last try was
version 6.x.

[Michiel Salters]

Mats Weber <ma***@bluewin.ch> wrote in message news:<ma*************************@sicinfo.epfl.ch> ...

In article <Xn**********************************@130.133.1.4> ,
Rob Williscroft <rt*@freenet.co.uk> wrote:

Mats Weber wrote in news:ma*************************@sicinfo.epfl.ch in
comp.lang.c++:

This is incomplete. e.g. VC++ does not support nested templates.

[...]
That I just compiled with VC++ 7.1.

You are right. Version 7.1 compiles nested templates. My last try was
version 6.x.

Well, that's a vintage 1997 compiler, judging it by ISO 14882-1998 is
not a fair criticism. The only major feature missing nowadays is
'export', and that's a common omission.

Regards,
Michiel Salters

[Michiel Salters]

"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message news:<GM********************@speakeasy.net>...

I can't fully agree with that. There are features in gcc-3.4.0 that bring
it into better conformity with ISO/IEC 14882:1997. I believe the C++
standard has been difficult to implement. That may in part be due to the
fact that it reads, in some parts, like a leagal contract drawn up by
lawyers, not a technical document written by engineers.

The major compiler vendors send engineers to the ISO meetings, and it's
these engineers who write the standard for their own use. The difficulty
lies more in the set of problems that it's supposed to solve. For instance,
the 'export' feature has a very tricky description of how it's supposed
to work. Normal engineering documents just specify the basics, and any
implementation would be OK. A standard is different, all 'export'
implementations should implement exactly the same feature.

You can see this in the Defect Reports. For a standard, it is bad to
allow two incompatible solutions. For a normal application, requirements
allowing two solutions are better than requirements allowing one -
developers can then choose the easiest solution once they can estimate
true costs.

'export' would have been done differently if we had known its true costs,
but standards are called standards for a reason.