int oder INT

Artchi

Was heißt es darf nicht gehen? Es ist halt einfach ein selbst definierter Typ, machen wir hier schliesslich alle tag täglich. Schau einfach mal wo INT definiert ist, und das kannst du auch in jedem anderen Compiler übernehmen, wenn es dort fehlt. Die WinAPI macht schliesslich kein Voodoo.

FireFlow

Ich meinte es darf nicht gehen ohne das der Typ definiert ist weil da c/c++ genau unterscheidet.

hallo
also ich bin für int(klein).
bin in einem tutorial drüber gestolpert, wo in einem beispiel viele fehler
gemeldet wurden, sich der compiler sich aber nicht über INT und LONG
beschwerte.
ist in dem beispiel nicht selbstdefiniert, denke aber, dass der ursprung
in billy's softwareschmiede liegt wegen WORD und DWORD. sucht dies mal
in eueren c oder c++ büchern. die meisten windofs-compiler mögens.

ich hab auch schon header-files modifiziert. aber in einem tutorial wie
stehts da mit mit dem lernerfolg, wenn der z.b. erste quelltext den
compiler als begrüssung schon mit einer umfangreichen fehlermeldung beglückt.
na gut eventuell packt mich dann der ergeiz und ich versuch die fehlerliste
zu schreddern.
aber müssen bei standarttutorials so umfangreiche fehlermeldungen sein?
okay bei sonderlösungen kann man's akzeptieren, wenn dies den code extrem
übersichtlicher macht. dann sollte aber auch der compiler genannt werden.

mfg f.-th.

nachtrag
frage wegen einiger antworten: dies ist doch ein allgemeines c/c++ forum
oder ein windows- c/c++ forum?

mfg f.-th.

Artchi

Also erstmal, das was die Microsofties mit INT, DWORD usw. gemacht haben ist richtig und sogar gut! Sich darüber herab lassend zu äußern ist also fehl am Platz. Denn mit den INT, WORD, DWORD usw. bessert man den fehlenden Standard in C++ aus, das die bit-Größe von int, long usw. nicht definiert ist. D.h. auf einem 64-Bit-System ist INT genauso groß wie auf einem 32-Bit-System. Wenn der Source also mal unter einem anderen System compiliert wird, wo sich die Typen in der Größe ändern, muß man nur einmal kurz die typedefs ändern, und gut ist.

Anstatt das du überall das INT durch ein int ersetzt, solltest du vielleicht lieber einmal ein

typedef int INT;

schreiben, wenn es bei dir fehlt.

Recht hast du aber, das ein Tutorial für C++ schon mit den eingebauten Typen arbeiten sollte. Ein Anfänger kann das schlecht wissen.

FireFlow schrieb:

Ich meinte es darf nicht gehen ohne das der Typ definiert ist weil da c/c++ genau unterscheidet.

OK, du meinstest die Groß-Kleinschreibung wird unterschieden? Das stimmt natürlich.

Das INT typedef wird aber sehr sehr selten genutzt in der WinAPI. Die anderen die du genannt hast werden aber häufig eingesetzt.

hallo
also die meisten c/c++ compiler die für windows geschrieben wurden sollten
dies ohne typedef können.
ich hab jetzt nicht nachgesehen wo's unter win32 steht aber bei win16 stand
die beschreibung in den windows-help-files und nicht in den compiler- spezifischen.
ich könnt mir aber vorstellen bei einem grösseren projekt INT und int
und je nach compiler oder typdef unterschiedlich definiert, da kommt freude
auf. oder wie?

Normal nimmt das auch kein windows-compiler, so lange du nicht windows.h inkludierst, oder den entsprechenden header der den Typ definiert.

Und wenn du nen windows-spezifisches Tutorial durchmachst ist es doch klar, dass es windows-spezifischen code hat.

groovemaster

b schrieb:

Das INT typedef wird aber sehr sehr selten genutzt in der WinAPI. Die anderen die du genannt hast werden aber häufig eingesetzt.

Nun, eigentlich ist INT ja auch ein bisschen sinnlos. int ist nunmal int, egal ob du jetzt ein gross geschriebenes Typ-Alias definierst oder nicht. Es macht keinen Sinn, INT anders zu definieren, zB

typedef long INT;

Was anderes ist es zB mit WORD, DWORD, INT32 etc.

Aber um mal auf die ursprüngliche Frage zurückzukommen, Standard Compiler kennen die grossgeschriebenen Typen natürlich nicht. Und auch andere Compiler werden das wohl kaum anbieten, da MS genau festgelegt hat, wo jeder Typ definiert wird. Nachzulesen im MSDN unter "Windows Data Types".

wird sich INT nie ändern?????

groovemaster

Keine Ahnung, aber die Chancen sind ziemlich gut, dass auch auf zukünftigen Plattformen INT mit

typedef int INT;

definiert wird.

hallo
also ausser den ms-compilern kommt mindestens der free bcc5.5 mit INT und int
klar. ich vermute auch die c/c++-compiler von watcom und symantec/digital mars.
hab die beiden letzten aber noch nicht getestet.
artchi schrieb ( 2. beitrag) der wertebereich von INT ist bei den ms-compilern
ist gleich egal ob 16, 32 oder 64 -bit compiler - int ist aber "bit-gebunden".
wenn das stimmt typedef = noch grösseres chaos. aber wie heisst es nur genies
beherschen das chaos.

habe mal vor einiger zeit einen dbase3-headerstruct (geschrieben für 16bit)
mit sizeof(headergrösse) gecheckt: ergebnis je nach compiler 32 bis 37 byte
gross! ursache asser int( 16 oder 32 bit) -> char wird eventuell von den
compilern im selben quelltext unterschiedlich optimiert (8, 16 oder 32 bit)

einen 64-bit compiler hab ich noch nicht getestet.

mfg f.-th.

groovemaster

f.-th. schrieb:

also ausser den ms-compilern kommt mindestens der free bcc5.5 mit INT und int
klar.

Kann ich nicht bestätigen.

Undefined symbol 'INT' in function main()

getestet mit Borland C++ 5.5.1 Compiler

f.-th. schrieb:

artchi schrieb ( 2. beitrag) der wertebereich von INT ist bei den ms-compilern
ist gleich egal ob 16, 32 oder 64 -bit compiler - int ist aber "bit-gebunden".

Weiss zwar nicht, was du mit "bit-gebunden" meinst, aber INT war schon immer ein int Alias (afaik). Unter DOS (16 Bit) war int auch 16 Bit, unter Win32 und Win64 ist int 32 Bit gross. So gross ist das Chaos also gar nicht.

f.-th. schrieb:

habe mal vor einiger zeit einen dbase3-headerstruct (geschrieben für 16bit)
mit sizeof(headergrösse) gecheckt: ergebnis je nach compiler 32 bis 37 byte
gross! ursache asser int( 16 oder 32 bit)

Für sowas nimmt man eben spezielle typedefs, zB int32. Damit ist sichergestellt, dass unabhängig von Compiler oder Plattform der Typ immer gleich gross ist. Zudem sollte man auf Alignment achten.

@groovemaster: ich hab meine c/c++ compiler auf einem anderen rechner.
deswegen kann ich jetzt nicht meine sub-sub-version (bcc5.5.?) nachsehen
aber windows-headerfile einbinden und dann INT no errors und no warnings.
oder hast du mit deinem bcc5.5 noch keine windows-api-exe erstellt?

und zur grösse von int 16-bit-umgebung ist klar, 32-bit auch noch aber bei
64-bit soll es nach den info's aus dem netz so sein das einige compiler
meinen int sei 32 bit und andere int sei 64 bit.

und zur dbase3-header-struct: ich wollte weitgehend compiler-unabhängige
quelltexte erstellen, denn welcher 16-bit-compiler kennt schon int32, da
eignet sich schon eher short.

aber das eigentliche problem waren die unterschiedliche interpretation
von char im selben quelltext mit dem selben compiler(verschiedene hersteller
zeigten diesen effect).
aber ich hab's inzwischen nachgelesen char ist mindestens 8bit breit, kann
z.b. auf 32bit systemen auch 16bit oder 32bit breit sein. jenach position
im quelltext wird dies von 32bit systemen entsprechend interpretiert. ich
hab das system noch nicht erkannt. andere getestete compilerschalter brachten
noch keinen erfolg. vielleicht find ich ja noch die passende kombination.

mfg f.-th.

nillable

f.-th. schrieb:

aber windows-headerfile einbinden und dann INT no errors und no warnings.

Also unterstützt der Compiler nicht INT, sondern typedef.

groovemaster

f.-th. schrieb:

aber windows-headerfile einbinden und dann INT no errors und no warnings.

Compilerunterstützt bedeutet immer nativ, also ohne externe Definitionen. Wenn du irgendwelche Headerdateien einbindest, dann ist klar, dass dem Compiler der Typ dadurch bekannt ist. Das ist bei anderen Compiler naber genauso.

f.-th. schrieb:

und zur grösse von int 16-bit-umgebung ist klar, 32-bit auch noch aber bei
64-bit soll es nach den info's aus dem netz so sein das einige compiler
meinen int sei 32 bit und andere int sei 64 bit.

Das könnte vermutlich von Plattform zu Plattform unterschiedlich sein. Mir ist bisher lediglich bekannt, dass sich unter Windows long von 32 Bit auf 64 Bit vergrössert, alle anderen Ganzzahltypen sollen gleich bleiben.

f.-th. schrieb:

und zur dbase3-header-struct: ich wollte weitgehend compiler-unabhängige
quelltexte erstellen, denn welcher 16-bit-compiler kennt schon int32

Äääähh, so ziemlich jeder DOS Compiler long.
Genauso gut könntest du fragen, welcher 32 Bit Compiler schon int64 kennt? Hey ich kenn einen, GCC. Und noch einen, MSC. Oder wie wärs mit dem DMC? Nahezu jeder aktuelle Compiler kennt long long. OK, ist zwar C, aber idR gibt es Optionen, diesen Typ auch in C++ zu nutzen. Mal ganz abgesehen davon, dass einige Compiler noch eigene Typen mitbringen, zB wie __int64 beim MSC. Vielleicht dürfen wir uns in zukünftigen C++ Standards auch auf sowas wie C's <stdint.h> freuen.
Du siehst, dieser ganze Typendschungel ist ein ziemliches Hick-Hack, aber es geht, wenn man nur will. Und ein int32 für 16 Bit Compiler nachzuschieben ist kein allzu grosses Problem. Wenn long nicht bereits 32 Bit gross ist, dann kann man immer noch zwei int16 nehmen, eines für lo und eines für hi. Du musst halt lediglich entscheiden, was du maximal supporten willst, und dann die Implementation entsprechend darauf ausrichten.

f.-th. schrieb:

aber das eigentliche problem waren die unterschiedliche interpretation
von char im selben quelltext mit dem selben compiler

Sehr unwahrscheinlich. C++ definiert die Grösse von char zwar nicht exakt, aber zumindest soweit, dass ein char so gross wie ein Byte ist. Und ein Byte sollte auf dem jeweiligen Compiler immer gleich gross sein. Sicherlich kann die Grösse eines Bytes von einem zum anderen Compiler unterschiedlich gross sein, aber immerhin gibt es auch mehr Plattformen als nur Windows oder Linux.
Wie ich bereits erwähnte, sind solche Beobachtungen oftmals auf Alignment zurückzuführen. Bsp.

struct foo
{
    char a;
    int b;
};

Gehen wir mal von einem 32 Bit System aus, auf dem char 8 Bit und int 32 Bit gross ist. Wider aller Erwartungen ist es möglich, dass hier ein Compiler für sizeof(foo) nicht 5 ausspucken wird. Warum? Nun, zum einen garantiert der Standard dies nicht. Und zum anderen möchte der Compiler evtl., dass für jeden Member höchstmögliche Zugriffsgeschwindigkeit erreicht wird, weil der Benutzer zB eingestellt hat, auf Geschwindigkeit zu optimieren. Für foo.a ist das ja noch kein grosses Problem, da foo.a ein Byte gross ist, und dies die kleinste adressierbare Einheit ist. Bei x86 CPUs ist es zB egal, an welcher Stelle dieses Byte im Speicher liegt, der Zugriff darauf ist immer gleich schnell (mal abgesehen davon, dass Lesezugriffe idR schneller als Schreibzugriffe sind). Bei foo.b ist es schon etwas schwieriger. Ich will jetzt nicht näher auf die Arbeitsweise von Memory-Pipelines in Verbindung mit der CPU eingehen, das würde zu weit führen. Aber x86 CPUs können zB schneller auf einen 32 Bit Wert zugreifen, wenn er auch an einer 32 Bit (4 Byte) Speichergrenze ausgerichtet ist. Der Compiler definiert diese Struktur dann wie folgt

struct foo
{
    char a;
    char __dummy[3];
    int b;
};

Da für die Struktur selbst dann auch mindestens ein 32 Bit Alignment verwendet wird, ist sichergestellt, dass foo.b immer an einer 32 Bit Grenze ausgerichtet ist.
Dennoch gilt immer, dass sizeof(foo.a) == 1.
Ich kann also deine Aussage bzgl. "unterschiedliche interpretation von char" nicht wirklich nachvollziehen.

f.-th. schrieb:

aber ich hab's inzwischen nachgelesen char ist mindestens 8bit breit, kann
z.b. auf 32bit systemen auch 16bit oder 32bit breit sein.

Nun, wie bereits erwähnt, definiert der Standard keine exakten Grössen. Er sagt lediglich Folgendes:

sizeof liefert die Grösse in Byte
1 == sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

Artchi

grooevmaster! Muß dich leider berichtigen. long wird auf 64bit-System unter Windows weiterhin wie unter Win32 32bit bleiben, das wird sich nicht ändern. Denn da hat sich MS schon lange drauf fest gelegt. long long wird aber 64bit.

Hier die fundamentalen Typen und weiter unten die von MS:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_pluslang_fundamental_types.asp

Data Type Ranges:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_langref_data_type_ranges.asp

groovemaster

Artchi schrieb:

grooevmaster! Muß dich leider berichtigen. long wird auf 64bit-System unter Windows weiterhin wie unter Win32 32bit bleiben, das wird sich nicht ändern. Denn da hat sich MS schon lange drauf fest gelegt.

Das wäre aber schlecht. Welchen 64 Bit Typ wird es denn dann unter Win64 geben? Immerhin kennt C++ kein long long.

Artchi

Eigentlich gibts ja auch kein long, da long nur für "long int" steht. Ich würde einfach mal sagen, das man unter Windows am besten __int64 benutzt und sich z.B. ein typedef definiert, so das man bei einer Portierung oder anderen Compiler einfach umschalten kann. Also long long meidet aber __int64 indirekt durch ein eigenes typedef benutzt, z.B.:

typedef __int64 long64;

Das SDK von Maxon Cinema4D hat z.B. ein INT64, und die haben auch schon ohne Problem eine Win64-Version von ihrem C4D released. Nur als Beispiel das es irgendwie funktioniert, wenn man will.

Walli

Der Standard nicht, aber nahezu jeder Compiler kennt einen 64 Bit-Typ, also wird man sich ja einen typedefen können. Ich finde u64 bzw. i64 auch schöner als (unsigned) long long.

EDIT: Artchi war Sekundenbruchteile schneller .