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.