int_fast8_t cannot be overloaded



  • Hallo!

    Ich versuche gerade ein C++ Projekt unter Linux zu kompilieren und das kostet mich so einige Nerven, da der g++ nicht ansatzweise so freundlich ist, wie der MSVC 2010 Compiler.

    Nachdem ich schon einige Fehler beseitigt habe, meckert der Compiler nun bei einigen Überladungen.

    operator>>(int_fast8_t&)
    

    Alle Überladungen haben int_fast8_t als Datentyp. Ich dachte der Datentyp wäre in der cstdint als char festgeschrieben? Über int8_t beschwert sich der g++ komischerweise nicht. 😕



  • Hat sich erledigt. Ich habe das Ganze jetzt einfach durch char ersetzt.

    Ich muss sagen der g++ ist ziemlich kleinlich. Von Template Spezialisierungen bis hin zum Member Scope und std::exception musste ich zahlreiche Stellen abändern, damit der Code unter beiden Compilern durchgezogen wird.

    Von wegen ANSI C++ ...

    Es erstaunt mich was der MSVC so alles durchlässt, wo der g++ streng bleibt. 🙄



  • 1. Sicher dass dein Operator binär ist und an linker Stelle ein user-defined Typ steht? Dann kompiliert der GCC es auf jeden Fall.
    2. Klar, der MSVC ist ne Katastrophe. Sei doch froh dass der GCC mal aufräumt. Einen Code zu schreiben, der ohne Murren von mehreren Compilern geschluckt wird, ist auch eine tolle Strategie um möglichst korrekten Code zu schreiben.
    Jetzt ruf noch den GCC mit "-Wall -Wextra -Weffc++ -pedantic" auf und du hast aufgeräumt. 😉



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



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



  • 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


  • Mod

    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.



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



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



  • 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



  • Phil222 schrieb:

    Ich muss sagen der g++ ist ziemlich kleinlich.

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



  • 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;
    

  • Mod

    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.



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



  • camper schrieb:

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

    Was für ein Argument?


  • Mod

    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.



  • int, welcher mindestens 16 Bit breit sein muss

    Jeder sagt irgendwie was anderes ...


  • Mod

    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.



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



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


Anmelden zum Antworten