Set- und Getterfunktionen verwenden oder nicht?

[SeppJ]

theliquidwave schrieb:

Ich habe dazu ein paar Fragen.
1.) Wozu genau ist das gut? Ich persönlich finde es "schöner".

Das ist eigentlich zu nichts gut. Für jede Variable einen Getter/Setter zu schreiben ist etwas das Leute tun, die mal was von Objektorientierung und Kapselung gehört, aber nicht verstanden haben. Im Prinzip macht man das Konzept damit nämlich wieder kaputt. Guter Stil wäre es, sinnvolle Methoden zur Manipulation eines Objekts anzubieten, anstatt alle Variablen einzeln veränderbar zu machen.

2.) Mir macht die Geschwindigkeit "sorgen". Ich weiß zwar, dass C++ verdammt schnell ist, doch können Setter- bzw. Getterfunktionen die Geschwindigkeit bei ca. 10 Aufrufen pro Sekunden deutlich beeinträchtigen?

Oho, 10 Aufrufe pro Sekunde. Ich glaube da hat selbst die Zuse Z5 mehr geschafft.

So kurze Funktionen werden garantiert inline gemacht, da verliert man nichts.

5.) Generell benutze ich C++- und Headerdateien. Würdet ihr mir empfehlen, wenn ich Getter und Setter benutze, diese direkt in die Headerdatei zu schreiben, oder dann doch auch mit in die C++-Datei?

In den Header, dann klappt das noch eher mit dem inline.

[theliquidwave]

Hi.
Danke für die Antworten!

Oho, 10 Aufrufe pro Sekunde. Ich glaube da hat selbst die Zuse Z5 mehr geschafft.

Ich mach mir immer zu viele Gedanken

In den Header, dann klappt das noch eher mit dem inline.

Ok. Könnte ein zusätzliches "inline" da noch mehr bewirken / ich mir sicher sein, dass es wirklich inline wird?

Noch einmal ausschweifend: Inline-Funktionen werden also vom Compiler direkt in den Code kompiliert? Dann müsste das hier zum Beispiel:

inline CClass *CClassManager::getClass(char *pszName)
{
    CClass *pClass = NULL;
    // iterieren, etc...
    return pClass;
}

CClass *pClass = pClassManager->getClass("aaa");

zu folgendem werden (Compilerintern):

CClass *pCompilerOptimizedClass = NULL;
// iterieren, etc...
CClass *pClass = pCompilerOptimizedClass;

Vorteile:
- schneller?
Nachteile:
- Compilen langsamer da mehr Code entsteht

Also kann man abschließend sagen, dass inline-Funktionen "quasi" C++-ische Makros sind? (also vom Prinzip her ^^)

Gruß

[audacia]

theliquidwave schrieb:

Also kann man abschließend sagen, dass inline-Funktionen "quasi" C++-ische Makros sind? (also vom Prinzip her ^^)

So quasi also vom Prinzip her ja.

[theliquidwave]

Ok, danke. Sorry falls ich mich etwas komisch ausdrücke

Gruß

[Kontrasubjekt]

Ich hasse getter/setter aus stilgründen und versuche sie eigentlich prinzipiell zu vermeiden.
Jedenfalls, es gibt bei einem inline getter keinen Unterschied zu einer normalen zuweisung; es entfällt natürlich der sprung zur Funktion.

[theliquidwave]

Gut, ich werde mir überlegen wie ich das mache - nur eins ist klar: Wenn, dann mache ich es durchgängig, denn das schlimmste ist es (m.M.n.) wenn man sein Stil (zumindest für ein Projekt) nicht beibehält!

Wäre cool wenn mir noch jemand meine "Vermutung" von Zeile 37/38 erklären/bestätigen könnte.

Gruß

[SeppJ]

theliquidwave schrieb:

Wäre cool wenn mir noch jemand meine "Vermutung" von Zeile 37/38 erklären/bestätigen könnte.

Ja, du brauchst das +1, wenn du mit Cstrings arbeitest. Und nein: Arbeite bloß nicht mit Cstrings, nimm stattdessen std::string.

[theliquidwave]

Kommen wir also wieder zur Geschwindigkeit. Es MUSS doch so sein dass std::string langsamer ist als C-Strings oder nicht?! Gibt es da nicht außerdem nen fetten Overhead wegen Templates, usw...? Ich benutze nämlich verdammt viele Strings

Gruß

[drakon]

theliquidwave schrieb:

Kommen wir also wieder zur Geschwindigkeit. Es MUSS doch so sein dass std::string langsamer ist als C-Strings oder nicht?! Gibt es da nicht außerdem nen fetten Overhead wegen Templates, usw...? Ich benutze nämlich verdammt viele Strings

Gruß

Klar hat std::string einen gewissen Overhead gegenüber C-Strings, aber wenn du anfängst C-Strings angenehm benutzbar zu machen, landest du bei so etwas, wie std::string . Und meistens ist der Einsatz von strings eh nicht dort, wo hochperformanter Code gebraucht wird. Also kann man sich das durchaus zugunsten der Flexibilität, Erweiterbarkeit usw. gönnen.

[SeppJ]

theliquidwave schrieb:

Kommen wir also wieder zur Geschwindigkeit. Es MUSS doch so sein dass std::string langsamer ist als C-Strings oder nicht?! Gibt es da nicht außerdem nen fetten Overhead wegen Templates, usw...? Ich benutze nämlich verdammt viele Strings

Gruß

Und wo ist deiner Meinung nach der Zusammenhang zwischen Templates und Geschwindigkeit?

[Ad aCTa]

Der "fette" Template-Overhead macht sich höchstens zur Kompilierzeit bemerkbar, aber da müsstest du schon große Metaprogramme gebaut haben, um das zu merken. std::string ist für die allermeisten Fälle schnell und klein genug. In der Standardbibliothek brauchst du keine Performancebremsen zu suchen.

[Nexus]

theliquidwave schrieb:

Es MUSS doch so sein dass std::string langsamer ist als C-Strings oder nicht?!

Sag mal, warum du glaubst, dass std::string langsamer ist als eine äquivalente Lösung mit C-Strings (eine, welche die selbe Flexibilität bietet).

[theliquidwave]

Hi.
Ok - das mögen Denkfehler sein aber irgendwie geht das aus meinem Hirn nicht so recht raus. Ich denke mir immer, dass ich in den meisten Fällen eh nur strcpy, strstr, strcat und strcmp benutze. Die std::string-Klasse bietet allerdings viel viel mehr Funktionen die ich nie brauche. Und die Funktionen, die ich nicht brauche, werden pro Instanz dann doch als Overhead erstellt obwohl sie es gar nicht müssten.

Ein anderer Grund für mich ist es, dass das SDK das ich benutze (Source SDK von VALVe) ebenfalls NUR mit char* (bzw. const char*) arbeitet. Eine ewige hin- und her-konvertiererei zwischen std::string und char* bleibt mir somit erspart.

Edit: Beispiel. Wie sollte man das mit std::string machen?

//Prototype der SDK-Funktion
void getModDir(char **pszDir);

//Aufruf mit C-String
getModDir(&pszString);

//Aufruf mit std::string
getModDir(&stdString); // ??

Gruß

[Bashar]

theliquidwave schrieb:

Ok - das mögen Denkfehler sein aber irgendwie geht das aus meinem Hirn nicht so recht raus. Ich denke mir immer, dass ich in den meisten Fällen eh nur strcpy, strstr, strcat und strcmp benutze. Die std::string-Klasse bietet allerdings viel viel mehr Funktionen die ich nie brauche. Und die Funktionen, die ich nicht brauche, werden pro Instanz dann doch als Overhead erstellt obwohl sie es gar nicht müssten.

Ohje, völlig falsch. Die Funktionen werden nicht in den Instanzen abgelegt. Im Wesentlichen ist ein Aufruf wie meinString.length() nur eine andere Schreibweise für so etwas wie string_length(&meinString).
Ein klein wenig Overhead gibt es bei virtuellen Funktionen, aber das brauch ich dir hier nicht zu erzählen, string hat nämlich nur nicht-virtuelle Funktionen.

Ein anderer Grund für mich ist es, dass das SDK das ich benutze (Source SDK von VALVe) ebenfalls NUR mit char* (bzw. const char*) arbeitet. Eine ewige hin- und her-konvertiererei zwischen std::string und char* bleibt mir somit erspart.

Das kann ein Grund sein. Der richtige Weg wäre vielleicht eine für diesen Fall angepasste String-Klasse zu verwenden.

[SeppJ]

theliquidwave schrieb:

Hi.
Ok - das mögen Denkfehler sein aber irgendwie geht das aus meinem Hirn nicht so recht raus. Ich denke mir immer, dass ich in den meisten Fällen eh nur strcpy, strstr, strcat und strcmp benutze. Die std::string-Klasse bietet allerdings viel viel mehr Funktionen die ich nie brauche. Und die Funktionen, die ich nicht brauche, werden pro Instanz dann doch als Overhead erstellt obwohl sie es gar nicht müssten.

Nein. std::string speichert als "Overhead" nur die Länge. Das ist 1 int mehr als bei char*. Dafür braucht's ein char weniger, weil die Nullterminierung entfällt. Dafür laufen dann auch Funktionen die die Länge benötigen schneller.

Ein anderer Grund für mich ist es, dass das SDK das ich benutze (Source SDK von VALVe) ebenfalls NUR mit char* (bzw. const char*) arbeitet. Eine ewige hin- und her-konvertiererei zwischen std::string und char* bleibt mir somit erspart.

Edit: Beispiel. Wie sollte man das mit std::string machen?

//Prototype der SDK-Funktion
void getModDir(char **pszDir);

//Aufruf mit C-String
getModDir(&pszString);

//Aufruf mit std::string
getModDir(&stdString); // ??

http://www.cplusplus.com/reference/string/string/c_str/

[Bashar]

SeppJ schrieb:

Edit: Beispiel. Wie sollte man das mit std::string machen?

//Prototype der SDK-Funktion
void getModDir(char **pszDir);

//Aufruf mit C-String
getModDir(&pszString);

//Aufruf mit std::string
getModDir(&stdString); // ??

http://www.cplusplus.com/reference/string/string/c_str/

getModDir(&meinString.c_str()); ? Nicht so prickelnd. Man hat hier keine Chance, als den String in einen std::string umzukopieren.

[drakon]

Bashar schrieb:

theliquidwave schrieb:

Ok - das mögen Denkfehler sein aber irgendwie geht das aus meinem Hirn nicht so recht raus. Ich denke mir immer, dass ich in den meisten Fällen eh nur strcpy, strstr, strcat und strcmp benutze. Die std::string-Klasse bietet allerdings viel viel mehr Funktionen die ich nie brauche. Und die Funktionen, die ich nicht brauche, werden pro Instanz dann doch als Overhead erstellt obwohl sie es gar nicht müssten.

Ohje, völlig falsch. Die Funktionen werden nicht in den Instanzen abgelegt. Im Wesentlichen ist ein Aufruf wie meinString.length() nur eine andere Schreibweise für so etwas wie string_length(&meinString).

Und wenn wir zu einem C-String gehen, dann muss für das count richtig was gemacht werden und nicht nur ein Wert zurückgegeben werden. Also muss man sich einfach überlegen, was man eher braucht. Speicher oder Speed beim zählen..

Einen C-String erhälst du, wie auch schon genannt mit der Memberfunktion c_str() .

Ich bezweifle aber stark, dass es bei dir wirklich einen Performance Unterschied macht, ob du std::string oder einen C-String benutzt..

[Nexus]

theliquidwave schrieb:

Und die Funktionen, die ich nicht brauche, werden pro Instanz dann doch als Overhead erstellt obwohl sie es gar nicht müssten.

Genau hier liegt dein Denkfehler. Funktionen werden weder pro Instanz erstellt, noch werden sie gelinkt, wenn sie nicht gebraucht werden. Bei Templates werden sie nicht mal kompiliert.

theliquidwave schrieb:

Ein anderer Grund für mich ist es, dass das SDK das ich benutze (Source SDK von VALVe) ebenfalls NUR mit char* (bzw. const char*) arbeitet. Eine ewige hin- und her-konvertiererei zwischen std::string und char* bleibt mir somit erspart.

Du meinst, weil andere Bibliotheken kein modernes C++ benutzen, ist das ein Grund, es selbst nicht zu tun? Die Konvertierung ist ja wirklich sehr einfach (Konstruktor oder c_str() ). Wenn du hingegen ein char -Array kopieren willst, musst du 1. die Grösse der Quelle bestimmen, 2. Speicher anfordern, 3. Zeichen für Zeichen rüberkopieren und 4. wieder daran denken, den Speicher nach der Benutzung freizugeben. Das kann schnell mühsam werden, wenn eine Funktion zum Beispiel einen String zurückgeben soll und nicht mehr klar ist, wer für die Freigabe verantwortlich ist. Oder falls Exceptions im Spiel sind. Glaub mir, du handelst dir damit Unmengen Probleme aus C ein, welche durch C++-Techniken wie RAII beseitigt werden.

theliquidwave schrieb:

Edit: Beispiel. Wie sollte man das mit std::string machen?

//Prototype der SDK-Funktion
void getModDir(char **pszDir);

Das geht nicht direkt, weil du einen Zeiger auf einen Zeiger (übrigens auch etwas, das man in C++ fast nie braucht) hast. Aber du hast Glück, dass dieses Problem schon mal aufgetaucht ist und ich den Thread wiedergefunden habe. Hier wäre eine Klasse, die das kann.

[Nexus]

Die verlinkte Klasse ist unter Umständen nicht ideal, da sie für Konvertierungen jeweils umkopiert. Sie ist darauf ausgelegt, dass man selbst einen Container mit Strings (in jenem Fall std::vector<std::string> ) besitzt, der selten einer Schnittstelle mit char** genügen muss.

Allerdings habe ich in diesem Thread auch geschrieben, dass die Klasse bei Bedarf erweitert werden sollte. Sie bietet bereits ein Fundament, um Konvertierungen zu ermöglichen. Weitere Funktionalität muss man sich selbst implementieren, was aber aufgrund des unterliegenden STL-Containers nicht viel mehr Aufwand als ein Funktionsaufruf bedeutet.

Das Wichtigste ist meiner Meinung nach – egal, was für eine Lösung du schlussendlich benutzt – dass fehleranfällige Low-Level-Operationen wie manuelle Speicherverwaltung innerhalb einer Klasse gekapselt sind, sodass der Benutzer sich wirklich wichtigen Dingen zuwenden kann.

[Bashar]

Festzuhalten bleibt in jedem Fall, dass es Fälle gibt, in denen std::string nicht die ideale Lösung ist. Genau das sind die Fälle, in denen in der Praxis Pointer auf C-Strings oder schlechte Eigenbaulösungen verwendet werden.
Oder vielleicht auch gute Eigenbaulösungen, der Vollständigkeit halber. Eigentlich kann es sowas kaum geben, weil man idealerweise ein std::string-kompatibles Interface haben möchte.