fehler beim auswerten eines Zeichens aus einem String in einem CASE

[BabCom]

Danke für die antwort Captain Obvious das werd ich gleich mal ausprobieren.
Das könnte sehr gut zutreffen ich werd's wiegesagt gleich mal prüfen hab das alte Programm ja noch.

@SeppJ
Nein wenn mein Compiler mir was sagt dann glaub ich das, sonst hätte ich hier nicht nach gefragt.
Und das was du mir im vorherigem Post geschrieben hast glaube ich auch nur hat's mich nicht wirklich weiter grebracht. denn das da nen fehler ist hat mir mein Compiler vertaten.
Ich habe mir blos erhofft das jemand weiß wiso der Compiler diesen Fehler meldet. und was ICH Falsch gemacht habe(n könnte).

@manni66
No komment

[BabCom]

Ich habe das mit dem unsigned char geprüft und im alten c Programm ist ibuf tatsächlich unsigned.

währe die lösung dann einfach

switch((unsigned char)ibuf[7]) // buffer[7] enthält den Funktion code der Antwort oder einen error code
    {
    case 0x04: //es wurde mit dem Richtigen Fkt Code geantwortet

anstatt von:

switch(ibuf[7]) // buffer[7] enthält den Funktion code der Antwort oder einen error code
    {
    case 0x04: //es wurde mit dem Richtigen Fkt Code geantwortet

??

[SeppJ]

Wenn, dann bitte static_cast<unsigned char>(ibuf[7]) . Kann richtig sein. Ist es wahrscheinlich auch. Kommt eben auf den Kontext an. Ist aber auf jeden Fall verdächtig, wenn man solche Umwandlungen braucht, denn das heißt, vorher lief irgendwo was falsch. Wieso ist der Typ denn nicht von vornherein unsigned char?

[Wutz]

Jammere nicht soviel rum, dass die gegebenen Antworten nicht komplett deinen Erwartungen entsprechen.
Wenn ich Erstantworter gewesen wäre, wäre deine Mimmosenhaftigkeit noch stärker strapaziert worden.
Es liegt auch nicht am "c programm" oder "c++ programm", sondern am Compiler, und am C Standard, der 3 unterschiedliche Typen char,signed char und unsigned char vorschreibt, und dafür jeweils die Wertebereiche

unsigned char:         0...UCHAR_MAX
signed char:   SCHAR_MIN...SCHAR_MAX
char:           CHAR_MIN...CHAR_MAX

und genau das prüft dein Compiler und kann (muss nicht!) hier eine Warnung ausgeben.
char ist implementierungsabhängig, d.h. der Compilerbauer legt das fest, ob äquivalent zu signed char oder unsigned char.
Deinen Cast kannst du so machen, Casts überdecken aber immer etwas und verlangen den totalen Überblick des Programmierers über seinen Code; der Compiler hier will dir also sagen, dass dein Ursprungsprogramm nicht portabel ausgelegt ist, eben weil du den Code anpassen musst um ihn woanders zum Laufen zu bringen; und auch hier wieder zeigt sich, dass C und C++ eben keine gleichen Programmmiersprachen sind.

[BabCom]

Also das leigt daran das ich mir eine Netzwerk Schnittschtelle gebaut habe in der das komplete Netzwerk management(dh Einstellungen wie AF_INET etc.) in eine Extra Klasse ausgelagert ist. Dies klasse habe ich intern mit c++ strings für die buffer aufgebaut.
Das hält meinen Code deutlich übersichtlicher als wenn ich zwischen der reinen Datenverarbeitung auch noch die ganzen socket sachen zwischen hätte. Daher kommt dann auch mein Problem. Die Daten werden als Strings(char arrays) gebuffert ich brauche aber unsinged.

Dan bendake ich mich hier für die schnelle hilfe.
MFG BabCom

[Wutz]

Kapseln kannst du auch in C. Sogar effizienter und benutzerfreundlicher als in C++.
Kapselung ist nur eine Eigenschaft von C++-Klassen.

[SeppJ]

strings für Netzwerkaktivität klingt komisch. Brauchst du wirklich Zeichenkettenverarbeitung oder bloß einen variablen Haufen (signed/unsigned) chars? Letzteres wäre nämlich vector<gewünschter chartyp> . Falls der Haufen nicht einmal variabel groß sein braucht, sogar nur array<chartyp> .

[BabCom]

nun ja das hat seinen begründung darin, das ich diese Klasse wiederverwendbahr haben wollte, dh sie nicht nur speziell für diese Netzwerkanwendung sondern im zweifel auch für spätere Anwendungen benutzen will.

Ich werde das ganze nächste woche durch teste nund dann evtl mit weitere Fragen aufwarten.^^

[Kellerautomat]

Wutz schrieb:

Sogar effizienter und benutzerfreundlicher als in C++.

Also ich weiss ja nicht wie's dir geht, aber Konstruktoren und Destruktoren manuell aufzurufen ist nicht mein Ding.

[käpsele]

Kellerautomat schrieb:

Wutz schrieb:

Sogar effizienter und benutzerfreundlicher als in C++.

Also ich weiss ja nicht wie's dir geht, aber Konstruktoren und Destruktoren manuell aufzurufen ist nicht mein Ding.

Was haben Konstruktoren mit Kapselung zu tun?

[häh?!]

Wutz schrieb:

Sogar...benutzerfreundlicher als in C++.

Dem Benutzer dürfte es doch ziemlich schnuppe sein, ob der Code in C oder in C++ geschrieben wurde und das Programm sollte sich in beiden Fällen nach außen gleich verhalten. Wenn ein Benutzer z.B. etwas in der Konsole eingeben soll, kriegt er also nicht mit, ob nun ein fgets oder ein cin dahinter steckt.
Begründe mal deine Aussage, wenn sie nicht als Nonsens angesehen werden soll.

[lol?!]

häh?! schrieb:

Wenn ein Benutzer z.B. etwas in der Konsole eingeben soll, [...]

Wie wäre es mit Benutzer = Benutzer von C bzw. C++ = Programmierer?
Etwas Textverständnis sollte schon vorausgesetzt werden können, zumal es hier alle Poster vor dir verstanden haben.

[Kellerautomat]

käpsele schrieb:

Kellerautomat schrieb:

Wutz schrieb:

Sogar effizienter und benutzerfreundlicher als in C++.

Also ich weiss ja nicht wie's dir geht, aber Konstruktoren und Destruktoren manuell aufzurufen ist nicht mein Ding.

Was haben Konstruktoren mit Kapselung zu tun?

Nichts. Hab ich auch nicht behauptet.
Ich habe damit gemeint, dass ich C besonders deshalb nicht leiden kann, weil es kein RAII kann.

[it n00b]

lol?! schrieb:

häh?! schrieb:

Wenn ein Benutzer z.B. etwas in der Konsole eingeben soll, [...]

Wie wäre es mit Benutzer = Benutzer von C bzw. C++ = Programmierer?
Etwas Textverständnis sollte schon vorausgesetzt werden können, zumal es hier alle Poster vor dir verstanden haben.

du hast Ahnung

du kennst dich mit geläufigen begriffen der it-branche aus

[käpsele]

Kellerautomat schrieb:

Ich habe damit gemeint, dass ich C besonders deshalb nicht leiden kann, weil es kein RAII kann.

C braucht das auch nicht, weil es keine Exceptions kennt.

Das Problem an RAII ist, dass es nicht ausschaltbar ist. Es macht genau 0 Sinn, den Destruktor von einem moved-from unique_ptr aufzurufen oder von einem sicher leeren Vektor. Und vor C++ war RAII noch schrecklicher, oder wie möchtest du ein Objekt, das klar nicht kopierbar ist aus einer Funktion rausbefördern? Das ging nur mit einer zusätzlichen Indirektion à la Pointer aka Anti-RAII oder auto_ptr aka DesignFailure oder shared_ptr aka Selbst-Java-Ist-Schneller.

RAII ist sehr oft sehr praktisch, aber manchmal ginge es benutzerfreundlicher und effizienter.

[out]

käpsele schrieb:

RAII ist sehr oft sehr praktisch, aber manchmal ginge es benutzerfreundlicher und effizienter.

Wie? Wo? Wann? Beispiel? Ich hatte mit RAII noch nie iregendwelche Probleme, du schon?

[Nathan]

käpsele schrieb:

Kellerautomat schrieb:

Ich habe damit gemeint, dass ich C besonders deshalb nicht leiden kann, weil es kein RAII kann.

C braucht das auch nicht, weil es keine Exceptions kennt.

HANDLE_TO_STH handle = create_handle(some_params);
if (!handle)
    return ERR_NOT_CREATED;

if (!do_something_with(handle));
    return SOME_OTHER_ERR;

destroy_handle(handle);
return ALL_RIGHT;

Ups.

[käpsele]

Schlechten Code kann man in allen Programmiersprachen schreiben oder willst du dass ich ein Beispiel mit new/delete bringe?

int do_this_with_handle(HANDLE* handle)
{
  if (!do_something_with(handle));
    return SOME_OTHER_ERR;

  return ALL_RIGHT;
}

HANDLE_TO_STH handle = create_handle(some_params);
if (!handle) {
  perror("bad luck");
} else {
  if (do_this_with_handle(handle) == ALL_RIGHT)
    puts("all right")
  destroy_handle(handle);
}

[Nathan]

käpsele schrieb:

Schlechten Code kann man in allen Programmiersprachen schreiben oder willst du dass ich ein Beispiel mit new/delete bringe?

Klar, kann man schlechten Code schreiben.
Aber nehmen wir mal an, man nutzt das handle mit einer Funktion, die, wenn sie schief geht auch keine Zerstörung erfordert (nur ein Beispiel). Dann kommt irgendwann ein anderer Programmierer daher, muss unter Zeitdruck ein weiteres Feature einbauen und fügt nur mal eben die do_something_with() mit Fehlerbehandlung ein (so wie ich das hatte, nicht so wie du das hattest).
So, und nun?
Was ich sagen will: mit RAII kann so etwas überhaupt nicht passieren. Jeder macht mal Fehler, wir sind auch nur Menschen.
Und delete nutzt man in gutem C++ (mit RAII) sowieso nicht.

[käpsele]

Ich sage ja nicht, dass RAII schlecht ist. RAII und C++, das passt gut zusammen, RAII und Non-Memory-Ressourcen, das ist eine super Lösung. Allerdings: File-Handling ist nur ein geringer Teil im Code. Den Code, der die Aktion ausführt in eine Funktion auszulagern und den Funktionsaufruf zwischen ein open/close einschieben ist ohne Exceptions ein gangbarer Workaround (dann kann man auch mal eben so was im Code hinzufügen).

Ich sage nur, dass RAII auch Probleme hat. Schreib in pre-C++11 mal eine Funktion, die einen ofstream zurückgibt => nur mit Hacks möglich. Und wenn du das in C++11 mit move() geschafft hast, versuch dann mal, den unsinnigen Destruktoraufruf zu verhindern => nur mit Hacks möglich.