invalid type argument of '->' (have 'jsmntok_t {aka struct <anonymous>}')
Bei
1
tokens[0]->....;
Johann L. schrieb:> meineFunktion(jsmntok_t tokens[])
Würde wohl funktioniere, aber hier würde ja der Inhalt kopiert werden.
Dies möchte ich ja eben nicht.
Holger K. schrieb:> Johann L. schrieb:>> meineFunktion(jsmntok_t tokens[])>> Würde wohl funktioniere, aber hier würde ja der Inhalt kopiert werden.> Dies möchte ich ja eben nicht.
Das wird er auch nicht. tokens[] ist an dieser Stelle absolut identisch
zu *tokens.
Nop schrieb:> Johann L. schrieb:>>> Muss nicht aber kann.>> Sollte, weil zwar die übergebene Adresse in beiden Fällen dieselbe ist,> aber nicht der assoziierte Typ.
Das macht in reinem C keinen Unterschied.
Außer natürlich für den Code-Leser.
Carl D. schrieb:> Das macht in reinem C keinen Unterschied.
Wenn wie hier, bei der Übergabe an eine Funktion nicht, weil C dann eh
castet. Beim Benutzen von sizeof schon.
> Außer natürlich für den Code-Leser.
Und damit auch für Code-Analysetools, die einen vor Typfehlern warnen
sollen. Mich würd's nicht wundern, wenn je nach Warnstufe sogar der eine
oder andere Compiler meckern würde.
Nop schrieb:> Carl D. schrieb:>>> Das macht in reinem C keinen Unterschied.>> Wenn wie hier, bei der Übergabe an eine Funktion nicht, weil C dann eh> castet. Beim Benutzen von sizeof schon.
Deshalb hat der Holger auch einen eigenen Thread zum Thema sizeof.
Weil's darum hier nicht geht.
Nop schrieb:> Johann L. schrieb:>>> Muss nicht aber kann.>> Sollte, weil zwar die übergebene Adresse in beiden Fällen dieselbe ist,> aber nicht der assoziierte Typ.
Wenn ich mit gcc folgendes übersetze
dann werden nacheinander folgende Werte in v gespeichert: 0, 1, 21, 21.
Die beiden letzten Werte sind klar, aber warum hat g nicht den Typ von g
sondern den von &g[0]?
Verwirrt ich bin. Oder ist das ein Bug?
Johann L. schrieb:> Nop schrieb:>> Johann L. schrieb:>>>>> Muss nicht aber kann.
.
>> Sollte, weil zwar die übergebene Adresse in beiden Fällen dieselbe ist,>> aber nicht der assoziierte Typ.
.
> Wenn ich mit gcc folgendes übersetzetypedef struct { char a[3]; }> __attribute((packed)) S;>> S g[7];>> #define T(x,y) _Generic((x), __typeof(y):1, default:0)>> int main()> {> static char volatile v;> v = T (g, g);> v = T (g, &g[0]);> __typeof(g) b;> v = sizeof (g);> v = sizeof (b);> }> dann werden nacheinander folgende Werte in v gespeichert: 0, 1, 21, 21.>> Die beiden letzten Werte sind klar, aber warum hat g nicht den Typ von g> sondern den von &g[0]?>> Verwirrt ich bin. Oder ist das ein Bug?
Wenn (x) als Parameter der "Funktion" _Generic() angesehen wird,
__typeof() aber den "echten" Typ ermittelt, dann würde es passen.
Wenn auch etwas strange.
Nop schrieb:> Mich würd's nicht wundern, wenn je nach Warnstufe sogar der eine> oder andere Compiler meckern würde.
Ich hoffe nicht, denn der implizite "Zerfall" von Arrays in einen Zeiger
auf deren erstes Element ist ein ziemlich grundlegendes Konzept in C,
das fast überall vorkommt, wo Arrays eingesetzt werden.
Johann L. schrieb:> Die beiden letzten Werte sind klar, aber warum hat g nicht den Typ von g> sondern den von &g[0]?
Weil auf das erste g der Array-zu-Zeiger-Zerfall auch angewendet wird,
auf das zweite aber nicht.
Aus http://en.cppreference.com/w/c/language/generic :
The conversion is performed in type domain only: it discards the
top-level cvr-qualifiers and atomicity or applies array to
pointer/function-to-pointer transformations to the type of the
controlling expression, without initiating any side-effects or
calculating any values.
Therefore, "abc" matches char* and not char[4] and (int const){0}
matches int, and not const int.
Rolf M. schrieb:> Ich hoffe nicht, denn der implizite "Zerfall" von Arrays in einen Zeiger
Hast natürlich recht, weil &array[0] dann auch genau den richtigen
Zeigertyp hat für die Funktion.