mfg f.-th.

Guckst du windef.h da steht das alles drin...

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.

mfg f.-th.

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.

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

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

typedef int INT;

definiert wird.

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.

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.

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.

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

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

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)

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

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.

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.

EDIT: Artchi war Sekundenbruchteile schneller .

http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx

Sind für mich nur Ausreden. Was hindert MS denn daran, zB

LONG biWidth;

in

INT32 biWidth;

umzudefinieren, wenn sie wollen, dass die Grösse immer gleich bleibt? Wie bereits erwähnt, bringt das durchaus etwas mehr Arbeit mit sich. Ich tendiere aber eher dazu, Altlasten über Bord zu werfen, anstatt sich damit ständig ein zeitgemässes Design zu verbauen. Und wenn man so einen Schritt nicht bei der Umstellung von der einen zur anderen Bit-Architektur wagt, wann dann?