Krishty hat geschrieben: Und &((int*)pArray) gleicht dem klareren ((int*)pArray) + i.
Code: Alles auswählen
T a[] = {...};
dann gilt: a[i] == &a[0]+i == a+i
ergo: &((int*)pArray)[i] == ((int*)pArray) +i
Nein tut es nicht. Was du schreibst, überspringt bei jedem Zugriff eine Anzahl von sizeof(int) - 1 Elemente des Arrays. Die Umwandlung von &(x[y]) zu x + y steht afaik sogar 1:1 so im Standard.kaiserludi hat geschrieben:Krishty hat geschrieben: Und &((int*)pArray) gleicht dem klareren ((int*)pArray) + i.
Nein, es gleicht ((int*)pArray) + i*sizeof(int)
Das liest du garantiert nie, weil es falsch ist. ((void*)x)+y gibt es nicht. Da ändert auch der Pseudo-Text nichts dran.kaiserludi hat geschrieben:So was darf ich öfter lesen
Also ich finde ptr als i-tes Element von ptr einfacher.Krishty hat geschrieben:Und noch einer hinterher:
ptr + i hat man zu lesen als ptr um i Elemente verschoben. Einfacher geht es wirklich nicht mehr.
Die einzigen Element-Typen, mit denen man auf Bytes arbeiten kann, sind char und unsigned char (wobei ich mir bei letzterem nicht sicher bin).
Code: Alles auswählen
int arr[5] = {0, 1, 2, 3, 4};
void* a = arr;
for(int i=0; i<5; i++)
printf("%d ", *(int*)(a+i));
printf("\n");
for(int i=0; i<5; i++)
printf("%d ", *(int*)(a+i*sizeof(int)));
printf("\n");
0 16777216 65536 256 1
0 1 2 3 4
Code: Alles auswählen
int arr[5] = {0, 1, 2, 3, 4};
void* a = arr;
for(int i=0; i<5; i++)
printf("%d ", *((int*)a+i));
printf("\n");
for(int i=0; i<5; i++)
printf("%d ", *((int*)a+i*sizeof(int)));
printf("\n");
Worauf ihr euch bezieht ist der zweite Fall. Der erste hingegen funktioniert nur mit dem sizeof korrekt.0 1 2 3 4
0 4 195028 94640000 12
gcc hat geschrieben:error: pointer of type 'void *' used in arithmetic
Doch der Standard definiert sizeof(char) == 1. Die Größe von einem Byte ist aber nicht definiert, es müssen nur mindestens 8 Bit sein.kaiserludi hat geschrieben:Meines Wissens nach schreibt der Standard vor, dass char, signed char und unsigned char identisch groß sein müssen, schreibt aber nicht vor, wie viele bytes es exakt sein müssen.
Ja, aber du willst ja nicht das Element, sondern einen Zeiger darauf. Und wenn & davorkommt muss man im Zweifelsfall erst nachschlagen, ob &ptr[j] als (&ptr)[j] oder als &(ptr[j]) behandelt wird. Ich weiß es z.B. vom Draufschauen nicht, obwohl ich mich mal intensiv damit auseinandergesetzt hatte. Und ich hasse zwei Operatoren auf demselben Ausdruck.kaiserludi hat geschrieben:Also ich finde ptr als i-tes Element von ptr einfacher.
Nein – der Standard schreibt vor, dass char die Größe der kleinsten adressierbaren Einheit hat. Auch ein Byte ist als kleinste adressierbare Einheit definiert; darum ist char immer automatisch 1 Byte groß. Bytes im Sinne von 8-Bit-Gruppen wären Oktetts; wie viele Oktetts ein char groß ist, weiß man nicht.kaiserludi hat geschrieben:Meines Wissens nach schreibt der Standard vor, dass char, signed char und unsigned char identisch groß sein müssen, schreibt aber nicht vor, wie viele bytes es exakt sein müssen.
Korrekt, der Standard sagt aber nichts darüber aus wieviele Bits ein Byte hat, es müssen lediglich mindestens 8 sein, die genaue Anzahl ist über das Makro CHAR_BIT zugänglich und muss nicht unbedingt ein Vielfaches von 8 sein (alles >= 8 ist möglich).Krishty hat geschrieben:Nein – der Standard schreibt vor, dass char die Größe der kleinsten adressierbaren Einheit hat. Auch ein Byte ist als kleinste adressierbare Einheit definiert; darum ist char immer automatisch 1 Byte groß. Bytes im Sinne von 8-Bit-Gruppen wären Oktetts; wie viele Oktetts ein char groß ist, weiß man nicht.
Doch der Standard schreibt für char und alle unsigned Typen vor dass sie die selbe Größe und die selben Alignmentkriterien haben wie die entsprechenden signed Typen, der Standard spricht an der Stelle sogar von "gleichen Objektrepräsentationen".Krishty hat geschrieben:Weiterhin schreibt der Standard afaik nicht vor, dass signed char und unsigned char dieselbe Größe wie char haben, sondern nur, dass sie den entsprechenden Wertebereich unterstützen. Darum bin ich mir bei unsigned char auch nicht sicher, ob er zur Byte-weisen Adressierung taugt; aber in den Aliasing-Regeln ist er explizit als überlappend zugelassen, was eigentlich dafürspricht.
Hast recht:dot hat geschrieben:Doch der Standard schreibt für char und alle unsigned Typen vor dass sie die selbe Größe und die selben Alignmentkriterien haben wie die entsprechenden signed Typen, der Standard spricht an der Stelle sogar von "gleichen Objektrepräsentationen".Krishty hat geschrieben:Weiterhin schreibt der Standard afaik nicht vor, dass signed char und unsigned char dieselbe Größe wie char haben, sondern nur, dass sie den entsprechenden Wertebereich unterstützen. Darum bin ich mir bei unsigned char auch nicht sicher, ob er zur Byte-weisen Adressierung taugt; aber in den Aliasing-Regeln ist er explizit als überlappend zugelassen, was eigentlich dafürspricht.
(Wobei ich nicht weiß, ob das in C++97 auch schon so war.)§5.3.3 aus dem C++0x-Draft hat geschrieben:sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1.
Interessant. Ich wusste nicht, dass 8bit Midnestgröße vorgeschrieben sind. Ich dachte immer, man könnte als Compilerentwickler z.B. ein Byte auch 7Bit groß wählen.dot hat geschrieben:@dot: Du hast die Autoren verwechselt ;)
oops, habs ausgebessert
Korrekt, der Standard sagt aber nichts darüber aus wieviele Bits ein Byte hat, es müssen lediglich mindestens 8 sein, die genaue Anzahl ist über das Makro CHAR_BIT zugänglich und muss nicht unbedingt ein Vielfaches von 8 sein (alles >= 8 ist möglich).Krishty hat geschrieben:Nein – der Standard schreibt vor, dass char die Größe der kleinsten adressierbaren Einheit hat. Auch ein Byte ist als kleinste adressierbare Einheit definiert; darum ist char immer automatisch 1 Byte groß. Bytes im Sinne von 8-Bit-Gruppen wären Oktetts; wie viele Oktetts ein char groß ist, weiß man nicht.
Doch der Standard schreibt für char und alle unsigned Typen vor dass sie die selbe Größe und die selben Alignmentkriterien haben wie die entsprechenden signed Typen, der Standard spricht an der Stelle sogar von "gleichen Objektrepräsentationen".Krishty hat geschrieben:Weiterhin schreibt der Standard afaik nicht vor, dass signed char und unsigned char dieselbe Größe wie char haben, sondern nur, dass sie den entsprechenden Wertebereich unterstützen. Darum bin ich mir bei unsigned char auch nicht sicher, ob er zur Byte-weisen Adressierung taugt; aber in den Aliasing-Regeln ist er explizit als überlappend zugelassen, was eigentlich dafürspricht.
C++ 97?Krishty hat geschrieben:Hast recht:dot hat geschrieben:Doch der Standard schreibt für char und alle unsigned Typen vor dass sie die selbe Größe und die selben Alignmentkriterien haben wie die entsprechenden signed Typen, der Standard spricht an der Stelle sogar von "gleichen Objektrepräsentationen".Krishty hat geschrieben:Weiterhin schreibt der Standard afaik nicht vor, dass signed char und unsigned char dieselbe Größe wie char haben, sondern nur, dass sie den entsprechenden Wertebereich unterstützen. Darum bin ich mir bei unsigned char auch nicht sicher, ob er zur Byte-weisen Adressierung taugt; aber in den Aliasing-Regeln ist er explizit als überlappend zugelassen, was eigentlich dafürspricht.(Wobei ich nicht weiß, ob das in C++97 auch schon so war.)§5.3.3 aus dem C++0x-Draft hat geschrieben:sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1.
Stimmt, der Standard ist von ’98. Ich hatte einfach schnell auf das __cplusplus-Makro in VC geguckt, und das ist auf November ’97 datiert … weird.kaiserludi hat geschrieben:C++ 97?Krishty hat geschrieben:(Wobei ich nicht weiß, ob das in C++97 auch schon so war.)
Gibt es nicht nur C++ 98, C++ 03 und C++ 0x und alles vor C++ 98 war nicht offiziell standadisiert?
C++ wurde ja ab 1979 entwickelt und die erste Referenzversion erschien 1985. Entsprechend muss natürlich schon vieles vor der ersten Standadisierung 1998 da gewesen sein.Krishty hat geschrieben:Stimmt, der Standard ist von ’98. Ich hatte einfach schnell auf das __cplusplus-Makro in VC geguckt, und das ist auf November ’97 datiert … weird.kaiserludi hat geschrieben:C++ 97?Krishty hat geschrieben:(Wobei ich nicht weiß, ob das in C++97 auch schon so war.)
Gibt es nicht nur C++ 98, C++ 03 und C++ 0x und alles vor C++ 98 war nicht offiziell standadisiert?
Es ist also tatsächlich so, dass sich der 98er Standard als von November 1997 identifiziert.§16.0 hat geschrieben:__cplusplus
The name __cplusplus is defined to the value 199711L when compiling a C++ translation unit.*
[Footnote: It is intended that future versions of this standard will replace the value of this macro with a greater value. Non-conforming compilers should use a value with at most five decimal digits. --- end foonote]
Was bringt das denn, das festzulegen? Entwede habe ich das Makro schon vor dem Standard auf einen anderen Wert definiert und kann es aus Abwärtskompatibilitätsgründen nicht mehr ändern, dann aknn ich es aber auch icht auf einen mindestens 5-stelligen Wert ändern ,wenn der bisherige maximal 4 stellig ist, oder aber ich habe es noch nicht vor dem Standard definiert, dann habe ich aber auch keinen Grund, es nicht standardkonform zu definieren.Krishty hat geschrieben:§16.0 hat geschrieben:__cplusplus
Non-conforming compilers should use a value with at most five decimal digits.
Code: Alles auswählen
template<class CType> struct ConfirmAllowed<const CType>
{
typedef typename const ConfirmAllowed<CType>::type type;
typedef typename const ConfirmAllowed<CType>::scalarType scalarType;
static const unsigned int dimensions = ConfirmAllowed<CType>::dimensions;
static const nByte typeName = ConfirmAllowed<CType>::typeName;
};
Code: Alles auswählen
template<class CType> struct ConfirmAllowed<const CType>
{
typedef const typename ConfirmAllowed<CType>::type type;
typedef const typename ConfirmAllowed<CType>::scalarType scalarType;
static const unsigned int dimensions = ConfirmAllowed<CType>::dimensions;
static const nByte typeName = ConfirmAllowed<CType>::typeName;
};
Wieso nicht einfach "Bei typedef typename const missversteht es der Compiler als Dekoration des typename durch const"?Bei typedef typename const versteht es der Compiler als Dekoration des typename durch const miss (kann man das Verb so teilen?)
Um da drauf noch einmal zurück zu kommen.Aramis hat geschrieben:Siehe auch http://codepad.org/dxG0wTNY fuer das erste und http://codepad.org/aghmcbkd fuer das zweite Snippet.
gcc hat geschrieben:error: pointer of type 'void *' used in arithmetic
Quelle: http://en.wikipedia.org/wiki/Pointer_(c ... nd_C.2B.2Bwikipedia hat geschrieben: Pointer arithmetic cannot be performed on void pointers because the void type has no size, and thus the pointed address can not be added to, although gcc and other compilers will perform byte arithmetic on void* as a non-standard extension. For working "directly" with bytes they usually cast pointers to BYTE*, or unsigned char* if BYTE is not defined in the standard library used.
Quelle: http://gcc.gnu.org/onlinedocs/gcc-4.5.0 ... nter-Arith6.22 Arithmetic on void- and Function-Pointers
In GNU C, addition and subtraction operations are supported on pointers to void and on pointers to functions. This is done by treating the size of a void or of a function as 1.
A consequence of this is that sizeof is also allowed on void and on function types, and returns 1.
The option -Wpointer-arith requests a warning if these extensions are used.
Code: Alles auswählen
compilertype = sizeof(void)?gcc:msvc;das mit dem return aVoidFunc() in einer void Funktion habe ich sogar erst letztens genutzt, hat einiges simplifiziert, weiß nur nicht mehr, wofür ich es eingesetzt habe. Gar nicht gewusst, dass das auch nicht standardkonform ist.Krishty hat geschrieben:Omg. Jaa, das mit sizeof(void) ist drin, weil es die Metaprogrammierung erleichtert (derselbe Grund, aus dem man auch void voidFunc() { return notherVoidFunc(); } schreiben kann) – aber das mit der void *-Arithmetik und 1 == sizeof(void) zeigt ziemlich gut, was für Verwirrung man stiftet, wenn man „handliche“ Änderungen am Standard vornimmt.
Aber danke, dass du das rausgesucht hast – diese Erweiterung war mir komplett unbekannt.
Ich meinte genau andersherum, dass beides erlaubt sei, aber sizeof(void) ist, wie ich gerade feststelle, nicht erlaubt (weil void ein incomplete type ist).kaiserludi hat geschrieben:das mit dem return aVoidFunc() in einer void Funktion habe ich sogar erst letztens genutzt, hat einiges simplifiziert, weiß nur nicht mehr, wofür ich es eingesetzt habe. Gar nicht gewusst, dass das auch nicht standardkonform ist.