enum vs. #define

[darthdespotism]

Hm da war doch auch noch was mit der Zeilenangabe bei Compilerfehlern.

#define abc 1

void f(std::string);

int main()
{
   f(abc);
}

Fehlermeldung:
Zeile 7: 1 ist kein string

"Wo steht da 1?"

________________

enum( abc = 1}

void f(std::string);

int main()
{
   f(abc);
}

Fehlermeldung: Zeile 7 enum abc ist kein string.

Dürfte gerade bei komplexeren sachen leichter zu erkennen sein.

[Stelfer]

benutz mal " "

und enums sind zahlen und keine strings

{ red, blue, yellow, grey = 100, black}

red = 0
blue = 1
...
grey = 100
black = 101

bei dem define kommt eine textersetzung ....
also schreibst du rein abc(l), ist das ein string -.- ?

[Kahino]

bei dem define kommt eine textersetzung ....
also schreibst du rein abc(l), ist das ein string -.- ?

Nun ja, im Prinzip schon, doch std::string weiß das ohne weiteres einfach nicht

[Stelfer]

im prinzip eben nicht -.- das ist ein parameter

[Kahino]

Mit define definierte Konstanten sind völlig Typlos, könnten also als fast alles geplant sein, wieso kann diese 1 dann nicht als Konstante vom Typ char geplant sein?
Schließlich handelt es sich bei charvariablen ebenso wie bei ints um einen integralen Datentyp, weswegen man strings natürlich auch aus integrale Zahlen zusammensetzen kann.
Gibt man z.B. char blub[] = { 72, 97, 108, 108, 111, 0 }; auf dem Bildschirm aus, erscheint dort "Hallo", ersetzt man hier char durch int erschiene auf dem Bildschirm "72971081081110"(je nachdem welchen Hinweis man dem Compiler zur Interpretation angibt).
Und diese 1 repräsentiert bei der (bei mir) standardmäßig gewählten Schriftart in der Konsole ein kleines Smilie :).

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.
Sicherlich wird dies wohl deswegen so geregelt, weil dies wohl häufig so gedacht ist.

Doch ändert dies nichts an der Tatsache, dass eine 1 bzw irgendwelche anderen Zahlen als integrale Zeichenliterle, im Prinzip durchaus einen String bilden können.
Die Angabe von (char)72 oder 'H' dürfte wohl äquivalent sein oO.

[volkard]

@hja

SideWinder schrieb:

Was ist an:

#define LOG(msg) Logger::log((msg), __FILE__, __LINE__);

schlechtes OOP-Design?
MfG SideWinder

gar nichts.
auch an 5+5 ist kein schlechtes OOP-design zu erkennen.
(/me fühlt ein "java.lang.Math.oprator+(5,5)//nur so ist es OO" anklopfen)
vielleicht mag man herumspielen mit sachen wie

#define LOG(msg) Logger::log(__FILE__<<__LINE__)<<msg;

, um auch problemlos

LOG("cant open file "<<fileName);

loggen zu können.
aber sooft man es dreht und wendet, beim logging kommen stets makros heraus.

[Um dagegen zu halten]

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

[Stelfer]

#define abc 1

void f(std::string);

int main()
{
   f(abc);
}

du übergibst als string also übergibst du einen parameter

ersetz sieht es dann so aus:

void f(std::string);

int main()
{
   f(1);
}

verstehste nun ?

[Kahino]

Wie wäre es wenn du einfach liest was ich schreibe?

Nur weil der Compiler da mecker, heißt das doch noch lange nicht, dass eine 1 kein String sein kann.
Sowohl int als auch char sind integrale Datentypen, beide speichern ganze Zahlen, hinter Buchstaben verstecken sich nunmal ganze Zahlen.

Die integrale Zeichenliterale 1 (wie zu sehen ist ohne Datentypanzeigenden Zusatz) hat so lange keinen Typ, bis sie in einen bestimmten Typ gecastet wird und sei dies nur implizit.

#define abc 1 // <-- Ohne Datentyp 
void f(std::string);
int main(int argc, char* argv[])
{
   f(abc);   // <-- Daraus wird "f(1);" Die Datentyplose integrale
             // Literale(welche sowohl als int als auch als (z.B.) char oder
             // String interpretiert werden kann) wird hier in eine int-
             // konstante gecastet.
             // Bei den meisten Compilern ist es nunmal "voreingestellt",
             // dass integrale konstanten ohne typanzeigenden Zusatz
             // in int-konstanten GECASTET (<-- Vor dem Cast natürlich kein
             // eindeutiger int!) werden,
             // manche Leute nennen das implizitcast oO.
             // Soll heißen, überall wo während der Compilierung eine 
             // integrale Literale steht, steht intern sowas wie (int)Literale.
             // Nunja, zumindest mindest lässt sich auf diese Weise 
             // verdeutlichen worauf ich hinaus will.
             // Demnach lässt sich "f(1);" so LESEN, als WÜRDE
             // dort "f( (int)1 );" stehen

   // compilier das Programm mal mit folgenden Zeilen
   f(char(abc)); // char() zur Aushebelung des Implizit Casts

   char zeichen = abc;
   int zahl = abc;
   std::cout << zeichen << (char)zahl << std::endl;
   std::cout << (int)zeichen << zahl << std::endl;
   // Sollte es sich bei dir bei der 1 um ein nichtdruckbares Zeichen handeln,
   // versuch es einfach mal mit 72 oder sowas, ist garantiert was druckbares
   // drinne.

return 0;
}

Soll heißen, eine 1, so ganz nackt im Quellocde, ist erst dann ein Int, wenn sie während der Compilierung einen impliziten Cast erfährt, wohlgemerkt - CAST, von "irgendwas" in int oO

[volkard]

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.

[Simon2]

EDIT: Is egal..

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