StrToFloat ohne try...catch... - wie?

Ingo

Ich teste es also mit try...catch...
Gibts noch eine andere Lösung ohne mit try...?

1. Weisst du wozu try und catch da sind ?
2. Was hat das mit StrToFloat zu tun ?

Ingo

Wenn der String keinen gültigen Gleitkommawert enthält, gibts einen EConvertError. Den fange ich für die Fehlerbehandlung mit try catch ab.
Tja, führt wohl kein Weg daran vorbei, was?
Mir wäre es lieber, ich würde einfach ein bool oder so zurück bekommen, ob die Konvertierung erfolgreich war, oder nicht.

was gefällt dir am try catch denn nicht? und vorallem was hindert dich dran trotz allem dem einen boolschen wert auszugeben? das kannst du im try cathc block machen oder eine boolfunction nutzen. nur sehe ich darin auch keinen weiteren sinn...

Windoof

Schreib dir doch 'ne Funktion:

bool CanStrToFloat(String Value)
{
  try
  {
    float test=StrToFloat(Value); // Testen, ob's geht
    return true; // Bei Erfolg wird true zurückgegeben
  }
  catch(...)
  {
    return false; // Ansonsten eben false ;)
  }
}

EDIT:

Ist wunderbar,um den Quelltext zu kürzen:

String sTmp="0,4321";
float fTmp=0;
if(CanStrToFloat(sTmp))
  fTmp=StrToFloat(sTmp);
else
  Application->MessageBox("Konnte Wert nicht umwandeln.","Fehler",16);

Ingo

das ist mir alles klar, was ihr schreibt. für die Antworten danke ich erstmal.
jedes Mal, wenn im Builder eine Exception abgefangen wird, wird die Programmausführung aus dem Entwicklungsumgebung heraus angehalten und eine entsprechende Meldung ausgegeben. Das nervt mich.

Windoof

Das kann man ausschalten... außerdem kann man auch nur "Projekt erstellen" und dann die Exe ausführen...

Blackhawk

@Ingo: debugger...
nimm dazu STRG+F9
ist projekt aktualisiern oder erzeugen oder sowas halt.

Ingo schrieb:

das ist mir alles klar, was ihr schreibt. für die Antworten danke ich erstmal.
jedes Mal, wenn im Builder eine Exception abgefangen wird, wird die Programmausführung aus dem Entwicklungsumgebung heraus angehalten und eine entsprechende Meldung ausgegeben. Das nervt mich.

dann programmiere gleich anständige ich fange solche sachen so ab, daß die exceptions erst gar nicht auftreten!

Ingo

rowisoft

..ausser du willst GANZ ausführlich gehn:

bool isValidFloat(String strNumber)
{
  for (int i = 1; i <= strNumber.Length(); i++)
  {
    if (  ((strNumber[i] == '.' || strNumber[i] == ',') && (strNumber[i] != DecimalSeparator))
       || ((strNumber[i] < '0' || strNumber[i] > '9') && (strNumber[i] != DecimalSeparator) && (strNumber[i] != '-'))
       || ((strNumber[i] == '-') && (i > 1))  )
      return false;
  }
  return true;
}

...ich würds net tun
und natürlich müsste dann noch ne Prüfung rein, ob die Zahl in Float reinpasst, nicht dass der String 1000 Zeichen lang ist

Grüße,
Robert

Ingo

Ja und du müsstest auch noch prüfen, ob nicht vielleicht die wissenschaftliche Schreibweise verwendet wird. Sowas auf Gültigkeit zu prüfen ist imho sehr aufwändig. Würg. Es wird, das war ja schon meine Vermutung, bei der try/catch-Geschichte bleiben müssen.

Windoof

Ganz genau, denn für soetwas wurde try...catch... ja gemacht.

Nash

Hallo,

Jede Exception verbraucht Speicher...
Besser man nimmt das hier : "TryStrToFloat" zu finden in "SysUtils".

Bis dann denn,

Nash

Ingo

Habe Sysutils.hpp eingebunden, nehme an, dass das die entsprechende Bib ist. Aber leider behauptet der Compiler beharrlich, TryStrToFloat nicht zu kennen. Wäre ne undefinierte Funktion

Jede Exception verbraucht Speicher...

Ja und da die heutigen Recvner dafür nicht ausgelegt wurden, sollten man darauf also komplett verzichten. der speicherverbrauch ist hierbei so hoch, dass man wirklich eine andere lösung suchen sollte!

akari

Ingo schrieb:

Habe Sysutils.hpp eingebunden, nehme an, dass das die entsprechende Bib ist. Aber leider behauptet der Compiler beharrlich, TryStrToFloat nicht zu kennen. Wäre ne undefinierte Funktion

Bei mir (BCB 5) ist die Funktion TryStrToFloat auch nicht vorhanden. Die beste Lösung ist also immer noch Exceptions fangen. Wegen dem Speicher würde ich mir auch keinen Kopf machen.

bis bald
akari

Nash

Hallo,

Eigentlich sollte es egal sein, wieviel Speicher ein Rechner hat. Es geht darum, nicht unnötig Speicher zu verbrauchen. Es ist auch nicht so schlimm, wenn das nur ein paar mal passiert, aber wenn man das in einer Schleife mit mehreren tausend Durchläufen macht, kommen auch 512 MB bald an ihre Grenze. Durch solche Aktionen wird der Speicher fragmentiert und unter Umständen kann dann für andere Programme nicht mehr ein genügend großer Speicherbereich aloziert werden.
Außerdem gibt es doch schon genug speicherfressende Programme, warum noch ein neues hinzufügen...

@ Ingo :
Also im 6er C++Builder gibt es "TryStrToFloat()"...

Bis dannd enn,

Nash

akari

Nash schrieb:

Hallo,

Eigentlich sollte es egal sein, wieviel Speicher ein Rechner hat. Es geht darum, nicht unnötig Speicher zu verbrauchen. Es ist auch nicht so schlimm, wenn das nur ein paar mal passiert, aber wenn man das in einer Schleife mit mehreren tausend Durchläufen macht, kommen auch 512 MB bald an ihre Grenze. Durch solche Aktionen wird der Speicher fragmentiert und unter Umständen kann dann für andere Programme nicht mehr ein genügend großer Speicherbereich aloziert werden.
Außerdem gibt es doch schon genug speicherfressende Programme, warum noch ein neues hinzufügen...

@ Ingo :
Also im 6er C++Builder gibt es "TryStrToFloat()"...

Bis dannd enn,

Nash

Wieviel Speicher braucht denn eine Exception? Und ich schreibe bewußt eine Exception. Denn selbst wenn ich eine Schleife mit tausend Durchläufen habe, werfe ich doch nur eine Exception, um diese Schleife in Fehlerfall (also eigentlich Ausnahmefall) zu beenden.
Klar, wenn TryStrToFloat bei mir vorhanden wär, würde ich auch das nehmen. Doch ich arbeite doch lieber mit Exceptions als selber eine Konvertierroutine zu schreiben.

bis bald
akari

rowisoft

Hallo Nash,

gebe dir vollkommen Recht! TryStrToFloat kannte ich bisher auch nicht, gefällt mir aber.
Es geht auch nicht unbedingt um den Speicher, sondern darum wie sauber programmiert ist! Und die Lösung mit try catch ist irgendwie nicht so ganz sauber und macht den Quellcode meiner Einsicht nach unnötig unübersichtlich.

Grüße,
Robert