warum static const statt const static
-
Hallo NG,
ich habe
const static int array[] = { 0, 1, 2 };deklariert und der Compiler (gcc-4.2) hat
source.c:10: warning: ´static´ is not at beginning of declaration
ausgeworfen. Nun bin ich im Internet auf der Suche warum
static const int array[] = { 0, 1, 2 };kein Warning erzeugt. Hintergund warum ich dass wissen muss ist, dass ich die Änderung im Quellcode begründen muss.
Freundliche Grüße und Danke an alle,
BlackPepper
-
http://www.approxion.com/?p=41 schrieb:
The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.
-
Hallo pyhax und alle anderen,
pyhax schrieb:
http://www.approxion.com/?p=41 schrieb:
The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.
Auf ähnliche Bemerkungen bin ich bei meiner Suche auch schon gestossen. Ich muss aber wissen, ob das nur "Beauty" ist (die Compilerwarung ignoriert/schön geredet werden kann) oder ob davon ein Problem ausgehen kann (Handlungsbedarf besteht). Denn evtl. muss ich eine Quellcodeänderung rechtfertigen. Wer noch neugieriger ist, die Änderung würde innerhalb der Testphase erfolgen.
Grüße,
BlackPepper
-
BlackPepper schrieb:
Hallo pyhax und alle anderen,
pyhax schrieb:
http://www.approxion.com/?p=41 schrieb:
The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.
Auf ähnliche Bemerkungen bin ich bei meiner Suche auch schon gestossen. Ich muss aber wissen, ob das nur "Beauty" ist (die Compilerwarung ignoriert/schön geredet werden kann) oder ob davon ein Problem ausgehen kann (Handlungsbedarf besteht).
Es besteht ein Problem, wenn der nächste oder übernächste C-Standard(*) erscheint, und du mit dem Code auf einen Compiler umsteigst, der diesen Standard strikt umsetzt und keine Kompatibilitätsoption besitzt. Dann compiliert der Code nämlich nicht mehr. Wenn man das denn als Problem ansieht ... Im Moment ist das jedenfalls noch vollkommen korrekte Syntax.
Ich denke aber, dass eine Portierung auf einen anderen Compiler, mit einer neuen Sprachversion dazu, ohnehin viele Änderungen erfordert, so dass diese eine nicht weiter ins Gewicht fällt.
(*) Ich habe hier einen Draft von C11, in dem immer noch von "obsolescent" die Rede ist. Wann -- und ob -- es dann wirklich "obsolete" wird, wer weiß...
Denn evtl. muss ich eine Quellcodeänderung rechtfertigen.
Wenn "warnungsfreie Compilierung" kein Argument ist (QA-Fritzen stehen doch auf sowas), dann weiß ichs auch nicht.
-
C-Standard schrieb:
Certain features are obsolescent, which means that they may be considered for
withdrawal in future revisions of this International Standard. They are retained because
of their widespread use, but their use in new implementations (for implementation
features) or new programs (for language [6.11] or library features [7.26]) is discouraged.
-
Hallo Basher,
Bashar schrieb:
Es besteht ein Problem, wenn der nächste oder übernächste C-Standard(*) erscheint, und du mit dem Code auf einen Compiler umsteigst, der diesen Standard strikt umsetzt und keine Kompatibilitätsoption besitzt. Dann compiliert der Code nämlich nicht mehr. Wenn man das denn als Problem ansieht ... Im Moment ist das jedenfalls noch vollkommen korrekte Syntax.
Ich denke aber, dass eine Portierung auf einen anderen Compiler, mit einer neuen Sprachversion dazu, ohnehin viele Änderungen erfordert, so dass diese eine nicht weiter ins Gewicht fällt.
(*) Ich habe hier einen Draft von C11, in dem immer noch von "obsolescent" die Rede ist. Wann -- und ob -- es dann wirklich "obsolete" wird, wer weiß...
Denn evtl. muss ich eine Quellcodeänderung rechtfertigen.
Wenn "warnungsfreie Compilierung" kein Argument ist (QA-Fritzen stehen doch auf sowas), dann weiß ichs auch nicht.
ok, vielen Dank für Deine Antwort. Das hilft mir für eine handfeste Begründung. Denn bisher habe ich teils wiedersprüchliche Aussagen gefunden.
Gruß,
BlackPepper
