Hex String in einen Int umzuwandeln

[tobidope]

Unregistrierte sollten nicht posten dürfen oder jederzeit fremdgecancelt werden. Ist ja zum heulen hier.

[bin]

Warum? Ich hab doch recht. Das wird dir jeder C++'ler bestätigen können.

[peterchen]

@Knuddlbaer:

Wo ist deine Fehlerbehandlung? Wie kriegst du raus ob was schief gegangen ist - und was?

und die Frage war ja auch -
wieso ist std::string besser als String - von dem du und moddie gar nix wissen?

[Knuddlbaer]

peterchen schrieb:

@Knuddlbaer:
Wo ist deine Fehlerbehandlung? Wie kriegst du raus ob was schief gegangen ist - und was?

Du kannst z.B. die failbits verwenden

peterchen schrieb:

und die Frage war ja auch -
wieso ist std::string besser als String - von dem du und moddie gar nix wissen?

std::string -> standard -> portabel -> ... (wir sind im standard C++ Forum)

[peterchen]

Hab 'ne Menge mit char * und mit std::string "gespielt", ich würde mich in Production Code in 80% aller Fälle für die <cstdlib> - Variante entscheiden

Was ich mit den beiden Frage meinte war:

a) Du weißt nichts über String. Vielleicht bietet die Klasse ja Services, die die Anwendung dringend benötigt. Vielleicht ist String ja sogar von std::string abgeleitet. Insofern ist ein pauschales "besser" m.E. nicht angebracht.

b) Wenn du alle Fehlerbehandlung mit reinnimmst (die ich bis zum Schluß aufgeschlüsselt hab, weil der Nutzer das halt manchmal wissen muß), bläht sich der STL-Code auch auf.

Was mich stört ist nicht, daß ein anderer Vorschlag gebracht wurde, sondern daß dieser Vorschlag als "besser" bezeichnet wurde, ohne Gründe anzugeben (und ich würde vermuten ohne wirklich nachzudenken, sondern weil "std::string besser ist als char const *").

Mal ein paar Punkte die mir so einfallen:

> NULL-Zeiger check fehlt bei mir, den kann man sich mit der STL sparen.

> STL-Variante funktioniert auch für "exotische" chars,

> Bei vergleichbarer implementation skaliert strtol besser als (oder im schlimmsten Fall genauso gut wie) stringstream.

> Wie die STL-variante skaliert hängt letztlich von der STL-Implementation ab. Das heißt aber: Selbst wenn die Implementation auf der Ursprungsplatform akzeptabel ist, kann sie auf der Zielplattform untragbar sein. Sehe ich als leichte Einschränkung der Portierbarkeit.

> strtol ist ohne Fehlerbehandlung ein Statement, die STL-Variante 3. Das glättet sich sicher etwas wenn man die Fehlerbehandlung mit reinnimmt, aber wenn ich mir anschau wieviel Dokumentation ich lesen muß, um die jeweilige Variante vollständig zu verstehen, hat die "klassische" variante einen klitzekleinen Vorsprung.

> <cstdlib> ist meines Wissens Teil von Standard C++

Vielleicht wirkt das alles ein bißchen Überzogen, aber ich fand es leicht nervend, wenn

a) cd verschiebt die Frage in ein passendes Forum. OK.
b) Ich versuche eine funktionsfähige Antwort zu geben
c) cd erklärt mir nicht etwa, das die Antwort falsch ist, sondern stellt nur fest daß sie "nicht in dieses Forum gehört". Bitte??
d) von kb kommt ein konstruktiver Beitrag.
e) bin hat einen Anfall von spätmorgendlicher Übelkeit. vergessen wir das.

Da frag ich mich schon: Geht es hier darum, jemandem zu helfen, oder einen ausgewählten Teil des C++ - Standards zu bewachen?

Soviel Dazu. Jetzt eß' ich erstmal ne leckere Feinfrostpizza.

[falscher Troll]

Jetzt eß' ich erstmal ne leckere Feinfrostpizza.

*kotz*

[nman]

peterchen schrieb:

Vielleicht ist String ja sogar von std::string abgeleitet.

Das wäre unklug da der Destruktor von std::string bekanntermaßen non-virtual ist.

[Bashar]

Dann benutzt man String eben nicht polymorph. :p

[Vellas]

Die Klasse String scheint sich im namespace System zu befinden. Zumindest ist sie bei .NET Teil des .NET-Framwork, dort enthält die mscorlib.dll die Einzelheiten zur Klasse String. Die Deklaration sieht laut dem Buch der .NET-IDE so aus:

#using <mscorlib.dll>
using namespace System;

Und die 2. using-Zeile macht es wie hier wohl jeder weiß es nur einfacher bestimmte Klassen (bzw. .NET-Klasse) zu nutzen.

Code-Hacker

[phlox81]

Code-Hacker schrieb:

Die Klasse String scheint sich im namespace System zu befinden. Zumindest ist sie bei .NET Teil des .NET-Framwork, dort enthält die mscorlib.dll die Einzelheiten zur Klasse String. Die Deklaration sieht laut dem Buch der .NET-IDE so aus:

#using <mscorlib.dll>
using namespace System;

Und die 2. using-Zeile macht es wie hier wohl jeder weiß es nur einfacher bestimmte Klassen (bzw. .NET-Klasse) zu nutzen.

Code-Hacker

Das hat nix mit C++ zu tun, zumindest nicht mit dem (heiligen) Standard!!!
Und .net, naja ich sag mal nix...

Devil

[Vellas]

devil81 schrieb:

Das hat nix mit C++ zu tun, zumindest nicht mit dem (heiligen) Standard!!!
Und .net, naja ich sag mal nix...

Ach was du nicht sagst! Hier geht es doch um "String" statt "std::string" oder habe ich den falschen Thread erwischt? Und was .net anbelangt kannst du gerne sagen was du hast. mit .net kann man auch ohne .net programmieren. Wie gesagt so ist die String-Klasse im C++ Buch was bei der IDE dabei war von MS beschrieben. Und das "String" etwas mit dem Standard zu tun habe scheint nicht der fall zu sein, da ich es nirgends finden konnte.

Code-Hacker

[Shade Of Mine]

peterchen schrieb:

Hab 'ne Menge mit char * und mit std::string "gespielt", ich würde mich in Production Code in 80% aller Fälle für die <cstdlib> - Variante entscheiden

schonmal was von RAII gehört?
Also gerade im production code gehe ich persönlich den sichersten weg - und std::string garantiert mir exceptionsicheres aufräumen des speichers.

b) Wenn du alle Fehlerbehandlung mit reinnimmst (die ich bis zum Schluß aufgeschlüsselt hab, weil der Nutzer das halt manchmal wissen muß), bläht sich der STL-Code auch auf.

Interessanterweise nicht. Denn du lässt einfach exception fliegen wenn es fehler gibt und schon hast du nur noch wenig fehlerbehandlungen in deinem code.

Was mich stört ist nicht, daß ein anderer Vorschlag gebracht wurde, sondern daß dieser Vorschlag als "besser" bezeichnet wurde, ohne Gründe anzugeben (und ich würde vermuten ohne wirklich nachzudenken, sondern weil "std::string besser ist als char const *").

da muss man keine Gründe angeben.
Lies Effective C++ und die Guru Of The Week Artikel und du weisst warum...

> STL-Variante funktioniert auch für "exotische" chars,

und vorallem für 'exotische' char_traits

> Bei vergleichbarer implementation skaliert strtol besser als (oder im schlimmsten Fall genauso gut wie) stringstream.

begründung?

> Wie die STL-variante skaliert hängt letztlich von der STL-Implementation ab. Das heißt aber: Selbst wenn die Implementation auf der Ursprungsplatform akzeptabel ist, kann sie auf der Zielplattform untragbar sein. Sehe ich als leichte Einschränkung der Portierbarkeit.

wieso? erklär mal warum die STL schlecht implementiert sein sollte?
notfalls haust du STLPort drauf und hast ne Top performance...

> strtol ist ohne Fehlerbehandlung ein Statement, die STL-Variante 3. Das glättet sich sicher etwas wenn man die Fehlerbehandlung mit reinnimmt, aber wenn ich mir anschau wieviel Dokumentation ich lesen muß, um die jeweilige Variante vollständig zu verstehen, hat die "klassische" variante einen klitzekleinen Vorsprung.

nein. Denn strtol hat keinen so so sprechenden namen wie
[cpp]
stringstream stream;
stream<<hex<<"A1";
int i;
stream>>i;

da erkennt man den sinn vom lesen - während mal strtol kennen muss.
was man allerdings sollte - deswegen sind hier beide varianten gleich gut

Da frag ich mich schon: Geht es hier darum, jemandem zu helfen, oder einen ausgewählten Teil des C++ - Standards zu bewachen?

ne, es geht darum gute Lösungen zu erarbeiten.
und C++ ist mehr als ein C mit Klassen

[Knuddlbaer]

peterchen schrieb:

a) Du weißt nichts über String. Vielleicht bietet die Klasse ja Services, die die Anwendung dringend benötigt. Vielleicht ist String ja sogar von std::string abgeleitet. Insofern ist ein pauschales "besser" m.E. nicht angebracht.

Du diskutierst hier in einem Forum das sich im reinen Standard bewegt. Es ist egal was der XSTring CString TString QTSTring oder was auch immer es sein mag an leistungen bringt, er ist nicht portabel und damit im Sinne des Standards einfach besser. String gibt es vllt. nur für Compiler X auf OS Y. Nun sollst Du das ganze nach Z portieren. Und portabel ist in diesem Bereich des Forums nun mal sehr wichtig.

[quote="peterchen"]
b) Wenn du alle Fehlerbehandlung mit reinnimmst (die ich bis zum Schluß aufgeschlüsselt hab, weil der Nutzer das halt manchmal wissen muß), bläht sich der STL-Code auch auf.

Was kann denn bei der Umwandlung eines Hexstrings schiefgehen ?
Es ist keiner. Warum es keiner ist spielt doch erst mal keine Rolle. Wenn man ein Programm schreiben soll reicht es zu wissen das es nicht ging.
Zumal der stream verschiedene Bits anbietet u.a. eof fail und bad.
Wüsste nicht was da den STL Code aufbläht ?!

Um das was Du meinst zu testen würde ich übrigens die algorithmen einsetzen mit einem Prädikat das mit hilfe von isxdigit testet. (find liefert Dir dann sogar die Position die nicht passt).

[quote="peterchen"]
Was mich stört ist nicht, daß ein anderer Vorschlag gebracht wurde, sondern daß dieser Vorschlag als "besser" bezeichnet wurde, ohne Gründe anzugeben (und ich würde vermuten ohne wirklich nachzudenken, sondern weil "std::string besser ist als char const *").

Die Lösung die Du anbietest ist übrigens auch nicht auf das Problem anwendbar weil Du garnicht weisst ob der "String" in char* konvertierbar ist. (Ball zurückwerf

peterchen schrieb:

> Bei vergleichbarer implementation skaliert strtol besser als (oder im schlimmsten Fall genauso gut wie) stringstream.

Das hängt von der Implementierung beider Methoden ab.

peterchen schrieb:

> Wie die STL-variante skaliert hängt letztlich von der STL-Implementation ab. Das heißt aber: Selbst wenn die Implementation auf der Ursprungsplatform akzeptabel ist, kann sie auf der Zielplattform untragbar sein. Sehe ich als leichte Einschränkung der Portierbarkeit.

s.o. strtol kann ebenfalls schlecht implementiert sein.

peterchen schrieb:

> strtol ist ohne Fehlerbehandlung ein Statement, die STL-Variante 3. Das glättet sich sicher etwas wenn man die Fehlerbehandlung mit reinnimmt, aber wenn ich mir anschau wieviel Dokumentation ich lesen muß, um die jeweilige Variante vollständig zu verstehen, hat die "klassische" variante einen klitzekleinen Vorsprung.

Na das hängt nun aber vom Wissen des Programmieres ab. Ich kann mit stringstream mehr anfangen und schneller zum ergebnis kommen als mit strtol. (Kannte das z.B. noch garnicht).

peterchen schrieb:

> <cstdlib> ist meines Wissens Teil von Standard C++

Ja, sogar char* ist Teil des C++ Standards

peterchen schrieb:

Da frag ich mich schon: Geht es hier darum, jemandem zu helfen, oder einen ausgewählten Teil des C++ - Standards zu bewachen?

Ich habe legedlich eine der vielen Möglichkeiten mit Hilfe des stringstreams gezeigt. Es geht darum jemanden zu helfen. Es geht aber auch darum was neues zu lernen (wie für mich strtol) und anderen neue Wege zu Zeigen (wie Dir stringstream).

WEiß nicht so ganz worauf es hinausläuft. Am Ende ist es doch die tatsache das in einem C++ Forum gepostet wird. Und da erwartet man eher eine C++ konforme Lösumng. Wenn jemand im ANSI C Forum wissen will wie er was ausgibt und man cout und nicht printf schreibt hilft ihm das nicht wirklich weiter.

peterchen schrieb:

Soviel Dazu. Jetzt eß' ich erstmal ne leckere Feinfrostpizza.

Mahlzeit

[peterchen]

@Knuddl: Es gibt in der C/C++-Welt sehr wenige stringformate/wrapper, die nicht einen null-terminierten String wenigstens als "Bridge" anbieten.
Ball gefangen hab?

Hab nix gegen die STL-Variante - hab' nochmal alles brav gelesen und festgestellt, daß du sie tatsächllich nur "daneben gestellt" hast. Die m.E. "sinnlosen" Kommentare kamen woanders her.

Ich habe gewiß deutliche Vorurteile gegenüber Programmierern, die ihnen als "gut" verkaufte Konzepte und Werkzeuge als den heiligen Gral hinnehmen, ohne die Randbedingungen zu erfragen. Ich bin in diesem Forum nicht zum ersten Mal angeeckt, weil jemand (auch berechtigte) Einwände hatte - nur war fast jedesmal das Hammerargument "Nicht Standardkonform" (was ich bei dieser Frage nach wie vor für falsch halte) - und kein Wort mehr. Siehe cd9000. Als hätte ich "Jehova" gesagt - ohne Sinn und Verstand. Find ich putzig, ist mir in keinem anderen Forum so untergekommen, wollt ich mal nachbohren.

aber weil's so shön ist..

@ShadeofMine:

CUJ/Alexandrescu lesen enthebt mich leider nicht vom selbst denken.

Kannst du mir bitte erklären, was an der strtol-Lösung schlecht ist?

**std::string vs. char const ***
Betrachte doch char const * einfdach mal als Bridge-Typ zwischen der String-Klasse (die nicht eindeutig bekannt ist) und den im C++ - Standard verfügbaren Funktionen... ist doch plötzlich allerfeinstes Design. Ich bin natürlich davon ausgegangen, daß die Implementation von String einen Null-terminierten (w)char const * als bridge unterstützt.

Weiterhin: Es gibt unzählige Situationen, in denen ein std::string besser ist als ein char * - aber keinen absoluten Grund.

RAII - welche Resourcen werden in der strtol-Variante bitte aquiriert?
Netterweise kann nur in der STL-version überhaupt eine Exception fliegen...

Exceptions = weniger code: Nur bedingt. Exceptions separieren primär Fehlerbehandlung vom "normalen" Programmfluß. (Was unbestritten Vorteile hat.) Weniger Code bekommst du nur, wenn die Exceprtion tatsächlich über mehrere Aufrufe durchgereicht wird - das ist aber eher marginal, weil für sinnvolles User-Feedback meist eine Übersetzung der Exceptions notwendig ist.

Performance strtol beinhaltet nur den Konvertierungskern, die STL-Version einiges mehr. Hm... stringstream anlegen, der noch ein streambuf anlegt, string kopieren (im günstigen fall referenzgezählt), und dann erst die Umwandlung - also mein compiler optimiert das nicht alles weg. da muß strtol sich schon viel Mühe geben, nicht hinterherzukommen. Und wenn dir std:.string so am Herzen liegt - was ist

strtol kennen oder nicht Ich bin nur davon ausgegangen, daß jemand wirklich den gesamten Vertrag der involvierten Entities studieren muß - z.B. um einen Fehler zu finden. Da machtz es keinen Unterschied, ob man von dem einen schon mal was gehört hat und dem anderen nicht - höchstens, wenn man mit dem einen regelmäßig arbeitet, und dem anderen nicht.

Falsches Forum erstens war meine einzige Standard-Verletzung das "deprecated" stdlib.h, zweitens wurde die Frage ursprünglich in einem anderen Forum gestellt. Ich will euch eure templates doch nicht wegnehmen, Menschenskinder.