Custom compiler message beim Aufruf einer Methode möglich?

[Stevie]

Moin,

ist es möglich, beim Kompilieren eine eigene Compiler message auszugeben, wenn irgendwo im kompilierten Code eine bestimmte Methode aufgerufen wird? Ich möchte damit bei einer Singleton Implementierung verhindern, dass irgendwo der Konstruktor aufgerufen wird.
Ich hab {$MESSAGE WARN 'Instantiation of TSingleton not allowed'} in den constructor meiner TSingleton Klasse geschrieben, aber die wird immer angezeigt, egal ob ich irgendwo ein Objekt dieser Klasse instanziere oder nicht - irgendwie ja auch logisch
Wäre prima, wenn beim Aufruf von TSingleton.Create irgendwo im Code sowas kommt, wie wenn man eine Klasse mit abstrakten Methoden instaziert (oder gar ein Fehler, der das Kompilieren ganz verhindert)

MfG

[himitsu]

nein

selbst wenn du diese Message in die Prozedur reinschreibst, wird sie immer beim Compilieren der Prozedur angezeigt ... ob diese dann verwendet/aufgerufen wird, ist dabei leider egal.

du kannst diese Methode maximal als Abstract definieren, dann kommst diese Abstract-Compiliermeldung, ansonsten kannst du zur Laufzeit einen Fehler werfen, wenn jemand diese Methode/Constructor aufruft.

[Corpsman]

Warum schreibst du nicht eine entsprechende Exception in den Create Part deiner Klasse ?

Ansonsten müsste der Compiler eigentlich eh schon eine Warnung bringen , wenn du versuchst eine Klasse mit Abstracten Methoden zu instantiieren...

[Stevie]

Zitat von himitsu:

du kannst diese Methode maximal als Abstract definieren, dann kommst diese Abstract-Compiliermeldung, ansonsten kannst du zur Laufzeit einen Fehler werfen, wenn jemand diese Methode/Constructor aufruft.

Zitat von Corpsman:

Warum schreibst du nicht eine entsprechende Exception in den Create Part deiner Klasse ?

Ansonsten müsste der Compiler eigentlich eh schon eine Warnung bringen , wenn du versuchst eine Klasse mit Abstracten Methoden zu instantiieren...

Genau das wollte ich ja vermeiden, die abstract warning ist mir nicht speziell genug und ein abstract error zur Laufzeit eher ungewünscht. Die Exception wäre die "Notlösung" gewesen, schade, dass es nicht mit compile error geht.

[himitsu]

PS: wir hatten hier schonmal was Ähnliches:
http://www.delphipraxis.net/internal...t.php?t=162021


nicht schön, aber selten ... und wenn man einfach mal hofft, daß der Programmierer ließt, bevor er schreibt
constructor Create(const Diese_Klasse_bitte_nicht_direkt_verwenden_oder_sowas); Und eventuell doch noch einen "irren" :Typen hinten dranhängen, welchen man so dort nie verwendet,
dann hat man erstmal Probleme dieses zum Kompilieren zu bringen.

[mjustin]

Zitat von Stevie:

Wäre prima, wenn beim Aufruf von TSingleton.Create irgendwo im Code sowas kommt, wie wenn man eine Klasse mit abstrakten Methoden instaziert (oder gar ein Fehler, der das Kompilieren ganz verhindert)

Ist der Konstruktor nicht "private"? Dann bekommt die Klasse auch nicht das Qualitätssiegel "Zertifiziertes Singleton"

Viele Grüße,

[himitsu]

Zitat von mjustin:

Ist der Konstruktor nicht "private"? Dann bekommt die Klasse auch nicht das Qualitätssiegel "Zertifiziertes Singleton"

Das ist kein Problem, aber der "Standardkonstruktor" wäre immernoch erreichbar.

Delphi-Quellcode:

TObject = class
  // per standard public
  constructor Create;

[Stevie]

Zitat von mjustin:

Ist der Konstruktor nicht "private"? Dann bekommt die Klasse auch nicht das Qualitätssiegel "Zertifiziertes Singleton"

Wenn man die Sichtbarkeit in Delphi verringern könnte, wär mir schon so manches Gebastel erspart geblieben

[Medium]

Dann würde Delphi aber auch einem fundamentalen Mechanismus der OOP entgegen arbeiten

[SubData]

Ich habe sowas mal für einen Destruktor gebraucht und bin zu folgender Lösung gekommen.

Delphi-Quellcode:

type
  TQueryObj = class(TQuery)
  private
   [...]
  public
   [...]
  published
    procedure Free; deprecated;
  end;

Delphi-Quellcode:

{$WARN SYMBOL_DEPRECATED OFF}
procedure TQueryObj.Free;
begin
  inherited;
end;
{$WARN SYMBOL_DEPRECATED ON}

Da das Objekt nicht freigegeben werden darf, sondern von einem QueryPool verwaltet wird, der auch für die Freigabe zuständig ist, wird so unterbunden, dass irgendwo direkt .Free aufgerufen wird. Zumindest gibt es dann eine Warnung.

Der Compilerschalter bewirkt in diesem Fall nur, dass die Methode selbst nicht auch schon im Quellcode angemeckert wird.