int_fast8_t cannot be overloaded

[Tachyon]

Alternativ kannst Du MSVC auch einfach sagen, dass er keine Erweiterungen benutzen und sich standardkonform verhalten soll.

[knivil]

Ich frage mich gerade, was int_fast8_t fuer ein Datentyp sein soll. Gibt es auch einen int_slow8_t?

[arghonaut]

knivil schrieb:

Ich frage mich gerade, was int_fast8_t fuer ein Datentyp sein soll. Gibt es auch einen int_slow8_t?

http://en.wikipedia.org/wiki/C_data_types#stdint.h

[SeppJ]

knivil schrieb:

Ich frage mich gerade, was int_fast8_t fuer ein Datentyp sein soll. Gibt es auch einen int_slow8_t?

Verwirr doch die Leute nicht .

Für alle, die es wissen möchten:

C Standard schrieb:

The typedef name int_fastN_t designates the fastest signed integer type with a width of at least N. The typedef name uint_fastN_t designates the fastest unsigned integer type with a width of at least N.

[Phil222]

Tachyon schrieb:

Alternativ kannst Du MSVC auch einfach sagen, dass er keine Erweiterungen benutzen und sich standardkonform verhalten soll.

Ja, über http://msdn.microsoft.com/en-us/library/0k0w269d(v=vs.80).aspx

Aber ganz konform verhält er sich trotzdem nicht. Trotz /Za kann ich zum Beispiel eine std::exception direkt mit einem const char* füttern.

[knivil]

SeppJ schrieb:

Für alle, die es wissen möchten:

C Standard schrieb:

The typedef name int_fastN_t designates the fastest signed integer type with a width of at least N. The typedef name uint_fastN_t designates the fastest unsigned integer type with a width of at least N.

D.h. koennte auch ein 64 Bit Integer sein? Warum dann nicht einfach int ?

[Ethon]

knivil schrieb:

SeppJ schrieb:

Für alle, die es wissen möchten:

C Standard schrieb:

The typedef name int_fastN_t designates the fastest signed integer type with a width of at least N. The typedef name uint_fastN_t designates the fastest unsigned integer type with a width of at least N.

D.h. koennte auch ein 64 Bit Integer sein?

Jop

[cooky451]

Phil222 schrieb:

Ich muss sagen der g++ ist ziemlich kleinlich.

rofl, von der Seite hab ich das noch nie gesehen.

[Phil222]

cooky451 schrieb:

Phil222 schrieb:

Ich muss sagen der g++ ist ziemlich kleinlich.

rofl, von der Seite hab ich das noch nie gesehen.

Man könnte auch sagen pedantisch, kleinkariert oder haarspalterisch. Ein weiteres Beispiel.

Das funktioniert nicht:

window->foo(300, 200, std::string("Hallo"));
break;

Das funktioniert im g++:

std::string str("Hallo");
window->foo(300, 200, str);
break;

[camper]

Phil222 schrieb:

cooky451 schrieb:

Phil222 schrieb:

Ich muss sagen der g++ ist ziemlich kleinlich.

rofl, von der Seite hab ich das noch nie gesehen.

Man könnte auch sagen pedantisch, kleinkariert oder haarspalterisch. Ein weiteres Beispiel.

Das funktioniert nicht:

window->foo(300, 200, std::string("Hallo"));
break;

Das funktioniert im g++:

std::string str("Hallo");
window->foo(300, 200, str);
break;

Da wirst du das foo genauer angeben müssen, wenn das ein überzeugendes Argument werden soll.

[seldon]

Mit einiger Wahrscheinlichkeit fehlt da ein const zwischen string und & in der Funktionssignatur.

[Phil222]

camper schrieb:

Da wirst du das foo genauer angeben müssen, wenn das ein überzeugendes Argument werden soll.

Was für ein Argument?

[SeppJ]

Phil222 schrieb:

camper schrieb:

Da wirst du das foo genauer angeben müssen, wenn das ein überzeugendes Argument werden soll.

Was für ein Argument?

Das GCC pedantisch haarspalterisch sein soll. (Was er übrigens auch ist und das ist auch gut so!)

Wenn seldon nämlich Recht hat mit seiner Vermutung, dann wäre es praktisch unmöglich daraus korrekten Code zu generieren. Wenn ein nachsichtigerer Compiler diesen Fehler schluckt, dann hat man, falls es doch kein Fehler sondern Absicht war, Probleme zur Laufzeit. Super Sache.

knivil schrieb:

D.h. koennte auch ein 64 Bit Integer sein? Warum dann nicht einfach int ?

Weil an int eben teilweise andere Anforderungen gestellt sind als an die spezialisierten int-Typen. Ein uint_fast8_t könnte auf einem 8-Bit System schneller sein als int, welcher mindestens 16 Bit breit sein muss. Ein uint_fast64_t kann auf einem 32-Bit System langsamer sein als int, weil er größer sein muss als die optimale Wortbreite.

[knivil]

int, welcher mindestens 16 Bit breit sein muss

Jeder sagt irgendwie was anderes ...

[SeppJ]

knivil schrieb:

int, welcher mindestens 16 Bit breit sein muss

Jeder sagt irgendwie was anderes ...

Dann lies es eben selber im Standard nach (im Abschnitt über climits, welcher auf limits.h im C-Standard verweist, welcher konkrete Zahlen nennt) oder vertrau demjenigen, von dem du am ehesten annimmst, dass er den Standard kennt.

[knivil]

Ich habe nachgeschlage: Im C89 Standard ist UINT_MAX 65535. Wieso haelt sich niemand dran?

[Bashar]

knivil schrieb:

Ich habe nachgeschlage: Im C89 Standard ist UINT_MAX 65535. Wieso haelt sich niemand dran?

Da hast du dich verlesen. UINT_MAX ist mindestens 65535.