Library für große Zahlen

[Shade Of Mine]

groovemaster2002 schrieb:

Ist das so? Fänd ich irgendwie net richtig. Immerhin gibts für 64 bit Integer doch long long (naja zumindest bei C99).

Wozu wäre dann long gut?
Ich würde sagen: long sollte 64bit sein und long long 128bit

wobei int 64bit auch vernünftig wäre - int sollte einfach der schnellste datentyp bleiben - je nachdem was die CPU halt am besten kann.

[SideWinder]

int == schnellster Datentyp (wäre dann meistens int32)
int8, int16, int32, int64, int128

Eine striktere Haltung mit den Größen von Typen würde imho C++ ganz gut tun, wär was für C++0x [in manchen Kreisen ja bereits C++1x :p]

MfG SideWinder

[japro]

groovemaster2002 schrieb:

Shade Of Mine schrieb:

Naja, ich verwende jetzt einfach long double - das muss reichen.

Wobei long double meines Wissens nach zumindest auf Win32 Plattformen die gleiche Auflösung wie double hat.

also bei mir winme+mingw(gcc) ist sizeof(double)=8 und sizeof(long double)=10 was im prinzip auch den formaten entspricht die von der x86 fpu unterstütz werden.

[groovemaster]

japro schrieb:

also bei mir winme+mingw(gcc) ist sizeof(double)=8 und sizeof(long double)=10

Kommst etwas spät. SideWinder hat mich ja bereits korrigiert.

SideWinder schrieb:

Eine striktere Haltung mit den Größen von Typen würde imho C++ ganz gut tun

Seh ich genauso.

Shade Of Mine schrieb:

Wozu wäre dann long gut?

Für 32 bit.

Shade Of Mine schrieb:

Ich würde sagen: long sollte 64bit sein und long long 128bit

Was machst du dann, wenn die 128 bit Prozessor Generation kommt? Wieder alles im eins nach vorn schieben? Da bekommst du dann irgendwo ne Lücke.

[Shade Of Mine]

groovemaster2002 schrieb:

Was machst du dann, wenn die 128 bit Prozessor Generation kommt? Wieder alles im eins nach vorn schieben? Da bekommst du dann irgendwo ne Lücke.

so macht man es in C++

oder willst du dann einmal ein
long long long long long long
haben?

wenn ich wirklich die typen nach bits verwenden will - dann verwende ich zB die boost typedefs

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

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

[Gast]

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

[Gast]

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.

[Gast]

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

[Gast]

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.

[Gast]

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