ich habe einen merkwürdigen Effekt. Hier ein Auszug aus dem Header:

inline STRING &operator >> ( int value, STRING &destination )
{
    return ((long)value) >> destination;
}
STRING &operator >> ( long value, STRING &destination );

Wenn der Operator mit einem int aufgerufen wird, soll dieser nach long konvertiert werden und die Version mit long aufgerufen werden. Das klappt auch unter 32-Bit Windows mit den Borland Compilern (BC++ 5.02 und BCB 5) wunderbar. Auf einem System mit 64-Bit Linux und Gnu Compiler bekomme ich eine Rekursion, die natürlich gnadenlos abstürzt.

Meiner Meinung nach ist das Verhalten von Gnu nicht korrekt und der Source Code korrekt. Wie seht Ihr das?

mfg Martin
P.S.: Ich will keine Lösungsvorschläge, die habe ich schon selbst gefunden. Es geht mir nur darum, was der Standard dazu sagt. Deshalb ist auch diese Frage hier und nicht im Linux-Forum.

Übrigens sieht man in C++ eher

Datenbehaelter << Wert

als

Wert >> Datenbehaelter

Mach die long -Überladung vor dem Aufrufzeitpunkt bekannt.

Das könnte es sein. Der Borland Compiler ist da wohl etwas fehlertoleranter. Was sagt denn der Standard dazu? Bei Memberfunktionen ist ja die Reihenfolge egal. Da das aber keine Memberfunktionen sind, sollte es wohl eher so sein, wie im Standard ANSI-C. Daher ist es wohl doch eher ein Fehler des Borland-Compilers, oder aber das übliche "The behaviour is undefined" und ich hatte nur bisher Glück gehabt. Jedenfalls Danke für den Hinweis. Das habe ich echt übersehen.

Nexus schrieb:

Übrigens sieht man in C++ eher

Datenbehaelter << Wert

als

Wert >> Datenbehaelter

Ähm ja, das kann schon sein. Ich muß dazu erklären, daß der Code schon sehr sehr alt ist. Ich habe keine Ahnung mehr, warum ich das damals so gemacht habe. Wahrscheinlich, weil ich vom Motorola-assembler gewohnt bin, zuerst Quelle dann das Ziel.

mfg Martin

Was ist STRING ?

Das spielt zwar für die Beantwortung meiner Frage keine Rolle aber egal:

Das ist eine selbst entwickelte Klasse zur Zeichenkettenverarbeitung ähnlich wie std::string.

Und bevor irgendwelche Bemerkungen kommen, die Klasse ist sehr alt und std::string war damals noch nicht standardisiert bzw gab es noch gar nicht.

mfg Martin

Nexus schrieb:

Mach die long -Überladung vor dem Aufrufzeitpunkt bekannt.

Das könnte es sein. Der Borland Compiler ist da wohl etwas fehlertoleranter. Was sagt denn der Standard dazu? Bei Memberfunktionen ist ja die Reihenfolge egal. Da das aber keine Memberfunktionen sind, sollte es wohl eher so sein, wie im Standard ANSI-C. Daher ist es wohl doch eher ein Fehler des Borland-Compilers, oder aber das übliche "The behaviour is undefined" und ich hatte nur bisher Glück gehabt. Jedenfalls Danke für den Hinweis. Das habe ich echt übersehen.

Fehler des Compiler, wahrscheinlich durch dqs inline verursacht. Vermutlich wird die Funktiondefinition noch einmal erneut ausgewertet, wenn der Code inline eingefügt werden soll, und Borland macht dabei den Fehler, die Funktion nicht im Kontext der ursprünglichen Definition zu betrachten.

Fehler des Compiler, wahrscheinlich durch dqs inline verursacht. Vermutlich wird die Funktiondefinition noch einmal erneut ausgewertet, wenn der Code inline eingefügt werden soll, und Borland macht dabei den Fehler, die Funktion nicht im Kontext der ursprünglichen Definition zu betrachten.

Ich gehe mittlerweile auch davon aus, daß BC++ Murks macht. Für alle, die's nachstellen wollen:

#include <string.h>
#include <stdio.h>

class STRING
{
    char    text[256];

    public:
    void setText( const char *t )
    {
        strcpy( text, t );
    }

    const char *getText( void ) const
    {
        return text;
    }
};

STRING &operator >> ( long value, STRING &destination );
inline STRING &operator >> ( int value, STRING &destination )
{
    return ((long)value) >> destination;
}

STRING &operator >> ( long value, STRING &destination )
{
    char    tempBuffer[32];

    sprintf( tempBuffer, "%ld", value );
    destination.setText( tempBuffer );

    return destination;
}

int main( void )
{
    STRING  str;
    int     value = 55;

    value >> str;

    printf( "%s\n", str.getText() );

    return 0;
}

Ist der Prototyp STRING &operator >> ( long value, STRING &destination ); nach der Inlinefunktion, kracht es. So wie hier jedoch nicht.

mfg Martin