Zeiger auf Literal

pointercrash**

Tim schrieb:

Wo ist eigentlich nun das Problem?

Daß das total unlogisch rüberkommt.

void problem(void)
{
	int *check;
	int i = 3;	// einzelner Integer
	char a[9];	// a ist (*char)

	*check = 5;
	a[i] = 'a'; 	// logisch, a ist Basepointer, i wird offset (*char)
					// wir wollen ja ein array of char auflösen.
	i[a] = 'b'; 	// unlogisch, ist i ein basepointer auf char oder gar integer?!?
					// unlogisch ist i ein array?
					// nein, i ist nur ein Integer!!!
	a[*check] = 'a'; // logisch, a ist Basepointer, *check zu offset (*char)
	*check[a] = 'b'; // Operands of + have incompatible types 'int *' and 'char *'.
					// Type error: pointer expected - Achnee?.
}

Wo steckt die tiefere Logik dahinter, sowas wie in Zeile 10 zu erlauben? Wann wird aus welchen Vorgaben der Typ gecastet, um diese Zugriffe aufzulösen?

pointercrash() schrieb:

Tim schrieb:

Wo ist eigentlich nun das Problem?

Daß das total unlogisch rüberkommt.

void problem(void)
{
	int *check;
	int i = 3;	// einzelner Integer
	char a[9];	// a ist (*char)

	*check = 5;
	a[i] = 'a'; 	// logisch, a ist Basepointer, i wird offset (*char)
					// wir wollen ja ein array of char auflösen.
	i[a] = 'b'; 	// unlogisch, ist i ein basepointer auf char oder gar integer?!?
					// unlogisch ist i ein array?
					// nein, i ist nur ein Integer!!!
	a[*check] = 'a'; // logisch, a ist Basepointer, *check zu offset (*char)
	*check[a] = 'b'; // Operands of + have incompatible types 'int *' and 'char *'.
					// Type error: pointer expected - Achnee?.
}

google: C operator precedence...

LordJaxom

NDEBUG schrieb:

Ich mußte das hier ändern:

//enum { bgeissl, NDEBUG };
#define bgeissl 0
#define NDEBUG  1

Dir ist aber schon klar, dass NDEBUG ein Makro ist, welches von der Standardbibliothek verwendet wird um zwischen Debug- und Release-Version zu unterscheiden, dieses Makro von Visual Studio sogar automatisch gesetzt wird (im Releasemodus bei Standardprojekteinstellungen) und Du Dir damit höchstwahrscheinlich das Testergebnis verfälscht?

NDEBUG

Guter Hinweis. Ich hab die defines geändert nach

#define bgeissl     0
#define peterlustig 1

und die notwendigen Veränderungen vorgenommen. Es hat sich an den Ergebnissen aber nix geändert.

pointercrash**

Tim schrieb:

google: C operator precedence...

Achja, jetzt frißt er's.

Das war aber nicht meine Frage. Ich habe mehrfach über Arrays gelesen, daß der Name als Basispointer gilt und dann der Index dem Typen des Arrays entsprechend als Offset draufgeklatscht wird.

Nun ist aber i immer noch kein Array, sondern ein Integer. Woher bezieht der Compiler seine Typeninformation bzw. löst die [] wirklich auf?

pointercrash() schrieb:

Nun ist aber i immer noch kein Array, sondern ein Integer. Woher bezieht der Compiler seine Typeninformation bzw. löst die [] wirklich auf?

der compiler akzeptiert einfach beide schreibweisen, array[i] und i[array]. in beiden fällen bleibt i ein 'int' und das array bleibt ein array. aus welchem grund i[array] erlaubt ist, weiss ich nicht, aber vielleicht kann uns jemand hier aufklären?

NDEBUG

Erklären kann ich es nicht, aber es funktioniert auch auf Assembler Ebene. Hier erstmal kurz ein Listing:

#include <stdio.h>
#include <stdlib.h>

void _cdecl printit(char &c) {
    printf("%c\n", c);
}

int main(int argc, char *argv[]) {
    char a[128] = "Hello World";

    // a[i] access
    // c version
    printit(a[4]);
    // asm version
    _asm {
        lea     edi, a+4    // load address of a[i]
        push    edi         // push it
        call    printit     // print it
        pop     edi         // pop it
    }

    // i[a] access
    // c version
    printit(4[a]);
    // asm version
    _asm {
        lea     edi, 4+a    // load address of i[a]
        push    edi         // push it
        call    printit     // print it
        pop     edi         // pop it
    }

    system("pause");
    return 0;
}

Wie man sieht lautet der Befehl in Assembler der den Array Zugriff regelt "lea". Wenn ich mir nun also mal laienhaft vorstelle, daß jeder Array Zugriff auf folgende Art und Weise umgewandelt wird

array[j]
-> tokenize: token[0] = array, token[1] = j
-> lea edi, token[0]+token[i]

so erkennt man natürlich sofort daß die eigentlichen Reihenfolge der Werte total egal ist. Warum nicht stärker Typgeprüft wird, habe ich keine Ahnung.

NDEBUG schrieb:

lea edi, a+4 // load address of a[i]
lea edi, 4+a // load address of i[a]

das ist aber der selbe asm-befehl, oder?

NDEBUG

Jep, und viellciht der Grund warum a[j] == j[a] ist.

Edit: Achso um nochmal kurz den Bogen zu Pointern zu spannen

*(array + j)
-> tokenize: token[0] = '*', token[1] = array, token[2] = j
(token 0 zeigt eine Dereferenzierung an, d.h. was folgt muß eine Adresse sein)
-> lea edi, token[1]+token[2]

Und das ist dasselbe wie bei den Arrays. Also vollkommen gleichwertig.

pointercrash**

NDEBUG schrieb:

... Wenn ich mir nun also mal laienhaft vorstelle, daß jeder Array Zugriff auf folgende Art und Weise umgewandelt wird
array[j]
-> tokenize: token[0] = array, token[1] = j
-> lea edi, token[0]+token[i]
so erkennt man natürlich sofort daß die eigentlichen Reihenfolge der Werte total egal ist. Warum nicht stärker Typgeprüft wird, habe ich keine Ahnung.

Muß wohl einen Grund haben und genau der interessiert mich eigentlich schon . Wenn man's auf dem M16C anschaut, sieht das nach selbem in Grün aus, nur daß der ASM die Addition schon aufgelöst hat:

// i steht an offset -2 des Framebuffers
// array[i] = 'c';
    90  0004A  EB4BE6                   	mova	-26[FB],A0	;  array 
    91  0004D  A1B4FE                   	add.w	-2[FB],A0	;  i 
    92  00050  74C663                   	mov.b	#63H,[A0]	; 'c'
//	i[array] = 'd';
    94  00053  EB4BE6                   	mova	-26[FB],A0	;  array 
    95  00056  A1B4FE                   	add.w	-2[FB],A0	;  i 
    96  00059  74C664                   	mov.b	#64H,[A0]	; 'd'

Mit dem Renesas und KPIT bis auf die Basisadresse identisch, IAR und Tasking hab' ich gar nicht erst probiert, der Compiler wirds wohl ungefähr so wie in Deiner Metasprache auflösen.
Damit wird zumindest klar, daß an dieser Stelle keine Typenprüfung GEWÜNSCHT ist, fragt sich nur noch, warum, außer dem Wettbewerb um das unübersichtlichste Programm noch ein paar Features zu stiften.
Also, wenn es jemand drauf anlegt, bei jedem Arrayzugriff Anker und Index zu vertauschen und dabei mit eingestreuten Pointerdereferenzierungen Verwirrung stiftet, platzt mit ab Zeile 10 der Kopf .
Warum zum Henker wird also sowas erlaubt?

Der Operator [] ist halt einfach so definiert, dass a[b] gleichbedeutend mit *(a+b) ist, welches (Kommutativgesetzt) gleichbedeutend mit *(b+a) ist, welches in Folge gleichbedeutend mit b[a] ist. Was das hier speziell mit Typprüfung zu tun haben soll... keine Ahnung was du meinst. Im wesentlichen ist das Pointerarithmetik. Was ihr hier noch mit Assemblercode rumwerft verstehe ich auch nicht...

pointercrash**

Tim schrieb:

... Was das hier speziell mit Typprüfung zu tun haben soll... keine Ahnung was du meinst.

Weil das syntaktisch inkonsistent und verdammt nochmal i kein Array of irgendwas ist.

Tim schrieb:

Im wesentlichen ist das Pointerarithmetik. Was ihr hier noch mit Assemblercode rumwerft verstehe ich auch nicht...

Wenn Du keine Erklärung für die Fragen hast, dann halte Dich einfach an Nuhr und damit den Mund (oder die vorlauten Tippelfinger).

pointercrash() schrieb:

Tim schrieb:

... Was das hier speziell mit Typprüfung zu tun haben soll... keine Ahnung was du meinst.

Weil das syntaktisch inkonsistent und verdammt nochmal i kein Array of irgendwas ist.

Es ist eine Definition und diese ist konsistent. Wenn dir die Definition nicht gefällt und/oder sie nicht verstehst, kannst du wie so viele andere einen Rant auf youtube stellen.

Tim schrieb:

Im wesentlichen ist das Pointerarithmetik. Was ihr hier noch mit Assemblercode rumwerft verstehe ich auch nicht...

Wenn Du keine Erklärung für die Fragen hast, dann halte Dich einfach an Nuhr und damit den Mund (oder die vorlauten Tippelfinger).[/quote]
Sorry, ich werde mich in Zukunft zurückhalten deine Wissenslücken zu stopfen.

Tim schrieb:

Der Operator [] ist halt einfach so definiert, dass a[b] gleichbedeutend mit *(a+b) ist, welches (Kommutativgesetzt) gleichbedeutend mit *(b+a) ist, welches in Folge gleichbedeutend mit b[a] ist.

bekannte tatsachen vorzubeten hilft uns nicht weiter. wir wollen doch wissen, warum man für array[i] auch i[array], aber nicht [i]array hinschreiben kann. ist es ein abfallprodukt irgendwelcher parsing-techniken, ein bug in der syntaxdefinition, oder steckt tatsächlich ein sinn dahinter? dass array[i] das gleiche ist wie *(array+i) erklärt überhaupt nichts. wo sind eigentlich diese ganzen freaks, die hier immer den c-standard vorwärts und rückwärts aufsagen? das muss doch irgendwer wissen.

pointercrash**

Also, bei den untersuchten Compilern (KPIT/Renesas) werden auch außerhalb des Codeblocks definierte statics als Offset des Framebuffers gehandhabt, was auf eine generelle Pointeraddition hinweist, eine MMU gibt es hier nicht.
Also löst der Compiler a[b] = irgendwas; wohl so nach dem Motto auf "mir brauchen an Pointer, den Typ drauf, machen intern einen sizeof(*typ) und mal dem anderen Kameraden (probeweise kommutativ) und das wird's wohl sein.
Ich muß es ja nicht mögen, aber verstehen wollte ich's schon.

pointercrash**

~fricky schrieb:

bekannte tatsachen vorzubeten hilft uns nicht weiter. ... das muss doch irgendwer wissen.

Ah, Danke!

~fricky schrieb:

Tim schrieb:

Der Operator [] ist halt einfach so definiert, dass a[b] gleichbedeutend mit *(a+b) ist, welches (Kommutativgesetzt) gleichbedeutend mit *(b+a) ist, welches in Folge gleichbedeutend mit b[a] ist.

bekannte tatsachen vorzubeten hilft uns nicht weiter. wir wollen doch wissen, warum man für array[i] auch i[array], aber nicht [i]array hinschreiben kann.

Also das [i]array lese ich hier zum ersten Mal. Wo wurde diese Frage schon gestellt? Wie auch immer, was soll daran inkonsequent sein? So ein Konstrukt wurde einfach nicht definiert. Oder fängst du dich gleich an zu wundern warum man pointer nicht so dereferenzieren kann: int a = foo*; ???
Und den C-Standard kannst du auch selbst lesen. Lächerlicher gehts ja wohl kaum noch...

volkard

Tim schrieb:

Also das [i]array lese ich hier zum ersten Mal. Wo wurde diese Frage schon gestellt? Wie auch immer, was soll daran inkonsequent sein? So ein Konstrukt wurde einfach nicht definiert.

aha. da bitte ich doch mal um quellen!

[quote=5.2.1]The expression E1[E2] is identical (by definition) to *((E1)+(E2)).[/quote]

supertux

bis jetzt war es sehr interessant (auch die Kinderstreitereien) zu lesen, aber ich verstehe es noch nicht ganz:

A postfix expression followed by an expression in square brackets [] is a subscripted designation of an element of an array object. The definition of the subscript operator [] is that E1[E2] is identical to (*((E1)+(E2))). Because of the conversion rules that apply to the binary + operator, if E1 is an array object (equivalently, a pointer to the initial element of an array object) and E2 is an integer, E1[E2] designates the E2-th element of E1 (counting from zero).

dann heißt es E1[E2] ist (nur?) definiert, wenn E1 ein Array/Pointer und E2 ein Interger ist. Aber im Falle i[array] trifft das nicht zu. Hab ich was übersehen?

volkard schrieb:

[quote=5.2.1]The expression E1[E2] is identical (by definition) to *((E1)+(E2)).

[/quote]
mehr hab ich auch nicht dazu gefunden (hab' aber nur nach 'subscript' gesucht). jedenfalls sagt das nicht aus, dass e2[e1] oder [e1]e2 auch erlaubt sind.