Set- und Getterfunktionen verwenden oder nicht?

theliquidwave

Hallo.
Ich habe schon des öfteren davon gelesen, und es auch in vielen Sourcecodes gesehen. Es gibt einfach keine public-Membervariablen, sondern jede von ihnen hat eine Getter- und/oder Setterfunktion.

Ich habe dazu ein paar Fragen.
1.) Wozu genau ist das gut? Ich persönlich finde es "schöner".
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?
3.) Gibt es Tools, die solche Funktionen automatisch erzeugen können (bevorzugt für MSVC)?
4.) Würdet ihr bei boolschen Funktionen "getIsActive" oder "isActive" benutzen?
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?

Damit auch jeder versteht was ich meine, hier ein kurzes Beispiel:

class CClass
{
public:
    CClass(char *pszName, bool bActive)
    {
        this->setName(pszName);
        this->setActive(bActive);
    }
    ~CClass(void)
    {
        if (this->m_pszName)
        {
            delete[] this->m_pszName;
        }
    }

    char *getName(void)
    {
        return this->m_pszName;
    }
    bool isActive(void) // siehe Frage
    {
        return this->m_bActive;
    }
    int getNumItems(void)
    {
        return this->m_vecItems.size();
    }

    void setName(char *pszName)
    {
        if (this->m_pszName)
        {
            delete[] this->m_pszName;
            this->m_pszName = NULL;
        }

        this->m_pszName = new char[strlen(pszName) + 1]; // brauch ich das + 1 eigentlich? (ich gehe davon aus wegen dem \0)
        strcpy(this->m_pszName, pszName);
    }
    void setActive(bool bActive)
    {
        this->m_bActive = bActive;
    }

private:
    char *m_pszName;
    bool m_bActive;
    std::vector<int> m_vecItems;
};

Gruß

l'abra d'or

Wenn du Member public machst, kannst du gleich C Programmieren mit Structs
Du hast einfach Kontrolle, du kannst die zu setzende Variable in dem setter prüfen, ob sie bestimmte Kriterien erfüllt.
Dann hast du bei multithreaded-Anwendungen nur über setter/getter die Möglichkeit zu synchronisieren! Bei public-Membern ist das nicht so einfach.
und sicher gibt es noch viele andere Argumente.
10 Aufrufe/sec? Du scherzt, oder?
Sicher gibt es sowas wie Klassenwizards. Und Tools um neue Member samt getter + setter hinzuzufügen. Aber generiert werden da ja effektiv max. 7 Zeilen, die sind auch gleich per Hand geschrieben.
Wenn du die getter + setter im Header stehen hast, und die nicht sehr lange sind, wird die dein Compiler recht wahrscheinlich inlinen. Keine Ahnung ob das alle Compiler auch selber hinkriegen, wenn die Definition in einer separaten Datei (*.cpp) liegt.

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.