Syntaxoptionen "Boolesche Ausdrücke vollständig" Ein-/Ausschalten

[RaSoWa1]

Hallo,

in meiner TFilterGrid-Kompenente verwende ich an verschiedenen Stellen folgende Code-Konstruktion:
z.B.:

Delphi-Quellcode:

 
var
  ci: TColInfo; 
begin
....
  ci := ColInfo[c];
  if (ci <> nil) and Assigned(ci.CompToCellProc) then
.....

Bei mir ist die Syntaxoptionen "Boolesche Ausdrücke vollständig" immer ausgeschalten und der Code funktioniert.
Ein Nutzer meiner Komponente hat diese Option aktiviert und es kommt zwangsläufig zu einer Zugriffverletzung, wenn ci = nil ist.

Ich kann den Code ändern in:

Delphi-Quellcode:

....
  if (ci <> nil) then
    if Assigned(ci.CompToCellProc) then
....

was mir aber nicht sehr gefällt, da er dadurch unübersichtlicher wird.
Ich würde lieber die Compilerschalter {$B+} bzw. {$B-} verwenden.

An welcher Stelle im Quelltext der Komponenete muss ich diese Compilerschalter setzten, damit sie nur für diese gelten?
Wie kann ich erkennen welcher Schalter gesetzt ist?
Wie würdet ihr das Problem lösen?

Grüße Klaus

[Uwe Raabe]

Zitat:

Zitat von RaSoWa1 (Beitrag 1186290)

Ich würde lieber die Compilerschalter {$B+} bzw. {$B-} verwenden.

An welcher Stelle im Quelltext der Komponenete muss ich diese Compilerschalter setzten, damit sie nur für diese gelten?
Wie kann ich erkennen welcher Schalter gesetzt ist?

Der Schalter muss vor der Code-Zeile gesetzt werden und kann nach der Code-Zeile wieder zurückgesetzt werden. Abfragen kannst du ihn über IFOPT.

[himitsu]

Da dieser Schalter nur lokal wirkt, also ab seines Vorfindens und maximal bis zum Ende der Unit, kannst du es lokal deaktivieren.

Aber ganz im Enst, wenn der Typ das global aktiviert, dann hat er selber Schuld, wenn irgendwas nicht ordentlich läuft. Es gibt Dinge, da spielt man einfach nicht dran rum! :evil:
Fazit: ER sollte bei sich diese Option mit bedacht einsetzen und dein Problem wäre gelöst.

Oder du deaktivierst zu Beginn deiner Unit (da wo deine Komponente drinsteckt) diese Option, für deine Komponente.


Wenn es mich nervt, daß ich jedesmal, wenn ich nach Hause komm, einen Code eingeben muß,
dann kann ich natürlich einfach die Alarmanlage immer deaktiviert lassen.
Dann soll ich mich aber auch nicht wundern, wenn jemand einbricht und keiner es mitbekommt.

[Furtbichler]

Wieso schreibst Du nicht einfach eine Funktion, die aussagt, was Du willst? Dann hast Du beide Probleme ein für alle mal gelöst:

Delphi-Quellcode:

Function CanAccessAdapter (col : TColInfo) : Boolean;
// Ja ja geht auch anders/einfacher aber egal, die Funktion ist zweitrangig
Begin
  if Not Assigned (ci) Then return false;
  return := Assigned(ci.CompToCellProc);
End;
...
// wichtiger ist, das der eigentliche Code nun viel lesbarer ist
If CanAccessAdapter (ColInfo[i]) Then begin
  ...

Sieht doch noch besser aus, oder?
Ich persönlich finde, das Compilerschalter keine Änderung der Funktionalität herbeiführen sollen.
Heute machst Du das so harmlos (knallt/knallt nicht), aber was ist, wenn Du mal soetwas machst?

Delphi-Quellcode:

function SomeFunc (p : TSomething) : Boolean;
Begin
  if p=Nil then inc(SomeCounter);
  return false
End;
...1
if (ci<>Nil) and SomeFunc(ci) then

Ok, das ist auch kein sonderlich guter Stil (Seiteneffekte in Funktionen), aber trotzdem ein Beispiel, wie ein Programm je nach Compilerschalter unterschiedlich funktioniert. Und DAS wäre fatal, weil Du es nicht einmal sofort merkst

[DSCHUCH]

was ich besonders gern verwende, ist die neue Exit Syntax.

Delphi-Quellcode:

If not Assigned(X) Then Exit(False);
Result:=X.Y

[RaSoWa1]

Danke an alle für die zahlreichen Vorschläge.

Zitat:

Zitat von himitsu (Beitrag 1186302)

Da dieser Schalter nur lokal wirkt, also ab seines Vorfindens und maximal bis zum Ende der Unit, kannst du es lokal deaktivieren.

Aber ganz im Enst, wenn der Typ das global aktiviert, dann hat er selber Schuld, wenn irgendwas nicht ordentlich läuft. Es gibt Dinge, da spielt man einfach nicht dran rum! :evil:
Fazit: ER sollte bei sich diese Option mit bedacht einsetzen und dein Problem wäre gelöst.

Oder du deaktivierst zu Beginn deiner Unit (da wo deine Komponente drinsteckt) diese Option, für deine Komponente.[/SIZE]

Ich glaube, das ist die beste Lösung für mich.

Zitat:

Zitat von Furtbichler (Beitrag 1186312)

Ich persönlich finde, das Compilerschalter keine Änderung der Funktionalität herbeiführen sollen.
Heute machst Du das so harmlos (knallt/knallt nicht), aber was ist, wenn Du mal soetwas machst?

Im Grunde hast du Recht, aber {$B-} ist ja die Standardeinstellung, die ich ggf. für meine Komponenete wieder herstelle.
Mein Codeschnipsel dient nur als Beispiel für meine Vorgehensweise. Da ich auch mit anderen Objekten und auch in zeitkritischen Schleifen so vorgehe, möchte ich nach Möglichtkeit nicht unnötig in eine Funktion springen.


Danke für die Hilfe

Klaus

[Bernhard Geyer]

Wir haben hier in zentraler Unit folgendes stehen:

Delphi-Quellcode:

{$IFOPT B+}
  {$Message Fatal 'xyz-Programm/Komponenten/Unit nur lauffähige mit Option B-'}
{$ENDIF}

oder du definierst eine Include-Datei die du überall bei dir verwendest dwelche diese Option setzt.
Machen auch viele Komponentenhersteller so.

[himitsu]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1186352)

Delphi-Quellcode:

{$IFOPT B+}
  {$Message Fatal 'xyz-Programm/Komponenten/Unit nur lauffähige mit Option B-'}
{$ENDIF}

Sowas mach ich auch immer öfters. (wie gesagt ... es gibt Dinge, da spielt man einfach nicht dran rum)

Schade ist nur, daß $IFOPT nur mit einbuchstabigen Optionen funktioniert :cry:

[Furtbichler]

Zitat:

Zitat von RaSoWa1 (Beitrag 1186337)

Im Grunde hast du Recht, aber {$B-} ist ja die Standardeinstellung, die ich ggf. für meine Komponenete wieder herstelle.
Mein Codeschnipsel dient nur als Beispiel für meine Vorgehensweise. Da ich auch mit anderen Objekten und auch in zeitkritischen Schleifen so vorgehe, möchte ich nach Möglichtkeit nicht unnötig in eine Funktion springen.

Bei Performancebottlenecks muß man Abstriche machen, das ist richtig. Inline-Funktionen helfen hier jedoch meist.
Bei mir sind derartige Funktionen, weil unschön und unsicher, in einer separaten Unit gekapselt und dort kann ich meine Spezialkompilereinstellungen von mir aus mit dickem Kommentar plazieren.

Es kommt jedoch sehr sehr selten auf reine Codeperformance an, Du wirst also in 99,9% aller Fälle sauber und ordentlich programmieren können. Und dafür galt mein Tipp.

[RaSoWa1]

Sorry, dass ich mich erst melde, aber ich musste arbeiten.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1186352)

Wir haben hier in zentraler Unit folgendes stehen:

Delphi-Quellcode:

{$IFOPT B+}
  {$Message Fatal 'xyz-Programm/Komponenten/Unit nur lauffähige mit Option B-'}
{$ENDIF}

oder du definierst eine Include-Datei die du überall bei dir verwendest dwelche diese Option setzt.
Machen auch viele Komponentenhersteller so.

Die Idee ist gut. Ich habe sie neben den Schalter als zusätzliche Warnung eingebaut. Meine Komponente funktioniert damit und der Nutzer kann mit seinen Schaltern spielen, wie er will.

Zitat:

Zitat von Furtbichler (Beitrag 1186370)

Bei Performancebottlenecks muß man Abstriche machen, das ist richtig. Inline-Funktionen helfen hier jedoch meist.
Bei mir sind derartige Funktionen, weil unschön und unsicher, in einer separaten Unit gekapselt und dort kann ich meine Spezialkompilereinstellungen von mir aus mit dickem Kommentar plazieren.

Es kommt jedoch sehr sehr selten auf reine Codeperformance an, Du wirst also in 99,9% aller Fälle sauber und ordentlich programmieren können. Und dafür galt mein Tipp.

Danke für den Inline-Tip. Den hatte ich schon wieder vergessen.
Ich habe erstmal als Sofortlösung die Compilerschalter-Lösung verwendet. Später, wenn ich etwas mehr Zeit habe, werde ich den Code durchgehen und die problematischen Stellen suchen und durch entspreche Funktionen ersetzen, so dass ich dann ohne die Compilerschalter auskomme.


Danke nochmals an alle.

Klaus.