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ß

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.

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ß

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.

Gruß

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

Gruß

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.

Gruß

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.

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?

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).

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ß

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.

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/

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.

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..

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.

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.

ist einer der Fälle, in denen man leicht auf std::string verzichten kann, denn es wird ein std::string-Objekt erzeugt, nur um auf den c_str zuzugreifen.
Sobald aber die parse-Funktion den fileName nicht direkt verwendet, sondern z.B. in einem Daten-Verzeichnis nach einer Datei mit dem Namen sucht und zur Pfad-Zusammensetzung string-Operationen durchgeführt werden, kann sich der std::string schon wieder lohnen.

Also, const char* nicht gleich verteufeln, es gibt (eben auch in der Standard-Bibliothek) genügend Verwendungsmöglichkeiten.

Klar gibt es Verwendungsmöglichkeiten für C-Strings, aber die sind nicht da, wo man dann einen std::string nachbaut.
Obwohl.. Mir fällt kein richtig gutes Argument/Anwendungsgebiet wo C-Strings std::string wirklich überlegen sind ein, abgesehen von alten Schnittstellen.

Das ist 1 int mehr als bei char*. Dafür braucht's ein char weniger, weil die Nullterminierung entfällt.

Nicht ganz. Das ist 1 size_t mehr, welches auf 64 bit Systemen einem uint64_t entspricht

Also 1 Byte vs 8 Byte.

Wer allerdings bei Stringverkettungen nicht zuviel Performance verlieren möchte, sollte wie bei C Strings den benötigten Speicherbedarf errechnen/schätzen und dann via reserve() genügend reservieren.

void MyClass::parse(const std::string& fileName)
{
    std::ifstream stream( fileName.c_str() );
    ////
}

MyClass class;
class.parse( "Hello.txt" );

Oh je, solche Dinger sind ECHTE Performancefresser. Mit echte meine ich ECHTE.
Bitte so schreiben:

void MyClass::parse(const std::string& fileName)
{
    std::ifstream stream( fileName.c_str() );
    ////
}

MyClass class;
static const std::string halloString = "Hello.txt";
class.parse( halloString );

std::string Referenzen niemals mit statischen c-strings füttern

mfg~

> std::string Referenzen niemals mit statischen c-strings füttern

Und warum bitte?