enum vs. #define

Simon2

templäd schrieb:

Außerdem denke ich man kann doch in literalen auch den Typ angeben oder:
also so:
#define ZWEI_LONG 2L
#define ZWEI_UNSIGNED_LONG 2UL
//oder
#define (char)1

... aber leider auch so

#define ZWEI_LONG "Wummi"
#define ZWEI_UNSIGNED_LONG 4.0f

Gruß,

Simon2.

volkard schrieb:

Um dagegen zu halten schrieb:

volkard schrieb:

aber sooft man es dreht und wendet, beim logging kommen stets makros heraus.

Auch nur, weil es in C++ keinen Stacktrace gibt, um die Position im Code zu ermitteln

vor allem, weil man das loggen einigermaßen zentrall ausschalten können mag, ohne daß die parameter ausgewertet werden und funktionen aufgerufen werden.

Wenn man eine Konstante in der log-funktion auf true überprüft, sollte doch jeder vernünftige compiler den nie erreichbaren teil ganz raus werfen und die dann leere funktion hoffentlich auch, oder?

void log(...) {
  if(DO_LOGGING) {
    write(...);
  }
}

Einfach mal ein Gedanke zum Thema Logging.

Logging hat zwei Hauptanwendungen: Ablauffehler im Programm finden und Statusinformationen über das Programm erzeugen. Im ersten Fall geht es halt darum bei einem Fehlerverhalten analysieren zu können wodurch der Fehler entstanden ist, im letzteren Fall geht es darum zu überprüfen ob das Programm sich auch ordnungsgemäß verhält.

Früher, vor gut 20 Jahren gab es noch einen dritten Fall: Zum Debuggen, weil es damals noch keine brauchbaren Debugger gab, wenn überhaupt. In Grenzfällen mag dies auch heute noch nötig sein, doch ansonsten benutzt man dafür heutzutage schlicht Debugger.

Die beiden ersten Fälle oben gehören für mich zum Gebiet der Qualitätssicherung, wo es darum geht eine einwandtfreie Funktion des Programms zu überprüfen. In dem Zusammenhang sprechen zwei Gründe vollkommen dagegen, das Logging mit Makros zu implementieren, die man dann zu Compilerzeit an- bzw ausschalten kann:

1. Die QS sollte idealerweise nicht vom Programmierer selber ausgeführt werden. Der QSler aber sollte ebenso wenig selber das programm compilieren, er soll viel mehr das fertige Compilat testen. Dazu muß er aber in der Lage sein das Loging zu steuern.

2. Auch wenn es trivial erscheinen mag, wenn man das Loging durch Makros implementiert und im Compilerlauf dann ab- bzw anschaltet, dann erhält man zwei unterschiedliche Programmversionen. Wer kann denn jetzt sicherstellen das nicht durch das rein- bzw rauskompilieren der Loging-Makros (die ja typischerweise massenhaft im Programm vorkommen) nicht ein Fehler entsteht bzw. ausgelöst wird? Nimmt man seine Arbeit genau, muß man beide Programmversionen (mit und ohne Loging compiliert) gründlich testen. Wie aber testet man dann die Version ohne Loging gründlich, wenn man gerade die Log-Informationen braucht um die einwandtfreie funktion zu überprüfen?

Für mich läuft es darauf hinaus das Logging ein fester Bestandteil des Programms ist und als solcher ebenso wie alles andere über ein sauberes Klassendesign implementiert wird.

tntnet

Sag mir mal, was der Unterschied zwischen "Ablauffehler im Programm finden" und "Debugging" ist.

Simon2

hja schrieb:

....Für mich läuft es darauf hinaus das Logging ein fester Bestandteil des Programms ist und als solcher ebenso wie alles andere über ein sauberes Klassendesign implementiert wird.

Mache ich aus denselben Gründen ebenso.

Gruß,

Simon2.

volkard

Um dagegen zu halten schrieb:

Wenn man eine Konstante in der log-funktion auf true überprüft, sollte doch jeder vernünftige compiler den nie erreichbaren teil ganz raus werfen und die dann leere funktion hoffentlich auch, oder?

nein, gar nicht!
in c++ muß man funktionsrückgaben nicht benutzen.
desdawegen ist
log(getFreeFestplattenplatz())
immer mit dem aufruf des ermittelns des freien fesplattenspeichers behaftet. ich will diesen aufruf einsparen, wenn ich mich entschlossen habe, daß dieser programm-abschnitt unproblematisch ist und nicht mehr debug-geloggt werden soll.

klar darf man bei so einem logging nur nebeneffektfreie funktionen aufrufen.

welche qs habt ihr denn, die dafür sorgt, daß das logging nicht ausschaltbar ist? die qs selber will doch manchmal mehr und manchmal weniger haben. beim logging darf man natürlich nur nebeneffektfreie funktionen aufrufen. und das mit dem "sauberen klassendesign" widerspricht doch dem makro nicht. der makro ist doch nur eine hauchdünne zwischenschicht. drunter sind bestimmt klassen, glaub's mir.

volkard

hja schrieb:

Einfach mal ein Gedanke zum Thema Logging.

Logging hat zwei Hauptanwendungen: Ablauffehler im Programm finden und Statusinformationen über das Programm erzeugen. Im ersten Fall geht es halt darum bei einem Fehlerverhalten analysieren zu können wodurch der Fehler entstanden ist, im letzteren Fall geht es darum zu überprüfen ob das Programm sich auch ordnungsgemäß verhält.

Früher, vor gut 20 Jahren gab es noch einen dritten Fall: Zum Debuggen, weil es damals noch keine brauchbaren Debugger gab, wenn überhaupt. In Grenzfällen mag dies auch heute noch nötig sein, doch ansonsten benutzt man dafür heutzutage schlicht Debugger.

Die beiden ersten Fälle oben gehören für mich zum Gebiet der Qualitätssicherung, wo es darum geht eine einwandtfreie Funktion des Programms zu überprüfen. In dem Zusammenhang sprechen zwei Gründe vollkommen dagegen, das Logging mit Makros zu implementieren, die man dann zu Compilerzeit an- bzw ausschalten kann:

1. Die QS sollte idealerweise nicht vom Programmierer selber ausgeführt werden. Der QSler aber sollte ebenso wenig selber das programm compilieren, er soll viel mehr das fertige Compilat testen. Dazu muß er aber in der Lage sein das Loging zu steuern.

2. Auch wenn es trivial erscheinen mag, wenn man das Loging durch Makros implementiert und im Compilerlauf dann ab- bzw anschaltet, dann erhält man zwei unterschiedliche Programmversionen. Wer kann denn jetzt sicherstellen das nicht durch das rein- bzw rauskompilieren der Loging-Makros (die ja typischerweise massenhaft im Programm vorkommen) nicht ein Fehler entsteht bzw. ausgelöst wird? Nimmt man seine Arbeit genau, muß man beide Programmversionen (mit und ohne Loging compiliert) gründlich testen. Wie aber testet man dann die Version ohne Loging gründlich, wenn man gerade die Log-Informationen braucht um die einwandtfreie funktion zu überprüfen?

Für mich läuft es darauf hinaus das Logging ein fester Bestandteil des Programms ist und als solcher ebenso wie alles andere über ein sauberes Klassendesign implementiert wird.

lol.
hja mag bestimmt auch UML und ist ein mädchen.

volkard

hja schrieb:

Früher, vor gut 20 Jahren gab es noch einen dritten Fall: Zum Debuggen, weil es damals noch keine brauchbaren Debugger gab, wenn überhaupt. In Grenzfällen mag dies auch heute noch nötig sein, doch ansonsten benutzt man dafür heutzutage schlicht Debugger.

irgendwie gucke ich ins log des httpd nur zum debuggen (zum debuggen meiner schäbigen php-schripts). macht mich das jetzt um 20 jahr zu alt?

mal deine anderen beiden fälle beleuchten.

-Ablauffehler im Programm finden
also debuggen.

-Statusinformationen über das Programm erzeugen
also debuggen, optimieren oder abrechnen.

sicherlich sachen, die man abschaltbar gestalten sollte.

tntnet schrieb:

Sag mir mal, was der Unterschied zwischen "Ablauffehler im Programm finden" und "Debugging" ist.

Hatte ich unglücklich ausgedrückt.

Debugging sind für mich Fehler im Sourcecode selber, also sowas wie Abstürze usw.

Mit Ablauffehler meinte ich Logische Fehler im Programm. Auch wenn der Sourcecode selber einwandfrei läuft kann man logische Fehler gemacht haben und bei denen kann Dir kein debugger helfen, wohl aber ein sauberes Logfile

volkard

die suche und behebung logischer fehler nennt man auch debugging, obwohl man dazu unter umständen keinen debugger benutzt.

volkard schrieb:

Um dagegen zu halten schrieb:

Wenn man eine Konstante in der log-funktion auf true überprüft, sollte doch jeder vernünftige compiler den nie erreichbaren teil ganz raus werfen und die dann leere funktion hoffentlich auch, oder?

nein, gar nicht!
in c++ muß man funktionsrückgaben nicht benutzen.
desdawegen ist
log(getFreeFestplattenplatz())
immer mit dem aufruf des ermittelns des freien fesplattenspeichers behaftet. ich will diesen aufruf einsparen, wenn ich mich entschlossen habe, daß dieser programm-abschnitt unproblematisch ist und nicht mehr debug-geloggt werden soll.

getFreeFestplattenplatz wird natürlich weiter aufgerufen, aber der log aufruf fliegt raus. wenn alles weg soll, dann braucht man wohl ein makro

welche qs habt ihr denn, die dafür sorgt, daß das logging nicht ausschaltbar ist?

Wir haben keine, liegt wohl an unserem genialen chef. Wir hatten mal einen der getestet hat, aber der ist weg. Ich überleg mir auch schon zu gehen, wie einige andere auch...