Library für große Zahlen

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.

rüdiger

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

long ist glaube ich immer der schnellste Integer Typ.

btw. ist zB. auf IA64 Systemen int AFAIK 64Bit groß

SirLant

Nehmen wir an wir haben ein Projekt 'x' welches einmal für 32Bit und einmal für 64Bit
kompiliert werden soll, dann macht man für die 64Bit Version doch einfach:

#ifdef 64_BIT_VERSION
#define int __int64
#endif

__int64 ersetzt man dann durch den 64Bit Typ

Ich bin mir ziemlich sicher, dass die Typen nicht ohne Grund _keine_ fixe Größe haben.

rüdiger

@Sirlant
oder nimmt einfach boost bzw. stdint.h in C

(btw. wegen der __)

Shade Of Mine

Optimizer schrieb:

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

int muss nicht der schnellste sein - er muss passend sein.

2.) int hat immer z.B. 32 Bit. Das stimmt sowieso nicht, das wissen wir ja.

Exakt - das habe ich als Vorteil hingestellt. Und dein Argument dagegen ist...?

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.

*grml*
Ich wiederhole mich.
Was ist an typedefs schlecht?

In C++ ist int nun mal ein high level konstrukt

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.

Das wäre ungut, weil der schnellste Typ nunmal nicht passend sein muss.
zB könnte der schnellste Typ ein 1 Byte typ sein - das wäre aber nicht passend, weil der Typ zu klein 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.[/quote]
Ja, wenn du long long nicht magst, kann niemand was dafür.

Warum long nicht 64bit hat, weiss ich nicht. aber da alle Compiler es so machen, nehme ich an, dass es einen Grund gibt.

zB ist kings Argument mit long ist der schnellste int Typ recht gut, bzw. einleuchtend.

int muss nicht der schnellste sein - er muss passend sein.

Definiere "passend"... "Der Wortbreite entsprechend" trifft jedenfalls nicht zu.

Exakt - das habe ich als Vorteil hingestellt. Und dein Argument dagegen ist...?

Ich habe kein Argument dagegen genannt und das habe ich auch nicht vor. Aber du hast als Vorteil definiert, dass int dadurch der "passendste" Typ für die Maschine ist, was nicht stimmt. d.h. man hat weder die Vorteile einer festen Größe genutzt noch die Vorteile des immer passenden. Das habe ich bemängelt.

Das wäre ungut, weil der schnellste Typ nunmal nicht passend sein muss.
zB könnte der schnellste Typ ein 1 Byte typ sein - das wäre aber nicht passend, weil der Typ zu klein ist.

Aha und wie soll das gehen, dass ein byte auf einem 64 Bit Prozessor der schnellste Typ ist?

Ja, wenn du long long nicht magst, kann niemand was dafür.

Da habe ich natürlich kein Argument dagegen. Wenn dir das lieber ist (oder dir zumindest egal ist), dass man statt "long" "long long" schreiben muss, weil long nicht genutzt wird, was soll ich dazu sagen?

Warum long nicht 64bit hat, weiss ich nicht. aber da alle Compiler es so machen, nehme ich an, dass es einen Grund gibt.

Ich nehme mal an, dass es eine Fehlentscheidung war, vorausgesetzt, ich bekomme keinen einleuchtenden Gegengrund zu hören...
Ich lass mich ja gerne überzeugen, aber "das wird schon seine Gründe haben" leuchtet mir nicht ein. :p
Weil es hat auch sicher seine Gründe, dass die meisten anderen Sprachen es anders handhaben.

SirLant

Dir ist bewusst, dass int im Grunde nur ne Abkürzung ist?
Denn es gibt den short int und den long int, welche man wiederum
kurz als short und long schreiben kann. Für welche der beiden int
steht ist dem Compilerbauer überlassen.