class SString
{
  ....
  operator   char* ()    { return _str; }
  int operator == (const char*);        

  //int operator == (const SString&);                    // dasselbe Problem 
  //friend int operator == (const SString&, const char*);// dasselbe Problem 
  ...
};

Das hat mit dem Borland Compiler gut funktioniert. Der hat also den Operator ausgewählt, für den keine Conversion erforderlich ist.

Doch der MS-Compiler will sich nicht entscheiden, ob er den Klassen-Operator
SString == char*,
oder den C++ built-in Operator
char* == char*
benutzen soll. Wenn ich auf den Conversions Operator verzichte, müsste ich wohl an recht vielen Programmstellen eine explizite Konvertierung einfügen.

Gibt es einen Weg das aufzulösen?
hg

Poste doch mal den Ausdruck, der diesen Fehler erzeuget (mit Deklarationen versteht sich).

ja, zum Bsp:

char  m_animal[40];
...
SString animal;
....
if( animal == m_animal)
{ ...

ERROR in IF-Zeile: could be 'int SString::operator ==(const char *)'
or 'built-in C++ operator==(char *, char *)'

Welcher compiler soll hier Schwierigkeiten haben?

MS Visual C++, von der Express Edition. Den probiere ich gerade neu aus.
Kenn mich also mit Switches und Einstellungen nicht besonders aus. Generell habe ich den Eindruck er ist mehr restriktiv und mehr auf Sicherheit ausgerichtet, als der Compiler von Borland.

$Der Vollstrecker$

Kann ich nicht nachvollziehen, bitte kompilierbares Beispiel!

$Der Vollstrecker$

Kompilierbares Beispiel. Kann das leider heute nicht mehr machen. (Weil ich dafür die Settings für eine Konsolenanwendung erst neu einstellen müsste.) Kann ich morgen machen.

Aber ich finde das Problem ist relativ klar aus der Error Meldung: der Konversions Operator verwandelt mein SString in ein char*. Und damit sind 2 Operatoren gleichzeitig prinzipiell auf die == Situation anwendbar.

Also der Compilierbare Code würde so aussehen:

int _tmain(int argc, _TCHAR* argv[])
{

	char animal[] = "Fuchs";
	char* p       = animal;
	SString tier  = "Ente"

    if(tier == 	p)
	   return 1;
	return 0;
}

Nur ich habe noch nicht testen können, dass dies mit derselben Fehlermeldung NICHT compiliert.

struct Foo {
    int bar;
    Foo(int val) : bar(val) {}
    operator int() const { 
        return bar; 
    }
    friend bool operator==(Foo const& foo, int val) { 
        return foo.bar == val; 
    }
};

int main() {
    return Foo(1) == 1;
}

$Der Vollstrecker$

-Die erste Operatorüberladung 'int SString::operator ==(const char )'
erfordert keine (oder man könnte sie auch als identische K.-sequenz bezeichenn) Konvertierungssequenz für den ersten Parameter, aber eine Qualifikationskonvertierung (von char auf const char*) für den 2.Parameter
-Die zweite Operatorüberladung operator==(char *, char
dagegen erfordert die zweitschlechteste Form einer Konvertierungssequenz, nähmlich eine, die einen Nutzerdefinierten operator benötigt (schlechter sind Ellipsen), dagegen keine für den zweiten Parameter.

Die erste Überladung ist also besser für den ersten Operanden aber schlechter für den zweiten Operanden. Es ist also nur logisch und folgerichtig, wenn der Compiler hier eine Entscheidung verweigert. Im Übrigen ist das - wie erwähnt - nur Folge eines schlechten Designs und nicht ein Fehler der Sprachkonzeption.

Habe das Beispiel jetzt mit einer künstlichen SString Klasse gemacht:

struct SString
 { char m_str[20];
   SString()   {;}  
   operator    char* ()    { return m_str; } 
   friend bool operator == (const SString&, const SString&) { return 1; }   
   friend bool operator == (const SString&, const char* )   { return 0; }
 };

int main()
{
	char animal[] = "Fuchs";
	char* p = animal;
	SString tier;
	SString tier2;
	if(tier == p)              // hier selbe Fehlermeldung  wie zuvor
            return 1;               // aber siehe unten        
	if(tier == tier2)          // ok
            return 1;
}

@Camper

Weiss nicht, ob ich das mit dem Rang einer Konvertierungssequenz recht verstanden habe. Intuitiv finde ich, dass operator ==(const SString&, const char gewählt werden sollte, wenn die Argumente entsprechend sind. Und so macht es der Compiler ja auch, wenn kein Conversion Operator definiert ist.

Aber Du hast mich darauf gebracht, auch die Umwandlung const - non-const als conversion zu berücksichtigen. Es stellt sich heraus, dass folgendes funktioniert (Veränderung zu oben ist die unterschiedliche Qualifikation von char* mit const):

operator    const char* ()    { return m_str; } 
   friend bool operator == (const SString&, const SString&) { return 1; }   
   friend bool operator == (const SString&, const char* )   { return 0; }

ODER

operator    char* ()    { return m_str; } 
   friend bool operator == (const SString&, const SString&) { return 1; }   
   friend bool operator == (const SString&, char* )         { return 0; }

also char* ist nun beide male gleichartig. Verstehen tu ich es noch nicht, aber zumindest kompiliert es jetzt.

grüße

Was soll an dem Design schlecht sein? Wieso soll ein Konvertierungsoperator schlechter sein als ein c_str()? Schließlich besteht die Klasse nur aus einem char*, warum also keinen Konvertierungsoperator dafür einbauen?
Man kann die Klasse intuitiv benutzen und es ergibt sich kein Nachteil! Was soll an diesem Design schlecht sein

An c_str() ist besser das man SString Objekte nicht "ausversehen" in char* umwandeln kann...

Ja, aber was ist dann an einem const char* Operator so schlecht?

Schlecht ist, dass er immer dort aufgerufen werden kann, wo die Sprache das vorsieht, und nicht nur an den Stellen, an die der Programmierer denkt, wenn er diesen Operator einführt. Ein Konvertierungsoperator, der in einen primitiven Typ konvertiert, macht alle Operationen, die für diesen primitiven Typ schon eingebaut sind, auch dem ursprünglichen Typ zugänglich. Das muss sehr schnell zu Mehrdeutigkeiten (im besten Falle) oder zu stillen Bedeutungsänderungen führen. Viele Konstrukte, die eigentlich falsch sind und diagnostiziert werden sollten, können so auf Umwegen doch noch legal werden.
In deinem Beispiel sollte

if(tier == p)

natürlich den selbstdefinierten Vergleichsoperator benutzen. Tatsächlich funktioniert das aber auch dann noch, wenn du gar keinen Vergleichsoperator definierst. Die Bedeutung des Ausdrucks tier==p hängt also nicht bloß von den Dingen, die explizit dastehen (also den Operanden und deren Typen und dem Vergleichsoperator) ab, sondern noch von etwas, was gar nicht dasteht, nähmlich ob und, wenn ja, welche Konvertierungsoperatoren/-konstruktoren definiert wurden. Das macht so einen einfachen Ausdruck kompliziert und das ist per se schlecht. Wie soll das erst werden, wenn wir etwas haben, was an sich schon sehr komplex ist.

Habt ihr vielleicht ein (mehr oder weniger) konkretes Beispiel, wie es "gefährlich" werden könnte, bzw halt nicht im Sinne des Benutzers?

class string
{
public:
  string(const char*);
  operator const char*() const;
  friend operator==(const string& l, const string& r);
}

string ob1;
char ob2[20];
if(ob1==ob2)...
//soll ich ob1 per operator char* umwandeln und den eingebauten char* Vergleich durchführen?
//oder soll ich ob2 per Ctor in einen string umwandeln und obigen op== verwenden?

Wenn ich Compiler wäre, würde ich sowohl ob2 als auch ob3 in const char* umwandeln, dann müsste es ja funktionieren...
Der Compiler müsste ja alle in Frage kommenden Vergleichsobjekte (also char* char[], const char*, const char[]) in const char* umwandeln können und damit den Vergleichsoperator aufrufen können.
Würde auch funktionieren, wenn es nicht den eingebauten char* == char* Operator geben würde^^

Oder hab ich da was falsch verstanden? Jedenfalls kommt es mir so vor, als würde es komplett ohne casten gehen..??.?

grüße

Wenn ich Compiler wäre, würde ich sowohl ob2 als auch ob3 in const char* umwandeln, dann müsste es ja funktionieren...

Ja, denke ich auch. (Allerdings betrachte ich den operator == (string&, string&) als den für die Klasse typischen Operator und den
operator == (string&, char*) als sekundäre Anpassung an externe char*'s.)

Würde auch funktionieren, wenn es nicht den eingebauten char* == char* Operator geben würde^^

Oder hab ich da was falsch verstanden?

Beim dem Satz oben bekomme ich schon den Eindruck, dass Du vielleicht etwas falsch verstanden hast. Der eingebaute operator == (char*, char*) ist ja das, was in den diskutierten Situationen immer vermieden werden muss. Ich weiss nicht ob Du string und char* zu sehr vermischt. Du hattest da einige nicht ganz richtigen Formulierungen wie:

Schließlich besteht die Klasse nur aus einem char*, ...

Für den string-vergleich spielt es in der Tat keine so grosse Rolle, dass die Klasse auch noch andere Elemente enthält.

In meinen Beispielen habe ich statt des notwendigen Codes für den Vergleich immer nur return 0/1 geschrieben, nur um etwas kompilierbares zu haben. Ich hoffe, das hat niemanden verwirrt.

In meinen Beispielen habe ich statt des notwendigen Codes für den Vergleich immer nur return 0/1 geschrieben, nur um etwas kompilierbares zu haben. Ich hoffe, das hat niemanden verwirrt.

Glaube nicht, dass du jemanden verwirrt hast

hgf schrieb:

Allerdings betrachte ich den operator == (string&, string&) als den für die Klasse typischen Operator [...]

Im Prinzip ja, aber IMO bräuchte man als zweiten Parameter ja gar kein string&, wenn der sowieso in ein const char* gecastet wird (werden kann). Deckt man halt ein größeres Feld mit dem Operator ab

hgf schrieb:

Für den string-vergleich spielt es in der Tat keine so grosse Rolle, dass die Klasse auch noch andere Elemente enthält.

Ich dachte immer, der Compiler benutzt die eingebauten Operatoren, wenn die Klasse nur aus einem Typ besteht...?

hgf schrieb:

Der eingebaute operator == (char*, char*) ist ja das, was in den diskutierten Situationen immer vermieden werden muss.

Das wollte ich ja auch gar nicht! Mir ging es ja nur um den Operator const char*. Also auch operator== (const char*, const char*). Gilt da das auch noch mit dem Vermeiden? Wenn ja, warum?

PS: Danke für die Antwort

Das wollte ich ja auch gar nicht! Mir ging es ja nur um den Operator const char*. Also auch operator== (const char*, const char*). Gilt da das auch noch mit dem Vermeiden? Wenn ja, warum?

Weil auch dieser nur Zeiger vergleicht, und nicht Inhalte.

hgf schrieb:

Allerdings betrachte ich den operator == (string&, string&) als den für die Klasse typischen Operator [...]

Im Prinzip ja, aber IMO bräuchte man als zweiten Parameter ja gar kein string&, wenn der sowieso in ein const char* gecastet wird (werden kann). Deckt man halt ein größeres Feld mit dem Operator ab

Nein, eine String-Klasse hat üblicherweise auch einen Ctor, der (const) char* entgegennimmt - und dann ist es letztlich egal, ob die Umwandlung von char* nach string bei der Parameter-Übergabe passiert oder im Inneren des op==.

hgf schrieb:

Für den string-vergleich spielt es in der Tat keine so grosse Rolle, dass die Klasse auch noch andere Elemente enthält.

Ich dachte immer, der Compiler benutzt die eingebauten Operatoren, wenn die Klasse nur aus einem Typ besteht...?

Falsch gedacht. Der Compiler benutzt die eingebauten Operatoren immer, wenn er in der Lage ist, deine Klasse in einen Build-in Typ umzuwandeln (und nichts "besseres" zur Verfügung steht). Sprich: Sobald deine Klasse 'string' einen op char* anbietet, denkt er zumindest darüber nach, die Vergleiche auf char*-Ebene durchzuführen.

Badestrand schrieb:

Das wollte ich ja auch gar nicht! Mir ging es ja nur um den Operator const char*. Also auch operator== (const char*, const char*). Gilt da das auch noch mit dem Vermeiden? Wenn ja, warum?

Weil auch dieser nur Zeiger vergleicht, und nicht Inhalte.

Wenn ich den Operator überschreibe (bzw halt op== string&, const char*), vergleicht er ja eben nicht mehr die Zeiger. Sonst bräuchte ich den Operator ja nicht...

CStoll schrieb:

Nein, eine String-Klasse hat üblicherweise auch einen Ctor, der (const) char* entgegennimmt - und dann ist es letztlich egal, ob die Umwandlung von char* nach string bei der Parameter-Übergabe passiert oder im Inneren des op==.

Achso, na gut... Aber verbraucht die Umwandlung in ein (bzw Erstellung eines) string-Objekt(es) dann nicht mehr Laufzeit als ein Cast? Den Cast könnte man ja inlinen, dann muss ja nur das Objekt direkt auf den Stack gepusht werden. Wenn das Objekt erstellt wird, muss es ja auf dem Stack erzeugt werden (was ja nicht viel kostet), aber dann wird der Konstruktor aufgerufen, der String kopiert, übergeben und dann der Destruktur ausgeführt... Das dürfte der Compiler ja eigentlich nicht weg-optimieren.
Und was meinst du mit "Umwandlung [...] im Inneren des op=="? Im Inneren des op musst du ja nicht nach string umwandeln. In dem Fall kann man doch einfach strcmp aufrufen oder eine ähnliche Funktion durchlaufen lassen

Nach wie vor: Ich sehe immer noch keinen Nachteil, in eine String-Klasse den operator const char* zu implementieren :xmas2: