enum vs. #define

[Artchi]

Kahino schrieb:

Nur weil der Compiler da mecker, heißt das doch noch lange nicht, dass eine 1 kein String sein kann.

Sorry das ich das sage: aber was Du meinst, ist sowas von unerheblich, das glaubst du garnicht. Weil nur das Zählt, was der ISO-C++-Standard und somit jeder weitestgehend konforme Compiler dazu sagt.

War jetzt hart für dich, aber das mußte einfach sein.

[Bashar]

Kahino schrieb:

Nur das "Problem" ist, die meisten Compiler erdreisten bzw erbarmen sich (je nachdem wie man das denn sehen möchte) eine integrale Zeichenliterale ohne typanzeigenden Zusatz so zu interpretieren, als SEI(!) diese integrale Zeichenliterale vom Typ int.

Naja. Sie erdreisten sich, dem C++-Standard zu folgen, der das so fordert. In C sind BTW sogar Zeichenliterale wie 'H' vom Typ int.

[templäd]

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

[SideWinder]

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

^^

#define ONE_LONG 1L
#define ONE_FLOAT 1.0f
...

lol

MfG SideWinder

[Kahino]

Sorry das ich das sage: aber was Du meinst, ist sowas von unerheblich

Brauchst dich dafür nicht entschuldigen, schließlich ist es unerheblich ob es unerheblich ist, sprechen wir doch über das Prinzip von Zahlen als typlose Abstrakta welche erst während der compilierung gecastet werden und als was sie zuvor so alles geplant sein könnten.

War jetzt hart für dich, aber das mußte einfach sein.

Tu mir leid, kann ich nicht nachvollziehen, hast du irgendwas gesagt, das meinen Aussagen widerspricht?

Naja. Sie erdreisten sich, dem C++-Standard zu folgen, der das so fordert.

Was hast du denn dagegen, dass integrale Literale ohne typanzeigenden Zusatz von Compilern standardmäßig in int-konstanten gecastet werden?
Ich hätte von den beiden angegebenen jeweiligen Extrema eher erbarmen statt erdreisten gewählt, wäre lästig ständig explizite casts für irgendwelche Tests mit Zahlen durchzuführen.

Außerdem denke ich man kann doch in literalen auch den Typ angeben oder:

WÄRE durchaus möglich, ja

[Bashar]

Kahino schrieb:

Naja. Sie erdreisten sich, dem C++-Standard zu folgen, der das so fordert.

Was hast du denn dagegen, dass integrale Literale ohne typanzeigenden Zusatz von Compilern standardmäßig in int-konstanten gecastet werden?

"gecastet" ist wohl das falsche Wort. Außerdem hab ich nichts dagegen, wie kommst du denn darauf? Ich habe nur deine Ausdrucksweise übernommen.

[Bashar]

Kahino schrieb:

Außerdem denke ich man kann doch in literalen auch den Typ angeben oder:

WÄRE durchaus möglich, ja

Jetzt wirst du aber inkonsistent. Wenn du 1L einen Typ zubilligst, kannst du nicht gleichzeitig sagen, dass 1 keinen Typ hat. Beides sind auf einer Ebene einfache Zeichenfolgen im Quelltext, und auf der nächsten Ebene ein long- bzw. ein int-Literal.

BTW (char)1 ist kein char-Literal, sondern ein cast-Ausdruck.

[Kahino]

Außerdem hab ich nichts dagegen, wie kommst du denn darauf? Ich habe nur deine Ausdrucksweise übernommen.

Nun ja, du kommentierst ein von dir zitiertest Zitat von mir, indem du inhaltlich widerholst was ich sage und dabei meine Ausdrucksweise verwendest, dich jedoch ausschließlich auf die Alternative "erdreisten" beschränkst.
Wieso nicht "erdrestet bzw erbarmt"? So hättest du dort keine Wertung einfließen lassen.
Darauf, dass du dies als Stilmittel verwendest um in Kombination mit dem Hinweis auf den Standard andeutest, ich würde sagen der Standard sei scheiße, muss ich mich ja nicht einlassen oO

So wie es da Steht, nennst du dieses Verhalten erdreisten.

Jetzt wirst du aber inkonsistent. Wenn du 1L einen Typ zubilligst, kannst du nicht gleichzeitig sagen, dass 1 keinen Typ hat. Beides sind auf einer Ebene einfache Zeichenfolgen im Quelltext, und auf der nächsten Ebene ein long- bzw. ein int-Literal.

Joar ey, da hast du völlig Recht, war mir auch nicht sicher ob ich das wirklich noch schreiben soll, war ich zu vorschnell, womit ich jetzt nicht sagen will, es ginge nicht oder es ginge doch. War halt gerade in Fahrt oO

Hier bin ich jedoch einfach im Zwispalt.

Ich rede davon was Zahlen im Prinzip sind, nicht was zeichenfolgen sind.
Die Literale 1L, ist kein eindeutiges Zeichen für uns, welches wir mit Dem Abstraktum der eins direkt verbinden, doch handelt es sich bei diesem L, an der 1, einfach um einen Typanzeigenden Zusatz.
So ist dies nun eine 1 mit einem L dran oder die Zeichenfolge 1L?

Die meisten Compiler mögen dieses L durchaus als Typspezifizierer kennen,
weswegen der Compiler selbst diese Zeichenfolge durchaus als eine 1 mit einem L dran interptretiert und daraus halt eine Long-konstante macht.

Damit diese Betrachtung überhaupt Sinn macht (Prinzip von Zahlen), gehen wir mal in eine Typlose Ebene.
Bei der Zeile #define 1L erstellen wir eine Konstante, welche so wie sie da steht, eindeutig keine Zahl ist, wenn man sie allgemein betrachtet.
1L entspricht nunmal nicht dem Abstraktum welches wir mit 1 verbinden.
Schön und gut, doch meine Grundaussage eine 1 kann im Prinzip auch ein String sein, bezog sich ja nunmal auf die Arbeit mit c++, also müssen wir das auch hier machen.
Jetzt wissen wir, was dieses L einmal bewerkstelligen wird.

So ließe sich 1L auch als 1 mit einem L dran lesen, doch ändert auch dies nichts daran, dass 1L als eine einzelne Konstante keine Zahl im allgemeinen ist.
Unklarer Punkt 1 : Konstante vor der Compilierung gleich Zahl oder nicht Zahl?

Doch selbst wenn wir uns entscheiden, 1L sei nun eine Zahl, inwiefern ließe sich hier behaupten, diese Zahl könnte auch ein String sein? Schließlich Ist mit dieser Methode schon vorherbestimmt, dass dem nicht so sein soll, noch bevor man in eine Ebene kommt, in der Typen tatsächlich zugewiesen werden.

Die Frage ist also, inwieweit man bei diesem Determinismus nun von einer Zahl im Prinzip sprechen kenn, wurde diese typlose Zahl doch schon als ein zukünftiger Long vorherbestimmt, wenn man nichts spezielles macht.

Unklarer Punkt 2: 1L im Typlosen Raum, doch bezogen auf c++ nun allgemein eine 1 mit einem L dran oder eine 1 speziell gedacht als 1 vom Typ Long?

In wie weit legt ein klarer Determinismus, welcher in diesem Fall als inhaltlich mit "gedacht als" gefüllt werden kann, einen Typ im Typlosen Raum Fest ?

Geht man so tief, kommt man aus meinem Blickwinkel in eine Wishiwashiebene, welche sich für mich ohne weiteres nicht eindeutig differenziert betrachten lässt (womit ich nicht sagen will das ginge nicht), weswegen ich auch ungern so tief in diese Fragestellung eindringe, bis ich nicht durch andere nette hinweise erleuchtet werde :).

Bis jetzt vertrete ich in diese ebene auch Bewusst konträre Meinungen, welche ich nicht breittreten werde bis diese eine weitere Schlussfolgerung sind oO.

BTW (char)1 ist kein char-Literal, sondern ein cast-Ausdruck.

habe ich auch nie behauptet

[Michael E.]

Sehr philosophisch.

Hat man dir eigentlich schon verraten, wie die Konstruktoren von std::string aussehen?

[camper]

Kann das mal jemand übersetzen oder lohnt das nicht?

[Kahino]

Hat man dir eigentlich schon verraten, wie die Konstruktoren von std::string aussehen

Das ist bezogen auf das Thema dieser Vom Topic abgeschweiften Diskusion völlig unerheblich. Naja, nimmt man es genau, nicht wirklich, doch für das angesprochene Prinzip durchaus.

Kann das mal jemand übersetzen oder lohnt das nicht?

Lohnt nicht, da praktischer Nutzen gleich Null.
Reine Gedankenspiele.

[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.

[Um dagegen zu halten]

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(...);
  }
}

[hja]

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.

[hja]

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