warning C4996: 'strcpy' was declared deprecated
-
Was ist denn daran Overloaded? Mir kommt es so vor, als ob immernoch die Meinung herrscht, das Klassen mehr Code zur Laufzeit erzeugen als Funktionen. Glaubst du wirklich, das std::string mehr Code benötigt, als wenn du die ganzen C-Funktionen für die String-Bearbeitung benötigst? Komisch komisch...
-
lasst ihn einfach seinen schrott weitermachen. wenn er spaß dran hat...
-
Artchi schrieb:
Was ist denn daran Overloaded? Mir kommt es so vor, als ob immernoch die Meinung herrscht, das Klassen mehr Code zur Laufzeit erzeugen als Funktionen. Glaubst du wirklich, das std::string mehr Code benötigt, als wenn du die ganzen C-Funktionen für die String-Bearbeitung benötigst? Komisch komisch...
jup.
man nehme nur loadImage(string const& fileName) statt loadImage(char const* fileName).
-
@unregistrierter
Hast du schon einmal ein 3D - Spiel programmiert?
-
Das muß er nicht mal gemacht haben, um zu wissen, ob str::string performant ist.
-
Dazu sollte man aber jetzt schon sagen, dass es nicht performant ist. Genau wie new char[]/strcpy auch. Wer sowas an einer performancekritischen Stelle verwendet, beweist nur, dass er keine Ahnung davon hat.
-
Egal, std::string ist auch nicht darauf ausgelegt, performant zu sein bis zum geht nicht mehr. Es ist eben eine sehr allgemein gehaltene Stringklasse. Wenn man unflexibel sein darf, ist es viel einfacher schnell zu sein.
-
Es spricht nix dagegen, eine Assembler-Implementation von std::string zu verwenden. Eigentlich sollten im Header ja auch nur die Schnittstellen dokumentiert sein. Notfalls kann man ja seine eigene machen.
-
In 3D-Spielen macht man ja auch so unheimlich viel mit Strings...
-
Dieses 3D-Spiele-Gerede gerade mal außen vorgelassen:
Die höchste Effizienz erreicht man nur, wenn der String auf das Problem angepasst verwaltet wird. Wenn ich einen String sauoft kopiere, ist es vielleicht besser, immutable Strings zu verwenden mit einem shared buffer. Oder copy-on-write. Wenn ich Strings sauoft konkateniere, brauche ich ausgeklügeltes Speichermanagement, vielleicht mit speziellen Allokatoren und den internen Buffer werd ich ein Stück größer lassen. Wenn es mir auf den Speicherbedarf ankommt, werde ich für den Buffer nicht viel extra-Platz lassen. Wenn ich aus einem String oft einen C-String herausholen muss, muss auch manches berücksichtigt werden.
Solche Verhaltensweisen sind sehr viel entscheidender für die Performance eines Strings, als ob er in eine Klasse gepackt ist oder nicht, ob die Funktionen in einer Assemblersprache geschrieben sind oder nicht. Klassen sind halt ein schönes Hilfsmittel, um dieses interne Verhalten von der Benutzung des Strings besser zu trennen.
-
Wenn man wirklich Geschwindigkeit will in nem Spiel, dann würd ich auf Stack-Arrays mit fester Größe setzen. Sehr oft kann man sich ja sicher sein, dass ein Name niemals größer als 32 Zeichen sein wird, oder der Name einer Waffe/Gegenstandes niemals größer als x Zeichen.
Würde mir daher ne Klasse schreiben die intern nen Stack-Array hat und sonst ne Schnittstelle wie std::string anbietet.