Unsigned | Signed .. Standart wenn keine Angabe

volkard schrieb:

Na, sicher.

bei mir nicht. foo(12) und foo(-99) geben:

error C2668: 'foo' : ambiguous call to overloaded function
could be 'void foo(unsigned char)'
or 'void foo(signed char)'
or 'void foo(char)'

soviel zum 'sinn' dieser char-dreifaltigkeit in C++

Bashar

-12 und 99 sind int-Literale, es passiert also genau das richtige.

volkard

;fricky schrieb:

volkard schrieb:

Na, sicher.

bei mir nicht. foo(12) und foo(-99) geben:

error C2668: 'foo' : ambiguous call to overloaded function
could be 'void foo(unsigned char)'
or 'void foo(signed char)'
or 'void foo(char)'

soviel zum 'sinn' dieser char-dreifaltigkeit in C++

Das ist aber das erwartete Verhalten. Und sinnvoll ist es sogar auch.

LordJaxom

;fricky schrieb:

[...]

Dass solche Antworten kommen würden, waren mir sowas von klar, dass ich schon nach Tims Posting ein C-Beispiel dafür gebastelt hatte. Leider habe ich das aus Zeitnot nicht mehr posten können.

void cFunc( char* c ) { ((void)c); }
void iFunc( int* i ) { ((void)i); }

int main()
{
    signed char a;
    unsigned char b;
    signed int c;
    unsigned int d;
    cFunc( &a );
    cFunc( &b );
    iFunc( &c );
    iFunc( &d );
    return 0;
}

Dreimal darfst Du raten (am besten fängst Du dabei bei "eins" an, dann ist die dritte Antwort die korrekte), wieviele Warnungen ein standardkonformer Compiler auf höchster Warnstufe, z.B. der gcc, bei diesem Code ausgibt.

(P.S.: Der MSVC ist ein C++-Compiler, der von früher noch ein bisschen C kann und zählt damit nicht :p :D)

Bashar schrieb:

-12 und 99 sind int-Literale, es passiert also genau das richtige.

volkard schrieb:

Das ist aber das erwartete Verhalten. Und sinnvoll ist es sogar auch.

erwarten tut man's nur, wenn man's vorher schon weiss. intuitiv ist das verhalten keineswegs. seltsamerweise klappts aber mit allen 3 aufrufen, sobald ich bis auf 'foo(char)' die anderen funktionen auskommentiere. wieso ist ein c++ compiler schlau genug, um mit int-literalen eine 'char'-funktion aufzurufen, streikt aber, sobald überladungen da sind. er könnte doch an den parametern erkennen, was gemeint ist. konsequenterweise sollte er dann auch den aufruf der char-funktion mit int-literalen verweigern.

LordJaxom schrieb:

void cFunc( char* c ) { ((void)c); }
void iFunc( int* i ) { ((void)i); }

int main()
{
    signed char a;
    unsigned char b;
    signed int c;
    unsigned int d;
    cFunc( &a );
    cFunc( &b );
    iFunc( &c );
    iFunc( &d );
    return 0;
}
Dreimal darfst Du raten (am besten fängst Du dabei bei "eins" an, dann ist die dritte Antwort die korrekte), wieviele Warnungen ein standardkonformer Compiler auf höchster Warnstufe, z.B. der gcc, bei diesem Code ausgibt.

hab's nicht ausprobiert, aber ich schätze er wird mal 'signed/unsigned-mismatch' und mal sowas wie 'truncation' anmeckern. oder meintest du was anderes?

volkard

;fricky schrieb:

erwarten tut man's nur, wenn man's vorher schon weiss. intuitiv ist das verhalten keineswegs. seltsamerweise klappts aber mit allen 3 aufrufen, sobald ich bis auf 'foo(char)' die anderen funktionen auskommentiere. wieso ist ein c++ compiler schlau genug, um mit int-literalen eine 'char'-funktion aufzurufen, streikt aber, sobald überladungen da sind. er könnte doch an den parametern erkennen, was gemeint ist. konsequenterweise sollte er dann auch den aufruf der char-funktion mit int-literalen verweigern.

Denk doch mal selber nach.
Wenn der Laden nur eine Pizza führt, reicht es "Pizza" zu bestellen.
Wenn er aber drei verschiedene Pizzen führt, und Du "Pizza" bestellt, sagt der Ober

error C2668: 'Pizza' : ambiguous call for overloaded food 
could be 'Pizza Hawaii' 
or 'Pizza Margeritha' 
or 'Pizza Calzone'

volkard schrieb:

;fricky schrieb:

erwarten tut man's nur, wenn man's vorher schon weiss. intuitiv ist das verhalten keineswegs. seltsamerweise klappts aber mit allen 3 aufrufen, sobald ich bis auf 'foo(char)' die anderen funktionen auskommentiere. wieso ist ein c++ compiler schlau genug, um mit int-literalen eine 'char'-funktion aufzurufen, streikt aber, sobald überladungen da sind. er könnte doch an den parametern erkennen, was gemeint ist. konsequenterweise sollte er dann auch den aufruf der char-funktion mit int-literalen verweigern.

Denk doch mal selber nach.
Wenn der Laden nur eine Pizza führt, reicht es "Pizza" zu bestellen.
Wenn er aber drei verschiedene Pizzen führt, und Du "Pizza" bestellt...sagt der Ober
error C2668: 'Pizza' : ambiguous call for overloaded food 
could be 'Pizza Hawaii' 
or 'Pizza Margeritha' 
or 'Pizza Calzone'

nicht ganz, in unserem beispiel bestelle ich z.b. pizza(99) mit ananas(-), also geht der pizzafahrer in die küche und ruft 'einmal pizza mit' ananas. der koch, dessen repertoire nur aus 3 pizzen besteht überlegt kurz: pizza==char könnte sein, calzone, ohne ananas == unsigned char, nee das passt nicht, hawaii mit ananas == signed char -> das muss es sein. bingo! also schmeisst er 'ne hawaii in den ofen und ich kriege meine pizza mit ananas.

Bashar

Die Idee ist, dass bestehender Code nicht falsch wird, wenn eine Überladung hinzugefügt wird.
BTW ist das hier extrem OT.

Bashar schrieb:

Die Idee ist, dass bestehender Code nicht falsch wird, wenn eine Überladung hinzugefügt wird.

das scheint aber nicht zu funktionieren.
zuerst:

void foo (int)
{
    cout<<"richtig\n";
}

int main ()
{
   foo('a');
}

irgendwann später:

void foo (int)
{
    cout<<"richtig\n";
}

void foo (char)
{
    cout<<"falsch\n";
}

int main ()
{
   foo('a');
}

pointercrash**

In dem Beispiel von LordJaxom wird dem Compiler die char- Sache wurscht, sobald man nicht typisierte Pointer, sondern Werte in die Funktion stopft, da ist dann Schluß mit Typüberwachung.
Vermutlich nur so eine Sache mit der möglichen Sonderrolle von char* als String.

In C99 gibt's ja auch nur int8_t und uint8_t als Ersatzbezeichner, der dritte Typ ist nur Compiler- Folklore.

LordJaxom

pointercrash() schrieb:

In dem Beispiel von LordJaxom wird dem Compiler die char- Sache wurscht, sobald man nicht typisierte Pointer, sondern Werte in die Funktion stopft, da ist dann Schluß mit Typüberwachung.

Richtig.

;fricky schrieb:

hab's nicht ausprobiert, aber ich schätze er wird mal 'signed/unsigned-mismatch' und mal sowas wie 'truncation' anmeckern. oder meintest du was anderes?

Falsch.
Er meckert drei mal "Pointers differ in signedness".
Damit wollte ich zeigen dass int == signed int, aber mitnichten char == signed char (oder unsigned char). Aber dass Du auf etwas anderes kommst war mir fast klar

pointercrash**

LordJaxom schrieb:

Damit wollte ich zeigen dass int == signed int, aber mitnichten char == signed char (oder unsigned char).

Welchen Sinn Du darin siehst, Du mir sagen mußt, junger Jedi (frei nach Yoda).

Wir dürften uns alle einig sein, daß alle ganzzahligen Typen eigentlich nur signed oder unsigned sein können und das Ganze auf die unterschiedliche Interpretation des MSB hinausläuft.

Beim Char dürfte eine Lücke (oder eine doofe Definition) im Standard dafür verantwortlich sein, daß da kein einheitlicher default ist, deswegen müssen Compiler drei Fälle unterscheiden (wohl implementation defined).

Also normalo: Signed, bei char müssen Bytefuchser aber aufpassen.

LordJaxom schrieb:

Aber dass Du auf etwas anderes kommst war mir fast klar

wie gesagt, habs leider immer noch nicht ausprobiert, aber ich glaube dir auch so. was würde eigentlich passieren, wenn du statt adressen die variablenwerte selbst übergeben würdest? auch 3 warnings?

pointercrash**

;fricky schrieb:

was würde eigentlich passieren, wenn du statt adressen die variablenwerte selbst übergeben würdest? auch 3 warnings?

Hatten wir schon (sh. meinen vorletzten Post) ^^^^^^^^^^
Nee, passiert gar nichts - char hat keinen default => Compiler- Folklore.