Hallo, * Eberhard Wilfrid ZFF TE-PR [2004-04-14 14:49]:

ich hab ein Problem mit dem Praeprozessor,

ich hab folgenden Define:

#define GET_TEST_MACRO(name, idx) (&(test_ptr->name##[idx]))

in einem c-File habe ich folgenden Aufruf:

hallo = GET_TEST_MACRO(kap, kap_nr);

Der Kompiler spukt folgende Fehlermeldung aus

pasting "kap" and "[" does not give a valid preprocessing token

ich würde mal die Tatsache ausnutzen, dass a[b] == *(a + b) gilt. Das dürfte zu leichter verdaulicher Syntax führen. Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ I couldn't give [Bill Gates] advice in business and he couldn't give me advice in technology. -- Linus Benedict Torvalds

On Wed, 2004-04-14 at 21:59, Philipp Thomas wrote:

Ralf Corsepius [14 Apr 2004 15:39:53 +0200]:

...

On Wed, 2004-04-14 at 14:49, Eberhard Wilfrid ZFF TE-PR wrote:

...

...

pasting "kap" and "[" does not give a valid preprocessing token

Ein Klassiker unter den gcc-3.3.x Inkompatibilitäten ;)

Du kannst das Stänkern wohl nicht lassen :) Du scheinst misszuverstehen (Siehe unten).

Das ist *keine* Inkompatibilität sondern schlicht und einfach standardkonformes Verhalten. Ja.

Trotzdem ist Fakt: Es eine Inkompatibilität zwischen gcc-3.3 und seinen Vorgängern, sowie zu vielen anderen existierenden Compilern. Ebenso ist es ein typisches Problem dass beim Übersetzen älterer Quellen mit gcc-3.3 auftritt.

Der C Standard legt fest, dass das Ergebnis einer Kombination von Token mittels "##" wiederum ein gültiges Token ergeben muss.

Genau diese Kombination von Token war noch nie nötig (man kann genauso 'test_ptr -> bla [ blubb ]' schreiben, der Compiler würde es verstehen), aber wenige Programmierer machen sich die Mühe, C bis in diese Feinheiten hinein zu lernen. Wenn Du meinst ... Die meisten Programmierer halten ein Sprachkonstrukt solange für richtig, solange ein Compiler ein Konstrukt nicht ankreidet. GCC < 3.3 tat es nicht, weshalb dieses Problem bei mit gcc entwickelten, oder sehr alten Quellen nicht gerade selten auftritt.

Oder noch allgemeiner: Es handelt sich um eine Feinheit/Auslegung der C-Spezifikation, die bis gcc-3.3 insbes. unter mit gcc arbeitenden Entwicklern nur wenig bekannt war (sprich: defacto überhaupt nicht bekannt war) und auch sonst nur wenig bekannt war/ist. Ähnliche Fälle hat es in der Vergangenheit schon viele gegeben und wird es immer wieder geben. Das galt in der Vergangenheit für volatile, betrifft hier '##'-concats. Mit gcc-3.4 würde ich davon ausgehen, dass die in gcc-3.4 neuen lvalue-casts-deprecation Warnungen für Verwirrung sorgen werden. Ralf -- Ralf Corsepius Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW) Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690 mailto:corsepiu@faw.uni-ulm.de FAX: +49/731/501-999 http://www.faw.uni-ulm.de