strtoint gibt 0 zurück

[JPSelter]

Hätte nicht gedacht, dass mir folgendes solche Probleme macht:

Code:

ein_string:='42';
ein_integer:=strtoint(ein_string);

Das Ergebnis von ein_integer ist 0 und nicht 42. Nur wieso?

[TeronG]

Evtl. "Anti-Fans" von Anhalter bei Borland!? :duck:

[Klaus01]

Hallo,

welche Delphi Version nutzt Du?

Was für ein Typ ist ein_string? (AnsiString, String, WideString)?

Grüße
Klaus

[mirage228]

Delphi 7 Prof und es geht ohne Probs:

Delphi-Quellcode:

var
 ein_string: string;
 ein_integer: integer;
begin
  ein_string:='42';
  ein_integer:=strtoint(ein_string);
  ShowMessageFmt('%d', [ein_integer]);
end;

Ausgabe ist '42'...

[himitsu]

Hast du "ein_integer" auch nach der Zuweisung verwendet?
(also nicht nur genau diesen Code und dann versucht es im Debugger auszulesen

[JPSelter]

Hier der Originalcode:

Code:

var zeile,i: integer;
    tag,monat,jahr: integer;
    temp,temptag: string;

temp:=Excel.Cells[zeile,1].value;
temptag:=temp[1]+temp[2];
tag:=strtoint(temptag);

Ich öffne eine Exceltabelle und lese eine Zelle aus, in der ein Datum steht. Dieses Datum möchte ich mit einer anderen Zeit im Unix-Format vergleichen, muss aber den Umweg über einen integer gehen (lassen wir das mal so dahingestellt). Ich nehme mir also das erste und zweite Zeichen und mache daraus einen integer-Wert, den ich danach umrechne nach Unixtime. Aber es kommt immer 0 raus... die Werte davor sind aber ok.

[Wolfgang Mix]

Bei D2005 ergibt sich auch 42.

Gruß

Wolfgang

[himitsu]

wie gesagt, wenn du Tag nicht verwendest, wird es von Compiler, im Zuge der Codeoptimierung, schnell mal entfernt
und da es dann diese Variable nicht mehr gibt, zeigt der Debugger "Mißt" an.

[TeronG]

Wie "siehst" du denn, dass da Müll drinnen steht?
Nur über den Debugger?

Teste doch mal sowas aus...

Delphi-Quellcode:

MessageDlg(temptag, mtWarning, [mbOK], 0);
oder 
Caption := temptag
oder 
...

Wie himitsu schon sagte macht Delphi die "witzigsten" Sachen im Hintergrund.

[hoika]

Hallo,

Zitat:

temp[1]+temp[2];
nehme mir also das erste und zweite Zeichen

Hast du den Wert von temptag mal im Debugger geprüft ?

Ich würde das per Copy machen

Delphi-Quellcode:

temptag:= Copy(temp, 1, 2);

Ausserdem würde ich Präfixe verwenden:

Delphi-Quellcode:

var
  iRow: iXXX: integer;
  iTag,iMonat,iJahr: integer;
  sTemp,sTempTag: string;

Solltest du weiter mit EnodeDate arbeiten,
sind das keine Integer, sondern Word.

Delphi-Quellcode:

  wTag,wMonat,wJahr: Word;

Heiko

[himitsu]

Delphi-Quellcode:

tag:=strtoint(temptag);
if tag = 0 then ;

oder was ich immer mach .. einfach die variable verwenden, wenn auch nicht ganz so sinnvoll :nerd:
(vor dem IF ist sie nun verwendet und danach gibt's wieder das selbe Problem)

[Luckie]

@hoika: Die ungarische Notation ist mittlerweile überholt und bei typensicheren Sprachen auch überflüssig. Sie macht Variablennamen eigentlich nur unlesbarer. Hinzukommt, wenn ich den Datentyp ändere, muss ich auch die Variablennamen ändern. Und außerdem zeigen einem moderne IDs auch den Datentyp an.

[hoika]

Hallo,

Einsoruch ;)

Bsp
tag

Es gibt ein property Tag.
Vielleicht wird das hier gerade "benutzt".

Und gerade ebend bei den Datenbanken.

Delphi-Quellcode:

var
  Name: String;
begin
  Name:= 'Meier';
  with Query do
  begin
    SQL.Text:= 'Select * From Personal Where Name=:Name';
    ParamByName('Name').AsString:= Name;
    Open;
    try
    finally
      Close;
    end;
  end;
end;

Wer den Fehler findet, bekommt ein Bonbon ;)

Mache ich statt Name ein sName, habe ich kein Problem.
OK, ohne das with gibt es auch keines ;)


Heiko

[DeddyH]

Hatten wir genau dieses Phänomen nicht erst am Wochenende? :mrgreen:

[nahpets]

Zitat:

Zitat von DeddyH

Hatten wir genau dieses Phänomen nicht erst am Wochenende? :mrgreen:

und deshalb benutze ich weiterhin die "veraltete" ungarische Notation. http://de.wikipedia.org/wiki/Ungarische_Notation, dann komme ich mit lokalen Variablen und Attributen von Klassen nie durcheinander.

[JPSelter]

Ich hab "tag" einfach mal in "tagx" umbenannt, bekomme aber wieder nur eine 0. Die sehe ich über den Debugger, habe eine Zeile nach dem strtoint einen Haltepunkt eingefügt. Im String davor steht eindeutig eine '17'.

[JPSelter]

Hmmm jetzt begreife ich gar nichts mehr, denn mit einem eingefügten showmessage klappt es...

a) ohne showmessage, einen Haltepunkt in der Programmzeile NACH dem strtoint, Debugger sagt bei der Variable tag "0"
b) kein Haltepunkt, aber ein showmessage in der Zeile nach dem strtoint, Debugger und das showmessage geben korrekt die "17" aus

Hmmmmm...

[DeddyH]

Vielleicht ist die Zeile wegen anschließender Nichtbenutzung wegoptimiert worden.

[himitsu]

sagte ich doch
und nicht nur vielleicht

alles was in ein Register paßt wird wegoptiomiert, wenn es nicht zufällig irgendwo auf'm Stack liegt
nur Strings, dynamische Arrays und Interfaces werden nicht wegoptiomier, da dort beim END; erst aufgeräumt wird

[DeddyH]

Das hab ich glatt überlesen (sogar 2 mal :shock:)

[nahpets]

Hallo,

befindet sich die Routine in einem Formular?

Dann könnte folgende Überlegung eventuell weiterhelfen.

Du hast eine lokale Variabel tag.
Das Formular hat ein Attribut Tag.

Der Compiler erkennt die Variabel tag und Du kannst sie benutzen und im Debugger "begutachten".
Die gilt auch für das Attribut Tag.

Der Compiler geht nun her und wirft Variabeln zu dem Zeitpunkt weg, bei dem er der Meinung ist, das die Variabel nicht mehr benötigt wird.

Das Problem, das hier nun auftritt ist: Der Compiler ist einer anderen Meinung als Du, was die Lebensdauer der Variabel tag angeht. Zu dem Zeitpunkt, an dem Du auf die Variabel tag zugreifst, ist der Compiler der Meinung, dass die Variabel tag nicht mehr benötigt wird, er ist der Ansicht, dass Du auf das Attribut Tag zugreifen möchtest und liefert es Dir.

Und nun beweise Du mal dem Compiler, dass er Unrecht hat :wink:

Problemlösungsmöglichkeit: Konsequent keine Variabelnnamen nutzen, die auch als Attribute (anderer Klassen) vorkommen (könnten). Also alles weglassen, was Attribut des Formulars ist, wie z. B.: Name, Enabled, Visible, Tag, Height, Align, Width... . Deshalb ist hier die ungarische Notation durchaus hilfreich. Du muss sie ja nicht konsequent in vollem Umfang umsetzten, aber nimm sie als Richtschnur, Hilfestellung... für eine konsequente eigene Vergabe von Variabelnnamen. Schlimmstenfalls setze vor alle eigenen Variablemnamen ein my (für: Die Variabel ist mirzu oder meineseine;-)) oder loc (für lokale Variabel). Bei solchen Problemen suchst Du die in großen Projekten 'nen Wolf und das ist durch Namenskonventionen vermeidbar.

[TeronG]

Zitat:

Zitat von nahpets

Problemlösungsmöglichkeit: Konsequent keine Variabelnnamen nutzen, die auch als Attribute (anderer Klassen) vorkommen (könnten).

Theoretisch ein guter Tipp.
Aber nicht die Lösung von diesem Problem. ;) (siehe u.a. #16)
Wie himitsu schon (mehrfach ^^) schrieb würde auch ein iTag (vTag, ...) "weg-optimiert" werden.
Einfach das Tag-Dings iwo (nochmal (?)) verwenden und gut isses (oder sollte es zumindest sein ^^)

[JPSelter]

Klappt ja jetzt ;-) Danke Euch allen... eine Frage habe ich aber noch... *WindowsAPI-Forum*

[nahpets]

Hallo,

Zitat:

Zitat von JPSelter

Klappt ja jetzt ;-) Danke Euch allen... eine Frage habe ich aber noch... *WindowsAPI-Forum*

bitte noch die Lösung hier (als Quelltext?) posten, bin halt neugierig und andere interessiert es sicherlich auch, warum das Problem nun weg ist und vor allem, was jetzt eigentlich die Ursache war.

[Wolfgang Mix]

Ja bitte

Gruß

Wolfgang