CC 5.5 vs CC 5.9

I'm trying to port some C++ code from Solaris to Linux. The code was running on Solaris 9, compiled with CC version 5.5. I've installed the Sun StuidoExpress on Redhat EL 4 - which comes with Sun's CC 5.9 compiler (right?). I'm assuming that there is no CC 5.5 for Linux - right? (sorry, I'm a little new to these technologies/tools - I'm even quite rusty with C/C++ - I didn't write the code I'm trying to port).

My problem is that I'm getting "Overloading ambiguity" errors between two operator functions when I compile in Linux. The code compiled fine with CC 5.5 on Solaris. I'm assuming that I'm getting these compiling errors because of the difference between CC 5.5 and CC 5.9 - the later version is better at catching ambiguities.I'm posting because I want to verify this assumption with people who are more familiar with these compilers.

Any comments would be greatly appreciated!

[921 byte] By [mark6] at [2007-11-26 10:43:18]
# 1
Can you show an example? The difference might be in the compilers, or it might be because Solaris 9 did not have a full set of the C++ version of the C standard headers.
clamage45 at 2007-7-7 2:55:17 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 2

Here is some code that illustrates the error I was talking about.

IC_String.h:

--

char operator[] (IC::Uint int i) const;

char& operator [] (IC::Uint int i);

Runtime_Setting.cc:

--

#include "IC_String.h"

...

IC_String pathname;

...

if(pathname[0] == '/')<-- Error referes to this line

...

Error:

--

Error: Overloading ambiguity between "My_String::operator[](unsigned) const" and "operator[](const char*, int)"

The weird thing is that (as far as I understand) the call looks very ambiguous, but somehow the old developers got it to compiled using CC 5.5. Are there compiler flags that would relax a compiler's check for ambiguous things? - maybe I'm missing some flags?I'm getting many other similar errors that can be resolved by explicitly casting values (where they were implicitly casted before) - so it's not a show stopper, I just thought it was weird.

Thanks for your help!

mark6 at 2007-7-7 2:55:17 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 3

> char operator[] (IC::Uint int i) const;

>

> char& operator [] (IC::Uint int i);

These declarations do not look like valid C++ syntax. Were they copied correctly?

> IC_String pathname;

> ...

> if(pathname[0] == '/')<-- Error referes to this

> Error: Overloading ambiguity between

> n "My_String::operator[](unsigned) const" and

> "operator[](const char*, int)"

You don't show enough code for me to evaluate the error message.

>

> The weird thing is that (as far as I understand) the

> call looks very ambiguous, but somehow the old

> developers got it to compiled using CC 5.5.

C++5.5 did not correctly follow the overload resolution rules regarding user-defined and built-in versions of operators like the arrary-index operator []. It is possible that the code is not valid and C++ 5.5 did not catch the error. It is also possible that the code is valid and C++ 5.9 is incorrectly rejecting it.

> Are

> there compiler flags that would relax a compiler's

> check for ambiguous things?

No. We have options to relax some rules, but we cannot provide flags to change the way function overload resolution works. (Suppose we had a flag to ignore ambiguity errors. The compiler would pick one function arbitrarily, and you could not predict or control which one.)

To determine whether the problem is in your code or in the compiler, and to suggest how to fix the code, I need to see an example that can be compiled except for the error messages that you cite.

clamage45 at 2007-7-7 2:55:17 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 4

You probably have something like the following:

struct str {

operator const char*() const;

char operator[] (unsigned i) const;

};

void f(){

str a;

a[0];

}

sunCC gives the error message you posted and g++ also refuses this code, which does indeed look ambiguous. One "solution" would be to provide one more overloading of operator[] that takes as argument an int (not unsigned).

Marc_Glisse at 2007-7-7 2:55:17 > top of Java-index,Development Tools,Solaris and Linux Development Tools...