StreamWrite erzeugt nur 0 Byte-File

[tomsel]

Delphi-Quellcode:

...
  bStreamOk := true; 
  try 
    datei := Tfilestream.create(s_filename, fmcreate or fmShareExclusive); 
  except 
    bStreamOk := false; 
  end; 

  if (bStreamOk = true) then 
    begin

Bevor ihr euch weiter in eine Grundsatzdiskussion verheddert, sagt mir doch mal bitte einer, wo in desem konkreten Fall das Problem mit dem Vergleich mit true genau liegt.

[ED]
bStreamOK hat beim Vergleich entweder den Wert der Konstanten TRUE oder den von FALSE, und keinen Anderen. Als Fehlerursache im Zusammenhang mit der Ausgangsfrage kommt der true-Vergleich daher m.E. nicht in Betracht. Oder irre ich mich, das wollte ich eigentlich nur wissen
[/ED]

[Muetze1]

Vorschlag: lies bitte den letzten Teil meines Beitrags zuvor, ab dem letzten Quote durch.

Zitat von tomsel:

bStreamOK hat beim Vergleich entweder den Wert der Konstanten TRUE oder den von FALSE, und keinen Anderen. Als Fehlerursache im Zusammenhang mit der Ausgangsfrage kommt der true-Vergleich daher m.E. nicht in Betracht. Oder irre ich mich, das wollte ich eigentlich nur wissen

Bei einer reinen Compilierung würde ich dir zustimmen, nicht aber wenn die Optimierung eingeschaltet ist. Diese optimierte das ganze um und zwar so, dass eventuelle Zuweisungen von irgendwelchen Konstanten (z.B. true) einfach ein Dekrement ausgeführt wird. Und schon kommt es zu einem solchen Verhalten. Um allen möglichen Fehlerquellen aus dem Weg zu gehen bietet sich die einfache Lösung an, niemals direkt auf true/false zu vergleichen und einfach mit NOT bzw. ohne in der Bedingung zu arbeiten. Delphi definiert dies ja eh explizit, dass der Vergleichsterm wahr ergeben muss, damit der nachfolgende Teil ausgeführt wird (bzw. im anderen Falle der Else-Zweig).

[p80286]

@Muetze1

danke! das ist mal eine gute Erklärung! Werd es mir hinter die Ohren schreiben.

In dem Zusammenhang eine Frage:

Besteht zwischen

Delphi-Quellcode:

bvar:=(a and b);
if bvar then ....

und

Delphi-Quellcode:

if (a and b) then bvar:=true
else bvar:=false;
if bvar then ...

ein Unterschied?
Ich vermute mal die erste Version ist zu bevorzugen.

Gruß
K-H

[mkinzler]

Benötigst du bvar anschliessend noch?
Dann natürlich die erstere

[Muetze1]

Zitat von p80286:

In dem Zusammenhang eine Frage:

Besteht zwischen

Delphi-Quellcode:

bvar:=(a and b);
if bvar then ....

und

Delphi-Quellcode:

if (a and b) then bvar:=true
else bvar:=false;
if bvar then ...

ein Unterschied?

Hier wäre es wirklich Geschmackssache, ob nun eine einzeilige Evaluierung genutzt wird oder es ausformuliert wird. Grundsätzlich ist ersteres für den Optimierer leichter zu erfassen (und zu optimieren), weil der zweite Konstrukt umfangreich ist und mit Konstantenzuweisungen arbeitet.

Da du die Variable direkt danach in einer Bedingung benutzt, würde ich es direkt auswerten in der If Anweisung, ausser die Variable wird noch woanders benötigt, dann würde ich persönlich die einzeilige Evaluation benutzten. Aber wie gesagt, das wäre hier wirklich Geschmackssache - im Gegensatz hierzu:

bvar := (a and b) = true; Hier würde dann wieder das zuvor geschriebene gelten, vor allem da dies nur bei boolschen Variablen a und b klappen sollte und bei allen anderen Ordinaltypen als a und b zu einer binären AND Operation führen und nicht zu einer logischen Evaluierung...

[p80286]

Vielen Dank euch beiden!

Gruß
K-H

[DevidEspenschied]

Zitat von Muetze1:

Delphi-Quellcode:

function DateiSchreiben(const AFilename: string; const AFileSize: Int64);

...
      lWritten := lStream.WriteBuffer(lFileData[1], Min(lBytesToWrite, coBlockSize));
...

Wenn ich Deine Funktion "DateiSchreiben" direkt übernehmen möchte, gibt es 2 Probleme. Das erste ist, dass der eigentliche Rückgabewert der Funktion während der Deklaration fehlt, es müsste also heißen:

function DateiSchreiben(const AFilename: string; const AFileSize: Int64) : Boolean; Das 2. Problem ist die Zeile mit WriteBuffer, wobei mir Delphi jedesmal den folgenden Compilierungsfehler meldet:

E2010: Inkompatible Typen: 'Integer' und 'procedure, untyped pointer or ununtyped parameter'.

Wobei Du von lFileData immer nur das erste Zeichen verwendest. Angenommen ich habe hier einen String mit 64 unterschiedlichen Zeichen, dann würde die Verwendung des ausschließlich 1. Zeichens falsche Ergebnisse liefern.

[Muetze1]

Zitat von devidespe:

Wenn ich Deine Funktion "DateiSchreiben" direkt übernehmen möchte, gibt es 2 Probleme. Das erste ist, dass der eigentliche Rückgabewert der Funktion während der Deklaration fehlt, es müsste also heißen:

Nun gut, vergessen - passiert. Ist schliesslich hier im Editor getippt und nicht in einem Projekt...

Zitat von devidespe:

Wobei Du von lFileData immer nur das erste Zeichen verwendest. Angenommen ich habe hier einen String mit 64 unterschiedlichen Zeichen, dann würde die Verwendung des ausschließlich 1. Zeichens falsche Ergebnisse liefern.

Hä? Ich gebe das erste Zeichen an - bzw. dessen Adresse, da WriteFile() einen untypisierten Var Parameter hat. Somit schreibe ich, wenn ich hinten nur eine 1 bei der Größe angeben würde, ein Zeichen, ja - aber ich gebe mehr als 1 bei der Grösse an und somit schreibt er auch alle nachfolgenden Daten und nach dem 1. Zeichen im String folgenden die anderen.

[DevidEspenschied]

Zitat von Muetze1:

Hä? Ich gebe das erste Zeichen an - bzw. dessen Adresse, da WriteFile() einen untypisierten Var Parameter hat.

Du meinst bestimmt WriteBuffer, da ich kein WriteFile entdecken kann.

Wie erklärst Du Dir die Fehlermeldung beim Compilieren ?

Übrigens nette Signatur, ich hätte aber an 3 Stellen jeweils 20h eingefügt.

[Muetze1]

Zitat von devidespe:

Du meinst bestimmt WriteBuffer, da ich kein WriteFile entdecken kann.

Ja, ich meinte WriteBuffer().

Zitat von devidespe:

Wie erklärst Du Dir die Fehlermeldung beim Compilieren ?

Na das WriteBuffer() eine Procedure ist und keine Funktion. Und da liegt auch der Fehler: WriteBuffer() gibt keine Anzahl der geschriebenen Bytes zurück, sondern versucht immer die angegebene Anzahl im Stück zu schreiben. Write() kehrt direkt zurück und gibt die Anzahl der geschriebenen Bytes an. Da hatte ich also die falsche Methode im Kopf.

Ich habe es eben nochmal schnell korrigiert in Delphi und getestet:

Delphi-Quellcode:

function DateiSchreiben(const AFilename: string; const AFileSize: Int64): boolean;
const
  coBlockSize = 16384;
var
  lStream: TStream;
  lFileData: string;
  lBytesToWrite: Int64;
  lWritten: Integer;
begin
  result := false;

    // Erstmal den Stream öffnen. Wenn das nicht klappt, brauch ich kein Array...
  lStream := TFileStream.Create(AFilename, fmCreate or fmShareDenyWrite);
  try
    lFileData := StringOfChar(#55, coBlockSize);

    lBytesToWrite := AFileSize;
    while ( lBytesToWrite > 0 ) do
    begin
      lWritten := lStream.Write(lFileData[1], Min(lBytesToWrite, coBlockSize));

      if lWritten <> Min(lBytesToWrite, coBlockSize) then
        exit;

      Dec(lBytesToWrite, lWritten);
    end;

    result := true;
  finally
    lStream.free;
  end;
end;

Zitat von devidespe:

Übrigens nette Signatur, ich hätte aber an 3 Stellen jeweils 20h eingefügt.

Da ich schon sehr gut Hex so lesen kann (wie manche andere auch), wäre das zu einfach gewesen, da 0x20 zu auffällig sind. So weiss man erstmal nicht ob es was sinniges etc ist.