Abgeleitete string Klasse

Ich habe folgender Code geschrieben

class octet : public std::string
{
    public:
        octet() {;}

        octet( const string value ) : std::string( value )
        {
        }

        const string operator=( string value )
        {
            return string::operator=( value );
        }

        const string operator=( const char value[] )
        {
            return string::operator=( value );
        }

        const string operator=( const char value )
        {
            return string::operator=( value );
        }   

        int toInt()
        {
            return hexToInt( string::operator+=( "" ) );
        }

        string toBin()
        {
            return hexToBin( string::operator+=( "" ) );
        }
};

Wie kann ich auf den string zugreifen ohne die string::operator+=("") zu benutzen? Dies ist sicherlich nicht die gedachte Methode, oder?

Entschuldigt für die doofe Frage aber ich weiss es wirklich nicht.

Eine andere Frage wäre, ich habe eine map z.B map<int,string> meineMap, es existiert aber noch eine andere map, nämlich map<int,octet> deineMap, eigentlich ist ja ein octet ein string mit 2 zusätzlichen methoden, aber folgendes functioniert nicht: meineMap = deineMap, gibt's irgend ein Mechanismus bei dem man nicht meineMap in ein <int,octet> umwandeln muss?

Vielen Dank im Voraus

Shade Of Mine

Blöde Frage:
warum erbst du von std::string?
Die beiden Funktionen toBin und toInt kann man doch genauso gut als non Member implementieren - was man IMHO auch machen sollte, da es eleganter ist.

Shade Of Mine schrieb:

Blöde Frage:
warum erbst du von std::string?
Die beiden Funktionen toBin und toInt kann man doch genauso gut als non Member implementieren - was man IMHO auch machen sollte, da es eleganter ist.

Weil es recht oft, z.B., diesen Aufruf gibt

cout << ringValue[binToInt( hexToBin( context.getActualElement() ).substr( 3, 5 ) )] << " \n";

Christoph

Dann schreib dafür eine non-Member Funktion. :p

Worauf Shade hinauswollte: std::string ist nicht dazu da, um davon zu erben. Das sieht man schon daran, dass der Destruktor nicht virtual ist.

Shade Of Mine

WilderSchorsch schrieb:

Weil es recht oft, z.B., diesen Aufruf gibt
cout << ringValue[binToInt( hexToBin( context.getActualElement() ).substr( 3, 5 ) )] << " \n";

Und ringValue[context.getActualElement().toBin().substr( 3, 5 ) ).toInt()]

ist besser?
Das ist doch Syntax-Zucker. Ich sehe keinen Grund warum toBin eine Memberfunktion sein sollte.

Shade Of Mine schrieb:

WilderSchorsch schrieb:
Weil es recht oft, z.B., diesen Aufruf gibt
cout << ringValue[binToInt( hexToBin( context.getActualElement() ).substr( 3, 5 ) )] << " \n";
Und ringValue[context.getActualElement().toBin().substr( 3, 5 ) ).toInt()]

ist besser?
Das ist doch Syntax-Zucker. Ich sehe keinen Grund warum toBin eine Memberfunktion sein sollte.

Nee aber:

ringValue[context.getActualOctet().binRangeToInt(3, 5)]

(die Methode binRangeToInt(int,int) existiert bereits)

das Obige ist leserlicher als:

ringValue[binToInt(hexToBin(context.getActualOctet().substr(3, 5)))]

Vor allem muss man nicht auf die Verschachtelung der Klammern aufpassen...

BTW, meine ursprüngliche Frage ist immer noch aktuell, wie zum Kukuck greife ich auf den string zu ohne die vermurkste return operator+=("") methode?

Christoph

*this

cd9000 schrieb:

*this

Vielen Dank

BTW, warum soll es so schlimm sein von string zu erben?

Christoph

cd9000 schrieb:

std::string ist nicht dazu da, um davon zu erben. Das sieht man schon daran, dass der Destruktor nicht virtual ist.

cd9000 schrieb:

cd9000 schrieb:

std::string ist nicht dazu da, um davon zu erben. Das sieht man schon daran, dass der Destruktor nicht virtual ist.

Da ich keine pointers in der Klasse erzeuge die man zerstören muss habe nehme ich an, dass mein Fall keine Probleme auftauchen sollte.

Oder muss ich besser eine eigene String klasse basteln?

Shade Of Mine

WilderSchorsch schrieb:

ringValue[context.getActualOctet().binRangeToInt(3, 5)]
(die Methode binRangeToInt(int,int) existiert bereits)

das Obige ist leserlicher als:
ringValue[binToInt(hexToBin(context.getActualOctet().substr(3, 5)))]

Und was spricht gegen

ringValue[ binRangeToInt(getActualOctect(context), 3, 5) ]

Du scheints nicht zu verstehen:
Ein ableiten ist sinnlos. Die goldene Regel lautet: alle Funktionen die man auch als non Member implementieren kann, sollten keine member sein.

Was machst du, wenn du eine neue Methode brauchst? von octet erben? Das läuft darauf hinaus, dass jeder von octet erbt und du auf einmal die funktionalitaet von octet2 und octet3 brauchst - welche beide von octet erben.

Aus genau diesem Grund gibt es non-member Funktionen um die Funktionalitaet einer Klasse zu erweitern.

Shade Of Mine schrieb:

Und was spricht gegen
ringValue[ binRangeToInt(getActualOctect(context), 3, 5) ]
Du scheints nicht zu verstehen:
Ein ableiten ist sinnlos. Die goldene Regel lautet: alle Funktionen die man auch als non Member implementieren kann, sollten keine member sein.

Was machst du, wenn du eine neue Methode brauchst? von octet erben? Das läuft darauf hinaus, dass jeder von octet erbt und du auf einmal die funktionalitaet von octet2 und octet3 brauchst - welche beide von octet erben.

Aus genau diesem Grund gibt es non-member Funktionen um die Funktionalitaet einer Klasse zu erweitern.

Im Grunde genommen spricht nichts dagegen, die angesprochenen methoden sind aber immer noch öffentlich, wer die benutzen will muss nichts erben...

Bevor das Ganze ausartet, mein Programm is ein Isdnserver und Dekoder, mittlerweile hat es eine beachtliche Grösse erreicht und einige Leute haben sich bereit erklärt zum code beizutragen. Octet soll ein byte räpresentieren das durch eine HEX Zahl dargestellt wird, bis jezt wurde das einfach durch einen string realisiert, in Zukunft will ich es aber durch einen integer ersetzen. Damit nacher ich nicht tausende von Zeilen durchchecken muss und ändern muss, zwinge ich die Leute jetzt schon eine vordefinierte Klasse zu benutzen, aber ich will Ihnen auch gewisse Bequemlichkeiten anbieten...

Christoph

Dann ist es aber Blödsinn von string public zu erben. Du könntest höchstens private erben. Oder ein string-Objekt als Member haben.

Wenn du public von string erbst, "zwingst" du niemanden deine Klasse richtig zu benutzen. Überleg dir, was die Klasse Octet bieten muss, implementier diese Funktionen. Aber nicht mehr. Auf gar keinen Fall alle Funktionen die std::string bietet, vor allem wenn Octet später intern durch einen Integer repräsentiert wird.

cd9000 schrieb:

Dann ist es aber Blödsinn von string public zu erben. Du könntest höchstens private erben. Oder ein string-Objekt als Member haben.

Wenn du public von string erbst, "zwingst" du niemanden deine Klasse richtig zu benutzen. Überleg dir, was die Klasse Octet bieten muss, implementier diese Funktionen. Aber nicht mehr. Auf gar keinen Fall alle Funktionen die std::string bietet, vor allem wenn Octet später intern durch einen Integer repräsentiert wird.

Wo du recht hast...

Ich hab's geändert, aber jetzt functioniert folgendes nicht mehr

string getMessageType(const octetObj& octet)
{
    map<octetObj,string> text;

    text["01"]="ALERTING";
    text["02"]="CALL PROCEEDING";
    text["03"]="PROGRESS";

    // ...

    return text[octet];
}

ich habe in octet eine const string &operator[]( string ) methode implementiert, aber leider funktioniert's nicht.

Christoph

Implementier einen Konstruktor, der einen const char* übernimmt.

Dann müsste der Code funktionieren.

btw: Eine "const string &operator[]( string )"-Methode bringt in octetObj nicht viel. Du rufst doch den operator[] von map und nicht den von octetObj auf.

cd9000 schrieb:

Implementier einen Konstruktor, der einen const char* übernimmt.

Dann müsste der Code funktionieren.

btw: Eine "const string &operator[]( string )"-Methode bringt in octetObj nicht viel. Du rufst doch den operator[] von map und nicht den von octetObj auf.

Vielen Dank!

Ich musste nachher nur noch die > und < operatoren implementieren, jetzt funktionierts tadellos!