Unnötige Ini-Befehle vermeiden sinnvoll?

[a.def]

Im Zuge dessen, dass ich mir die Tage eine eigene Ini-Klasse angelegt habe mit ein paar Änderungen drin stelle ich mir jetzt eine Frage:
wie sinnvoll ist es, unnötige Befehle zu vermeiden?

Konkreter:
Wenn ich ein TMemIniFile verwende mir AutoSave := False, sollte man dann die Writes irgendwie blockieren?
Ich meine... der schreibt dann irgendetwas in den Speicher, was am Ende eh kein Mensch braucht.

Meine Unit kann man hier sehen: http://www.delphipraxis.net/1367025-post21.html

In etwa sowas hier

Delphi-Quellcode:

procedure WriteString(const Section, Ident, Value: string); reintroduce; overload;
procedure WriteInteger(const Section, Ident: string; Value: Integer); reintroduce; overload;
procedure WriteBool(const Section, Ident: string; Value: Boolean); reintroduce; overload;

//////////////////////////////////////////


procedure TMemIniFile.WriteString(const Section, Ident, Value: string);
begin
 if FAutoSave then
  inherited WriteString(Section, Ident, Value);
end;

procedure TMemIniFile.WriteInteger(const Section, Ident: string; Value: Integer);
begin
 if FAutoSave then
  inherited WriteString(Section, Ident, IntToStr(Value));
end;

procedure TMemIniFile.WriteBool(const Section, Ident: string; Value: Boolean);
const
 Values: array [Boolean] of string = ('0', '1');
begin
 if FAutoSave then
  inherited WriteString(Section, Ident, Values[Value]);
end;

Was ist von soetwas zu halten?

[himitsu]

Zitat:

Zitat von a.def (Beitrag 1367161)

Ich meine... der schreibt dann irgendetwas in den Speicher, was am Ende eh kein Mensch braucht.

Was ist von soetwas zu halten?

Nur weil AutoSave=False ist, heißt es nicht, dass nicht gespeichert wird.
Immerhin kann man das Ganze auch am Ende immernoch per Update in die Datei schreiben lassen.

[a.def]

Stimmt ist mein Fehler, muss ich umbenennen.
Aber der Sinn dahinter ist ja, dass nur lesender Zugriff stattfinden darf und kein schreibender :stupid:

Ausgangsfrage ist aber: wie sinnvoll ist es unnötige Writes zu blockieren, wenn die Datei am Ende doch eh nicht geschrieben wird?

[Jasocul]

Zitat:

Zitat von a.def (Beitrag 1367170)

Ausgangsfrage ist aber: wie sinnvoll ist es unnötige Writes zu blockieren, wenn die Datei am Ende doch eh nicht geschrieben wird?

Wenn man innerhalb des Programms wieder ein Read macht, bekommt man meines Wissens dann die "neuen" Werte (Falls ich mich irre, ignoriert mich einfach :wink: ). Also kann das Write durchaus sinnvoll sein, auch wenn die Werte später nicht physisch gespeichert werden.

[a.def]

Zitat:

Zitat von Jasocul (Beitrag 1367173)

Zitat:

Zitat von a.def (Beitrag 1367170)

Ausgangsfrage ist aber: wie sinnvoll ist es unnötige Writes zu blockieren, wenn die Datei am Ende doch eh nicht geschrieben wird?

Wenn man innerhalb des Programms wieder ein Read macht, bekommt man meines Wissens dann die "neuen" Werte (Falls ich mich irre, ignoriert mich einfach :wink: ). Also kann das Write durchaus sinnvoll sein, auch wenn die Werte später nicht physisch gespeichert werden.

Ok das habe ich jetzt nicht verstanden :stupid:

[Fritzew]

Zitat:

Zitat von Jasocul (Beitrag 1367173)

Zitat:

Zitat von a.def (Beitrag 1367170)

Ausgangsfrage ist aber: wie sinnvoll ist es unnötige Writes zu blockieren, wenn die Datei am Ende doch eh nicht geschrieben wird?

Wenn man innerhalb des Programms wieder ein Read macht, bekommt man meines Wissens dann die "neuen" Werte (Falls ich mich irre, ignoriert mich einfach :wink: ). Also kann das Write durchaus sinnvoll sein, auch wenn die Werte später nicht physisch gespeichert werden.

Aber nur wenn Die Ini-Datei oder besser gesagt die Instance der Ini-Klasse persistent ist, also z.B beim Programmstart erzeugt und bei Programmende zerstört wird.

Zitat:

Ausgangsfrage ist aber: wie sinnvoll ist es unnötige Writes zu blockieren, wenn die Datei am Ende doch eh nicht geschrieben wird?

Also wenn Du anfängst Dir darüber Gedanken zu machen, dann kannst Du auch im gleich im Code prüfen ob geschrieben werden soll, also z.B:

Delphi-Quellcode:

 if {not readonly} then StoreDatatoIni(Inifile);

[Ghostwalker]

Zitat:

Zitat von a.def (Beitrag 1367170)

Ausgangsfrage ist aber: wie sinnvoll ist es unnötige Writes zu blockieren, wenn die Datei am Ende doch eh nicht geschrieben wird?

Da kann ich doch nur mit einer Gegenfrage antworten..:twisted:

Wie sinnvoll ist so eine Ini dann überhaupt ?

Ich geh mal davon aus, das du Programmeinstellungen speicherst. Wenn die nicht in irgendeiner Form auf der Platte landen, ärgerst du den Anwender, der jedesmal die Einstellungen neu machen darf.

Oder hab ich da was verpasst ?

Wenn du nur temporäre Daten in ein File speichern willst, würd ich nicht grad Inis nutzen :)

[Jasocul]

@Fritz: korrekt.
@a.def:
Gemeint ist, du lädst die Datei und hältst die Daten in deiner Komponente. Jedes write ändert die Daten, ohne in der Datei zu speichern. Ein Read greift dann auf die Daten im Speicher zu und erhält dann die Angaben durch das letzte Write.
So könntest du die Ini-Daten praktisch temporär ändern und nutzen

[a.def]

Zitat:

Zitat von Ghostwalker (Beitrag 1367181)

ich geh mal davon aus, das du programmeinstellungen speicherst. Wenn die nicht in irgendeiner form auf der platte landen, ärgerst du den anwender, der jedesmal die einstellungen neu machen darf.

Oder hab ich da was verpasst ?

Zitat:

Zitat von a.def (Beitrag 1367025)

sinn zusammengefasst damit es jeder versteht:
Das hier ist dasselbe wie der autosave-parameter ab berlin.
Mit diesem code verhindere ich fehler wenn mein programm in einem uac-geschütztem verzeichnis gestartet wird.

Teamspeak macht es ähnlich. Bei programmstart kommt in einem uac-geschützten verzeichnis die meldung

Zitat:

---------------------------
error
---------------------------
teamspeak 3 cannot write to the configuration file:
...settings.db

you can use teamspeak 3, but all settings will be lost!
---------------------------
ignore abort
---------------------------

ein klick auf ignore setzt in diesem fall eine art autosave auf false (ganz grob ausgedrückt).

Hab das jetzt nach "ReadOnly" umgeändert. Writes werden nur ausgeführt, wenn ReadOnly False ist.

Ich meinem Aberglauben dachte ich nur, ich könnte so ein paar unnötige Speicheroperationen auslassen :roll:

[Ghostwalker]

Ok...auf das Prob bin ich bisher nicht gestoßen, da ich mir via Api die enstprechenden Userverzeichnisse hole :)

Aber für den genannten Fall (oder vielleicht gibts ja durchaus noch andere Fälle wo sowas nützlich wäre), macht das schon Sinn, vor dem Write das ganze entsprechend Abzufragen, auch wenns nur in den Speicher geht.

Bei enstprechenden Anwendungen (z.B. Video-Bearbeitungen), kann ja auf einem PC auch der Speicher mal eng werden.

[a.def]

Hätte ich ehrlich gesagt nicht gedacht, dass doch noch jemand meiner Meinung ist.
Ich dachte eigentlich etwas zu lesen wie "in der heutigen Zeit mit 4-Kern-Prozessoren und 16 GB Arbeitsspeicher, braucht man auf so etwas nicht mehr zu achten" :stupid:

[Jumpy]

Zitat:

Zitat von a.def (Beitrag 1367187)

Hätte ich ehrlich gesagt nicht gedacht, dass doch noch jemand meiner Meinung ist.
Ich dachte eigentlich etwas zu lesen wie "in der heutigen Zeit mit 4-Kern-Prozessoren und 16 GB Arbeitsspeicher, braucht man auf so etwas nicht mehr zu achten" :stupid:

Bei den Datenmengen, die man üblicherweise (OK üblich ist bei jedem anders) noch in ini-Dateien speichert ist das doch wirklich vernachlässigbar.

[freejay]

Die Frage ist doch: "sinnvoll" in Bezug auf was?

Einfachen, lesbaren Code?
Geschwinddigkeit?
Speicherbedarf?

Warum komplexeren, komplizierteren Code schreiben, wenn der sich nicht spürbar auf irgendetwas auswirkt?

Aber ganz generell: Warum sollte man denn etwas in eine INI schreiben, wenn man nicht vorhat es zu speichern? Um die INI als Zwischenspeicher für Werte zu nutzen, statt Variablen oder Properties zu verwenden? Das wär schon schräg...

[a.def]

Zitat:

Aber ganz generell: Warum sollte man denn etwas in eine INI schreiben, wenn man nicht vorhat es zu speichern? Um die INI als Zwischenspeicher für Werte zu nutzen, statt Variablen oder Properties zu verwenden? Das wär schon schräg...

Siehe dir mal TMemIniFile von Delphi selber an. Da ist es gleich. Wenn man UpdateFile nicht ausführt oder AutoSave False ist, wird auch ins Nirvana geschrieben.
Deswegen dachte ich fange ich schreibende Befehle ab.

Zitat:

Warum sollte man denn etwas in eine INI schreiben, wenn man nicht vorhat es zu speichern?

Das habe ich bestimmt schon dreimal erklärt hier :P