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.

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

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;

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)

Wenn Du size_t nicht nehmen willst, nimm

typedef decltype(sizeof(0)) Size;

Das ist size_t

volkard schrieb:

Wenn Du size_t nicht nehmen willst, nimm

typedef decltype(sizeof(0)) Size;

Das ist size_t

Ach? Das ist ja interessant.

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?

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

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

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?

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.

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

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

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.

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?

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?

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.

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

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

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.

@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

Nicht die Compiler-Bauer, sondern die CPU-Bauer size_t ist so definiert, daß er auf deiner Zielplattform jede plausible Größenangabe aufnehmen kann, die das System hergibt.

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

Auf Quellcode-Ebene kannst du eine ANSI-konforme Library überall hinportieren, wo du einen vernünftigen C++ Compiler zur Verfügung hast. Auf Binär-Ebene hast du vermutlich ganz andere Probleme, weil Plattform 1 womöglich nichts mit dem Maschinencode anfangen kann, den du für Plattform 2 erzeugt hast.

Und welchen Typ new erwartet, ist im Standard genau festgelegt - es ist *trommelwirbel* size_t

In der Praxis gibt es keine Probleme damit.

Nur wenn ich das weiß und size_t entsprechend mit ifdef´s für den jeweiligen Compiler definiere.

Als Bsp. sei mal ein Kernel genannt, ich werde bei einem Kernel nicht die Standard-Library vom Compiler nehmen (kann ich ohnehin nicht, jedenfalls nicht so einfach), sondern entweder meine eigene schreiben oder nur das schreiben, was ich brauche (oder halt entsprechend anpassen).

Sicherlich bindet man sich gerade mit nem Kernel doch sehr stark an den Compiler, aber wenn du ihn wechselst und mit einmal feststellen musst, das der Kernel nicht mehr läuft oder kompiliert werden kann, weil die Typen nicht eindeutig definiert sind, sehe ich das als failure-by-design an.

Anderes Bsp. wären Mikrokontroller. Ich will dort auch new nutzen (als Bsp.) und dort nehme ich bestimmt keine Standard-Library sondern, werde eigenen Code nutzen und muss wieder aufpassen was der Compiler nun erwartet.

Das sind Probleme die man vllt nicht auf der PC-Plattform hat, aber wenn man mal über den Tellerrand guckt, wird man feststellen, dass es einige solcher Probleme gibt und eigentlich wurden C und C++ doch genau damit angepriesen das sie Plattform/Hardware unabhängig seien.

typedef decltype(sizeof(0)) Size;

längst gelöst. Sogar zufällig ohne #ifdef. Und rede nicht vom Tellerrand.

Ich sehe auch dein Problem nicht. Systeme sind unterschiedlich und erfordern unterschiedlichen Code. Das man trotzdem mit C++ platformunabhängig programmieren kann, liegt daran, weil die Bibliotheken, allen voran die Standardbibliothek, für die verschiedenen Systeme portiert sind und systemabhängige Funktionen unter einem einheitlichen Interface kapseln.
Bei Java muss eben für jedes System die JVM portiert werden, bei C++ die Standardbibliothek. Das hat nichts mit Failure-by-Design zu tun.

Hab ich doch mit ...

Das muss ich irgendwie überlesen haben

Kannst du mir mal erklären was das genau bedeutet bzw. was da genau passiert? Vorallem wie daraus dann sowas wie "unsigned int" oder "unsigned long" wird.