defines wie lang?

[Manfred]

wie lang dürfen eigentlich Inhalte von DEFINES werden? 512 Zeichen?

[Tom]

Du meinst den Bezeichner, den Platzhalter selbst, oder? Der Inhalt kann natürlich beliebig lang werden, also das, wodurch der Platzhalter ersetzt wird. Der Platzhalter selbst darf m.E. sogar nur 256 Zeichen lang sein. Aber - wer braucht da auch mehr Zeichen?

[Manfred]

Hi Tom,

ich habe hier derzeit ein Projekt, in dem verdammt viel mit defines gearbeitet wurde und da mußte ich feststellen, das der Wert, also der Text, der in dem DEFINE untergebracht wurde, wohl nicht beliebig lang sein darf. Ich hatte den etwas erweitert und schon kam beim Compilieren eine Fehlermeldung, dass der String zu lang wäre. Also habe ich alle Leerzeichen daraus entfernt (wirklich alle) und siehe da, es klappte wieder.

[Tom]

Hallo, Manfred.

Ich kann einen beliebig langen Text definieren:

Code: Alles auswählen

#define MEINTEXT 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'+;
                          'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'+;
(...)
'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'

[Manfred]

Deshalb war ich ja auch verwundert. Es ist zunächst erstmal so, wie ich es schreibe. Aber ob es nicht evtl. ein Seiteneffekt ist und ganz woanders herkommt, das werde ich dann mal jetzt untersuchen. ich habe in der Anleitung auch nichts dazu gefunden. Allerdings fällt mir gerade im Unterschied zu Deinem Beispiel ein:

Das Teil sieht so jetzt aus:

Code: Alles auswählen

#define BST_INHALT  Abs(JSAL->b_soll)+Abs(JSAL->b_haben)+;
                    Abs(JSAL->sb_soll)+Abs(JSAL->sb_haben)+;
                    Abs(JSAL->k_soll)+Abs(JSAL->k_haben)+;
                    Abs(JSAL->sk_soll)+Abs(JSAL->sk_haben)+;
                    Abs(JSAL->o_soll)+Abs(JSAL->o_haben)+;
                    Abs(jsal->oaj_soll)+Abs(jsal->oaj_haben)+;
                    Abs(jsal->so_soll)+Abs(jsal->so_haben)+;
                    Abs(JSAL->h_soll)+Abs(jsal->h_haben)+;
                    Abs(jsal->sp_soll)+Abs(jsal->sp_haben)+;
                    Abs(jsal->vb_betr_vj)+;  // korr 26.06.2009
                    Abs(jsal->vb_betr_aj)+;  // korr 26.06.2009
                    Abs(jsal->vb_betr_fj)+;  // korr 26.06.2009
                    Abs(jsal->hh_vor_vj)+;
                    Abs(jsal->hh_vor)+;
                    Abs(jsal->fina)

anfänglich fehlte ein großer Teil der Aliasangaben. Nachdem ich die alle ergänzt hatte, kam der Fehler. Dann habe ich sie nach und nach wieder entfernt, bis der Fehler verschwand. Dann dachte ich mir, es mal mit Entfernen der Leerzeichen zu probieren und da kam dann das heraus, was jetzt auch klappt.

[Manfred]

Wobei mir gerade noch was einfällt. Es wird nachher so weiterverarbeitet:

Code: Alles auswählen

IF BST_INHALT > 0 

[Tom]

Hallo, Manfred.

Syntax für ein Define dieser Art:

#DEFINE<leer>PLATZHALTER<leer>INHALT

Wenn Du also innerhalb von "INHALT" ein Leerzeichen hast, konterkarierst Du die Syntax. Du musst den Ausdruck klammern!

[Manfred]

Hi Tom

ich habe das nicht programmiert. Ich arbeitet mich derzeit nur da ein.

Ich verstehe aber jetzt nicht so ganz, was Du meinst. Kannst Du mir das ein wenig erklären?

[georg]

Hallo, Manfred -


es gibt in der Länge des INHALT eine Beschränkung. Wenn die Länge dieses Wertes eine bestimmte Schwelle überschreitet, verweigert der Preprozessor die Verarbeitung. Ich habe das früher ein- oder zweimal in Projekten gehabt, dass der INHALT zu lang war.

Eventuell steht Dein Ersatzwert von der Länge her jetzt (nach dem Herausnehmen der Leerzeichen) wieder kurz vor dieser Grenze.

[AUGE_OHR]

wie Tom schon sagte sollte die "Länge" kein Problem darstellen.

allerdings finde ich die Verwendung von #define "so" doch ziemlich "merkwürdig" ...

Code: Alles auswählen

IF BST_INHALT > 0 

das ist doch eine Abfrage also sollte es eine FUNCTION sein statt einer #define.

[Manfred]

ich habe sowas auch zum ersten Mal gesehen. Das Programm ist total durchsetzt damit. Ich weiß auch nicht was mein Vorgänger damit bezwecken wollte. aber es ist nun mal so. Vor allen Dingen wird der Code dadurch schwer lesbar und schlecht zu debuggen.

[Martin Altmann]

Warum? Mach doch mal ein ppo beim Compilieren und schau Dir dieses an. Dann siehst Du, was die Zeile

Code: Alles auswählen

IF BST_INHALT > 0

wirklich darstellt.

Viele Grüße,
Martin

[georg]

Hallo,


als Anfänger habe ich ähnliche Konstrukte verwendet und kenne heute bessere Wege, das eine oder andere zu regeln.

Zu der THEORIE, dass es keine Grössenbeschränkung gibt, habe ich ein kleines Testprogramm geschrieben. Bei einer Länge von 20.000 Zeichen in einem #DEFINE verschluckt sich der Compiler und gibt eine Fehlermeldung aus:

Code: Alles auswählen

DEMO.PRG(0:0): error XBT0523: Length of input line exceeds input buffer length

19.870 Bytes Länge werden akzeptiert, danach ist Schicht, dann kommt der erwähnte Fehler vom Compiler.

[brandelh]

Ich frage mich, wie man das DEBUGGEN will

[Manfred]

Ich kann es Dir genau sagen: Gar nicht... Jedenfalls nicht im Einzelschritt Modus.

[brandelh]

genau darum macht man so einen Scheiß nicht

[AUGE_OHR]

Zu der THEORIE, dass es keine Grössenbeschränkung gibt, habe ich ein kleines Testprogramm geschrieben. Bei einer Länge von 20.000 Zeichen

"wo" ist das Testprogramm
ich gebe ja zu das ich es nicht bis zum "extremen" Ende ausprobiert hatte und auch nicht auf jedem OS() denn der Wert "könnte" auch OS() abhängig sein.

[AUGE_OHR]

Ich weiß auch nicht was mein Vorgänger damit bezwecken wollte. aber es ist nun mal so. Vor allen Dingen wird der Code dadurch schwer lesbar und schlecht zu debuggen.

vielleicht wollte er genau das erreichen

lief das ganz mal unter Cl*pper ? da haben die Jungs #define statt PUBLIC verwendet ...

was Martin sagte mit dem PPO Code ist schon ganz gut aber das "auflösen" innerhalb des Source mittels einer Function ist "besser".
genau das macht "SUMMER '93" von QBS ... schon lange nicht mehr benutzt ...

[Jan]

Jimmy,

ich bin mir sehr sicher das der Programmierer das zumindest in diesem Fall nicht beabsichtigt hat. Sondern daß das sein Programmierstil war.

Und sicher wird Manfred das alles irgendwann mal auflösen. Aber erstmal muß der gesamte Code gesichtet und verstanden werden. Nichts ist schlimmer als einfach mal drauf los zu korrigieren und aufzulösen, und irgendwann rennt man dann in eine vorher nicht beachtete Falle rein.

Jan

[AUGE_OHR]

ich bin mir sehr sicher das der Programmierer das zumindest in diesem Fall nicht beabsichtigt hat. Sondern daß das sein Programmierstil war.

wie ich schon sagte war es ein Trick unter Cl*pper um PUBLIC zu "sparen"

Und sicher wird Manfred das alles irgendwann mal auflösen. Aber erstmal muß der gesamte Code gesichtet und verstanden werden.

Manfred sagt doch das er schon bei Änderungen Problem beim compilieren, hat also muss man wohl erst mal an den Stellen was machen.

Nichts ist schlimmer als einfach mal drauf los zu korrigieren und aufzulösen, und irgendwann rennt man dann in eine vorher nicht beachtete Falle rein.

das machen nur Anfänger

üblicherweise wird der "fremde" Source Code analysiert und dem Kunden ein Konzept vorgelegt bevor man eine Zeile schreibt. wenn aber der "fremde" Source nicht einwandfrei durch die Analyse Tools läuft bezweifle ich das man die Zusammenhänge erkennen kann z.b. "wo", "wer" "welche" Function aufruft.
diese Vorarbeiten können je nach Kunden mehrere Monate dauern bis wirklich alles "klar" ist und man die Unterschrift des Kunden hat und erst dann fängt die "richtige" Arbeit an.

[Manfred]

Jimmy,

das ist alles richtig was Du geschrieben hast. Nur die Sache mit den Publics kann ich so nicht unterschreiben. Oder aber ich möchte gar nicht erst wissen, was ansonsten an Publics eingebaut worden wäre zu den Menge, die jetzt schon drin sind.

Ansonsten hast Du vollkommen Recht und zwar bis zum letzten Satzzeichen.

[Jan]

das machen nur Anfänger

Danke das Du allwissender Oberguru Dich dazu herabläßt, uns Unwissende an Deinem Wissen teilhaben zu lassen.

Jan

[Manfred]

Jan,

ich sehe das so, dass er Dich nur bestätigt hat...

[Manfred]

Nachdem ich mir das Handbuch zu define etwas genauer durchgelesen habe, bin ich auf den Punkt gestossen:

Pseudofunktionen erleichtern die Programmierung, da weniger Code in ein Programm geschrieben werden muß. Den gültigen, compilierbaren Programmcode schreibt der Präprozessor. Ein weiterer Vorteil ist ihr besseres Laufzeitverhalten, da der Overhead eines echten Funktionsaufrufs entfällt. Der Nachteil von Pseudofunktionen ist, daß sie immer durch einen Ausdruck ersetzt werden, der gegebenenfalls sehr umfangreich sein kann. Dadurch wird die ausführbare Datei (EXE-Datei) vergrößert, und das kostet Speicherplatz. Es ist bei der Definition von Pseudofunktinen daher immer zwischen dem Vorteil der höheren Ausführungsgeschwindigkeit und dem Nachteil des höheren Speicherbedarfs abzuwägen.

Ich habe also zunächst angefangen die Pseudofunktionen wieder in normale Funktionen umzuwandeln, da es einige gibt/gab, die so besser zu kontrollieren sind. Die Exe wurde dadurch zusehends kleiner, wie angekündigt. Meine Frage wäre jetzt aber:

Hat jemand schonmal Erfahrung damit gesammelt, oder kann Vermutungen oder Wissen dazu äußern, in wie weit sich die Ausführungsgeschwindigkeit jetzt dadurch verlangsamen könnte?

[brandelh]

Ich denke damit ist gemeint, dass der Aufruf einer Funktion etwas mehr Zeit kostet als das Ergebnis direkt zu berechnen, einfaches Beispiel:

Code: Alles auswählen

#define _PI_ 3.14159265359
function PI()
return 3.14159265359

1. nFlaeche := nRadius * nRadius * 3.14
2. nFlaeche := nRadius * nRadius * _PI_
3. nFlaeche := nRadius * nRadius * PI()

die Berechnungen 1. und 2. sollten gleich schnell sein, die 3. könnte etwas langsamer ausfallen ...
allerdings wirst du mit seconds() bei einem Aufruf keine Differenz feststellen, es geht einfach zu schnell.
Wenn du um jede dieser 3 Zeilen eine Schleife mit 1.000.000 Aufrufen legst, könntest eventuell einen Unterschied ausmachen, aber wäre das wirklich relevant ?

Ich denke das man den Overhead eines Funktionsaufrufes vernachlässigen kann, die Lesbarkeit des Codes aber steigt.
Die #defines machen auf jeden Fall Sinn um "magic Numbers" flexibel und aussagekräftig zu halten, aber das kennen wir ja:

der Sinn von K_ESC ist leichter erkennbar als 27 ...
in der Stärke liegt aber auch die Gefahr,

#define PI 3.14159265359

ist zwar gut gemeint, könnte aber wegen des kurzen Names leicht zu unerwünschen Vertauschungen führen und gilt NUR in der aktuellen PRG-Datei. Die Funktion PI() gilt im ganzen Programm.