lokale Variablen mit globaler Lebensdauer?

[Olli]

@Hagen: Volle Zustimmung!

Typecasts ohne explizite Operatoren, oder implizite Typecasts zwischen eigentlich inkompatiblen (String und PChar) Typen. Ist Delphi deswegen schlecht? Delphi erlaubt es, wie andere Sprachen auch, daß man interne Handles aus Objekten zurückgeben kann - sollte man eigentlich nie machen. Provokante These: Delphi fördert also "schlechten Programmierstil"!

Was will ich damit sagen?:
1.) Es ist (fast) alles eine Ansichtssache!
2.) Es hängt von den Sprachfeatures ab, die einem eine Sprache bietet!
3.) Nur weil eine Sprache ein Feature bietet, ist die Sprache doch nicht schlecht, oder die Programmierung in dieser Sprache Unfug.

Irgendwie ist es wie der alte Streit um GOTO ... :roll:

[negaH]

Beispiel:

Delphi-Quellcode:

interface

type
  IPool = interface
    .. blabla
  end;

function NPool: IPool;

implementation

type
  TPool = class(TInterfacedObject, IPool);
    .. blabla
  end;

function NPool: IPool;
var
  Pool: IPool = nil;
begin
  if Pool = nil then Pool := TPool.Create;
  Result := Pool;
end;

Hier wird eine globale Variable Pool benutzt die aber nur in der Zugriffsfunktion NPool lokal sichtbar ist. Sinn und Zweck dieser Art der Programmierung war es:

1.) das Objekt TPool nur zu erzeugen wenn es gerbraucht wird, dann aber automatuisch
2.) die Funktion NPool: IPool dient als Zugriffs-Schutz-Funktion auf die Variable Pool
3.) es darf pro Anwednungssession nur EINE Kopie von Pool geben
4.) einmal Pool alloziert so darf er nie wieder DEALLOZIERT werden, das ist eine sehr WICHTIGE Rahmenbedingung

Nun, hätte man Pool ganz global deklariert so ist es aber möglich das der Delphi Compiler so smart ist diese globale Variable in der Finalisation Sektion auf NIL zu setzen ! Und genau dies widerspräche der Forderung 4.)
Ergo: in diesem Falle ist der Weg über eine globale Variable die aber nur lokal sichtbar sein darf der einzigste Weg der die geforderten Rahmenbedingungen erfüllen kann.

Fazit: das der Programmierer dieses Weg gewählt hat zeugt davon das er die Funktionalität seines Werkzeuges sehr genau kannte und auch ausgenutzt hat. Und das er das absichtlich so getan hat ist sein Stil.

Gruß Hagen

[Olli]

Zitat:

Zitat von negaH

Beispiel: [...]

Das Beispiel sehe ich eher als Liste der Defizite in Delphi. Es erinnert mich an eine Sache, die ich im Rahmen eines Projekts zur Native API als Problem hatte. Leider kann man mit Delphi keine Objekte "auf dem Stack" anlegen, welche automatisch beim Verlassen ihres Sichtbarkeitsbereiches zerstört werden. Es gibt Workarounds mit Interfaces und - noch schlimmer - mit einem alten Schlüsselwort (war es TObject?!) welches eigentlich nur noch zur Abwärtskompatibilität existiert. Fazit: Delphi kann keine Objekte erzeugen, die sich wie Basistypen verhalten. (Mit .NET mag sich das geändert haben ...)

Ach ja, bist du sicher, daß es so geht? Ich nicht, denn Pool ist nicht global (also nichtmal innerhalb der Implementation-Sektion der Unit):

Delphi-Quellcode:

function NPool: IPool; 
var 
  Pool: IPool = nil; 
begin 
  if Pool = nil then Pool := TPool.Create; 
  Result := Pool; 
end;

[negaH]

So nun das Gegen-Beispiel

Delphi-Quellcode:

interface 

type 
  IPool = interface 
    .. blabla 
  end; 

function NPool: IPool; 

implementation 

type 
  TPool = class(TInterfacedObject, IPool); 
    .. blabla 
  end; 

var
  Pool: TPool = nil;

function NPool: IPool; 
begin 
  if Pool = nil then Pool := TPool.Create; 
  Result := Pool; 
end;

Hier wird nun Pool vom implementierenden Klassentyp sein, statt wie oben ein Interface. Ergo wirken auf die globale Variable Pool nicht die gleichen Wirkmechanismen wie sie bei Interfaces wirken. Damit ist also garantiert das Pool durch den Programmierer gegebenfalls manuell zerstört werden muß. Nun, das soll aber laut Rahmenbedingung nicht möglich sein. Relevant sind nun 3 Punkte:

1.) dieser Source wäre auch in neueren Delphi Versionen kompilierbar
2.) Pool ist in seiner Sichtbarkeit aber nicht auf NPool beschränkt, im nachfolgenden Source kann man also unbeabsichtigt darauf zugreifen
3.) da innerhalb von NPool das Object permanet bei jedemAufruf der Funktion erst in ein Interface umgewandelt werden muß ist die Performance dieser Funktion schlechter als im 1. Beispiel

Beides sind annehmbar gute Programmierstile und denoch gibt es große Unterschiede im schlußendlichen Laufzeitverhalten.

Gruß Hagen

[negaH]

@Olli, was soll ich auf deine Frage antworten ?

Ich bin mir sehr sicher das es so funktionieren wird ! Wie ich oben schon ausdrückte ist eine der Grundvorraussetzungen eines guten Programmierstils eben auch das perfekte Wissen und Können mit seinen Werkzeugen umgehen zu können.

Gruß Hagen

[Olli]

Zitat:

Zitat von negaH

@Olli, was soll ich auf deine Frage antworten ?

Ich bin mir sehr sicher das es so funktionieren wird ! Wie ich oben schon ausdrückte ist eine der Grundvorraussetzungen eines guten Programmierstils eben auch das perfekte Wissen und Können mit seinen Werkzeugen umgehen zu können.

Tja, keine Ahnung. Jedenfalls mag mein benutzter Delphi-Compiler keine lokalen Variablen, die mit Nil initialisiert werden sollen. Und wenn ich deinen (ersten) Code mal in eine Sprache umsetze, die mein benutzter Delphi-Compiler versteht, also von (siehe Kommentare)

Delphi-Quellcode:

function NPool: IPool;
var
  Pool: IPool = nil; // <--- DAS
begin
  if Pool = nil then Pool := TPool.Create;
  Result := Pool;
end;

nach

Delphi-Quellcode:

function NPool: IPool;
var
  Pool: IPool; // <--- ZU DIESEM UND
begin
  Pool :=  nil; // <--- DIESEM
  if Pool = nil then Pool := TPool.Create;
  Result := Pool;
end;

wirkt der Spaß ziemlich sinnlos. Oder?!

Also entweder unterscheiden sich die "neueren" Versionen fundamental von den "älteren" (ich benutze D4) - was ich mangels Verfügbarkeit nicht weiß, oder dein Wissen ist an dieser Stelle nicht ganz so perfekt.

[negaH]

Ähm stop :) Recht haste, mache mal aus dem var ein const. Es ging ja im Thread um "beschreibbare Konstanten" also "nicht-konstante-Konstanten". Das Problem mit diesem Ding ist es ja das es syntaktisch was anderes suggeriert als das was es funktional tatsächlich darstellt (nämlich eine Variable).

Sorry das ich deine Ehre so hart angegriffen habe :)

Gruß Hagen

[NicoDE]

Ich nehme an, dass es ein Tippfehler war:

Code:

[color=green]const[/color]
  Pool: IPool = nil;
begin

[negaH]

Ja das war es.

Sich über diese "Konstanten" zu streiten ist schon ein bischen irrsinnig, da es im Grunde eine Design-Schwäche in der Delphi Sprache darstellt.

Es gibt Konstanten und Variablen, wie unterscheiden sie sich ?

Delphi-Quellcode:

const
  Konstante = 1;

var
  Variable: Integer;

Das sind die beiden Basiskonstrukte im ursprünglichem PASCAL. Der Unterschied besteht darin das ein Variable eine Typisierung bestitzt wohingegen eine Konstante eine Wertzuweisung haben sollte.

So, nun mit der Zeit hat Borland aber einige Neuerungen eingeführt, zb.

Delphi-Quellcode:

var
  Variable: Integer = 1;
const
  Konstante: Integer = 1;

Als erstes die Typisierten Variablen mit Vorinitialisierung und als zweites die Typisierten Konstanten mit Wertzuweisung. Worin besteht aber nun der syntaktisch funktionale Unterschied ?

Nun, während Konstanten IMMER global sind, d.h. ihre Gültigkeit ist immer global egal wo ich sie verwende können Variablen in ihrer Gültigkeit lokal beschränkt sein. Und exakt hier setzt der Design-Fehler an.

Ergo: die typisierte Konstante die modifizierbar ist ist ein Unding oder funktional eine Variable die immer global gültig sein wird.

Aber fakt ist nun mal das diese Funktuionalität existent ist, und sie zu benutzen niemals einen Fehler darstellen kann. Denn wozu existiert Funktinalität wenn man sie niemals benutzen kann, oder umgekehrt wenn über dieses Unding eine ganz spezielle Funktionalität möglich ist die sonst anders nicht realisierbar ist, warum dannnicht benutzen ? Was ist schlecht daran, warum sollte das schlechter Stil sein.

Gruß Hagen

[NicoDE]

Zitat:

Zitat von negaH

Aber fakt ist nun mal das diese Funktuionalität existent ist, und sie zu benutzen niemals einen Fehler darstellen kann. Denn wozu existiert Funktinalität wenn man sie niemals benutzen kann, oder umgekehrt wenn über dieses Unding eine ganz spezielle Funktionalität möglich ist die sonst anders nicht realisierbar ist, warum dannnicht benutzen ? Was ist schlecht daran, warum sollte das schlechter Stil sein.

Schlechter Stil wäre es dann, wenn man 'Anfängern' beibringt diesen "Design-Fehler" an Stellen einzusetzen an denen es nicht nötig wäre... meine 2 Cent.