Bei meinen Versuchen mit größeren (Zufalls-) Zahlen ist mir folgendes aufgefallen :
http://img5.imagebanana.com/view/055a5wfb/ULongUInt.dib

Die Varable L (unsigned long) müsste größer sein als die Variable I (unsigned int), da ich beiden den größtmöglichen Wert für ihre Typen (ulong: 0xffffffffffffffff, uint: 0xffffffff, LIMITS.h) zugewiesen hab, sie haben aber beide den gleichen Wert. Und warum gibt der Debugger mir keinen Fehler in Zeile 9 aus, in der der Varialbe I ein größerer Wert zugewiesen wird, als sie aufnehmen kann.
Ich weiß nicht ob das wichtig ist aber egal: Ich benutze noch die Beta von Windows 7(Evaluierungskopie Build 7100).

MfG Icon

Die Varable L (unsigned long) müsste größer sein als die Variable I (unsigned int) [...]

Nein, müsste sie nicht. Der C++-Standard erlaubt durchaus, dass unsigned long und unsigned int die selbe Grösse besitzen.

Icon² schrieb:

[...] da ich beiden den größtmöglichen Wert für ihre Typen (ulong: 0xffffffffffffffff, uint: 0xffffffff, LIMITS.h) zugewiesen hab

Wenn du <limits.h> inkludierst (korrekt wäre eigentlich <climits> , C++-Standardheader besitzen keine Dateiendung), solltest du auch die Makros einsetzen und nicht mit Literalen wie 0xffffffff hantieren...

Was heißt "Literale" ?

Literale nennt man temporäre Objekte, deren Wert du gleich in den Code schreibst. Beispiele:

"hallo" // Stringliteral
77ul    // unsigned long-Literal
2.5     // double-Literal
false   // bool-Literal

Icon² schrieb:

Ich hab halt L = 0xFF..... geschrieben, wobei ich die selbe Anzahl an Fs genommen habe wie in LIMITS.H.

Was denkst du, wofür der Header ist? Sicher nicht, um dessen Inhalt abzuschreiben.
Benutze wie gesagt die dort definierten Makros. Welche das sind, findest du zum Beispiel auf www.cplusplus.com heraus.

Icon² schrieb:

Ja ich weiß dass der C++ Standard nur vorschreibt dass der Werte Brereich einer unsigned long größer oder gleich groß wie der Werte Bereich einer unsinged int.
Aber ich benutze Windows 7 x64 und MSVC++ und dann müsste unsigned long doch eigentlich um den wert aus LIMITS.H größer sein, oder nicht?

Müsste nicht, das ist wiederum compilerabhängig. Nur weil du ein 64-Bit-System verwendest, heisst das noch nicht, dass long 64 Bit gross sein muss (es ist allerdings wahrscheinlicher). Eventuell kannst du die Grösse in der IDE konfigurieren (soviel ich weiss, kannst du zumindest einstellen, ob du für 32 oder 64 Bit kompilierst).

Ansonsten benutze den Typen unsigned long long , dieser ist allerdings nicht im C++-Standard enthalten.

Sonst empfehle ich immer wieder gerne die Seite Integer Types in C and C++.

Ansonsten benutze den Typen unsigned long long , dieser ist allerdings nicht im C++-Standard enthalten.

Oder von <boost/cstdint.hpp> den Typalias boost::uint_least64_t wenn man mindestens 64 Bits braucht.

<Korinthenkacker-Mode>
Mit Ausnahme von String-Literalen sind Literale keine Objekte nach C++ Standard-Definition von "Objekt".
</Korinthenkacker-Mode>

Und wie kommst du darauf, das Stringliterale, die in C++ den Typ char* haben,
Objekte wären und das Floatliteral 4.5f kein Objekt?

Wenn schon, dann richtig

<Korinthenkacker-Mode>
Mit Ausnahme von String-Literalen sind Literale keine Objekte nach C++ Standard-Definition von "Objekt".
</Korinthenkacker-Mode>

Stimmt, ich dachte gerade nicht mehr daran, dass skalare RValues ja speziell behandelt werden...

branleb schrieb:

Und wie kommst du darauf, das Stringliterale, die in C++ den Typ char* haben,
Objekte wären und das Floatliteral 4.5f kein Objekt?

Wenn schon, dann richtig

Das gilt auch für dich. Stringliterale haben den Typ const char[size] .

branleb schrieb:

Und wie kommst du darauf, das Stringliterale, die in C++ den Typ char* haben,
Objekte wären und das Floatliteral 4.5f kein Objekt?

Wenn schon, dann richtig

Das gilt auch für dich. Stringliterale haben den Typ const char[size] .

Verdammt - hast recht ...

Sebastian Pizer schrieb:

<Korinthenkacker-Mode>
Mit Ausnahme von String-Literalen sind Literale keine Objekte nach C++ Standard-Definition von "Objekt".
</Korinthenkacker-Mode>

Und wie kommst du darauf, das Stringliterale, die in C++ den Typ char* haben,

Hamse nicht. String-Literale sind Lvalue-Ausdrücke vom Typ const char[N] , wobei N die Zahl der Zeichen (inklusive Nullterminator) sind. Alle anderen Literale sind Rvalue-Ausdrücke skalarer Typen. Die Definition von "Objekt" kann man in Abschnitt 1.8 nachlesen:

The constructs in a C++ program create, destroy, refer to, access, and manipulate objects. An object is a region of storage. An object is created by a definition, by a new-expression or by the implementation when needed. [...]

Und dann gibts noch Abschnitt 3.10:

Every expression is either an lvalue or an rvalue.

An lvalue refers to an object or a function. Some rvalue expressions -- those of class or cv-qualified class type -- also refer to objects. [...]

Und dann gibts noch Abschnitt 5.1

[...]
A literal is a primary expression. Its type depends on its form. A string literal is an lvalue; all other literals are rvalues.
[...]

Ob man jetzt skalare Rvalues als "Objekte" bezeichnen kann .... naja, das ist zumindest eine Grauzone, würde ich sagen.

Gruß,
SP

unsigned int I = UINT_MAX;           // ==> 4294967295
unsigned long L = ULONG_MAX;         // ==> 4294967295
unsigned long long LL = ULLONG_MAX;  // ==> 18446744073709551615

Das heißt, dass bei meinem MSVC++ Compiler "long" = "int" ist.

unsigned int I = UINT_MAX;           // ==> 4294967295
unsigned long L = ULONG_MAX;         // ==> 4294967295
unsigned long long LL = ULLONG_MAX;  // ==> 18446744073709551615

Das heißt, dass bei meinem MSVC++ Compiler "long" = "int" ist.

Kommt drauf an, was Du damit meinst. long int und int sind zwei verschiedene Typen. Du kannst zB Funktionen mit ihnen überladen oder sie als Template-Parameter benutzen. vector<int> und vector<long> sind dementsprechend auch zwei verschiedene Typen. long ist also niemals ein "typedef" (Alias) für int.

Das heißt, dass bei meinem MSVC++ Compiler "long" = "int" ist.

Von solchen "Annahmen" sollte man grundsätzlich die Finger lassen, das geht irgend wann schief. Denn im 32Bit und im 64Bit Modus sind die die Typen unterschiedlich definiert, d.h. was im 32Bit Modus gültig ist, muß im 64Bit Modus längst nicht gültig sein.

Denn im 32Bit und im 64Bit Modus sind die die Typen unterschiedlich definiert, d.h. was im 32Bit Modus gültig ist, muß im 64Bit Modus längst nicht gültig sein.

Und von Compiler zu Compiler kann es ebenfalls unterschiedlich sein...