Set- und Getterfunktionen verwenden oder nicht?

[loks]

NewSoftzzz schrieb:

l'abra d'or schrieb:

Im Binary wird das String-Literal mit in den Speicher geladen, und sobald der static const std::string erstellt wird wird dieses Literal dem Konstruktor übergeben, welcher das Chararray als Kopie zu den Membervariablen legt.

Es gibt bestimmt einen const std::string Constructor, der einen Übergebenes c-string-literal als Buffer benutzt, und eben keinen eigenen anlegt? Wenn es den nicht geben würde, wäre das ziemliche Ressourcenverschwendung

mfg, René~

Das würde vorraussetzen das std::strings immuteable sind, was aber nicht der Fall ist...

[camper]

loks schrieb:

Das würde vorraussetzen das std::strings immuteable sind, was aber nicht der Fall ist...

Kein Problem mit COW. Allerdings kann der string nicht wissen, ob das Argument selbst unveränderlich ist, noch kann das mitgeteilt werden.

char foo[]="abcd";
string bar = foo;
foo[0]='e';
// bar ist hier immer noch "abcd"

Folglich muss stets eine Kopie angelegt werden. iirc hat Qts QString eine solche shallow-copy Funktionalität.

[NewSoftzzz]

Wir reden aber von nem static const std::string

Der sollte doch immutable sein..

mfg, René~

[LordJaxom]

NewSoftzzz schrieb:

Wir reden aber von nem static const std::string

Der sollte doch immutable sein..

Das weiss der const char* Konstruktor aber immernoch nicht.

[camper]

Abgesehen vom WTF-Faktor, bekämpft NewSoftzzz ohnehin nur Symptome und nicht das Problem. Dient eine Stringklasse primär der Verwaltung von Zeichenketten, ist diese überflüssig, wenn wir mit Literalen hantieren. Die aufgerufene Funktion interessiert ja offenbar sowieso nicht, wie die Zeichenkette gespeichert wird. Folglich ist die aufzurufende Funktion zu ändern, und nicht beim Aufrufer zusätzlicher Unfug zu betreiben. z.B.

void MyClass::parse(const char* begin, const char* end); // macht die eigentliche Arbeit
// kann auch allgemeiner als Template mit geeigneten Iteratoren gestaltet werden

void MyClass::parse(const char* str)
{
    return parse( str, str + strlen( str ) );
}
template<size_t N>
void MyClass::parse(const char (&str)[N])
{
    return parse( str, str + N - 1 );
}

void MyClass::parse(const string& s)
{
    return parse( s.data(), s.data() + s.size() );
}

Alles andere führt nur dazu, dass die aufzurufende Funktion unnötige Anforderungen an ihre Parameter stellt, was überflüssige Koppelung bedeutet. Und nur ganz nebenbei ist es ineffizient.

[loks]

NewSoftzzz schrieb:

Wir reden aber von nem static const std::string

Der sollte doch immutable sein..

mfg, René~

Ich bezog mich auf immutable Klasse, const dagegen erzeugt nur immutable Objekte. (Vergleiche String von C# oder Java, da sind die Klassen selbst immutable)

std::string ist keine solche Klasse weil hier Änderungen immer auf den internen Buffer angewendet werden. (by design, schon klar) const kannste Du problemlos wegcasten (ebenfalls by design) und schon ist das Objekt wieder veränderbar:

const std::string text = "hahahaha";
const_cast<std::string*>(&text)->insert(0, "aber", 4);

Auch mit const kannst Du also nicht verhindern das jemand bewußt den Inhalt des Objektes verändert, weil die Klasse std::string nicht immutable ist.

[NewSoftzzz]

camper schrieb:

void MyClass::parse(const char* begin, const char* end); // macht die eigentliche Arbeit
// kann auch allgemeiner als Template mit geeigneten Iteratoren gestaltet werden

void MyClass::parse(const char* str)
{
    return parse( str, str + strlen( str ) );
}
template<size_t N>
void MyClass::parse(const char (&str)[N])
{
    return parse( str, str + N - 1 );
}

void MyClass::parse(const string& s)
{
    return parse( s.data(), s.data() + s.size() );
}

Und das ist jetzt leserlicher als ein static const std::string?

Und ganz davon abgesehen, nur um keinen static const std::string benutzen zu müssen, soll ich alle Algorithmen umschreiben auf C-string Basis? Zurück in die Steinzeit?

loks schrieb:

Auch mit const kannst Du also nicht verhindern das jemand bewußt den Inhalt des Objektes verändert, weil die Klasse std::string nicht immutable ist.

Na und? Man kann auch nen NULL-Pointer dereferenzieren, aber solche Sachen muss man als Library-Ersteller (oder auch Klassen-Entwickler) nicht berücksichtigen. Das ist also kein Argument.

mfg, René~

[camper]

NewSoftzzz schrieb:

Und das ist jetzt leserlicher als ein static const std::string?

selbstverständlich.

NewSoftzzz schrieb:

Und ganz davon abgesehen, nur um keinen static const std::string benutzen zu müssen, soll ich alle Algorithmen umschreiben auf C-string Basis?

Wie kommst du auf C-String?

[NewSoftzzz]

camper schrieb:

Wie kommst du auf C-String?

void MyClass::parse(const char* begin, const char* end);

Das ist der neue Algorithmus und der funktioniert ja ganz offensichtlich auf C-String Basis.

mfg~

[camper]

NewSoftzzz schrieb:

camper schrieb:

Wie kommst du auf C-String?

void MyClass::parse(const char* begin, const char* end);

Das ist der neue Algorithmus und der funktioniert ja ganz offensichtlich auf C-String Basis.

mfg~

Ganz offensichtlich nicht. Hier wird nicht mit 0-Terminierung gearbeitet, sondern mit Zeichensequenzen - folglich kannst du ganz normale Standardalgorithmen verwenden.

[NewSoftzzz]

camper schrieb:

Ganz offensichtlich nicht. Hier wird nicht mit 0-Terminierung gearbeitet, sondern mit Zeichensequenzen - folglich kannst du ganz normale Standardalgorithmen verwenden.

Sind aber trotzdem raw char pointers und es wird keine Containerklasse benutzt. Außerdem ist das Umschreiben des Algorithmus wohl 100 mal mehr Arbeit, als ein static const std::string davor zu schreiben, oder?

Und in diesem Fall gibt es ja WIRKLICH keinen Performancevorteil.

Das wäre dann WIRKLICH premature optimizing.

mfg, René

[camper]

NewSoftzzz schrieb:

camper schrieb:

Ganz offensichtlich nicht. Hier wird nicht mit 0-Terminierung gearbeitet, sondern mit Zeichensequenzen - folglich kannst du ganz normale Standardalgorithmen verwenden.

Sind aber trotzdem raw char pointers und es wird keine Containerklasse benutzt.

Das sind Iteratoren. Und wozu Container, wenn es nichts aufzubewahren gibt.

NewSoftzzz schrieb:

Außerdem ist das Umschreiben des Algorithmus wohl 100 mal mehr Arbeit, als ein static const std::string davor zu schreiben, oder?

Wenn du die ganzen static-strings schon verbrochen hast - sicher.

NewSoftzzz schrieb:

Und in diesem Fall gibt es ja WIRKLICH keinen Performancevorteil.

Ich weiss nicht, was du vergleichst. Zudem ging es mir gerade nicht um irgendein fiktives Laufzeitverhalten-

NewSoftzzz schrieb:

Das wäre dann WIRKLICH premature optimizing.

Und das eine ziemlich kreative Deutung.

[l'abra d'or]

NewSoftzzz schrieb:

Und in diesem Fall gibt es ja WIRKLICH keinen Performancevorteil.

Das wäre dann WIRKLICH premature optimizing.

In dem Fall ist es vorausschauendes, flexibles Interfacedesign. Wenn ich mich - nur weil ich C++ schreibe und C++ ist OOP uns da brauche ich Klassen - stur auf std::string als Parameter für die Schnittstelle und bei den Algorithmen festlege, binde ich mich in der Verwendung.

Und das sind nicht wirklich "nur" reine rohe char-Pointer, das sind "Iteratoren". Du kannst sie hoch- und runterzählen, vergleichen, usw. Du kannst wenn du lustig bist nur einen Substring übergeben - ohne großem Rechen- und Kopieraufwand! einfach im char-Array zwei Pointer übergeben und fertig. So kann dein Algorithmus problemlos ohne Kopien (!) performant arbeiten.

Das war ja jetzt nicht ein Beispiel für dich und deinen Server, sondern auf das "parse" ausgelegt, was nahelegt, dass ein string (ob C oder std::) von Anfang bis Ende abgeklappert und nötige Information extrahiert wird. Da macht so ein Interface durchaus Sinn.

[loks]

NewSoftzzz schrieb:

loks schrieb:

Auch mit const kannst Du also nicht verhindern das jemand bewußt den Inhalt des Objektes verändert, weil die Klasse std::string nicht immutable ist.

Na und? Man kann auch nen NULL-Pointer dereferenzieren, aber solche Sachen muss man als Library-Ersteller (oder auch Klassen-Entwickler) nicht berücksichtigen. Das ist also kein Argument.

mfg, René~

Versuchst Du eigendlich auch mal den Standpunkt anderer Leute zu verstehen oder weisst du schon alles so viel besser das Du das nciht mehr nötig hast? Ich wollte lediglich verdeutlichen das std::string KEINE immutable Klasse ist und habe versucht an einem Beispiel zu verdeutlichen warum ein const vor der Variablendeklarierung etwas anderes ist als eine immutable klasse.