char * mit enum wert vergleichen

Simon2

traceman schrieb:

Simon2 schrieb:
InitSerialBus(thread_prirec.baudRate);
Das Problem ist dass genau an der Stelle thread_prirec.baudRate ein Enumeratortyp stehen musss (in dem Fall also z.B. BAUD9600) und kein int oder string

Also ist das eine vorgegebene Funktion, die damit auch ParameterBereich und vermutlich sogar den Typen (enum) vorgibt.
Ergo: Es ist doch festgelegt und Du fährst mit der map gut.

BTW: "map" ist hier sogar ziemlich wörtlich zu verstehen: Du "mappst" (im Sinne einer Abbildung) nämlich Deinen Parametertyp (string, Werte von Dir festgelegt) auf den der genutzten Schnittstelle (enums).

Gruß,

Simon2.

asc

traceman schrieb:

Simon2 schrieb:
InitSerialBus(thread_prirec.baudRate);
Das Problem ist dass genau an der Stelle thread_prirec.baudRate ein Enumeratortyp stehen musss (in dem Fall also z.B. BAUD9600) und kein int oder string

Nicht desto Trotz ist ein enum ein Integerwert, und wenn du im Enum die Werte richtig verschlüsselt hast (Sprich z.b. BAUD9600 = 9600), läßt sich - vorausgesetzt es hat immer den gleichen Aufbau "BAUD<Zahl>" später über diesen Wert ein String generieren. Der Enum selbst ist freilich aber kein String.

cu André

Fellhuhn

InitSerialBus((BaudRateType)meinErmittelterBaudInt);

müsste einwandfrei funktionieren. Wenn natürlich der Enum vordefiniert ist, wovon ich jetzt einmal ausgehe, wenn die Funktion nicht von dir ist, dann kannst du natürlich auch deren Wertigkeit nicht ändern, oder?

Wenn dem so ist, dann müsstest du die ja nur einlesen und den Zahlenwert auf den Enum-Mappen. Und zum "mappen" eignet sich eine "map" bestens.

traceman

Fellhuhn schrieb:

... wenn die Funktion nicht von dir ist, dann kannst du natürlich auch deren Wertigkeit nicht ändern, oder?

thats the problem!

Fellhuhn

Dann reicht doch eine simple Map. Um es flexibel zu halten würde ich da auf std::map<unsigned int, BaudRateType> zurückgreifen. Dort fügst du dann die ganzen Vorgaben ein und bist damit durch. baudMap[2400] = BAUD2400 etc.

traceman

Ich hab jetzt noch genau nachgeschaut was für Baudraten der Receiver überhaupt kann. Die Auswahl beschränkt sich damit auf 6 Werte und die vergleiche ich dann mit einer Abfrage über map.

traceman

(...)
	sscanf(line.toStdString().c_str(),"%s %s",param,arg);
(...)

if (QString(param)=="[BAUDRATE_PRIM_REC]") {		
	std::map<std::string, BaudRateType> bdrpr;
	bdrpr["BAUD9600"] = BAUD9600;
	bdrpr["BAUD19200"] = BAUD19200;
	bdrpr["BAUD38400"] = BAUD38400;
	bdrpr["BAUD57600"] = BAUD57600;
	bdrpr["BAUD115200"] = BAUD115200;
	thread_prirec.baudRate = bdrpr[arg];
}

so gehts thanks@all

Simon2

Glückwunsch ....

aber: Warum DAS ?

traceman schrieb:

...QString(param)...

Gruß,

Simon2.

Fellhuhn

Weil er dann nicht strcmp benutzen muss.

traceman

Simon2 schrieb:

Glückwunsch ....

aber: Warum DAS ?

traceman schrieb:
...QString(param)...
Gruß,

Simon2.

(->Qt), habs aber jetzt schon auf c umgeschrieben

traceman

Fellhuhn schrieb:

Weil er dann nicht strcmp benutzen muss.

genau

Simon2

traceman schrieb:

Fellhuhn schrieb:

Weil er dann nicht strcmp benutzen muss.

genau

Und warum deswegen QString, wenn Du std::string sowieso schon nutzt ?

... und wo gerade für so Zeug wie "Parameterverarbeitung" std::string so viele und ausschließliche Vorteile ggü. char* hat, verstehe ich noch weniger, warum Du es nicht nutzt (geschweige denn, warum Du einen weiteren Stringtypen einführst).

Gruß,

Simon2.

traceman

Simon2 schrieb:

traceman schrieb:

Fellhuhn schrieb:

Weil er dann nicht strcmp benutzen muss.

genau

Und warum deswegen QString, wenn Du std::string sowieso schon nutzt ?

... und wo gerade für so Zeug wie "Parameterverarbeitung" std::string so viele und ausschließliche Vorteile ggü. char* hat, verstehe ich noch weniger, warum Du es nicht nutzt (geschweige denn, warum Du einen weiteren Stringtypen einführst).

Gruß,

Simon2.

Ist doch wurscht, funktioniert trotzdem

Fellhuhn

In den meisten Fällen hat QString gegenüber std::string den Vorteil, das man diese kinderleicht mit linguist internationalisieren kann. Macht natürlich nur bei konstanten Strings Sinn.

Warum C-Strings, kann ich aber auch nur raten.

simon.gysi

Warum C-Strings, kann ich aber auch nur raten.

Ja dann viel Spass beim raten.

Fellhuhn

Danke.

Simon2

Top2 der 'famous last words' schrieb:

...Ist doch wurscht, funktioniert trotzdem

traceman

Fellhuhn schrieb:

... mit linguist internationalisieren kann...

Versteh nur Obstkuchen

Fellhuhn

Nicht? Qt hat das nette Feature das jeder QString in der Art von

QString("narf")
// oder
tr("narf")

durch den Translator läuft. Bindet man diesen in das Qt-Projektfile ein, kann man mit einem Aufruf von linguist die Texte für beliebige Sprachen editieren. Der Sprachwechsel ist dann auch eine Kleinigkeit (nur zur Laufzeit ist das etwas tricky).

Siehe http://doc.trolltech.com/3.3/i18n.html oder welche Version man verwendet...

traceman

Fellhuhn schrieb:

Nicht? Qt hat das nette Feature das jeder QString in der Art von
QString("narf")
// oder
tr("narf")
durch den Translator läuft. Bindet man diesen in das Qt-Projektfile ein, kann man mit einem Aufruf von linguist die Texte für beliebige Sprachen editieren. Der Sprachwechsel ist dann auch eine Kleinigkeit (nur zur Laufzeit ist das etwas tricky).

Siehe http://doc.trolltech.com/3.3/i18n.html oder welche Version man verwendet...

Nett schlecht...ich glaub ich kauf mir mal ein qt buch wo man einen überblick über alle kapitel bekommt...