Library für große Zahlen

operator void

Auf den 64-bittern ist int AFAIK 32bit.

Ich habe ehrlich gesagt noch nie den Sinn hinter den C-Typen verstanden... Die sprechenden Namen könnten genauso gut in einem typedef-Header definiert werden, und dann würde highlevel auf lowlevel aufbauen - nicht andersrum...

Sehe ich das eigentlich richtig, dass es zukünftig von jedem Native-Code Programm mindestens 2 ausführbare Dateien gibt, eine für AMD64, eine für Itanium (und evtl. noch eine für x86 die nächsten paar Jahre)?

aber ansonsten erwarte ich von int, dass es der schnellste typ ist, long müsste etwas größer sein und short etwas kleiner.

Auf mich hört zwar keiner, aber sowas würde mir für die Zukunft gefallen:
byte, dbyte, short (32Bit), int (64Bit), long (128Bit)

Ich sollte mal an das Standardkomitee schreiben. Aber die wollen sich wahrscheinlich von ihrer Nicht-Festlegung gar nicht trennen.

SirLant

Optimizer schrieb:

aber ansonsten erwarte ich von int, dass es der schnellste typ ist, long müsste etwas größer sein und short etwas kleiner.

Auf mich hört zwar keiner, aber sowas würde mir für die Zukunft gefallen:
byte, dbyte, short (32Bit), int (64Bit), long (128Bit)

Ich sollte mal an das Standardkomitee schreiben. Aber die wollen sich wahrscheinlich von ihrer Nicht-Festlegung gar nicht trennen.

Natürlich werden sie das nicht wollen, wegen der Abwärtskompatibilität.

Finde die derzeitige Lösung bis jetzt nicht schlimm, hatte bisher noch keine Probleme damit.

rüdiger

der Standard schreibt doch eh nichts wegen der größen vor, außer die Verhältnisse.

Naja, ich wünsch mir einfach in C++0x ein stdint.h so wie es auch C99 hat und dann nimmt man wenn man ein 16Bit Signed Integer braucht einfach std::int16_t

operator void

Doch, durch die Makros aus <limits.h> werden Mindestgrößen impliziert. Ist zwar eh alles hypothetisch, aber immerhin kann so keine perverse Implementierung mit int=int8_t an so harmlosen Sachen wie "for (int i = 0; i < 500; ++i)" ersticken.

Solange die Datentypen keine feste Größe haben wird es immer so einen Schwachsinn wie INT, DWORD, ULONG und FLOAT geben. Geil.

Shade Of Mine

Optimizer schrieb:

Solange die Datentypen keine feste Größe haben wird es immer so einen Schwachsinn wie INT, DWORD, ULONG und FLOAT geben. Geil.

Weil die Leute zu dumm sin boost zu benützen - da kann man leider nix machen

Das war ja mal n richtig verständlicher Kommentar. Was ist bitte an int32_t schöner als an INT?
int32_t kannst du in die Schwachsinns-Liste aufnehmen. Nicht, weil es eine schlechte Idee ist, sondern, weil es Schwachsinn ist, dass man sowas braucht.

rüdiger

was willst du sagen?

warum sollte man nicht ein sigend integer der größe 32bit brauchen? Auch wenn int auf den meisten 32Bit Platformen 32Bit groß ist, aber es gibt mehr als nur IA32 und es gibt sogar Leute, die portable Software schreiben wollen

Shade Of Mine

Optimizer schrieb:

int32_t kannst du in die Schwachsinns-Liste aufnehmen. Nicht, weil es eine schlechte Idee ist, sondern, weil es Schwachsinn ist, dass man sowas braucht.

also ist int doch besser?
Was für Typen hättest du denn gerne?
int willst du ja nicht, oder doch? Oder soll ein int immer 32 Bit haben, nur darf er nicht int32 heissen?

Wenn mich die anzahl der bits interessiert, dann verwende ich ich gerne
int32_t oder uint64_t. Also ich brauche das schon.

kingruedi schrieb:

warum sollte man nicht ein sigend integer der größe 32bit brauchen?

Ist das so unverständlich? Ich habe festgestellt, dass man so Makros wie INT nicht brauchen würde, wenn die Größe der Datentypen festgelegt wäre. Daraufhin hat Shade gemeint, "jo mei, wenn die Leute kein boost verwenden..." obwohl das genau das selbe Prinzip wie bei INT ist.

Und wo habe ich bitte gesagt, dass man nie einen Typ mit einer bestimmten Größe braucht? Ich habe nur gesagt, dass es mich stört, dass man dafür solche Makros verwenden muss und dass ich es besser finden würde, wenn die Typen von Haus aus eine feste Größe hätten.

Shade Of Mine schrieb:

also ist int doch besser?

Der Name "int" ist besser. Aber darum geht es doch gar nicht. Ich habe gesagt, dass int32_t auch nicht schöner als INT ist.

Was für Typen hättest du denn gerne?

Welche mit einer festen Größe, damit man keine hässlichen Makros/Typedefs braucht.
Das hättest du dem Post

Solange die Datentypen keine feste Größe haben wird es immer so einen Schwachsinn wie INT, DWORD, ULONG und FLOAT geben.

ohne weiteres entnehmen können.

Shade Of Mine

Optimizer schrieb:

Ist das so unverständlich? Ich habe festgestellt, dass man so Makros wie INT nicht brauchen würde, wenn die Größe der Datentypen festgelegt wäre.

Was aber _unmöglich_ ist.

Daraufhin hat Shade gemeint, "jo mei, wenn die Leute kein boost verwenden..." obwohl das genau das selbe Prinzip wie bei INT ist.

also ein int32_t ist wohl besser als ein INT zumal wenn int und INT dann unterschiedliche größen haben

Und wo habe ich bitte gesagt, dass man nie einen Typ mit einer bestimmten Größe braucht? Ich habe nur gesagt, dass es mich stört, dass man dafür solche Makros verwenden muss und dass ich es besser finden würde, wenn die Typen von Haus aus eine feste Größe hätten.

Für mich ist boost Teil von C++.
Somit ist ein int32_t für mich Teil von C++

und ob int auf int32_t aufbaut oder umgekehrt ist doch egal.

Welche mit einer festen Größe, damit man keine hässlichen Makros/Typedefs braucht.

Wo ist der Unterschied?
int32_t ist ein Typ genau wie int
Du merkst den Unterschied nur daran, dass int im Standard steht, aber int32_t nicht.

Das hättest du dem Post

Solange die Datentypen keine feste Größe haben wird es immer so einen Schwachsinn wie INT, DWORD, ULONG und FLOAT geben.

ohne weiteres entnehmen können.

Ja, INT ist ja auch schwachsinn. int32_t ist sinnvoll. denn INT sagt genau NULL über den Typ aus.

Du scheinst C++ nicht zu verstehen:
wenn int _immer_ 32 bit haben müsste - dann _müsste_ ich typedefs verwenden.
Warum?
Weil ich sonst auf einer 128Bit maschine mit einem 32Bit Datentyp vielleicht viel zu langsam bin.

int ist immer ein schöner passender Typ für die Zielplattform.

Wenn mich die exakte größe interessiert - was sie des öfteren tut (aber eben nicht immer) dann verwende ich intXX_t

Wenn sie mich aber nicht interessiert - und ich einfach nur einen schnellen Datentyp brauche - wie zB bei einem loop von 0 bis 100 - dann nehme ich int.

Stell dir mal vor int hätte 64Bit und ich lasse so einen loop auf einer 16Bit maschine laufen. Der loop wäre hoffnungslos ineffizient.

sicher, ich könnte int8fast_t verwenden - aber sowas artet dann aus.

ich finde das system gut so wie es ist.

int ist so schön HighLevel - genau so wie ich es mag. Wenn ich es genauer will, muss ich low Level gehen und boost::* verwenden.

Dass LowLevel auf HighLevel aufbaut und nicht umgekehrt, braucht mich ja nicht zu interessieren.

SideWinder

Für mich ist boost Teil von C++.
Somit ist ein int32_t für mich Teil von C++

Hmm

Weil die Leute zu dumm sin boost zu benützen - da kann man leider nix machen

Du kannst WinAPI-C-Programmierern nicht vorschreiben, dass sie auch mit Boost arbeiten müssen. Abgesehen davon, dass in reinem C sowieso fast nichts von Boost funktioniert.

MfG SideWinder

Shade Of Mine

SideWinder schrieb:

Du kannst WinAPI-C-Programmierern nicht vorschreiben, dass sie auch mit Boost arbeiten müssen. Abgesehen davon, dass in reinem C sowieso fast nichts von Boost funktioniert.

Tja, dafür gibts in C ja stdint.h
Ich verwende die boost Typen ja nur, weil C++ eben kein cstdint hat

Das klingt schon alles logisch... aber die Sache hat noch einen Haken:

int ist immer ein schöner passender Typ für die Zielplattform.

Wie wir ja schon einige Posts vorher weiter festgestellt haben, ist das eben nicht der Fall. int wird bei VC++ weiterhin 32Bit haben. Auch wenn du für 64Bit compilierst. Nur das long ändert sich. Das ist natürlich jetzt Compiler-spezifisch, aber das ist doch schon wieder nur ein weiterer Punkt, wo die Portabilität des Source-Codes dahin ist.

Und da ist eben das Problem: Es ist nicht so wie du sagst, dass int immer schön schnell ist und wenn man ne bestimmte Größe braucht, kann man die Typen aus boost verwenden.

Andererseits ist es auch nicht so, dass int immer eine bestimmte Größe hat, egal ob passend für die Zielplattform oder nicht.

Und portabel ist es jetzt eben auch nicht, sondern es ist ein totales Durcheinander und letztlich nur vom Compiler abhängig. Und dieses Chaos nützt keinem was. Das hat mit "C++ verstehen" nichts zu tun, wenn jeder Compilerhersteller das wieder anders machen kann und ganz offensichtlich kein schlaues System dahinter steckt, so wie viele es machen (man denke nur daran, dass int und long beim VC++ gleich groß sind).

SideWinder

Shade Of Mine schrieb:

SideWinder schrieb:

Du kannst WinAPI-C-Programmierern nicht vorschreiben, dass sie auch mit Boost arbeiten müssen. Abgesehen davon, dass in reinem C sowieso fast nichts von Boost funktioniert.

Tja, dafür gibts in C ja stdint.h
Ich verwende die boost Typen ja nur, weil C++ eben kein cstdint hat

Gut das meine WinAPI-Implementation dem C99-Standard entspricht

MfG SideWinder

rüdiger

naja, aber die WinAPI verbietet es ja nicht, dass du stdint.h inkludierst oder die hässlichen typedefs mit deinen eigenen austauschst

typedef INT int32_t;

man muss ja auch nicht diesen UN Müll da schlucken (PSTRING ist das nochmal char** oder char* ;))

Shade Of Mine

Optimizer schrieb:

Und da ist eben das Problem: Es ist nicht so wie du sagst, dass int immer schön schnell ist und wenn man ne bestimmte Größe braucht, kann man die Typen aus boost verwenden.
Andererseits ist es auch nicht so, dass int immer eine bestimmte Größe hat, egal ob passend für die Zielplattform oder nicht.

Warum?
Erklär mir das mal genau.

Die boost::* Typen haben eben fixe Größe - also genau das was du willst. Was stört dich an ihnen?

wenn jeder Compilerhersteller das wieder anders machen kann und ganz offensichtlich kein schlaues System dahinter steckt, so wie viele es machen (man denke nur daran, dass int und long beim VC++ gleich groß sind).

Können != tun

Wo ist das Problem wenn int==long ist? Ausser das der Typ long dadurch den sinnlos verschwendet ist?

Warum?
Erklär mir das mal genau.

In meinen Augen würde zwei Ansätze Sinn machen:

1.) int ist immer der schnellste Typ. Das hast du auch behauptet. Stimmt aber leider ab 64 Bit dann nicht mehr. (Außer ein paar Compiler machen das, aber ich denke mal, die meisten nicht).
2.) int hat immer z.B. 32 Bit. Das stimmt sowieso nicht, das wissen wir ja.

Es geht jetzt nicht um boost. Es geht darum, inwiefern die eingebauten Typen sinnvoll definiert sind. Schön, dass es Dinge wie boost oder ULONG_PTR ( ) gibt, aber noch viel schöner wäre es, wenn die eingebauten Typen eine feste Größe hätten und man keine hässlichen typedefs brauchen würde. Und wenn es schon nicht so ist, dann hätte man wenigstens den Vorteil nutzen können, int immer zum schnellsten Typen zu machen, was aber auch nicht der Fall ist.

Wo ist das Problem wenn int==long ist? Ausser das der Typ long dadurch den sinnlos verschwendet ist?

Das sehe ich als Problem. Und weiter sehe ich es noch als Problem "long long" zu schreiben. Potthässlich. Dann doch lieber __int64, am besten mit typedef __int64 int64.