ich vermisse sprintf... etc. in c++ :(

[BorisDieKlinge]

Hallo leute,

folgendes:

void AddValue(UINT iPR2Adr,std::string sName,double dValue){
			std::stringstream stdKey;
			stdKey << iPR2Adr;
			stdKey << sName;
			mValues[stdKey.str()]=dValue;
		}

die funktion fügt ein element an eine map hinzu, wobei sich der schlüsse aus einem integer wert und einem string zusammen setzt..

um sowas zu formatieren benutze ich normal sprintf.. aber in c++ gibts ja die stringstream.. gefällt mir nich.. gibts elegantere methodenß grüße

EDIT: so formatierungmöglicheien wie %5i etc. sollte auch schön gehen!?!?

[Bashar]

Wie kommst du darauf, dass es sprintf in C++ nicht gibt?

[Nexus]

Wenn man (weitgehend) reines C++ benutzen will, existiert für einen sprintf() nicht
Und letzteres ist natürlich zu empfehlen - zumindest ist es besser als ein C/C++-Gemisch.

[BorisDieKlinge]

jepp. wenn ich sprintf benutze, werd ich von vielen nur blöd angemacht^^
damit ihr zufrieden seit, nehm ich string stream.. hehe

[audacia]

boost::format wäre, glaube ich, eine Alternative.

Ansonsten nutze doch einfach die Vorteile, die du in C++ hast, und schreibe dir eine typsichere Version von sprintf

[Tachyon]

BorisDieKlinge schrieb:

jepp. wenn ich sprintf benutze, werd ich von vielen nur blöd angemacht^^
damit ihr zufrieden seit, nehm ich string stream.. hehe

Was interessiert Dich, ob wir mit Deinem Code zufrieden sind?

Für sowas gibts unter C++ auch ganz ohne boost iomanip.

[Nexus]

Tachyon schrieb:

Was interessiert Dich, ob wir mit Deinem Code zufrieden sind?

Verleite ihn doch nicht dazu, C++ mit C zu mischen. Es ist nicht nur für ihn selber vorteilhaft, wenn er reines C++ schreibt, es ist auch manchmal mühsam und unschön für die, die ihm helfen wollen, bei einem Konglomerat der beiden Sprachen durchzublicken (gerade wenn man C nicht gut beherrscht).

@ BorisDieKlinge: Es ist schon gut, dass du versuchst, C++ anzuwenden
Und wie bereits gesagt wurde, der Header <iomanip> kann für Formatierungen nützlich sein.

[buust]

audacia ftw! du solltest boost::format und die str funktion benutzen.

[Vevusio]

ich find das ehrlich gesagt voll lächerlich dass viele leute meinen dass es so schlecht ist funktionen wie sprintf etc in c++ zu verwenden

dann mischt man halt c sprachelemente mit c++, na und?

das heisst nicht dass man deswegen weniger objektorientiert programmiert, das programm fehleranfälliger, langsamer, unstabiler, unsauberer oder sonst was wird

es kommt nur darauf an wie man das ganze einsetzt
dass es unleserlich ist find ich ist auch kein argument, klar könnten die c funktionen nicht beschissener heißen aber so viele gibt es dann auch wieder nicht und die gängigsten wie die ganzen printfs usw sind eh allgemein bekannt
und solange man sie kurz und bündig benutzt und in c++ methoden kapselt (und nicht 50+ zeilen c befehle runterschreibt) gibts auch sicher keine verständnisprobleme

man kann sich genauso an reines c++ klammern und am ende etwas prozedurales damit fabrizieren was den sinn von oop total verfehlt

[gefahr]

die printf familie ist gefährlich, weil leicht möglichkeiten für buffer overflows übersehen werden.

[Vevusio]

klar aber mittlerweile gibt es zu jeder dieser funktionen auch eine "secure" funktion wo man ne maximale länge von characters angeben kann die kopiert / überprüft / etc werden sollen - natürlich sollte man die dann auch verwenden

[hustbaer]

Die Sache ist IMO ganze einfach. Für grundsätzlich alles erstmal boost::(w)format. Wenn sich dann herausstellt dass irgendwas dadurch wirklich langsam wird, dann zurück zu sprintf(). Mit einem kleinen Kommentar dazu warum. Ferdich.

[knuth]

Vevusio schrieb:

dann mischt man halt c sprachelemente mit c++, na und?

nicht jeder ist hobbybastler, wo schlechter code nur zum eigenen vergnügen geschrieben wird.

[knuth]

...davon abgesehen hast du bei deinen "argumenten" die typsicherheit einfach mal ignoriert.

[otze]

Vevusio schrieb:

dann mischt man halt c sprachelemente mit c++, na und?

das heisst nicht dass man deswegen weniger objektorientiert programmiert, das programm fehleranfälliger, langsamer, unstabiler, unsauberer oder sonst was wird

es kommt nur darauf an wie man das ganze einsetzt

Versuch mal die printf familie in direkter template umgebung, geschweige denn mit Objekten zu verwenden. Das funktioniert nicht.

Im C++ Umfeld ist es unsauberer. und fehleranfälliger erst recht, weil es fast unmöglich ist, mit den C++-streams bockmist zu bauen. Zudem kommt noch dazu, dass die print familie auf c strings aufbaut, und man deswegen immer wunderbare konvertierungen im C++ Umfeld machen darf(neben der tatsache dass c strings fehleranfälliger sind).

Hinzu kommt, dass du in einem locale abhängigen system C mit C++ locales mischt, und es dann deine Aufgabe ist, immer beide Seiten up to date zu halten(ergo aufpassen, dass beide locales immer auf das gleiche gebiet eingestellt sind).

Zusammengefasst: Du VERLIERST: Typsicherheit, flexibilität, fehlersicherheit(compiletimefehler>laufzeitfehler), lesbarkeit, die abstraktionsebene von C++

Du GEWINNST: Eine ein wenig kürzere/vertrautere Syntax.

[BorisDieKlinge]

Wenn ich einen "statischen" lockuptable coden möchte :

typedef struct {

 BYTE oAdr;
 BYTE bSize;
 char acCode[10]; 

} Datablock;

static Datablock Codes[]={

 {0x01,6,"CODEA" },
 {0x05,4,"CODEB" },
 {0x10,2,"CODEC" },
......
};

dies in pure C++ mit nem container zu machen ist ja auch nich zwinged nötig...oder kann man doch mit mischen...wobei man sowas auch als C++ code bezeichenn kann

[Xantus]

ja, das nennt man POD.
kann man, sollte man, müsste man, dürfte man.

eine Klasse, der du die 3 Werte im Konstruktur übergibst inklusive std::string anstatt einem char-buffer und nen std::vector, der die tabelle darstellt hätten es auch getan.

Und meiner Meinung nach auch wartbarer.

[BorisDieKlinge]

ich hab ja von "statisch" gesprochen der tabel wird einmal hardcodiert angelegt.. die adressierung eines externer hardware(welche fix bleibt).

so muss ich das gesöns doch nicht "umständlich" mit klassen vectoren etc machen.. ist doch so übersichtlicher und schöner meiner meinung nach also schesis esgal obs POD ansi c gedöns ist;)

[otze]

BorisDieKlinge schrieb:

static Datablock Codes[]={

 {0x01,6,"CODEA" },
 {0x05,4,"CODEB" },
 {0x10,2,"CODEC" },
......
};

kann man machen. allerdings ist ne map besser bei einer großen lookuptable, da O(log(n)) < O(n).

Und du musst dir im klaren sein, dass ein c-array sich nicht so schön einfach ins C++ Umfeld integriert...andererseits hab ich bei deinen Codeschnipseln keine bedenken, dass das irgendein Problem darstellen wird

[Tachyon]

otze schrieb:

kann man machen. allerdings ist ne map besser bei einer großen lookuptable, da O(log(n)) < O(n).

Wie kommst Du darauf? Bei einer normalen LUT ist die Komplexität doch O(1).