Set- und Getterfunktionen verwenden oder nicht?

NewSoftzzz

Athar schrieb:

Wieso weigerst du dich, zwei Zeilen hinzuzufügen, die das Problem endgültig aus der Welt schaffen

DIE METHODE/KLASSE KANN NICHT GEÄNDERT WERDEN.
LERN LESEN!

mfg, René~

Nexus

NewSoftzzz schrieb:

Und dazu stehe ich auch jetzt noch. Es IST allgemeingültig, dafür ist der Performanceunterschied einfach zu hoch, dass die EINE Zeile mehr Code OHNE IRGENDWELCHE Nachteile nicht benutzt werden sollte!!! Siehe benchmark.

Okay, dann macht eine weitere Diskussion mit dir wohl nicht allzu viel Sinn.

Alleine dass du vor deinem Edit static const im Code vergessen hast, zeigt ja, wie wichtig das ist und dass der Vorteil gegenüber einer lokalen Variable hier riesig sein muss. Von den etlichen sinnlosen Anwendungsfälle deines Dogmas, welche ich und andere Leute in diesem Thread nun wirklich zur Genüge erwähnt haben und du trotzdem partout ignorierst, gar nicht zu sprechen.

NewSoftzzz schrieb:

Benchmark fertig:

#include <sys/time.h> 
struct timeval tv; 
int myint; 
void benchmark(const std::string& input) 
{ 
   myint += input.size(); 
} 

int main() 
{ 
   gettimeofday(&tv, NULL); 
   uint64_t start = tv.tv_sec*1000 + (tv.tv_usec / 1000); 
   myint = 0; 
   for(uint64_t i=0; i< 100 * 1000 * 1000; i++) benchmark("This is for all the nonbelievers out there, who think that they shouldn't follow this rule."); 
   gettimeofday(&tv, NULL); 
   uint64_t end = tv.tv_sec*1000 + (tv.tv_usec / 1000); 
   std::cout << myint << ": " << (end - start) << std::endl; 

   gettimeofday(&tv, NULL); 
   start = tv.tv_sec*1000 + (tv.tv_usec / 1000); 
   myint = 0; 
   std::string messageToNonbelievers = "This is for all the nonbelievers out there, who think that they shouldn't follow this rule."; 
   for(uint64_t i=0; i< 100 * 1000 * 1000; i++) benchmark(messageToNonbelievers); 
   gettimeofday(&tv, NULL); 
   end = tv.tv_sec*1000 + (tv.tv_usec / 1000); 
   std::cout << myint << ": " << (end - start) << std::endl; 
}

Gut gemacht. Das sagt etwa so viel aus:

float Value = ComputeComplicatedValue();
for (int i = 0; i < 1200; ++i)
    Function(Value);
// braucht 1 Sekunde

vs.

for (int i = 0; i < 1200; ++i)
    Function(ComputeComplicatedValue());
// braucht 1200 Sekunden. OMFG Faktor 1200!!!!!

Dass ich auf genau diesen Punkt schon mindestens zwei Mal eingegangen bin, brauche ich wohl nicht zu erwähnen.

Aber du kannst dir entweder die Posts von mir und anderen Forenteilnehmern nochmals in Ruhe durchlesen, nachvollziehen und einsehen, dass deine pauschalisierende Aussage der reinste Schwachsinn ist, oder aber du bleibst bei deiner heilen Welt mit static -Strings. Du hast die Wahl, aber mir fehlt die Lust, um auf diesem Niveau weiterzudiskutieren.

Athar

NewSoftzzz schrieb:

DIE METHODE/KLASSE KANN NICHT GEÄNDERT WERDEN.
LERN LESEN!

Äh, bitte was? Du sagtest, dass du einen Server programmierst und nur der Client nicht von dir ist.
Edit: okay, gut.
Edit2: und genau deswegen ist dein Fall ein Ausnahmefall. Dass man gezwungen ist, an einer performanzkritischen Stelle mit einer unflexiblen Bibliothek arbeiten zu müssen, ist nicht der Regelfall.

NewSoftzzz

Nexus schrieb:

Alleine dass du vor deinem Edit static const im Code vergessen hast, zeigt ja, wie wichtig das ist und dass der Vorteil gegenüber einer lokalen Variable hier riesig sein muss.

Das static const braucht man nur, um die Variable über Methodenaufrufe hinweg zu behalten, das ist hier irrelevant, da sich alles in einer Methode abspielt. Und hat nix mit lokalen Variablen zu tun.

Nexus schrieb:

Von den etlichen sinnlosen Anwendungsfälle deines Dogmas, welche ich und andere Leute in diesem Thread nun wirklich zur Genüge erwähnt haben und du trotzdem partout ignorierst, gar nicht zu sprechen.

JEDER, aber auch wirklich JEDER bisherige "sinnlose Anwendungsfall" hat den Bedingungen des Dogmas nicht entsprochen. Aber die muss ich anscheinend in jedem Post wiederholen:

WTF? Es ist doch scheiß egal, warum die Methode einen "const std::string&" Parameter hat, sie HAT ihn einfach. PUNKT. (Die Methode/Klasse ist unveränderbar)

Und die Frage lautet bei einer solchen Methode wenn der string schon zur Compilezeit feststeht:
"c-string-literal oder const static std::string"?

Und die Antwort lautet IMMER:
"const static std::string"

Zeig mir mal bitte einen bisher geposteten sinnlosen Anwendungsfall / Gegenbeweis, der alle Bedingungen erfüllt?

mfg, René~

Nexus

NewSoftzzz schrieb:

Zeig mir mal bitte einen bisher geposteten sinnlosen Anwendungsfall / Gegenbeweis, der alle Bedingungen erfüllt?

Meine Güte, muss ich mich denn wirklich ständig wiederholen? Lies mal meine Beiträge!

Deine Aussage:

NewSoftzzz schrieb:

Ich meinte nur generell, jede Funktion, die eine std::string Referenz als Parameter hat, sollte man mit nem statischen std::string aufrufen.

Meine Antwort (sei Function() eine Funktion mit const std::string& als Parameter). Der folgende Fall wird von deiner Aussage eingeschlossen.

Nexus schrieb:

static std::string String; 
String = OtherString; // OtherString ist nicht-statischer std::string 
Function(String); // Funktion muss aber mit statischem String aufgerufen werden

So, und jetzt überleg bitte, bevor du wieder postest!

@NewSoftzzz,
Ruhig Blut, es will dich niemand töten

NewSoftzzz schrieb:

WTF? Es ist doch scheiß egal, warum die Methode einen "const std::string&" Parameter hat, sie HAT ihn einfach. PUNKT.

Nein, dass stimmt eben nicht ganz. Wenn man über Performance anfängt zu reden, muss man grössere Bereiche anschauen. Du kannst nicht einfach eine Funktion aus ihrem Kontext reissen, sonst macht die Performance-Überlegung keinen Sinn mehr.

Wie es Nexus gesagt hatte, wenn beim Start des Programmes eine Datei einmal geladen wird und dies über eine Funktion geschieht, welche einen std::string erwartet, dann wäre es völliger Unsinn, einen static const std::string zu nehmen, denn du hast dadurch gar keinen Vorteil. Im Gegenteil, die Leserlichkeit geht dadurch verloren. Du verkomplizierst deinen Code unnötig.

Deshalb sollten Performance-Überlegungen immer in einem Kontext stehen. Es ist völlig unsinnig, wenn du anfängst Bereiche zu optimieren, welche gar nicht ins Gewicht fallen. Das ist eine Verschwendung Zeit und es hindert zudem noch die Leserlichkeit.

NewSoftzzz schrieb:

JEDER, aber auch wirklich JEDER bisherige "sinnlose Anwendungsfall" hat den Bedingungen des Dogmas nicht entsprochen. Aber die muss ich anscheinend in jedem Post wiederholen:

Wo ist Volkard, wenn man ihn braucht ...

NewSoftzzz

[Ghost] schrieb:

Wie es Nexus gesagt hatte, wenn beim Start des Programmes eine Datei einmal geladen wird und dies über eine Funktion geschieht, welche einen std::string erwartet, dann wäre es völliger Unsinn, einen static const std::string zu nehmen, denn du hast dadurch gar keinen Vorteil. Im Gegenteil, die Leserlichkeit geht dadurch verloren. Du verkomplizierst deinen Code unnötig.

Nun, zugegebenermaßen, eine Stelle die über die komplette Laufzeit nur EIN einziges mal aufgerufen wird, lohnt nicht. Aber ab 2 mal dann schon.

Nehmen wir die Bedingung halt noch dazu: "Der Aufruf muss mindestens 2 mal erfolgen".

mfg, René~

NewSoftzzz

Nexus schrieb:

Meine Antwort (sei Function() eine Funktion mit const std::string& als Parameter). Der folgende Fall wird von deiner Aussage eingeschlossen.

Nexus schrieb:
static std::string String; 
String = OtherString; // OtherString ist nicht-statischer std::string 
Function(String); // Funktion muss aber mit statischem String aufgerufen werden
So, und jetzt überleg bitte, bevor du wieder postest!

Und wie genau steht OtherString jetzt zur Compilezeit fest? Da kann ich nur jemanden quoten:
So, und jetzt überleg bitte, bevor du wieder postest!

Wie kann man Programmierer werden, wenn man nicht mal 5 einfache Bedingungen anwenden kann...

mfg, René~

NewSoftzzz schrieb:

[Ghost] schrieb:

Wie es Nexus gesagt hatte, wenn beim Start des Programmes eine Datei einmal geladen wird und dies über eine Funktion geschieht, welche einen std::string erwartet, dann wäre es völliger Unsinn, einen static const std::string zu nehmen, denn du hast dadurch gar keinen Vorteil. Im Gegenteil, die Leserlichkeit geht dadurch verloren. Du verkomplizierst deinen Code unnötig.

Nun, zugegebenermaßen, eine Stelle die über die komplette Laufzeit nur EIN einziges mal aufgerufen wird, lohnt nicht. Aber ab 2 mal dann schon.

Nehmen wir die Bedingung halt noch dazu: "Der Aufruf muss mindestens 2 mal erfolgen".

mfg, René~

Google mal die Bedeutung von folgendem Satz:

"Premature optimizing is the root of all evil"

Und ja, das was Du argumentierst fällt unter diese Regel.

NewSoftzzz

loks schrieb:

"Premature optimizing is the root of all evil"

Und ja, das was Du argumentierst fällt unter diese Regel.

Nope, bei dem Satz geht es normalerweise um 5% Leistungsverbesserung bei Verschlechterung der Wartbarkeit.

Bei meinem Dogma geht es um 1640% Leistungsverbesserung ohne Verschlechterung der Wartbarkeit.

mfg, René~

NewSoftzzz schrieb:

Nehmen wir die Bedingung halt noch dazu: "Der Aufruf muss mindestens 2 mal erfolgen".

Gut, hier kann ich nun zumindest sagen, dass es einen Vorteil hat. Aber ist der wirklich so wichtig, dass ich den streng nach Dogma immer anwenden sollte? Ich denke eher nicht. Ich programmiere lieber zuerst so, dass man es einfach lesen kann. Zuerst auf die Einfachheit/Lesbarkeit schauen, meinen Code verunstalten kann ich später immer noch.

Vor allem läufst du dann Gefahr, dass du plötzlich überall per static const std::string eine Funktion aufrusft und daher grundsätzlich einfach ein char const* gereicht hätte. Und du merkst es nicht einmal

Dogmen sind immer eine gefährliche Sache. Nimm lieber Richtlinien und setze sie hier so fest:
Wenn eine Funktion oft in einem zeitkritischen Bereich aufgerufen wird, einen std::string const& als Parameter erwartet und man ein Literal übergeben möchte, dann sollte man einen static const std::string verwenden.

NewSoftzzz

[Ghost] schrieb:

Wenn eine Funktion oft in einem zeitkritischen Bereich aufgerufen wird, einen std::string const& als Parameter erwartet und man ein Literal übergeben möchte, dann sollte man einen static const std::string verwenden.

Bei der Formulierung ist es kein Dogma mehr, dann ist es schon Dummheit es nicht so zu machen.

[Ghost] schrieb:

Aber ist der wirklich so wichtig, dass ich den streng nach Dogma immer anwenden sollte? Ich denke eher nicht. Ich programmiere lieber zuerst so, dass man es einfach lesen kann. Zuerst auf die Einfachheit/Lesbarkeit schauen, meinen Code verunstalten kann ich später immer noch.

Es geht da eigentlich darum, es sich einfach anzugewöhnen. Aber ich weiß gar nicht was ihr alle habt, für mich senkt der seperate String nicht ein bisschen die Lesbarkeit, es ist doch sofort klar, dass das zusammengehört... (notfalls davor und dahinter eine leere Zeile)

[Ghost] schrieb:

Vor allem läufst du dann Gefahr, dass du plötzlich überall per static const std::string eine Funktion aufrusft und daher grundsätzlich einfach ein char const* gereicht hätte. Und du merkst es nicht einmal

Wie gesagt, die Methode ist nicht veränderbar oder eine Überladung mit "const char*" nicht möglich (oder sinnlos, wenn man dann eh wieder einen std::string erzeugen müsste)...

mfg, René~

NewSoftzzz schrieb:

Benchmark fertig:

#include <sys/time.h>
struct timeval tv;
int myint;
void benchmark(const std::string& input)
{
   myint += input.size();
}

int main()
{
   gettimeofday(&tv, NULL);
   uint64_t start = tv.tv_sec*1000 + (tv.tv_usec / 1000);
   myint = 0;
   for(uint64_t i=0; i< 100 * 1000 * 1000; i++) benchmark("This is for all the nonbelievers out there, who think that they shouldn't follow this rule.");
   gettimeofday(&tv, NULL);
   uint64_t end = tv.tv_sec*1000 + (tv.tv_usec / 1000);
   std::cout << myint << ": " << (end - start) << std::endl;

   gettimeofday(&tv, NULL);
   start = tv.tv_sec*1000 + (tv.tv_usec / 1000);
   myint = 0;
   static const std::string messageToNonbelievers = "This is for all the nonbelievers out there, who think that they shouldn't follow this rule.";
   for(uint64_t i=0; i< 100 * 1000 * 1000; i++) benchmark(messageToNonbelievers);
   gettimeofday(&tv, NULL);
   end = tv.tv_sec*1000 + (tv.tv_usec / 1000);
   std::cout << myint << ": " << (end - start) << std::endl;
}

Ergebnis:
510065408: 12735
510065408: 775

Faktor 16,4 !!!

lern coden

Athar

[Ghost] schrieb:

NewSoftzzz schrieb:

Nehmen wir die Bedingung halt noch dazu: "Der Aufruf muss mindestens 2 mal erfolgen".

Gut, hier kann ich nun zumindest sagen, dass es einen Vorteil hat.

Meinst du das ernst...? Eine Faustregel, die man immer anwenden kann/sollte und die ich auch schon erwähnt hatte, ist: wenn der Zeitaufwand für die Optimierung die Summe der Laufzeiteinsparungen aller jemals erwarteten Programmdurchläufe übersteigt, lohnt sich die Optimierung mit großer Sicherheit nicht.
Und darf ich daran erinnern, dass auch mit der Kopiervariante es immer noch fast 10 Millionen Stringkonstruktionen pro Sekunde sind?
Dass es in diesem speziellen Fall bei dem Server Sinn machen kann, sofern man die Klasse selbst nicht ändern kann, bezweifelt ja niemand. Wer ähnliches aber etwa für einen konstanten Dateinamen macht, ist mit beiden Beinen ins "premature optimization"-Näpfchen getreten.

kauf dir ne ps3 schrieb:

lern coden

Das kannst du dir echt sparen, wenn du keine Verbesserungvorschläge nennst.

NewSoftzzz schrieb:

Bei der Formulierung ist es kein Dogma mehr, dann ist es schon Dummheit es nicht so zu machen.

Es geht ja auch darum, keine Dogmen mehr anzuwenden. Dogmen sind schlecht, da man dadurch in ein viel zu enges Denkmuster gezwungen wird.
Und nein, es ist nicht Dummheit es nicht so zu machen, sondern man kann sich eben auch überlegen, ob eine Veränderung der Schnittstelle Sinn machen würde oder vielleicht ein komplettes Refactoring des Bereichs. Wenn man eben in Dogmen denkt, denkt man an solche anderen Möglichkeiten gar nicht mehr. Deshalb habe ich dies auch nicht als ein Dogma hingeschrieben, sondern als eine Richtlinie.

NewSoftzzz schrieb:

Es geht da eigentlich darum, es sich einfach anzugewöhnen. Aber ich weiß gar nicht was ihr alle habt, für mich senkt der seperate String nicht ein bisschen die Lesbarkeit, es ist doch sofort klar, dass das zusammengehört... (notfalls davor und dahinter eine leere Zeile)

void foo()
{
  static std::string const text01 = "hello";
  bar(text01);

  static std::string const text02 = "world";
  bat(text02);

  static std::string const text03 = "my";
  bar(text03);

  static std::string const text04 = "what";
  bar(text04);
}

// gegenüber

void foo()
{
  bar("hello");
  bar("world");
  bar("my");
  bar("what");
}

Du willst mir sagen, dass du beides gleich leserlich findest? Ehm, gut ... wenn du meinst ... ich bin da anderer Meinung ...

NewSoftzzz schrieb:

Wie gesagt, die Methode ist nicht veränderbar oder eine Überladung mit "const char*" nicht möglich (oder sinnlos, wenn man dann eh wieder einen std::string erzeugen müsste)...

Mir ist es ein wenig ein Rätsel, dass du deine eigene Methode nicht verändern kannst. Wenn du sagen würdest, dass du einen std::string in der Funktion brauchst, wäre bereits schon was anderes
Und eine Überladung hätte ich mir dann eher so vorgestellt (in die andere Richtung):

void foo(char const* str)
{
  // ...
}

void foo(std::string const& str)
{
  foo(str.c_str());
}

Allerdings wollte ich mit der Aussage jetzt nicht unbedingt auf diese spezielle Funktion hinaus. Ich meinte es viel allgemeiner, wenn du dich so streng an dein Dogma hälst.

@Athar,
Jap, mein ich ernst. Es ist ein Vorteil, du nennst eine Menge an zusätzlicher Negativpunkten, deshalb komme ich ja auch in der Summe der Punkte zu einem negativen Bescheid für diese Anwendung. Es hat einen Vorteil und x Nachteile

Nexus

NewSoftzzz schrieb:

Und wie genau steht OtherString jetzt zur Compilezeit fest? Da kann ich nur jemanden quoten:
So, und jetzt überleg bitte, bevor du wieder postest!

Wo genau in dem Zitat hast du etwas von Compilezeit erwähnt? Und überhaupt, was bringen solche Regeln? Man sollte je nach Kontext seinen Verstand einsetzen und nicht einfach blind static const hinschreiben.

NewSoftzzz schrieb:

Bei der Formulierung ist es kein Dogma mehr, dann ist es schon Dummheit es nicht so zu machen.

Was wirklich dumm ist, sind fixe Prinzipien, die man sich einmal setzt, über die man nie mehr nachdenkt und die einen deswegen zu schlechterem Code zwingen. Die Tatsache, dass du den Begriff "Dogma" derart verharmlost, ist bedenklich.

Athar schrieb:

kauf dir ne ps3 schrieb:

lern coden

Das kannst du dir echt sparen, wenn du keine Verbesserungvorschläge nennst.

name == Verbesserungvorschlag

l'abra d'or

NewSoftzzz schrieb:

Wer jetzt noch widerspricht, bitte Nachteile nennen oder Gegenteil beweisen.

Ich empfinde es beispielsweise als Nachteil, wenn ich eine Funktion nicht sehr oft aufrufe, dass da immer ein statischer std::string im RAM rumgeistert, der nur äußerst selten benötigt wird, nur um genau dann etwas minimal schneller zu sein.
Was sicherlich nett sein kann, ist dass der std::string auch als const deklariert ist und somit in einem Read-Only-Bereich im Speicher liegt, das kann schon nochmal schneller werden.

Ich muss aber auch sagen, dass ich selber noch keine wirklich zeitkritischen Programme entwerfen musste. Ich freu mich, wenn das Programm-Design mir (und anderen) gefällt, wenn ich neue Sachen lerne und umsetzen darf und dabei ein schönes Programm noch schneller wird.

Aber aus dieser möglichen minimalen Verbesserung der Laufzeit in einem möglicherweise vernachlässigbaren Teil der Gesamtlaufzeit eine Fixe Regel zu machen finde ich übertrieben. Deine Angabe von 1600% mehr Speed greift nur, wenn ich tatsächlich im Programm nichts anderes mache als jeden mir vom OS zur Verfügung gestellten Prozessortakt mit std::strings an Funktionen übergeben verbringe. Und das ist eine Annahme, die ich mich ehrlich gesagt nie trauen würde auszusprechen.

Im übrigen hätte ich dein Problem nicht durch lauter im Programm verteilte static-strings gelöst. Wenn du das in ner Funktion machst, und den selben String in einem anderen Teil - sprich Scope - auch ausgeben willst, musst du den nochmal als static ablegen.
Ein Singleton, der alle Strings fasst und dem du mit nem Enum oder direkten Funktionsaufrufen die Strings entlocken kannst, fände ich angenehmer zu bedienen. Bei Rechtschreibkorrekturen oder Übersetzungen hast du auch eine zentrale Anlaufstelle, was die Suchzeit verkürzt.
Weiterer Vorteil: Ich kann bei Programmstart den Singleton (und damit alle Strings) initialisieren. Bei der Version mit in Funktionen verteilten static strings werden diese erst beim ersten Aufruf initialisiert, was genau da wieder etwas länger dauert. Unter der Annahme, dass dein Server eh durchgehend läuft, wird auch der anfangs höhere Speicherverbauch durch noch nicht genutzte Strings wieder eliminiert.
Dieses Konzept weitergedacht, führt dazu, dass jedes Level sicher eigene Messages an den Player schicken wird, manche Sachen (wie Warnungen, allgemeine Anreden, usw.) ändern sich nicht. Also geben wir dem "MessageProvider" verschiedene "MessageBackends" für verschiedene Aufgaben. Manche statisch, manche ändern sich je nach geladenem Level/teilnehmenden Charakteren/....

So haben wir die static const std::string-Deklarationen aus dem Code verbannt und noch zusätzliche Flexibilität gewonnen!

NewSoftzzz

Nexus schrieb:

Wo genau in dem Zitat hast du etwas von Compilezeit erwähnt?

4 mal wörtlich und dann noch mehrmals sinngemäß (ca. in 10 VERSCHIEDENEN Posts hab ich das erwähnt)..
Soll ich Zitate raussuchen, um dich noch weiter zu blamieren?

l'abra d'or schrieb:

Ich empfinde es beispielsweise als Nachteil, wenn ich eine Funktion nicht sehr oft aufrufe, dass da immer ein statischer std::string im RAM rumgeistert, der nur äußerst selten benötigt wird, nur um genau dann etwas minimal schneller zu sein.

Wenn ich ein Programm ausführe, wird die Executable in den RAM geladen. Somit ist auch ein c-string-literal ständig im RAM... Es gibt also KEINEN Speichernachteil (wenn es den geben würde, hätte ich das Dogma niemals aufgestellt).

l'abra d'or schrieb:

Ein Singleton, der alle Strings fasst

Das ist auch ein static const string, nur anders verpackt. An sowas hab ich natürlich auch gedacht und passt hervorragend in das Dogma rein.

Athar schrieb:

Eine Faustregel, die man immer anwenden kann/sollte und die ich auch schon erwähnt hatte, ist: wenn der Zeitaufwand für die Optimierung die Summe der Laufzeiteinsparungen aller jemals erwarteten Programmdurchläufe übersteigt, lohnt sich die Optimierung mit großer Sicherheit nicht.

Der Regel stimme ich zu 100% zu. Ich brauche für die zusätzliche Zeile ca. 10 Sekunden, die ich nur in dem Benchmark schon wieder rausgeholt habe. Widerspricht dem Dogma also auch nicht

[Ghost] schrieb:

Du willst mir sagen, dass du beides gleich leserlich findest? Ehm, gut ... wenn du meinst ... ich bin da anderer Meinung ...

Wenn du die Text1-4 nennst, dann garantiert nicht. Ich hab aber auch schon 2 mal geposted, dass der Variablenname am besten eine kurze Zusammenfassung des Textes sein soll.

Nexus schrieb:

Die Tatsache, dass du den Begriff "Dogma" derart verharmlost, ist bedenklich.

Das ist Selbstironie. Natürlich sollte niemand sein Gehirn ausschalten und sobald jemand eine Ausnahme der Regel findet (eine Ausnahme wären Codestellen, die nur 1 mal während der kompletten Runtime ausgeführt werden), darf er die auch gerne posten...

mfg, René~

tntnet

theliquidwave schrieb:

Hui.
Erstmal alles verstehen
Ich muss mich morgen dann mal genauer mit der std::string-Klasse befassen. Ich dachte da wohl immer komplett in die falsche Richtung

@ tntnet: Also sollte der Prototyp so:
inline const CClass *CClassManager::getClass(const char *pszName)
oder so:
inline CClass *CClassManager::getClass(const char *pszName) const
aussehen? Ich habe beides schon des öfteren gesehen und beides funktioniert.
Wo ist der Unterschied und was ist in diesem Fall richtig?

Gruß

Ich würde es am ehesten so schreiben:

inline const CClass &CClassManager::getClass(const char *pszName) const

. Zur Not auch so:

inline const CClass *CClassManager::getClass(const char *pszName) const

. Ich vermeide halt Zeiger. Gerade wenn ich garantiere, dass ich wirklich eine Klasse zurück gebe und keinen Null-Zeiger, dann lieber als Referenz.

Das const hinten sagt, dass die Methode den Zustand der Klasse nicht verändert. Das const vorne sagt, dass Du das, was du zurück bekommst, nicht ändern darfst. Es kommt natürlich auf den Anwendungsfall an. Ich weiß nicht so recht, was Du erreichen willst. Wenn es eine Factory-Methode oder ein Sigleton sein soll, dann eventuell auch ohne const am Rückgabewert.

Dass beides funktioniert bedeutet nicht gleich, dass es elegant ist. Ich kann mit syntaktisch korrekten Programmen sehr viel Unsinn verzapfen. Im Prinzip ist das const nie wirklich notwendig. Es hilft nur, saubere Schnittstellen zu definieren.