Is Visual C++ .NET fully ANSI complaint?
Ernesto
I want to develop a cross-platform library and application, and I want
to know if the Visual C++ .NET compiler is 100% ANSI complaint
(obviously, forgetting the MANAGED code and all that stuff)
Best regards
Ernesto
Jumbo
"Ernesto" <eba...@hotmail.com> wrote in message
news:f7c444ea.0401...@posting.google.com...
Leor Zolman
Not quite 100% (I've seen it characterized as somewhere in the "high
90's" whereas older versions were 60's-70's, more or less).
Found this MSDN link that might prove useful:
(I've put blank lines around it; sorry if your newsreader makes you
glue it together). Once there, see esp. the link labeled "nonstandard
behavior".
AFAIK, Comeau C++ is still the champ in terms of compliance, even if
you don't have the need for "export". In my own experience, over a
year ago I was playing with an unreleased version of my Container
Initialization Library where I was able to cut down considerably on
the code by taking advantage of some cute template tricks
(SFINAE-related, I think, but it has been a while since I looked at
it), and at the time Comeau was the only compiler that could compiler
it. Well, Comeau is _still_ the only compiler that will compile it (I
just tried with the latest MinGW gcc). And I still don't even know
for sure why gcc and VC7.1 choke on it, because I can't understand the
messages ;-)
-leor
>
>Best regards
>
>
>
>Ernesto
Leor Zolman
BD Software
le...@bdsoft.com
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html
Jerry Coffin
says...
[ ... ]
> Well, Comeau is _still_ the only compiler that will compile it (I
> just tried with the latest MinGW gcc). And I still don't even know
> for sure why gcc and VC7.1 choke on it, because I can't understand the
> messages ;-)
I guess it's probably too much to expect that stlfilt can help decode
them if you can't figure out what they mean in the first place?
--
Later,
Jerry.
The universe is a figment of its own imagination.
Leor Zolman
wrote:
>In article <f1mr001fpabs2qbsa...@4ax.com>, le...@bdsoft.com
>says...
>
>[ ... ]
>
>
>> Well, Comeau is _still_ the only compiler that will compile it (I
>> just tried with the latest MinGW gcc). And I still don't even know
>> for sure why gcc and VC7.1 choke on it, because I can't understand the
>> messages ;-)
>
>I guess it's probably too much to expect that stlfilt can help decode
>them if you can't figure out what they mean in the first place?
Any time I write about not being able to understand C++ error
messages, that's _after_ STLFilt has had its way with them. STLFilt
was designed to deal with _STL_ - related messages, and does a pretty
good job with those (although later in life it was extended, for MSVC
and gcc, to help with metaprogramming-related messages that have
nothing to do with STL). What it is not capable of doing is clarifying
"any ole' arbitrary template-related error message", such as from
custom templates having little or nothing to do with STL. That's the
category the lib I speak of above falls into...but thanks for asking!
;-)
-leor
Gianni Mariani
> On Wed, 21 Jan 2004 03:20:04 GMT, Jerry Coffin <jco...@taeus.com>
> wrote:
>
>
>>In article <f1mr001fpabs2qbsa...@4ax.com>, le...@bdsoft.com
>>says...
>>
>>[ ... ]
>>
>>
>>
>>>Well, Comeau is _still_ the only compiler that will compile it (I
>>>just tried with the latest MinGW gcc). And I still don't even know
>>>for sure why gcc and VC7.1 choke on it, because I can't understand the
>>>messages ;-)
>>
>>I guess it's probably too much to expect that stlfilt can help decode
>>them if you can't figure out what they mean in the first place?
>
>
> Any time I write about not being able to understand C++ error
> messages, that's _after_ STLFilt has had its way with them. STLFilt
> was designed to deal with _STL_ - related messages, and does a pretty
> good job with those (although later in life it was extended, for MSVC
> and gcc, to help with metaprogramming-related messages that have
> nothing to do with STL). What it is not capable of doing is clarifying
> "any ole' arbitrary template-related error message", such as from
> custom templates having little or nothing to do with STL. That's the
> category the lib I speak of above falls into...but thanks for asking!
> ;-)
You can't leave us hanging like this (well you can really) so show us
the code....
G
Ulrich Eckhardt
> I want to develop a cross-platform library and application, and I want
> to know if the Visual C++ .NET compiler is 100% ANSI complaint
And what if? If you want portability (the real one, not the theoretical
one), you need to restrict yourself to things supported by the range of
compilers/libs you target as platforms. Just programming ISO and assuming
it will run everywhere is not enough in the real world.
Else, questions about particular implementations of C++ are considered
off-topic here - ask the vendor ;)
Uli
--
Questions ?
see C++-FAQ Lite: http://parashift.com/c++-faq-lite/ first !
Jason
Every compiler has it's extentions. Make sure you only use ANSIC++98
constructions, and if possible run it though another compiler - even if
you're not going to link your modules. VC++.NET in my opinion is quite good
and warns about troubblesome casts, and arithmetic mismatches and memory
problems much better than visual C 6 did. It's a good thing.
Leor Zolman
wrote:
>Leor Zolman wrote:
>>>>Well, Comeau is _still_ the only compiler that will compile it (I
>>>>just tried with the latest MinGW gcc). And I still don't even know
>>>>for sure why gcc and VC7.1 choke on it, because I can't understand the
>>>>messages ;-)
>>>
>>>I guess it's probably too much to expect that stlfilt can help decode
>>>them if you can't figure out what they mean in the first place?
>>
>>
>> Any time I write about not being able to understand C++ error
>> messages, that's _after_ STLFilt has had its way with them. STLFilt
>> was designed to deal with _STL_ - related messages, and does a pretty
>> good job with those (although later in life it was extended, for MSVC
>> and gcc, to help with metaprogramming-related messages that have
>> nothing to do with STL). What it is not capable of doing is clarifying
>> "any ole' arbitrary template-related error message", such as from
>> custom templates having little or nothing to do with STL. That's the
>> category the lib I speak of above falls into...but thanks for asking!
>> ;-)
>
>You can't leave us hanging like this (well you can really) so show us
>the code....
This is not something easily reducible, but not wanting to leave
anyone in suspense, I've posted a ZIP file with two separate problems
(one is in a subdirectory, so be sure to unzip preserving directory
structure) on my web site. The link is:
www.bdsoft.com/dist/testinit.zip
There's a README.TXT at the top level explaining the problems.
Not wanting to post this and have it end up being a really stupid
problem (eradicating whatever meager credibility I may have built up
in this group by answering questions), I decided to experiment a bit
this morning and discovered that a simple command-line option to the
MSVC compiler, /Za, solves all the MSVC 7.1-related problems. The
remaining problems are all with gcc, and for all I know there may be a
simple option there as well that will handle the problems. So if I
end up looking like an idiot, it may just end up being for not knowing
how to look up gcc command-line options...
Gianni Mariani
> On 21 Jan 2004 02:08:46 EST, Gianni Mariani <gi2n...@mariani.ws>
> wrote:
>
>
...
>
>
> This is not something easily reducible, but not wanting to leave
> anyone in suspense, I've posted a ZIP file with two separate problems
> (one is in a subdirectory, so be sure to unzip preserving directory
> structure) on my web site. The link is:
> www.bdsoft.com/dist/testinit.zip
> There's a README.TXT at the top level explaining the problems.
You seem to have two initutil.h (and InitUtil.h) files - I'm not sure
which one you are having issues with.
Anyhow - in trying to compiler test2.cpp, I came across this error which
seems to be an error in the - I suspect that this is a problem with the
code since I can create a 10 liner that has the same problem. But, I'm
not sure if this is the problem you are having.
gcc 3.3.2 ...
test2.cpp: In function `int main()':
test2.cpp:47: error: no matching function for call to `make_cont(const
char[10]
)'
test2.cpp:49: error: no matching function for call to `make_cont(const
char[18]
)'
This is similar to the code below and the other compilers give the same
kinds of error.
xxx.cpp
xxx.cpp(14) : error C2783: 'Z func(char,int)' : could not deduce
template argument for 'Z'
xxx.cpp(9) : see declaration of 'func'
"ComeauTest.c", line 13: error: no instance of function template "func"
matches the
argument list
The argument types that you used are: (char)
A a = func( 'a' );
struct A
{
int a;
};
template <typename Z>
Z func( char, int = 0 );
int main()
{
A a = func( 'a' );
}
Leor Zolman
for the group, so lets please take this off-line. My email address
isn't shrouded (relying on SpamCop to keep me sane, and it seems to be
working for the time being...), so I'd welcome any further feedback on
InitUtil via email, and if this issue gets resolved I'll post the
final resolution to the group (in case anyone else cares).
On 21 Jan 2004 13:36:24 EST, Gianni Mariani <gi2n...@mariani.ws>
wrote:
>You seem to have two initutil.h (and InitUtil.h) files - I'm not sure
>which one you are having issues with.
The top-level directory is self-contained, and so is the subdirectory.
If you treat each one independently, there's no confusion. I tried to
explain that in the README file...
The trouble is that when I compile my test programs with Comeau they
_compile_, whereas you're getting the error under Comeau, so I'm not
sure how far this is worth pursuing.
You did motivate me to work on whittling down at least one of the
problems (the conversion-function-related one, which is the one I was
referring to when I first brought this up, and the one that made me
throw my hands up in despair a year ago). I've succeeded in whittling
it way down to a self-contained (nothing but standard headers) 3K
source file here:
http://bdsoft.com/dist/t2.cpp
(Hard tab setting is 4). It compiles with every decent compiler I have
except gcc. I think if this can be fixed under gcc, the same fix
would take care of the InitUtil configuration in the top-level of my
ZIP file. The problem in the subdirectory is, I think, an entirely
separate issue involving hash-based containers, and I'd sure love to
know the solution for that as well.
Anyway, I really do not think of this group as my personal beta test
team, so let this post wrap up the thread until I can post some
solutions.
Thanks all,
Gianni Mariani
>
> Anyway, I really do not think of this group as my personal beta test
> team, so let this post wrap up the thread until I can post some
> solutions.
gcc borks on this code - I suspect gcc is broken.
struct X
{
template<typenameT,typename A, template<typename,typename> class C>
C<T, A> Func()
{
return C<T, A>();
}
template<typenameT,typename A, template<typename,typename> class C>
operator C<T, A> ()
{
return C<T, A>();
}
};
template<typename dpt, typename dpa>
class D
{
};
int main()
{
X x;
x.Func<char, char, D>();
}
It seems like the problem is that the lexer does not recognize that it
expects a typename and that C is a typename.
It seems like a work-around is :
struct X
{
struct C; // dummy struct - not used - required by gcc 3.x
template<typenameT,typename A, template<typename,typename> class C>
operator C<T, A> ()
{
return C<T, A>();
}
};
Gianni Mariani
> Leor Zolman wrote:
>
>>
>> Anyway, I really do not think of this group as my personal beta test
>> team, so let this post wrap up the thread until I can post some
>> solutions.
>
>
> gcc borks on this code - I suspect gcc is broken.
>
... I filed a gcc bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13808
Leor Zolman
wrote:
>Leor Zolman wrote:
>
>>
>> Anyway, I really do not think of this group as my personal beta test
>> team, so let this post wrap up the thread until I can post some
>> solutions.
>
>gcc borks on this code - I suspect gcc is broken.
>
Thanks for the detective work! You have in fact made the little t2.cpp
program work...unfortunately, even after I added a few
strategically-placed "struct C;" statements to the InitUtil.h program
(corresponding to the code at the top level of my ZIP archive, where
the client test program is named test2.cpp), I'm still getting other
errors from gcc...so there seem to be yet additional issues (which of
course make no sense to me.)
Appreciate your help. I guess I should just give up trying to take
this off-line? ;-)
Gianni Mariani
> On 21 Jan 2004 22:20:02 EST, Gianni Mariani <gi2n...@mariani.ws>
> wrote:
>
>
>>Leor Zolman wrote:
>>
>>
>>>Anyway, I really do not think of this group as my personal beta test
>>>team, so let this post wrap up the thread until I can post some
>>>solutions.
>>
>>gcc borks on this code - I suspect gcc is broken.
>>
>
>
> Thanks for the detective work! You have in fact made the little t2.cpp
> program work...unfortunately, even after I added a few
> strategically-placed "struct C;" statements to the InitUtil.h program
> (corresponding to the code at the top level of my ZIP archive, where
> the client test program is named test2.cpp), I'm still getting other
> errors from gcc...so there seem to be yet additional issues (which of
> course make no sense to me.)
You mean this: ?
test2.cpp: In function `int main()':
test2.cpp:151: error: conversion from `bds::Converter_' to `std::set<int,
std::less<int>, std::allocator<int> >' is ambiguous
initutil.h:528: error: candidates are: bds::Converter_::operator C<T, A>()
[with T = int, A = std::less<int>, C = std::set]
initutil.h:540: error: bds::Converter_::operator C<T, F,
A>()
[with T = int, F = std::less<int>, A = std::allocator<int>, C =
std::set]
test2.cpp:154: error: conversion from `bds::Converter_' to
`std::multiset<int,
std::less<int>, std::allocator<int> >' is ambiguous
initutil.h:528: error: candidates are: bds::Converter_::operator C<T, A>()
[with T = int, A = std::less<int>, C = std::multiset]
initutil.h:540: error: bds::Converter_::operator C<T, F,
A>()
[with T = int, F = std::less<int>, A = std::allocator<int>, C =
std::multiset]
std:set takes 4 parameters but it complains about 2 and 3 parameter
conversions - I think this is another gcc bug.
some more example code.
struct X
{
// struct C; //uncomment to make this work.
template<typename T, typename A, template<typename,typename> class C>
operator C<T, A > ()
{
return C<T, A>();
}
template<typename T, typename A, typename B,
template<typename,typename,typename> class C >
operator C<T, A, B> ()
{
return C<T, A, B>();
}
template<typename T, typename A, typename B, typename Z,
template<typename,typename,typename,typename> class C >
operator C<T, A, B, Z> ()
{
return C<T, A, B, Z>();
}
};
#include <set>
int main()
{
X x;
std::set<int> s = x;
}
Gianni Mariani
> Leor Zolman wrote:
>
>
>
> std:set takes 4 parameters but it complains about 2 and 3 parameter
> conversions - I think this is another gcc bug.
>
Bugzillarized ...
Jerry Coffin
says...
> OK, I'll respond to this one here, but I feel this discussion is OT
> for the group, so lets please take this off-line.
Actually, I don't see anything about this that's particularly off-topic.
In the end, the NG is all about learning to program, and this code is
all about a technique for programming, so I suspect it's something from
which some of us can learn. I'd say it's a bit more advanced than much
of what gets discussed here regularly, but let's face it: learning C++
is not (by any means) restricted to learning the first bits for
beginners.
Bob Jacobs
The October & November 2003 issues of Dr Dobbs Journal both contained
comparisons of various compilers, including Visual C++.NET. It's worth
getting hold of a copy.
Leor Zolman
wrote:
I only meant it was OT in the sense that it was becoming more about
ferreting out gcc bugs than learning C++.
Status report: I've now got InitUtil v2 (based on Thorsten Ottosen's
idea of using conversion object templates to streamline both the
implementation and calling conventions) compiling with Comeau/libcomo
_and_ MSVC 7.1 (stock lib, and must use /Za) for all containers
tested (including hash-based containers). What makes this version so
cool is that
a) it can be implemented without any explicit mention of any
container types, so extended (hash-based) containers get supported
(compiler/lib bugs notwithstanding) "automagically" with no namespace
issues, no need to drag in all the STL headers, etc. In theory it
ought to work for any custom STL-style containers with no
modification, but I haven't tried that yet. Anyone up for it? ;-)
b) all redundancy is eliminated from user invocations of the functions
(no need for either explicit specialization or the extra "dummy"
argument in the calls, as in the current .9x versions).
The current v2 package can be downloaded here (this group is the only
place I'm posting this):
www.bdsoft.com/dist/initutil2.zip
Ideally, I'd like for it to compile under a few more platforms before
I release it. One of the gcc bugs,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13809
seems too serious to be able to work around, so I'm no longer holding
out for it to work with gcc. I think if I can nail the issues I'm
working with pjp on now with the Dinkum Unabridged Library (both under
Comeau and MSVC 7.1), that'll be good enough for starters and I'd
release it.
Jerry Coffin
@robertjacobs.fsnet.co.uk says...
[ ... ]
> The October & November 2003 issues of Dr Dobbs Journal both contained
> comparisons of various compilers, including Visual C++.NET. It's worth
> getting hold of a copy.
While this sort of article is usually quite interesting, I'd urge a
little caution when reading them. The authors are human too, so it's
not always absolutely certain that the tests they devise are perfect
either. I haven't read these particular articles, and I'm not trying to
say they contain any mistakes, but I've certainly read a few in the past
that did contain a few mistakes.
In addition, 100% compliance might be handy, but it's a long ways from
being the sole criterion upon which a compiler should be judged.