RGB-Dez nach RGB-Web umwandeln: Wie ersetze ich sprintf mit std::String?
-
pale dog schrieb:
CStoll schrieb:
Ja, den Code, den du selber da oben geschrieben hast (ist zwar etwas länger als dein sprintf()-Aufruf, aber sicherer).
na, ganz toll, 11 mal << und 6 mal setfill/setw
Wenn du noch daran denkst, daß du setfill nicht für jeden Wert wiederholen mußt, wird das noch kürzer
das 'sprintf' spuckt immer 8 bytes aus, also unbedenklich in bezug auf buffer overflows...
Das weißt du, aber weiß es auch der Compiler? (und noch wichtiger: kann er feststellen, ob er wirklich genug Platz für diese 8 Byte zur Verfügung hat?)
-
CStoll schrieb:
Wenn du noch daran denkst, daß du setfill nicht für jeden Wert wiederholen mußt, wird das noch kürzer
das geht? ok, drei mal << gespart
CStoll schrieb:
das 'sprintf' spuckt immer 8 bytes aus, also unbedenklich in bezug auf buffer overflows...
Das weißt du, aber weiß es auch der Compiler? (und noch wichtiger: kann er feststellen, ob er wirklich genug Platz für diese 8 Byte zur Verfügung hat?)
wieso? machste einfach char array[8]; direkt darüber, dann ist doch alles gut...
-
pale dog schrieb:
CStoll schrieb:
Ja, den Code, den du selber da oben geschrieben hast (ist zwar etwas länger als dein sprintf()-Aufruf, aber sicherer).
na, ganz toll, 11 mal << und 6 mal setfill/setw
das 'sprintf' spuckt immer 8 bytes aus, also unbedenklich in bezug auf buffer overflows...
Warte mal. Verstehe ich das richtig? Du bist für 'sprintf', weil Dir die andere Variante zuviel zu Tippen ist und hast neulich in dem C++/Java-Thread einen Java-Code verteidigt, bei dem man seitenlang redundantes Zeugs schreibt, was einem der Compiler abnehmen könnte???
-
Konrad Rudolph schrieb:
Warte mal. Verstehe ich das richtig? Du bist für 'sprintf', weil Dir die andere Variante zuviel zu Tippen ist und hast neulich in dem C++/Java-Thread einen Java-Code verteidigt, bei dem man seitenlang redundantes Zeugs schreibt, was einem der Compiler abnehmen könnte???
wir sind hier ja nicht bei Java
wenn es mehrere möglichkeiten gibt, ein und dasselbe zu machen, dann bin ich immer für die kürzere oder einfachere oder vielleicht auch schnellere version...
-
Der C Code ist bei C++ keine Alternative! :p
-
David_pb schrieb:
Der C Code ist bei C++ keine Alternative! :p
sprintf ist in C++ erlaubt
-
pale dog schrieb:
David_pb schrieb:
Der C Code ist bei C++ keine Alternative! :p
sprintf ist in C++ erlaubt
Theoretisch ja! Hab ja auch nichts Gegenteiliges behauptet.
-
pale dog schrieb:
wieso? machste einfach char array[8]; direkt darüber, dann ist doch alles gut...
Wie man sieht, benötigt ein C-Programmierer sehr viel Selbstdisziplin (und wenn du diesen sprintf()-Aufruf in eine Funktion packst, der sein Ziel als Parameter übergeben bekommt, muß irgendwer anderes sicherstellen, daß der Speicherplatz ausreicht - und kein Compiler der Welt wird dich daran hindern, sowas zu schreiben:
char* rgbtext; convert(color,rgbtext);//viel Spaß bei der Suche nach dem FehlerJa, die stringstream-Variante ist etwas länger zu schreiben, aber dafür sorgt sie selber dafür, daß du genau den Speicherplatz bekommst, den du benötigst. Und im Zweifelsfall ist mir die Sicherheit, daß mein Code auch in Extremsituationen funktioniert (oder erst gar keine Extremsituationen zulässt) lieber als eine eingesparte Codezeile.
-
Und wo ist nu die optimale Lösung in vollendeter Form von Quellcode ?
-
CStoll schrieb:
Ja, die stringstream-Variante ist etwas länger zu schreiben, aber dafür sorgt sie selber dafür, daß du genau den Speicherplatz bekommst, den du benötigst. Und im Zweifelsfall ist mir die Sicherheit, daß mein Code auch in Extremsituationen funktioniert (oder erst gar keine Extremsituationen zulässt) lieber als eine eingesparte Codezeile.
Sind wir aber ehrlich: Die stringstream-Variante bläht das Programm richtig derbe auf und ist erheblich langsamer.
-
C++ Kritiker schrieb:
Sind wir aber ehrlich: Die stringstream-Variante bläht das Programm richtig derbe auf und ist erheblich langsamer.
Ich hatte mit der Stringstream-Performance noch nie Probleme. Gerade im vorliegenden Fall sollte das wirklich piepegal sein. Zum Programm aufblähen: Wayne …? Das mag vielleicht bei einem Tool von insgesamt 100 LOC interessant sein aber bei jedem halbwegs erstgemeinten Programm fällt's nicht ins Gewicht.
-
Konrad Rudolph schrieb:
Ich hatte mit der Stringstream-Performance noch nie Probleme. Gerade im vorliegenden Fall sollte das wirklich piepegal sein.
Du kennst die Umstände seines Problemes genau so wenig wie ich, also sollte ein guter Programmierer immer davon ausgehen, das es nicht auf die Performance hauen soll. Und wenn du vergleiche zwischen der sprintf-Variante und der stringstream-Variante anstellst, dann wirst du die Dimensionen erkennen die zwischen den beiden Varianten liegen.
Konrad Rudolph schrieb:
Zum Programm aufblähen: Wayne …?
Wie schon gesagt, wir kennen die Umstände nicht. Jemanden etwas zu empfehlen, was zwar einfach ist (wobei das hier absolut relativ ist) aber das Programm aufbläht ist auch nicht die feine art. Hier werden optimale lösungen gesucht und nicht lösungen, die relativ einfach zu benutzen sind (kommt auf den standpunkt an), sondern die effektiv sind. Und effektiv ist beim programmieren immer: Performance und Größe.
-
C++ Kritiker schrieb:
Und wenn du vergleiche zwischen der sprintf-Variante und der stringstream-Variante anstellst, dann wirst du die Dimensionen erkennen die zwischen den beiden Varianten liegen.
wenn's wirklich auf performance und geringe codegrösse ankommt, kann man noch nicht mal 'sprintf' nehmen. dann geht nur noch: immer 4 bits shiften/ausmaskieren, als index in ein array von hex-ziffern nehmen und diese dann aneinanderhängen.
wenn das auch nicht hilft, bleibt nur noch assembler
-
pale dog schrieb:
wenn's wirklich auf performance und geringe codegrösse ankommt, kann man noch nicht mal 'sprintf' nehmen. dann geht nur noch: immer 4 bits shiften/ausmaskieren, als index in ein array von hex-ziffern nehmen und diese dann aneinanderhängen.
Das ist gar nicht mal so falsch und disqualifiziert die Bemerkung des C++-Kritikers vollends: Da wir nichts über die genauen Umstände des Programmierers wissen, sollten wir die beste allgemeingültige Lösung geben und evtl. auf Probleme und Potential anderer Lösungen hinweisen – was getan worden ist. Trotzdem bleibt es dabei, dass 'stringstream' im Kontext von C++ ohne Zusatzbibliotheken wie Boost die beste allgemeingültige Lösung ist.
-
C++ Kritiker schrieb:
also sollte ein guter Programmierer immer davon ausgehen,
Der gute Softwarearchitekt hingegen denkt etwas über den Gesamtzusammenhang nach, erkennt dass bei einer HTML-Ausgabe noch mehr Text als <10 Zeichen anfällt, sieht dass ein std::stringstream einen hervorragenden Puffer abgibt den man mehreren Funktionen nacheinander per Referenz übergeben kann und sieht sich deshalb veranlasst in einem C++ Forum auch eine Lösung vorzuschlagen die die Features von C++ auch nutzt.
Damit's insgesamt kürzer, schneller und besser wartbar wird.
Grüsse
*this
P.S.: Und wer jetzt mit sowas wie MAX_BUF_SIZE ankommt hört den Gong nicht mehr; dafür sorg ich persönlich!
-
@Gast++
Was meinste wohl wieso sprintf_s und sonstige Secure Funktionen eingeführt wurden? Bestimmt nicht aus langeweile.
-
sprintf-user schrieb:
@Gast++
Was meinste wohl wieso sprintf_s und sonstige Secure Funktionen eingeführt wurden? Bestimmt nicht aus langeweile.Damit C Programmierer auch nachts ruhig schlafen können ...
Einen C++ler interessieren die C-Funktionen eigtl. relativ wenig. Ich habe außer memcpy noch nie ne C-Funktion benutzt, das heißt halt malloc und free bei der mal Mikrocontrollerprogrammierung mit nem gcc, wo new und delete nicht implementiert waren.
-
Gast++ schrieb:
Der gute Softwarearchitekt hingegen denkt etwas über den Gesamtzusammenhang nach, erkennt dass bei einer HTML-Ausgabe noch mehr Text als <10 Zeichen anfällt, sieht dass ein std::stringstream einen hervorragenden Puffer abgibt den man mehreren Funktionen nacheinander per Referenz übergeben kann und sieht sich deshalb veranlasst in einem C++ Forum auch eine Lösung vorzuschlagen die die Features von C++ auch nutzt.
Damit's insgesamt kürzer, schneller und besser wartbar wird.
Grüsse
*this
P.S.: Und wer jetzt mit sowas wie MAX_BUF_SIZE ankommt hört den Gong nicht mehr; dafür sorg ich persönlich!
Na klar, was ein echter CPlusplusler ist, der schreibt gleich eine ganze Klasse, am besten gleich mit Templates im STL-Style, wenn es darum geht bei einem Farbwert der 6 bis 8 Zeichen hat, vier Zeichen zu vertauschen.
-
C++ Kritiker schrieb:
Und effektiv ist beim programmieren immer: Performance und Größe.
Und Sicherheit. Die sich leider in fast allen Faellen mit Performance und Groesse kneift. Denn Sciherheitsrisiken in Kauf zu nehmen heisst auch, ungewolltes oder undefiniertes Verhalten und Programmabstuerze in kauf zu nehmen. Dann doch lieber ne Handvoll Byte Speicherbelegung und einige Microsekunden mehr...
-
proggingmania schrieb:
Na klar, was ein echter CPlusplusler ist, der schreibt gleich eine ganze Klasse, am besten gleich mit Templates im STL-Style, wenn es darum geht bei einem Farbwert der 6 bis 8 Zeichen hat, vier Zeichen zu vertauschen.
Nö, solange nichts gegen eine der allgemein verfügbaren, excellenten C++ Lösungen, wie zum Beispiel boost::format spricht:
int farbe_dez = 8421631; string farbe_html = str(format("#%x%x%x") % (farbe_dez&0xff) % ((farbe_dez>>8)&0xff) % ((farbe_dez>>16)&0xff));