bitte löschen



  • bitte löschen



  • adziu24 schrieb:

    begrenzung halt fuer int z.b. 2147483647

    segfault bekommt man dann.., wenn man den wertebereich des übergebenen datentyps
    überschreitet - warum sagt mir das keiner?

    Nein, das ergibt einen Überlauf.

    int i = 2147483647;
    i++;
    

    gibt keinen segfault. i ist dann -2147483648. (bei 32-Bit int)

    segfault kommt dann, wenn man Speicherbereiche schreiben/lesen will, für die das Programm keine Rechte hat.



  • bitte löschen



  • adziu24 schrieb:

    Ein Menge Code
    

    bin noch C neuling... probier nur bissel rum ^^

    Ja, mach mal.



  • adziu24 schrieb:

    bin noch C neuling...

    Dank Deiner ausgeprägten Beratungsresistenz wird sich daran auch nichts ändern.



  • bitte löschen



  • adziu24 schrieb:

    sry, aber von was redest du da? das von vorhin war sarkasmus, wie ich erwähnt habe
    und was soll an meinem rumspielcode jetzt noch falsch sein?

    Immer noch dasselbe:

    char eine_zahl[1];
    
    ...
    
    sprintf(eine_zahl, "%lf", zahl);
    
    ...
    
    sprintf(eine_zahl, "%d", zahl);
    

    Viel Erfolg weiterhin.



  • Ganz ehrlich! Ich finde deinen Code schrecklich kompliziert und damit nimmst du mir die Lust nachzuprüfen, ob er wirklich richtig arbeitet. An deiner Stelle würde ich den ganzen redundanten Eingabe-Code in eine eigene Funktion packen. Das Argument, dass ein Funktionsaufruf kostet, das zählt bei einer Eingabe definitiv nicht. Auch das du den Wertbereich hart rein gecodet hast, ist nicht wirklich schön. Dafür gibt es Konstanten, damit du bei einem Systemwechsel keine Probleme bekommst. Auch wenn das in deinem Fall wahrscheinlich eher unwichtig ist. Eine Sprache ist aber eine Routine-Angelegenheit und schlechte Angewohnheiten bekommt man nur schwer raus.



  • Er hat doch jetzt solange an seinem Code rumgespielt bis es funktioniert.
    Er glaubt ein Zahlenüberlauf gibt einen segfault. Nun denn.
    Wir haben ihn mehrmals auf den Fehler hingewiesen.
    Das eine Programm, das den Fehler klar machen sollte hat er richtig korrigiert.

    Das Programm was er jetzt gepostet hat, hat mit dem Problem nichts zu tun, bzw. tritt es dort durch "glückliche" Umstände nicht auf.
    Und jetzt ist es nur nuch rumgetrolle.

    Ist wie bei "drink and derive"

    a = b
           a² = ab        | * a
          2a² = a² + ab   | + a²
    2a² - 2ab = a² - ab   | - 2ab
    2a(a - b) = a(a - b)  | / (a-b)
           2a = a         | / a
            2 = 1
    

    Und dann passen auch 8 Zeichen in ein char[1]. 😃

    Wer den Fehler findet/weiss, darf ihn behalten.



  • nun denn.. ich werd erstmal paar ganz triviale funktionen benutzen,
    "solange ich nix von char arrays weiß" ^^

    ihr könnt mich später belehren, wenn ich mehr in erfahrung gebracht habe ;P



  • DirkB schrieb:

    Wer den Fehler findet/weiss, darf ihn behalten.

    | / (a-b)
    

    🙂



  • Viele Hinweise hier, aber nur wenig brauchbares dabei. Ist relativ einfach:

    # String to double: atof() einsetzen
    # double to string: sprintf() einsetzen oder meine Funktion dtoa() von meiner HP herunterladen (verwendet auch sprintf)



  • Soso, atof soll man also benutzen, wo ist denn dabei die Fehlerbehandlung, wo ist die Über/Unterlaufsprüfung?
    Deine angegebenen Funktionen verwenden u.a. itoa, dass ist weder C89 noch C99, das ist gar nichts.



  • Wutz schrieb:

    Soso, atof soll man also benutzen, wo ist denn dabei die Fehlerbehandlung, wo ist die Über/Unterlaufsprüfung?
    Deine angegebenen Funktionen verwenden u.a. itoa, dass ist weder C89 noch C99, das ist gar nichts.

    ad atof: Die Funktion double = atof(const char *s) akzeptiert jeden string, z.B auch "123456e50". Nur muss man natürlich wissen, welchen Wertebereich der Typ double annehmen kann. Die Funktion atof prüft das nicht, liefert aber dennoch brauchbares zurück.

    ad ito: Die Funktion char *itoa(int value,char *string,int radix) ist in der Tat kein ANSI-C, dennoch bei den meisten C-Compilern verfügbar. Ich benutze sie auch nur für die Aufbereitung des Formatstrings in sprintf.

    Wer will, kann statt sprintf auch die ANSI-C-Funktion strtod einsetzen, die liefert aus einem string ebenfalls einen double.

    Ich denke, jetzt ist alles zur gestellten Frage gesagt. daddeldu :p



  • berniebutt schrieb:

    Wer will, kann statt sprintf auch die ANSI-C-Funktion strtod einsetzen, die liefert aus einem string ebenfalls einen double.

    Ich denke, jetzt ist alles zur gestellten Frage gesagt. daddeldu :p

    Aber nich zu deiner Aussage:

    strtod ist kein Ersatz für sprintf.
    sprintf und strtod sind Umkehrfunktionen zueinander.
    3.14 -> sprintf -> "3.14" -> strtod -> 3.14



  • berniebutt schrieb:

    ad ito: Die Funktion char *itoa(int value,char *string,int radix) ist in der Tat kein ANSI-C, dennoch bei den meisten C-Compilern verfügbar. Ich benutze sie auch nur für die Aufbereitung des Formatstrings in sprintf.

    Kann das sprintf() nicht selbst?



  • mngbd schrieb:

    berniebutt schrieb:

    ad ito: Die Funktion char *itoa(int value,char *string,int radix) ist in der Tat kein ANSI-C, dennoch bei den meisten C-Compilern verfügbar. Ich benutze sie auch nur für die Aufbereitung des Formatstrings in sprintf.

    Kann das sprintf() nicht selbst?

    Klar kann sprintf() das mit explizit vorgegebem Formatstring selbst! Es kann aber nützlich sein, so etwas in eine eigene Funktion mit der Angabe der gewünschten Länge und den gewünschten Nachkommastellen zu packen. So kann ich leicht die beiden Angaben in übergordneten Variablen, z.B. int iw=12, ip=2; festlegen. Brauche ich etwas anderes, ändere ich nur die Werte dieser Variablen und erspare mir das Herumwühlen im Quelltext.

    Das bleibt aber Geschmacksache der Programmierung. Mir erscheint ein solcher Weg sinnvoll und ich verwende ihn ausgesprochen gerne.

    Aber, was lernt uns das alles? Mir fällt dazu nur der Refrain des plattdeutschen Liedes von Jan Hinnerk ein: "He kann moken wat he will - un dorbi wohnt he noch jümmer in de Lammerstraat - he kann moken wat he will!" 😞


Anmelden zum Antworten