3. Typ size_t beim Überschreiben von new

Typ size_t beim Überschreiben von new

  • F

    Ich habe also new bei einer Klasse überschrieben. Soweit so gut. Nun meckert mich gcc voll das new einen Parameter vom Typ size_t (long unsigned int) erwartet und ich habe new mit nem Parameter vom Typ "unsigned int" deklariert.

    Ich weiß das "unsigned int" auf 32bit Architekturen 4Byte groß ist und auf 64bit Architekturen 8Byte und das "long unsigned int" immer 4Byte groß ist.

    Also da ich für 32bit kompiliere, dürfte er mir maximal ne Warnung geben, dass das Programm eventuell unter 64bit Probleme machen könnte, aber ich bekomme nen Error (clang sagt gar nichts dazu).
    Das nächste ist, wenn ich das mal als gegeben hinnehme (das new immer einen Parameter vom Typ "long unsigned int" bekommt) dann heißt das ja auch das auf einer 64bit Architektur keine Objekte größer 0xFFFFFFFF alloziert werden können. Was ich wiederrum nicht ganz verstehen kann.

    0
  • C

    Selbst wenn die Typen gleich groß sind, kann der Compiler sie trotzdem unterscheiden. (und außerdem ist nicht garantiert, daß unsigned long immer 4 Byte groß ist)

    0
  • F

    Ich dachte das "long unsigned int" immer 4Byte groß ist!?

    Was anderes, ist das nun ein "unsigned long" oder ein "unsigned int" und wenn es ein "unsigned long" ist, wozu dann das "int"?

    Der Grund warum clang++ keine Fehlermeldung (und nicht mal ne Warnung) gbt, muss ja auch seinen Grund haben?!

    0
  • V

    FlashBurn schrieb:

    Ich weiß das "unsigned int" auf 32bit Architekturen 4Byte groß ist und auf 64bit Architekturen 8Byte und das "long unsigned int" immer 4Byte groß ist.

    Ganz falsch.
    int ist immer 4 Byte.
    long 4 oder 8.
    (Außer man stellt es mit ungewöhlichen Compileroptionen um)

    Also ist long meistens passend. size_t erst recht.
    Wenn Du size_t nicht nehmen willst, nimm

    typedef decltype(sizeof(0)) Size;
    0
  • C

    FlashBurn schrieb:

    Ich dachte das "long unsigned int" immer 4Byte groß ist!?

    Nein, der Standard definiert nur Mindestgrößen für die Zahlentypen - der Compiler kann gerne größere Typen festlegen.
    (PS: und "unsigned long" ist eine Kurzschreibweise für "unsigned long int", die aber so beliebt ist, daß kaum jemand die Langversion verwendet)

    0
  • ?

    volkard schrieb:

    Wenn Du size_t nicht nehmen willst, nimm

    typedef decltype(sizeof(0)) Size;

    Das ist size_t 🙂

    0
  • V

    Du bist was du misst schrieb:

    volkard schrieb:

    Wenn Du size_t nicht nehmen willst, nimm

    typedef decltype(sizeof(0)) Size;

    Das ist size_t 🙂

    Ach? Das ist ja interessant.

    0
  • F

    @volkard

    Seit wann ist denn int immer 4Byte und long je nach Architektur? Ich habe es noch genau anders herum gelernt und vorallem woher weiß man wie der Compiler das nun sieht?

    @all

    Wie schalte ich diesen Fehler beim gcc aus (wenn ich weder size_t nutzen noch deklarieren will)?

    Edit::

    Jetzt weiß ich wieso clang nicht meckert. Für clang ist size_t "unsigned int" und für gcc "unsigned long int". Wer hat nun recht?

    0
  • C

    FlashBurn schrieb:

    @volkard

    Seit wann ist denn int immer 4Byte und long je nach Architektur? Ich habe es noch genau anders herum gelernt und vorallem woher weiß man wie der Compiler das nun sieht?

    Bei beiden Typen kann der Compiler die Größe festlegen (innerhalb der Grenzen des Standard). Wenn du wissen willst, was dein Compiler dazu sagt, schau dir mal den Header <limits.h> bzw. <climits> an.

    Wie schalte ich diesen Fehler beim gcc aus (wenn ich weder size_t nutzen noch deklarieren will)?

    Was spricht denn dagegen, size_t zu verwenden?

    0
  • V

    FlashBurn schrieb:

    @volkard
    Seit wann ist denn int immer 4Byte und long je nach Architektur? Ich habe es noch genau anders herum gelernt

    Zu meiner großem Enttäuschung haben sich die Entwickler von MSVC und GCC dahingehend geeinigt. Damit ist es so. Natürlich nicht laut Standard, der spezifiziert das gar nicht. Naja, ein bißchen schon, sizeof(long)>=sizeof(int) ist garantiert. Damit ist deine Theorie nach Standard falsch. Ich denke, Du hast da was verwechselt. Oder Bücher gemischt. Ein Buch wie "Microsoft C++ in 21 Tagen" in der Zeit, wo 64 Bit nicht in Sicht war und 16 Bit längst out, kann zum Beispiel gerne long auf 4 festlegen. Und beim Wechsel von 16 auf 32 war immer die Konstante, daß (unsigned)int so breit ist wie ein Register und deswegen der natürliche Typ für Schleifenlaufvariablen und Größenangaben.

    FlashBurn schrieb:

    und vorallem woher weiß man wie der Compiler das nun sieht?

    Mit sizeof nachschauen.

    FlashBurn schrieb:

    Wie schalte ich diesen Fehler beim gcc aus (wenn ich weder size_t nutzen noch deklarieren will)?

    unsigned long klappt. Vermutlich bis 128-bittige Prozessoren kommen, also biste sicher für die mächsten Jahrzehnte. Nee, Jahre, der Takt wird ja kaum noch höher gedreht, nur breiter wird alle gemacht.

    0
  • F

    Also im Endeffekt zeigt das mal wieder das weder C noch C++ wirklich plattformunabhängig sind und das es ohne den Compiler zu beachten nicht möglich ist bestimmten Code (z.B. die C++ Standard-Library) zu schreiben. Spricht nicht gerade für die Sprachen 😉

    Ich hasse es wenn man für jeden Compiler eigene Sachen definieren muss (solche ifdef´s machen den Code nicht gerade lesbarer). Wieso kann sowas nicht in dem Standard sein?

    0
  • E

    FlashBurn schrieb:

    Ich hasse es wenn man für jeden Compiler eigene Sachen definieren muss (solche ifdef´s machen den Code nicht gerade lesbarer). Wieso kann sowas nicht in dem Standard sein?

    Makros (und eben die dazugehörigen Anweisungen ( #undef , #ifdef , ...)) sind standardisiert.

    0
  • 3

    FlashBurn schrieb:

    Also im Endeffekt zeigt das mal wieder das weder C noch C++ wirklich plattformunabhängig sind

    Falsch. Das zeigt exakt das Gegenteil. Wäre im C++ Standard eine exakte Größe für Datentypen festgelegt, dann wird der Code auf bestimmten Mikroprozessoren nicht laufen. Du darfst eben nicht beide Sprachen als PC-Only Sprachen sehen, wie das z.B. bei Java der Fall ist. C/C++ ist mehr.

    FlashBurn schrieb:

    und das es ohne den Compiler zu beachten nicht möglich ist bestimmten Code (z.B. die C++ Standard-Library) zu schreiben. Spricht nicht gerade für die Sprachen 😉

    Naja, einen Code mit falscher Syntax wirst du wohl nicht unbedingt kompilieren wollen, oder?

    FlashBurn schrieb:

    Ich hasse es wenn man für jeden Compiler eigene Sachen definieren muss (solche ifdef´s machen den Code nicht gerade lesbarer). Wieso kann sowas nicht in dem Standard sein?

    Musst du nicht. Habe ich z.B. noch nie gebraucht. Aber stell dir vor, das gibts bereits. http://en.wikipedia.org/wiki/Stdint.h

    0

  • volkard schrieb:

    FlashBurn schrieb:

    @volkard
    Seit wann ist denn int immer 4Byte und long je nach Architektur? Ich habe es noch genau anders herum gelernt

    Zu meiner großem Enttäuschung haben sich die Entwickler von MSVC und GCC dahingehend geeinigt.

    Ich dachte immer bei MSVC sind int und long immer 4 Byte und long long immer 8, unabhängig von sizeof(void*) .

    Und nur bei GCC gilt sizeof(long) == sizeof(void*) ...

    Hat sich da was geändert?
    Dann müssten wir alle unsere Windows-Programme umschreiben 😞

    0
  • V

    hustbaer schrieb:

    Ich dachte immer bei MSVC sind int und long immer 4 Byte und long long immer 8, unabhängig von sizeof(void*) .

    Und nur bei GCC gilt sizeof(long) == sizeof(void*) ...

    Hat sich da was geändert?
    Dann müssten wir alle unsere Windows-Programme umschreiben 😞

    Hast recht.
    Hab auch falsche Bücher gelesen. 😞

    0
  • F

    314159265358979 schrieb:

    Wäre im C++ Standard eine exakte Größe für Datentypen festgelegt, dann wird der Code auf bestimmten Mikroprozessoren nicht laufen.

    Das musst du mir erklären.

    Ich sehe es genau umgedreht, wenn der Datentyp den ich gewählt habe mit einmal kleiner ist, dann läuft mein Programm auf der Architektur nicht mehr. Wären die Datentypen genau spezifiziert, gäbe es solche Probleme nicht (und wozu haabn C/C++ eigentlich mehrere Datentypen für den selben Zahlenbereich?).

    Es wäre viel besser wenn es für jeden Zahlenbereich genau einen Typen geben würde und der wäre genau festgelegt, da gäbe es dann keine Gründe warum man mit sowas aufpassen muss wenn ein Programm z.B. von 32bit auf 64bit portiert wird!

    314159265358979 schrieb:

    Du darfst eben nicht beide Sprachen als PC-Only Sprachen sehen, wie das z.B. bei Java der Fall ist. C/C++ ist mehr.

    Wieso sollt Java PC-only sein? Java läuft auf jeder Architektur wo man ne VM dafür hat (und ich möchte meinen auch schon was von Java auf Mikrokontroller gehört zu haben).

    314159265358979 schrieb:

    Habe ich z.B. noch nie gebraucht. Aber stell dir vor, das gibts bereits.

    Aber irgendjemand muss ja die Library schreiben. Zumal damit die "Standard"-Libraries nicht Compiler unabhängig sind (ohne die ifdef´s).

    Aber keiner konnte mir nun sagen wer recht hat (bezüglich welchen Typ von Parameter new erwartet) clang oder gcc?

    0
  • V

    FlashBurn schrieb:

    Aber keiner konnte mir nun sagen wer recht hat (bezüglich welchen Typ von Parameter new erwartet) clang oder gcc?

    Ähm, size_t und clang und gcc widersprechen sich dahingehend gar nicht?

    0
  • I

    Der Compilerbauer entscheidet selbst, welchen Typ operator new erwartet. Den musst du aber nicht wissen. Um platformunabhängigr Programme zu ermöglichen ist genau für diesen Typ ein typedef standardisiert: size_t .

    Die Intension, für die Standardtypen keine festen Größen vorzuschreiben, hat übrigens Performancegründe. So sollte int ursprünglich genau ein Maschienenregister groß sein, so dass es also Mittel der Wahl ist, wenn man im beschränkten Wertebereich optimal schnell rechnen will. Braucht man feste Größen gibt es immer noch int32_t , int32_least_t , int32_fast_t etc. Leider haben sich im Laufe der Zeit so viele Programmierer und Programme an sizeof(int) == 4 gewöhnt, das man aus Gründen der Abwärtskompatibilität unter x64 int nicht einfach auf 8 Byte setzen konnte.

    0
  • F

    @volkard

    Aber size_t ist unterschiedlich definiert und das dürfte ja eigentlich auch nicht sein, oder?

    Ich sags mal so, entweder ist der Standard nicht eindeutig genug oder die Compiler-Bauer machen mal wieder was sie wollen 😉

    Edit::

    @ipsec

    Den Typ den new erwartet muss ich spätestens dann wissen, wenn ich die Standard-Library auf eine andere Plattform portiere und/oder eine Compiler unabhängige Standard-Library schreiben will (gibt sicherlich noch mehr Gründe).

    0
  • V

    FlashBurn schrieb:

    @volkard
    Aber size_t ist unterschiedlich definiert und das dürfte ja eigentlich auch nicht sein, oder?

    Doch, das darf sein. Es ist absolut ok. In der Praxis gibt es keine Probleme damit. Es gibt nur Probleme, wenn man erwartet, daß size_t genau 4 Bytes hat und dann beim Compilerwechsel überrascht ist.
    Und natürlich, wenn man den ganzen Videofilm mit 3.7GB in einen std::vector stopfen will, was bei sizeof(size_t)==4 nicht klappen wird.

    0
  • V

    FlashBurn schrieb:

    Ich sags mal so, entweder ist der Standard nicht eindeutig genug oder die Compiler-Bauer machen mal wieder was sie wollen 😉

    It's not a bug. It's a feature.
    Der C++-Standard läßt ganz viele Sachen offen. Und allermeistens sogar mit voller Absicht.

    0
Anmelden zum Antworten