Power funktioniert nicht wie gedacht

[madas]

Zitat von TigerLilly:

Der Thread ist ein gutes Beispiel für "Wie löse ich anstelle meines Problems eines, das es gar nicht gibt, und zwar so, dass es keiner versteht?".

Das zu lösende Problem ist doch, dass es "rundherum" Beschränkungen in den erwarteten Typen gibt. Das sollte gelöst werden.
Wenn das - warum auch immer - nicht geht, dann ist die Aufgabenstellung sinnvoll zu lösen und das Ergebnis auf die Typen brauchbar abzubilden.

Jetzt gibt es eine Lösung, die MaxSize zurückliefert, auch wenn der richtige Wert > MaxSize wäre. Gar nicht gut.

if Multiplier> 0 then
Result := UInt64(1) shl (Multiplier* 10) // Das versteht keiner auf den ersten Blick.
else
Multiplier:= 1; // Das ist Irreführung - wird ja gar nicht mehr verwendet.

Result := Bytes * Result; // Welchen Wert hat Result, wenn Multiplyer 0 ist?

if Result > MaxSize then
Result := MaxSize; // das tut in der Seele weh

Wenn der Thread Ersteller schreibt er möchte Byte in MB oder GB umrechnen, verstehe ich nicht warum die Ergebnisse dann größer werden sollen.

[DieDolly]

Vielleicht ist es so klarer.

Ich habe einen numerischen Wert und die Zusatzinformation, ob das B, KiB, MiB, GiB oder TiB sein sollen.

Rufe ich meine (umbenannte) Funktion nun so auf, erhalte ich 46080 Bytes.

Delphi-Quellcode:

type
  TFileSizes = (_B, _KiB, _MiB, _GiB, _TiB, _PiB);

Ausgabe := ConvertToBytes(45, _KiB);

Ich speichere also irgendwo auf der Festplatte 45 sowie die Zusatzinfo (Speichergröße) ab statt große Zahlen.

Zitat:

// Welchen Wert hat Result, wenn Multiplyer 0 ist?

Im Beispiel oben wären das 45 (Bytes).

Zitat:

if Result > MaxSize then
Result := MaxSize; // das tut in der Seele weh

Warum sollte man jemals höher als 1 EiB gehen? So große Datenmengen gibt es sicherlich insgesamt. Aber ich habe im privatanwenderbereich noch niemanden gesehen, der eine einzelne Datei hat die so groß ist. Angenommen durch falsche Eingaben hat Result schließlich einen Wert von 1 YiB, dann führt das zu einem Fehler.
Da im im weiteren Verlauf aber zwingend Int64 brauche, kann ich hier keine Fließkommazahlen nutzen.

Zitat:

Result := UInt64(1) shl (Multiplier* 10) // Das versteht keiner auf den ersten Blick.

Das ist dasselbe wie Power(1024, 2).

Zitat:

// das tut in der Seele weh

Hilfe nehme ich sehr gerne an! Ich meine jetzt keine Seelenhilfe oder so sondern programmiertechnisch.

[TigerLilly]

Zitat von DieDolly:

Zitat:

// Welchen Wert hat Result, wenn Multiplyer 0 ist?

Im Beispiel oben wären das 45 (Bytes).

Ich komme auf 0.

Zitat:

Zitat:

if Result > MaxSize then
Result := MaxSize; // das tut in der Seele weh

Warum sollte man jemals höher als 1 EiB gehen? So große Datenmengen gibt es sicherlich insgesamt. Aber ich habe im privatanwenderbereich noch niemanden gesehen, der eine einzelne Datei hat die so groß ist.

Vor 10 Jahren waren TB für Privatanwender undenkbar, so Dinge ändern sich. Außerdem: Das ist schlechter Stil. Das macht man einfach nicht.

[DieDolly]

Zitat von TigerLilly:

Zitat von DieDolly:

Zitat:

// Welchen Wert hat Result, wenn Multiplyer 0 ist?

Im Beispiel oben wären das 45 (Bytes).

Ich komme auf 0.

ddd

Zitat:

Zitat:

if Result > MaxSize then
Result := MaxSize; // das tut in der Seele weh

Warum sollte man jemals höher als 1 EiB gehen? So große Datenmengen gibt es sicherlich insgesamt. Aber ich habe im privatanwenderbereich noch niemanden gesehen, der eine einzelne Datei hat die so groß ist.

Vor 10 Jahren waren TB für Privatanwender undenkbar, so Dinge ändern sich. Außerdem: Das ist schlechter Stil. Das macht man einfach nicht.[/QUOTE]

Wie verhindere ich sonst das angesprochene Problem?

[gammatester]

Warum so kompliziert? Wenn man die UINT64-Beschränkung akzeptiert, kann man zB dies verwenden

Delphi-Quellcode:

function CalculateSize(Bytes, Multiplier: UInt64): UInt64;
var
  i: integer;
begin
  Result := Bytes;
  for i:=1 to Multiplier do Result := Result*1024;
end;

Wenn man R/O-Checks eingeschaltet hat, erhält man eine Überschreitung frei Haus, ansonsten ist noch eine Zeile mehr notwendig. Man kann auch Multiplier beschränken, aber das nützt nicht viel, weil ja Bytes*1024 schon ein Overflow werfen könnte.

[Frickler]

Zitat von TigerLilly:

Vor 10 Jahren waren TB für Privatanwender undenkbar, so Dinge ändern sich. Außerdem: Das ist schlechter Stil. Das macht man einfach nicht.

Vor 10 Jahren kostete eine 1TB Festplatte ca 100 Euro.

Auch beim 128 Bit Dateisystem ZFS ist die maximale Dateigröße "nur" 16 EiB (weil das genau 2^64 Bytes sind, nehme ich an). Und damit werden wir noch sehr sehr lange auskommen

[TigerLilly]

Zitat von Frickler:

Zitat von TigerLilly:

Vor 10 Jahren waren TB für Privatanwender undenkbar, so Dinge ändern sich. Außerdem: Das ist schlechter Stil. Das macht man einfach nicht.

Vor 10 Jahren kostete eine 1TB Festplatte ca 100 Euro.

Die erste TB HD gabs 2007. Aber du hast recht, vor 10 Jahren war 2008 + da werden die Preise wohl so um die 100.- gelegen sein.

Zitat:

Auch beim 128 Bit Dateisystem ZFS ist die maximale Dateigröße "nur" 16 EiB (weil das genau 2^64 Bytes sind, nehme ich an). Und damit werden wir noch sehr sehr lange auskommen

Ja, eh. Aber zwei Dinge sind sicher:
- Niemand weiß, welche Dateigrößen in 10 Jahren unterstützt(!) werden.
- Code, den du jetzt schreibst, wird in 10 Jahren noch im Einsatz sein.

Also würde ich abraten, so zu coden.

[Jasocul]

Zitat von DieDolly:

Warum sollte man jemals höher als 1 EiB gehen? So große Datenmengen gibt es sicherlich insgesamt. Aber ich habe im privatanwenderbereich noch niemanden gesehen, der eine einzelne Datei hat die so groß ist. Angenommen durch falsche Eingaben hat Result schließlich einen Wert von 1 YiB, dann führt das zu einem Fehler.
Da im im weiteren Verlauf aber zwingend Int64 brauche, kann ich hier keine Fließkommazahlen nutzen.

Nur, weil du etwas noch nie gesehen hast, heißt das nicht, dass es das nicht gibt oder mal geben kann. Meine erste Festplatte hatte 20 MB. Ich dachte, die bekomme ich niemals voll. Heute müsste ich nur 4 Fotos machen, um die Kapazität zu überschreiten.
Da Daten auch immer mehr in der Cloud gespeichert werden, können die Dateien auch immer größer werden. Kannst du abschätzen, wo die Grenze für Dateigrößen in Zukunft sein wird? Und gehe dabei nicht von Festplatten aus. In Zukunft wird es andere Speichermedien geben, die sicher ein vielfaches an Kapazität haben werden.

Du kannst natürlich von deiner jetzigen Sicht ausgehend, dein Programm erstellen. Aber du solltest den Fall, dass du ein Ergebnis bekommst, dass deine Funktion nicht erwartet, richtig behandeln. Es handelt sich in dem Fall wohl um eine Ausnahme-Situation, sprich Exception.
Aus deiner Sicht sollte diese ja niemals auftreten können, also schadet es auch nicht, wenn du das korrekt behandelst und nicht einfach die Werte, die dir nicht passen änderst.

[DieDolly]

Danke für eure Antworten bisher.

Ich habe eine Funktion die eine Datei in Häppchen zerteilt, deren Größe ich bestimmen kann. Dafür ist die ganze Umrechnung die zuvor erwähnt wurde da.
Meine Teilfunktion nimmt UInt64 entgegen.

Wäre es korrekter wenn ich meine ConvertToBytes so abändere, dass Result maximal High(UInt64) betragen kann?

[freimatz]

Nachdem in Windows eine Datei maximal Int64 gross sein kann sollten double unnötig sein.
(s.a. https://docs.microsoft.com/en-us/win...eattributesexa)

Zitat von gammatester:

Warum so kompliziert? Wenn man die UINT64-Beschränkung akzeptiert, kann man zB dies verwenden

Delphi-Quellcode:

function CalculateSize(Bytes, Multiplier: UInt64): UInt64;
var
  i: integer;
begin
  Result := Bytes;
  for i:=1 to Multiplier do Result := Result*1024;
end;

Wenn man R/O-Checks eingeschaltet hat, erhält man eine Überschreitung frei Haus, ansonsten ist noch eine Zeile mehr notwendig. Man kann auch Multiplier beschränken, aber das nützt nicht viel, weil ja Bytes*1024 schon ein Overflow werfen könnte.

Danke. Wollte auch was mit Integer vorschlagen (eher mit einer Tabelle).
Bei so etwas wo es nur um Integer geht etwas mit Fließkomma zu verwenden ist einfach nur
(Vor allem wenn man weiß, dass da intern mit Exponentialfunktion und Logarithmus gearbeitet wird.)