RGB-Dez nach RGB-Web umwandeln: Wie ersetze ich sprintf mit std::String?

pale dog

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

David_pb

Der C Code ist bei C++ keine Alternative! :p

pale dog

David_pb schrieb:

Der C Code ist bei C++ keine Alternative! :p

sprintf ist in C++ erlaubt

David_pb

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.

CStoll

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 Fehler

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.

proggingmania

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.

Konrad Rudolph

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.

pale dog

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

Konrad Rudolph

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.

Gast++

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.

Checker*amp*Murckser

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.

proggingmania

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.

pumuckl

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

pale dog

pumuckl schrieb:

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

ja, grösse und performance beissen sich manchmal, z.b. sind grössere codes oft performanter, weil sie keine schleifen und sprünge enthalten.
aber mit der sicherheit ist es ein anderes thema. ich denke, wenn ausgeschlossen ist, dass gewisse dinge passieren können, braucht man sich auch nicht davor zu schützen.
wie etwa bei dem sprintf: wenn man davon ausgeht, dass sprintf nicht selber buggy ist, sollte es in unserem fall immer konstant 8 bytes beschreiben, d.h. man braucht eigentlich keine 'angstbytes' anzuhängen oder irgendwelche bereichsüberprüfungen zu machen, etc.

format0r schrieb:

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

die %x müssten doch wohl %02x heissen, oder?
aber, hähä, ich fress' meinen computer wenn boost::format kein verstecktes 'sprintf' ist.

Konrad Rudolph

pale dog schrieb:

aber, hähä, ich fress' meinen computer wenn boost::format kein verstecktes 'sprintf' ist.

Guten Appetit.

http://boost.org/libs/format/ schrieb:

The format library provides a class for formatting arguments according to a format-string, as does printf, but with two major differences :

* format sends the arguments to an internal stream, and so is entirely type-safe and naturally supports all user-defined types.
* The ellipsis (...) can not be used correctly in the strongly typed context of format, and thus the function call with arbitrary arguments is replaced by successive calls to an argument feeding operator%

=> 'boost::format' ist typ- und overflowsicher.

pale dog

Konrad Rudolph schrieb:

pale dog schrieb:

aber, hähä, ich fress' meinen computer wenn boost::format kein verstecktes 'sprintf' ist.

Guten Appetit.

schluck
ich hab's gerade selber gesehen: http://www.boost.org/boost/format/parsing.hpp