Set- und Getterfunktionen verwenden oder nicht?

Korrekturen: zweiten*, ersten*

NewSoftzzz

;Athar schrieb:

Wenn du aber eine möglichst performante Verarbeitung von Stringliteralen benötigst, dann liegt es nahe, eine entsprechende Schnittstelle anzubieten, wie ich ja schon vorher gesagt habe. Extrazeilen mit static std::string sind dann ebenfalls nicht nötig.

Warum immer so sinnlose Argumente?

ich: "Was ist besser, Apfel oder Birne?"
du: "Schluck eine Vitamintablette, ist effizienter."

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

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"

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

mfg, René~

Athar

NewSoftzzz schrieb:

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"

Nein, eben nicht! Hast du meinen Post auch nur gelesen?
Die Antwort lautet BEIDES. Wieso weigerst du dich, zwei Zeilen hinzuzufügen, die das Problem endgültig aus der Welt schaffen und bereicherst stattdessen alle möglichen sendMessageToPlayer-Aufrufe mit einer Extrazeile? Vor allem, weil es davon wahrscheinlich nicht wenige geben wird.

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