R
rays
Hi,
I am trying to port a C++ program which is supposed to be standards
compliant. It works fine on Linux with GCC (4.x). But as I try to
compile it on Windows, all hell breaks loose. I have been struggling
with several free (as beer) compilers on windows, but none of them
does the job. I am not sure how much of the blame goes to our code and
how much to the compilers. By the way the platform is Windows XP and
all the softwares mentioned below are their latest versions.
Here are my experiences:
Visual C++ 2005 Express ( Microsoft C compiler ) :
It does not seem to have sufficient template support. The
particular, the problem is, we have some template overloading. I do
not know if it is a violation of C++ standards to overload template
parameters ( could not find any instance of it in Lippman ), but it
compiles fine with gcc. The functions definitions are like:
bool set( MyData* e, const FieldInfo* f ){...}
bool set( MyData* e, const string& f ){...}
template < class T > bool set( MyData* e, const FieldInfo* f, T v )
{...}
template < class T > bool set( MyData* e, const string& f, T v ){...}
template < class T1, class T2 > bool set(MyData* e, const FieldInfo*
f, T1 v1, T2 v2 ){...}
template < class T1, class T2 > bool set(MyData* e, const string& f,
T1 v1, T2 v2 ){...}
I could work-around this by renaming the overloaded functions but I
would really hate to do so unless I am sure that we are violating
standards here, because boreland C++ and mingw do not have any problem
with these definitions.
Borland C++ Builder (Developer Studio-2006)/ Free command line
tools :
It compiles fine in debug build, though giving a lot of unwanted
warnings for derived classes overloading some virtual function in
baseclass.
"[C++ Warning] DerivedFieldInfo.h(132): W8022
'DerivedFieldInfo::match(const MyData *,unsigned int) const' hides
virtual function 'FieldInfo::match(MyData *,const string &) const'"
But when I try to do a release build the compiler fails without much
information:
"[Linker Fatal Error] Fatal: Illegal SEGMENT fixup index in module
'E:\myproject\basecode\SharedFieldInfo.cpp'"
I have no idea how to resolve this error.
MingW - 5.1.3 (mingw-runtime 3.12):
Compiles fine both with and without -g in CFLAGS.
Now, although borland and mingw can compile and link it, the
executable seems to have some problem. There are some assertions for
testing that fails in the same place for executable generated by both
compilers. In mingw it just says assertion failed, with line number
etc. and borland pops up a message window saying:
"Project myproject.exe raised an exception class EAccessVioltion with
message 'AccessViolation'".
It may be some problem with static initializations that I have to look
at. But right now it will be nice if somebody could cast some light on
what is the most standard compliant and full featured C++ compiler for
windows. So I could embark on the wild-goose-chase with the most
reliable tool ( which itself does not camouflage as the wild goose).
Please note that I am not bothered about compilation speed or
executable size at this point. I just want to make sure the problem
lies with the code or with the build process / windows platform itself
( without getting into too much of a flame war).
I would appreciate any feedback from the community.
Thanks in advance,
Ray S.
I am trying to port a C++ program which is supposed to be standards
compliant. It works fine on Linux with GCC (4.x). But as I try to
compile it on Windows, all hell breaks loose. I have been struggling
with several free (as beer) compilers on windows, but none of them
does the job. I am not sure how much of the blame goes to our code and
how much to the compilers. By the way the platform is Windows XP and
all the softwares mentioned below are their latest versions.
Here are my experiences:
Visual C++ 2005 Express ( Microsoft C compiler ) :
It does not seem to have sufficient template support. The
particular, the problem is, we have some template overloading. I do
not know if it is a violation of C++ standards to overload template
parameters ( could not find any instance of it in Lippman ), but it
compiles fine with gcc. The functions definitions are like:
bool set( MyData* e, const FieldInfo* f ){...}
bool set( MyData* e, const string& f ){...}
template < class T > bool set( MyData* e, const FieldInfo* f, T v )
{...}
template < class T > bool set( MyData* e, const string& f, T v ){...}
template < class T1, class T2 > bool set(MyData* e, const FieldInfo*
f, T1 v1, T2 v2 ){...}
template < class T1, class T2 > bool set(MyData* e, const string& f,
T1 v1, T2 v2 ){...}
I could work-around this by renaming the overloaded functions but I
would really hate to do so unless I am sure that we are violating
standards here, because boreland C++ and mingw do not have any problem
with these definitions.
Borland C++ Builder (Developer Studio-2006)/ Free command line
tools :
It compiles fine in debug build, though giving a lot of unwanted
warnings for derived classes overloading some virtual function in
baseclass.
"[C++ Warning] DerivedFieldInfo.h(132): W8022
'DerivedFieldInfo::match(const MyData *,unsigned int) const' hides
virtual function 'FieldInfo::match(MyData *,const string &) const'"
But when I try to do a release build the compiler fails without much
information:
"[Linker Fatal Error] Fatal: Illegal SEGMENT fixup index in module
'E:\myproject\basecode\SharedFieldInfo.cpp'"
I have no idea how to resolve this error.
MingW - 5.1.3 (mingw-runtime 3.12):
Compiles fine both with and without -g in CFLAGS.
Now, although borland and mingw can compile and link it, the
executable seems to have some problem. There are some assertions for
testing that fails in the same place for executable generated by both
compilers. In mingw it just says assertion failed, with line number
etc. and borland pops up a message window saying:
"Project myproject.exe raised an exception class EAccessVioltion with
message 'AccessViolation'".
It may be some problem with static initializations that I have to look
at. But right now it will be nice if somebody could cast some light on
what is the most standard compliant and full featured C++ compiler for
windows. So I could embark on the wild-goose-chase with the most
reliable tool ( which itself does not camouflage as the wild goose).
Please note that I am not bothered about compilation speed or
executable size at this point. I just want to make sure the problem
lies with the code or with the build process / windows platform itself
( without getting into too much of a flame war).
I would appreciate any feedback from the community.
Thanks in advance,
Ray S.