Hallo zusammen,
gibt es für konstante Variablen in C (GCC) ähnliche Möglichkeiten, wie
eine "weak"-Deklaration für Funktionen?
Ich will in einer .c-Datei ein "Default" einer
(struct)-Konfigurationsvariablen anlegen, die aber in einer anderen
Datei überschreiben können.
Im Notfall könnte ich aus der const-Variablen eine normale Variable
machen, und eine Initialisierungsfunktion "weak" machen. Aber das wäre
irgendwie unschön, zumal die const-Variable im Flash liegen kann.
Alternativ kann ich die Initialisierungswerte in ein Präprozessor-Define
packen und dann mit #ifdef prüfen, ob es nicht schon anderweitig
vordefiniert wurde. Was mir daran nicht gefällt, ist dass der Header, in
dem dieser vorrangige #define eventuell steht, auch #includieren muss,
wenn er eigentlich gar nicht existieren müsste. Ausserdem wären dann die
Deklaration des Structs und die Definition im #define getrennt, was auch
eine nette Fehlerquelle ist.
Oder geht es noch schöner?
Viele Grüße
W.T.
In der Doku finde ich "weak" nur als Attribut für Funktionen.
Natürlich habe ich es ausprobiert, ob es auch für Variablen geht, und
ich diesen Teil nicht in der Doku finde.
Deklariere ich eine Variable als "weak", z.B. so:
so wird interessanterweise keine Compiler-Warnung erzeugt (GCC 5.1.0),
aber aus dem Struct auch nur noch Unsinn ausgelesen. Wird dann eine
zweite Definition des Structs erzeugt, also:
kommt erwartungsgemäß der Compiler-Fehler "error: redefinition ....".
Unterm Strich heisst das für mich: Der "weak"-Mechanismus scheint nur
für Funktionen und nicht für Variablen/Konstanten zu funktionieren.
Dein Forschergeist in Ehren, aber ist CONST als WEAK nicht ein
konzeptueller Alptraum?
Was spricht gegen eine normale Variable, die Du default (der CONST-Fall)
füllst und bei Bedarf (und nachvollziehbar) abänderst? Könntest die
Veränderung sogar über ein strukturelement (Z.B. .isDefaultInit)
vermerken)
Mit libraries geht es vielleicht: wenn Du dein Default einzeln in eine
lib legst, kannst Du im Projekt eine zweite Instanz definieren, die die
erste "überschreibt". Natürlich nur metaphorisch, die aus der lib wird
nicht dazugelinkt.
Walter T. schrieb:> Ich will in einer .c-Datei ein "Default" einer> (struct)-Konfigurationsvariablen anlegen, die aber in einer anderen> Datei überschreiben können.
Mach das doch einfach. Und um das Default im .c ein #if. Dann brauchts
im Header nur ein Schalter.
Das GCC-Manual sagt, dass weak auch mit Variablen geht.
https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Variable-Attributes.html#Variable-Attributes
Wenn ich dein Test oben richtig verstehe, hast du die gleiche Variable
in einer Datei zweimal definiert? Das dürfte auch mit weak-Attribut ein
Fehler sein (da das weak für den Linker ist, wenn ich mich nicht irre).
Stephan schrieb:> Dein Forschergeist in Ehren, aber ist CONST als WEAK nicht ein> konzeptueller Alptraum?> Was spricht gegen eine normale Variable, die Du default (der CONST-Fall)> füllst und bei Bedarf (und nachvollziehbar) abänderst? Könntest die> Veränderung sogar über ein strukturelement (Z.B. .isDefaultInit)> vermerken)
Beides ist schwer nachvollziehbar, wenn man es versteckt. Const gibt
aber etwas mehr Garatien, daher würde ich das persönlich eher vorziehen.
Ich bin zwar schon lange aus der Übung bzgl. c(++), aber wenn ich mir
die Doku anschaue (Link im 2. Post) dann schreiben die:
"The weak attribute causes the declaration to be emitted as a weak
symbol rather than a global. This is primarily useful in defining
library functions which can be overridden in user code, though it can
also be used with non-function declarations. Weak symbols are supported
for ELF targets, and also for a.out targets when using the GNU assembler
and linker. "
Was ich lese, dass es auch für Variablen geht.
Das es nicht innerhalb einesC Files für ein ELF Target geht, sondern nur
wenn man ein Symbol einer Lib oder einer Objektdatei ausserhalb
"überschreiben" will.
Was mir jetzt aber nicht klar ist. Wenn ich so eine Konstante benutze um
in der lib in der sie definiert wurde andere Konstanten oder Werte zu
definieren die der Compiler dann berechnet, wie wirkt sich das aus, wenn
die Konstante dann redefiniert wird? Dann müsste der Linker ja auch die
abhängigen Werte in der eingebundenen library neu berechnen.
Udo S. schrieb:> Was mir jetzt aber nicht klar ist. Wenn ich so eine Konstante benutze um> in der lib in der sie definiert wurde andere Konstanten oder Werte zu> definieren die der Compiler dann berechnet, wie wirkt sich das aus, wenn> die Konstante dann redefiniert wird? Dann müsste der Linker ja auch die> abhängigen Werte in der eingebundenen library neu berechnen.
Ich vermute, dass dann beide Definitionen gemischt werden. Also der
Compiler immer die weake Definiton nutzt.
Interessanterweise gibt es dieses Problem in C++ nicht, da es
Unterschiede bei const in C vs. C++ gibt:
https://stackoverflow.com/a/19492225 . In C++ gehen weak und const dann
einfach nicht zusammen.
Vll lohnt es sich weakref mal anzuschauen.
Stephan schrieb:> aber ist CONST als WEAK nicht ein konzeptueller Alptraum?
Sehe ich auch so.
Der Sinn darin, eine Variable als "const" zu deklarieren ist doch, dass
der Compiler (und nicht erst der Linker) darauf Optimierungen anwenden
kann, denn er muss nicht mehr davon ausgehen, dass sich deren Wert
jenseits der (für ihn sichtbaren) Initialisierung nochmal ändert.
Indem man eine Variable als weak deklariert, will man allerdings
explizit, dass der exakte Wert erst nach dem Linken zur Verfügung steht.
Damit darf der Compiler Zugriffe auf diese auf keinen Fall bereits zur
Compilezeit optimieren.
Udo S. schrieb:> Wenn ich so eine Konstante benutze um in der lib in der sie definiert> wurde andere Konstanten oder Werte zu definieren die der Compiler dann> berechnet, wie wirkt sich das aus, wenn die Konstante dann redefiniert> wird?
Der C-Compiler rechnet nicht mit Konstanten. Er bildet nicht Mal die
Adressen.
Naja, Optimierung ist ja nicht alles. Entscheidender scheint mir, dass
die Konstanten irgendwo im Code verstreut ueberschrieben sein koennen,
es also schwer zu ueberblicken ist.
"The weak attribute causes the declaration to be emitted as a weak
symbol rather than a global."
Hat das Einfluss auf den Scope?
Ich kann verstehen, dass "const" und "weak" für den Compilerbauer ein
Alptraum sind. Aber das dürfte für die Kombination "extern const" doch
auch schon zutreffen?
Walter Tarpan schrieb:> Aber das dürfte für die Kombination "extern const" doch> auch schon zutreffen?
nur wenn er die Konstanten Variablen auch schon zur Compilezeit
auswerten soll. C tut das nicht. Ansonsten ist es egal ob extern oder
extern const, nur das halt kein Schreibzugriff erlaubt ist.
Und auch const volatile stellt kein Problem dar, falls Du das meintest.
Jörg W. schrieb:> Stell doch bitte nicht pauschal solche Behauptungen auf.
dass der Gnu C++ Compiler das soll und der Gnu-C das innerhalb einer
Datei kann, geschenkt. Es bleibt dennoch eine in C nicht vorgesehene
(und natürlich nicht verbotene) Optimierung. Wenn er das nicht tut, ist
es OK. Wenn er das bei weak auch macht, ist es falsch.
In einer normalen Lib (ohne weak) gibt es mit der Implementierung auch
kein Problem, weil beide nur zusammen zugelinkt werden.
Es ging darum, dass es zu keinem Problem bei verschiedenen Dateien
führt, weil
> C tut das nicht.
Und wenn der Linker das mittlerweile in C trotzdem macht, … dann scheint
es erst recht kein Problem für den Compiler-Bauer, weil er es ja nicht
braucht.
Es ging um diese Aussage:
Walter Tarpan schrieb:> Ich kann verstehen, dass "const" und "weak" für den Compilerbauer ein> Alptraum sind. Aber das dürfte für die Kombination "extern const" doch> auch schon zutreffen?
Und das ist halt falsch. const und weak machen nichts anderes, als mit
einer Lib schon seit Ansi-C (oder früher) geht. Nur dass man ohne weak
nicht innerhalb einer C-Datei Kirschenpflücken kann.
A. S. schrieb:> Jörg W. schrieb:>> Stell doch bitte nicht pauschal solche Behauptungen auf.>> dass der Gnu C++ Compiler das soll und der Gnu-C das innerhalb einer> Datei kann, geschenkt. Es bleibt dennoch eine in C nicht vorgesehene> (und natürlich nicht verbotene) Optimierung.
Welche Optimierung ist denn deiner Meinung nach in C "vorgesehen"? Und
in welcher Sprache ist das Optimieren von konstanten Ausdrücken im
Compiler verpflichtend?
mh schrieb:> in welcher Sprache ist das Optimieren von konstanten Ausdrücken im> Compiler verpflichtend?
C++
In C haben const-"Variablen" externe Bindung. Es muss auch
funktionieren, wenn sie erst zur Laufzeit ausgelesen wird.
In C++ ist sowas erlaubt wie const int n=11; int a[n];. In C geht das
nicht (selbst wenn gcc das erlauben sollte).
A. S. schrieb:> mh schrieb:>> in welcher Sprache ist das Optimieren von konstanten Ausdrücken im>> Compiler verpflichtend?>> C++>> In C haben const-"Variablen" externe Bindung. Es muss auch> funktionieren, wenn sie erst zur Laufzeit ausgelesen wird.>> In C++ ist sowas erlaubt wie const int n=11; int a[n];. In C geht das> nicht (selbst wenn gcc das erlauben sollte).
Das ist keine Antwort auf meine Fragen. Mir ist der Unterschied zwischen
C-const und C++-const bekannt.
A. S. schrieb:> dass der Gnu C++ Compiler das soll und der Gnu-C das innerhalb einer> Datei kann, geschenkt. Es bleibt dennoch eine in C nicht vorgesehene> (und natürlich nicht verbotene) Optimierung.
Damit ist aber die pauschale Aussage, "wird in C nicht gemacht",
Quatsch.
Auf mehr wollte ich nicht hinaus: selbstverständlich darf auch ein
C-Compiler ein const-Objekt als unveränderlich annehmen.
> Wenn er das bei weak auch macht, ist es falsch.
Kannst du so auch nicht sagen, denn "weak" ist nichts, was der Standard
definiert.
Die Dokumentation des Compilers macht dazu auch keine weitere Aussage
(wurde ja oben schon zitiert).
Letztlich interessiert den Compiler das überhaupt nicht (weder GCC noch
Clang), wenn man in obigem Code ein "__attribute__((weak))" für die
Variable einfügt. Der generierte Code bleibt der gleiche.
Ergo: weak und const sollte man tunlichst nicht gemeinsam benutzen.
Maxe schrieb:> Naja, Optimierung ist ja nicht alles.
Wenn die dafür sorgt, dass diese Idee gar nicht erst zuverlässig
funktioniert, dann ist das erst mal ein k.o.-Kriterium.
> Entscheidender scheint mir, dass die Konstanten irgendwo im Code verstreut> ueberschrieben sein koennen, es also schwer zu ueberblicken ist.
Das sehe ich auch so. Wenn ich irgendwo im Quellcode eine Definition der
const-Variablen mit Initialisierung sehe, dann erwarte ich eigentlich
auch, dass sie diesen Wert hat und ihr nicht hinterrücks ein anderer
Wert gegeben wird.
A. S. schrieb:> Jörg W. schrieb:>> Stell doch bitte nicht pauschal solche Behauptungen auf.>> dass der Gnu C++ Compiler das soll und der Gnu-C das innerhalb einer> Datei kann, geschenkt.
Mit LTO würde es mich nicht wundern, wenn er es auch über
Quellcode-Dateien hinweg täte.
> Es bleibt dennoch eine in C nicht vorgesehene (und natürlich nicht> verbotene) Optimierung. Wenn er das nicht tut, ist es OK.
Und genauso ok ist es, wenn er das tut.
> Wenn er das bei weak auch macht, ist es falsch.
weak gibt es in C gar nicht.
> Walter Tarpan schrieb:>> Ich kann verstehen, dass "const" und "weak" für den Compilerbauer ein>> Alptraum sind. Aber das dürfte für die Kombination "extern const" doch>> auch schon zutreffen?>> Und das ist halt falsch. const und weak machen nichts anderes, als mit> einer Lib schon seit Ansi-C (oder früher) geht.
Libs sind in ANSI C auch nicht "vorgesehen".
A. S. schrieb:> mh schrieb:>> in welcher Sprache ist das Optimieren von konstanten Ausdrücken im>> Compiler verpflichtend?>> C++
Nein. C++ verpflichtet nicht zu irgendwelchen Optimierungen.
> In C haben const-"Variablen" externe Bindung. Es muss auch> funktionieren, wenn sie erst zur Laufzeit ausgelesen wird.
Nur wenn sie auch volatile sind. Sonst darf der Compiler da beliebig
dran rumoptimieren.
> In C++ ist sowas erlaubt wie const int n=11; int a[n];. In C geht das> nicht (selbst wenn gcc das erlauben sollte).
Und was hat das jetzt mit Optimierung zu tun?
Jörg W. schrieb:> Der Sinn darin, eine Variable als "const" zu deklarieren ist doch, dass> der Compiler (und nicht erst der Linker) darauf Optimierungen anwenden> kann, denn er muss nicht mehr davon ausgehen, dass sich deren Wert> jenseits der (für ihn sichtbaren) Initialisierung nochmal ändert.
Nö. Eigentlich ist das eben nicht der Sinn des Ganzen, sondern der Sinn
(und die Anwendung) ist, daß eben diese "Variable" nicht im RAM
angeordnet sein soll, sondern im Flash.
Manchmal braucht man genau das genau SO - und zwar derart, daß der
Compiler daran nichts herum"optimiert".
W.S.
W.S. schrieb:> Jörg W. schrieb:>> Der Sinn darin, eine Variable als "const" zu deklarieren ist doch, dass>> der Compiler (und nicht erst der Linker) darauf Optimierungen anwenden>> kann, denn er muss nicht mehr davon ausgehen, dass sich deren Wert>> jenseits der (für ihn sichtbaren) Initialisierung nochmal ändert.>> Nö. Eigentlich ist das eben nicht der Sinn des Ganzen, sondern der Sinn> (und die Anwendung) ist, daß eben diese "Variable" nicht im RAM> angeordnet sein soll, sondern im Flash.
Das kann gar nicht die Aufgabe von const sein, aus einem einfachen
Grund: C als Sprache weiß überhaupt nix von RAM oder Flash.
Mit const sagt man dem Compiler lediglich, dass er annehmen darf, dass
sich der Inhalt nie ändert. Das ist die einzige Aufgabe von const in C.
Natürlich darf der Compiler bzw. Linker sich das zunutze machen, indem
er die Variable dann in den Flash legt, sofern das geht. Das ist aber in
gewissem Sinne auch eine Optimierung.
> Manchmal braucht man genau das genau SO - und zwar derart, daß der> Compiler daran nichts herum"optimiert".
Dann muss man dem Compiler eben ausdrücklich sagen, dass er das nicht
tun soll. Genau dafür wäre volatile da.
Rolf M. schrieb:> Nein. C++ verpflichtet nicht zu irgendwelchen Optimierungen.
Das ist technisch korrekt. Aber man könnte "umgangssprachlich" sagen,
dass es in C++ verpflichtende RVO gibt.
Rolf M. schrieb:> Mit const sagt man dem Compiler lediglich, dass er annehmen darf, dass> sich der Inhalt nie ändert.
Nicht ganz: man sagt ihm, dass er keine Änderungsversuche darauf
zulassen darf.
Aber "const volatile" ist ganz legal, und auch als Erklärung
dokumentiert als "maybe modified by hardware".
Was wäre denn für einen Compiler/Compilerbauer der Unterschied zwischen
"const weak" und "const extern"? In beiden Fällen kann er die Werte erst
beim Linken einsetzen.
Walter T. schrieb:> Was wäre denn für einen Compiler/Compilerbauer der Unterschied zwischen> "const weak" und "const extern"? In beiden Fällen kann er die Werte erst> beim Linken einsetzen.
Wenn die Variable zweimal definiert ist, einmal mit weak und einmal
ohne, dann bekommt die ohne den Vorrang. Wenn keine von beiden weak ist,
gibt es einen Fehler.
Walter T. schrieb:> Was wäre denn für einen Compiler/Compilerbauer der Unterschied zwischen> "const weak" und "const extern"? In beiden Fällen kann er die Werte erst> beim Linken einsetzen.
Es geht nicht ums einsetzen, da C im Gegensatz zu C++ nicht einsetzt.
Zumindest nicht braucht.
Es geht darum, ob eine Definition durch eine zweite ersetzt werden
darf.
Mit einer lib ist das normal, aber in C immer für ein ganzes C-File,
also alle Funktionen und variablen darin.
Mit weak auch für einzelne
Wenn ein C File nur int a und b und Funktion f enthält, dann kann ich im
Projekt alle drei entweder selber neu definieren oder keine.
Mit weak a könnte ich stattdessen a neu definieren und b und f werden
aus der lib genommen.
Walter T. schrieb:> as wäre denn für einen Compiler/Compilerbauer der Unterschied zwischen> "const weak" und "const extern"? In beiden Fällen kann er die Werte erst> beim Linken einsetzen.
Die Frage bezieht sich auf die Aussage von Jörg
Beitrag "Re: C: Konstante weak definieren"
Rolf M. schrieb:> Das kann gar nicht die Aufgabe von const sein, aus einem einfachen> Grund: C als Sprache weiß überhaupt nix von RAM oder Flash.
Denke doch erstmal nach!
Selbstverständlich weiß ein jeder Compiler (auch ein C-Compiler) zu
unterscheiden zwischen Zeugs, was in den Code kommt und Zeugs, wofür
lediglich Platz reserviert wird.
Das gehört zu den elementaren Aufgaben eines Compilers!
Begreife mal, daß sogenannte Hochsprachen (POS: problemorientierte
Sprachen) eben genau zu dem Zweck erdacht worden sind, daß man sich als
Programmierer nicht mit der Maschinenebene herumschlagen muß, wie das in
Assembler vonnöten ist. Dein angeblicher Grund ist eine völlig unsinnige
Annahme, denn es ist nicht die Programmiersprache, sondern der Compiler
(kurz: die Toolchain), der von Ram und Rom und so weiter wissen muß.
Letztendlich ist es egal, ob der Code in einen Flash im µC oder in ein
schreibgeschütztes Code-Segment im PC kommt: Wichtig ist nur, daß klar
ist, ob das eine Variable ist, für die man Platz im schreib- und
lesbaren Speicher reservieren muß - oder ob das eine Konstante ist, die
entsprechend ihres Typs ein oder mehrere Bytes groß ist und genau so wie
die Bytes des Maschinencodes in das Codesegment/Flash hinein kommt. Und
genau für diese Unterscheidung ist 'const' zuständig.
Rolf M. schrieb:> Dann muss man dem Compiler eben ausdrücklich sagen, dass er das nicht> tun soll. Genau dafür wäre volatile da.
Das ist schon das zweite totale Mißverständnis deinerseits!
Nein, der Zweck von 'volatile' ist ein Workaround um den Fakt, daß C
kein sauberes Modulkonzept kennt und deshalb nicht unterscheiden kann,
ob ein Stück Code den exclusiven Zugriff auf eine Variable hat oder
nicht.
Deswegen ist es zum Steuern von eventuellen Optimierungen notwendig,
Variablen, die sich durch andere Instanzen ändern können (Nachbar-Thread
oder Hardware oder Interrupt oder mal bloß ein Zugriff per 'extern' von
einer anderen Quelle aus) so zu kennzeichnen, daß der Compiler für diese
keine lokale Kopie zwecks Optimierung erzeugt, sondern Lesezugriffe
immer direkt codiert. Das hat überhaupt nichts mit der Anordnung der
Variaben/Konstanten im Ram- oder Code-Segment zu tun.
W.S.
W.S. schrieb:> Nein, der Zweck von 'volatile' ist ein Workaround um den Fakt, daß C> kein sauberes Modulkonzept kennt und deshalb nicht unterscheiden kann,> ob ein Stück Code den exclusiven Zugriff auf eine Variable hat oder> nicht.
Absolut nicht.
Bitte lies dir als erstes mal durch, was der Standard dazu sagt.
W.S. schrieb:> Rolf M. schrieb:>> Das kann gar nicht die Aufgabe von const sein, aus einem einfachen>> Grund: C als Sprache weiß überhaupt nix von RAM oder Flash.>> Denke doch erstmal nach!>> Selbstverständlich weiß ein jeder Compiler (auch ein C-Compiler) zu> unterscheiden zwischen Zeugs, was in den Code kommt und Zeugs, wofür> lediglich Platz reserviert wird.
Ich hatte ganz bewusst von "C als Sprache" geschrieben, nicht vom
Compiler. Schade, dass du das übersehen hast.
Natürlich weiß der Compiler, wo er die Daten hinsteckt, aber das ist
dessen Implementierungsdetail und nicht Bestandteil der Sprache selbst.
const dagegen ist Bestandteil der Sprache.
> Das gehört zu den elementaren Aufgaben eines Compilers!
Ein Compiler für PC-Anwendungen kann in der Regel gar nichts in einen
Flash stecken. Es wäre auch überhaupt nicht sinnvoll. Dennoch gibt es
dort const, und es wird auch genutzt. Und es wurde auch schon bei
Compilern für DOS benutzt, wo es auch keine Read-Only-Segmente gab.
> Begreife mal, daß sogenannte Hochsprachen (POS: problemorientierte> Sprachen) eben genau zu dem Zweck erdacht worden sind, daß man sich als> Programmierer nicht mit der Maschinenebene herumschlagen muß, wie das in> Assembler vonnöten ist.
Ja, eben. Deshalb definiert die Sprache von sich auch auch nicht so
Dinge wie Flash und RAM. Darum kümmert sich der Compiler.
> Dein angeblicher Grund ist eine völlig unsinnige Annahme, denn es ist nicht> die Programmiersprache, sondern der Compiler (kurz: die Toolchain), der von> Ram und Rom und so weiter wissen muß.
Das bestätigt eher meine Aussage, denn das ist genau das, was ich
geschrieben habe. Dagegen hast du beim Lesen meines Postings offenbar
die Sprache mit dem Compiler verwechselt.
> Rolf M. schrieb:>> Dann muss man dem Compiler eben ausdrücklich sagen, dass er das nicht>> tun soll. Genau dafür wäre volatile da.>> Das ist schon das zweite totale Mißverständnis deinerseits!>> Nein, der Zweck von 'volatile' ist ein Workaround um den Fakt, daß C> kein sauberes Modulkonzept kennt und deshalb nicht unterscheiden kann,> ob ein Stück Code den exclusiven Zugriff auf eine Variable hat oder> nicht.
Das ist gelinde gesagt Blödsinn. Mit Modulen hat das überhaupt nichts zu
tun. Volatile dient dazu, dass alle Zugriffe auf den Speicher auch
wirklich ausgeführt werden, und das ist hier in diesem Fall
erforderlich.
> Deswegen ist es zum Steuern von eventuellen Optimierungen notwendig,> Variablen, die sich durch andere Instanzen ändern können (Nachbar-Thread> oder Hardware oder Interrupt oder mal bloß ein Zugriff per 'extern' von> einer anderen Quelle aus) so zu kennzeichnen, daß der Compiler für diese> keine lokale Kopie zwecks Optimierung erzeugt, sondern Lesezugriffe> immer direkt codiert.
Das stimmt, abgesehen von "bloß ein Zugriff per 'extern'". Da ist ein
volatile unnötig. Es ist nur dann erforderlich, wenn ein Zugriff
außerhalb des normalen Programmflusses passiert, also wie du schon
schreibst, durch einen Interrupt, durch externe Hardware oder durch
einen anderen Thread.
> Das hat überhaupt nichts mit der Anordnung der Variaben/Konstanten im Ram-> oder Code-Segment zu tun.
Natürlich nicht. Das habe ich auch nicht behauptet. Es hat aber damit zu
tun, dass hier der Wert der const-Variablen quasi nach dem Compilieren
und beim Linken durch einen anderen ersetzt werden soll. Das
funktioniert nur, wenn auch darauf zugegriffen wird und der Wert nicht
z.B. einfach direkt im Code eingesetzt wird. Das kann man mit volatile
sicherstellen.
W.S. schrieb:> Eigentlich ist das eben nicht der Sinn des Ganzen, sondern der Sinn (und> die Anwendung) ist, daß eben diese "Variable" nicht im RAM angeordnet> sein soll, sondern im Flash.
Dann wäre das Verwenden von "const" auf einem System ohne Flash (z.B. PC
mit Windows oder Linux: nur RAM) also ein Fehler?!?
Deine Erklärung ist einfach falsch. "const" sagt dem Compiler, dass der
Wert dieser Variablen vom Programm nicht geändert werden darf.
Quelle für Deine Behauptung?
W.S. schrieb:> Nö. Eigentlich ist das eben nicht der Sinn des Ganzen, sondern der Sinn> (und die Anwendung) ist, daß eben diese "Variable" nicht im RAM> angeordnet sein soll, sondern im Flash.
Mal wieder keine Ahnung und zu engstirnig?
Was ist denn mit Prozessoren welche erstmal ihr ganzes Programm per ROM
Bootloader vom QSPI Flash in den DRAM kopieren und dann vollständig
daraus laufen?
Offensichtlich ist deine "Argumentation" mal wieder hahnebüchen und
löchrig!
Jörg hat da schon recht.
Daher bitte ich darum:
W.S. schrieb:> Denke doch erstmal nach!
Rolf M. schrieb:> weak gibt es in C gar nicht
guter Aspekt; kenne ich nämlich auch nicht ... aber vielleicht haben sie
es ja im neuesten Standard dazu gekittert.
Außerdem:
https://en.wikipedia.org/wiki/Weak_symbol
Weak symbols are not mentioned by the C or C++ language standards; as
such, inserting them into code is not very portable.
So gewöhnt man sich schlechten Programmierstil an ;-)
Rolf M. schrieb:> Das ist gelinde gesagt Blödsinn. Mit Modulen hat das überhaupt nichts zu> tun. Volatile dient dazu, dass alle Zugriffe auf den Speicher auch> wirklich ausgeführt werden, und das ist hier in diesem Fall> erforderlich.
Das hat aber sehr wohl mit dem fehlenden Modulkonzept zu tun!
Im Grunde könnte der Compiler für jeden Lesezugriff auf eine Variable
eben auf diese zugreifen. Macht er aber aus Optimierungsgründen oftmals
nicht.
Jedoch kann ein C-Compiler bei globalen Variablen oder gar
Hardware-Registern eben nicht feststellen, ob sich der Inhalt eben
dieser Variable aus Gründen ändern kann, die außerhalb des
Sichtbereiches der vorliegenden Quelle stehen.
Hätte man in C ein Modulkonzept, was wie in Pascal ganz klar festlegt,
was irgend eine andere Instanz überhaupt sehen kann und was nicht, dann
bräuchte man sowas wie 'volatile' überhaupt nicht. Grund: der Compiler
könnte selbst feststellen, ob in der Zwischenzeit, wo der gerade
aktuelle Code läuft, von woanders ein Zugriff überhaupt möglich ist oder
nicht.
In C kann man im Prinzip jede irgendwo vorkommende Variable mit 'extern
typ name' oder schlichtweg über das Einbinden der .h (sofern dort diese
Variable erwähnt ist) erreichen. Damit ist der Compiler ausgehebelt, er
kann nicht feststellen, ob die Variable von woanders her erreichbar ist
oder nicht.
Und genau DAS ist der eigentliche Punkt.
Du hast bloß nicht gründlich genug nachgedacht.
Und hier haben wir noch einen, der nicht nachgedacht hat:
Frank M. schrieb:> Dann wäre das Verwenden von "const" auf einem System ohne Flash (z.B. PC> mit Windows oder Linux: nur RAM) also ein Fehler?!?
Soviel Nicht-Denken-Wollen ärgert mich.
Also für die Langsamdenker mal im Einzelnen:
1. const benötigt eine Wertfestlegung (const double a = 3.1415; ). Ist
dir dieses klar?
2. und warum benötigt const eine Wertfestlegung? Ist dir der tiefere
Grund dafür bewußt? Man könnte ja auch per #define a 3.1415 dem
Augenschein nach dasselbe tun -aber der Augenschein trügt.
3. Der Grund ist, daß diese 3.1415 eben nicht in irgendwelche
Maschinenbefehle eingebaut wird, sondern tatsächlich eine Variable ist,
die jedoch im CODE steht. Im Mikrocontroller also im Flash, am PC je
nach OS in einem schreibgeschützten (oder nicht schreibgeschützten)
Stück RAM (wäre vom Prinzip her dasselbe wie Flash: R/O und nicht R/W).
Das ist etwas anderes als das Vereinbaren einer Variablen, für die man
ja nur Platz reservieren muß. Hast du das jetzt begriffen?
> Deine Erklärung ist einfach falsch. "const" sagt dem Compiler, dass der> Wert dieser Variablen vom Programm nicht geändert werden darf.
Siehe oben, du liegst falsch. Der Hauptgrund ist, daß diese Variable ein
Teil des zu erzeugenden Codes wird und nicht, daß der Compiler weiß, daß
man sie nicht beschreiben darf. Das ist ne Schlußfolgerung, die zwar
logisch, am PC jedoch oftmal völlig falsch ist. Erinnere dich mal an die
Zeiten von DOS: dort konnte man const vereinbaren und dennoch drauf
herumschreiben. Ja, das ging.
> Quelle für Deine Behauptung?
Jede .exe Datei zum Beispiel.
Also begreife mal:
const ist dafür, daß etwas in den Code kommt - und zwar nicht implizit
in den Maschinenbefehlen, sondern explizit als typisierte und mit Wert
versehene Variable.
volatile ist dafür, daß man dem Compiler ansagt, daß die Variable auch
von anderen Instanzen geändert werden kann und der Compiler nicht die
volle Kontrolle darüber hat - und das ist eine Spätfolge davon, daß in C
einfach mit Header-Dateien gearbeitet wird, was so ziemlich das
Gegenteil eines Modulkonzeptes ist und keinerlei Kapselung ermöglicht.
Ist dir das nun klar?
Ich habe nämlich den Eindruck, daß du nur stänkern wolltest.
Jörg W. schrieb:> W.S. schrieb:>> Nein, der Zweck von 'volatile' ist ein Workaround um den Fakt, daß C>> kein sauberes Modulkonzept kennt und deshalb nicht unterscheiden kann,>> ob ein Stück Code den exclusiven Zugriff auf eine Variable hat oder>> nicht.>> Absolut nicht.
Absolut doch.
Hab das soeben noch einmal erklärt, siehe dieser Beitrag. Es gibt
keinerlei sonstigen Grund für 'volatile'. Auch nicht in irgend einem
Standard: der Grund für die Notwendigkeit von volatile in C ist nicht,
daß es im Standard steht, sondern daß man dem Compiler etwas ansagen
muß, was er aufgrund eines Mangels in der Sprachdefinition von selbst
nicht wissen kann. So herum.
So, Leute - im Grunde ärgert es mich nicht, daß ihr so tief mit der Nase
in der C-Furche steckt, sondern es ist bedauerlich, daß ihr es nicht für
nötig haltet, die Nase mal zu erheben und über den Rand der Furche zu
schauen.
W.S.
ohne Account schrieb:> Rolf M. schrieb:>> weak gibt es in C gar nicht>> guter Aspekt; kenne ich nämlich auch nicht ... aber vielleicht haben sie> es ja im neuesten Standard dazu gekittert.
und:
ohne Account schrieb:> Weak symbols are not mentioned by the C or C++ language standards; as> such, inserting them into code is not very portable.>> So gewöhnt man sich schlechten Programmierstil an ;-)
Gröhl... Wer es nicht begreift, daß 'weak' eine zwingend einzuführende
Sache ist, die ganz speziell für das Programmieren von
Cortex-Architekturen erforderlich ist, der hat die letzten 10 Jahre
geschlafen.
Es ist eben kein schlechter Programmierstil, sondern eine
Notwendigkeit, die allerdings auf Assembler-Ebene hätte bleiben können,
wenn es nicht fanatische C-Anhänger gegeben hätte, die die Forderung
aufgestellt hatten, daß sie selbst den Startup-Code ebenfalls in C
formuliert haben wollen. Man hätte das abschlägig beantworten können und
dann wäre weak niemals irgendwo in C aufgetaucht. Ist aber so nicht
gelaufen.
Selbstverständlich ist 'weak' überhaupt nicht als portable vorgesehen.
Das ist ebenso plattformspeziell wie die Adressierung per CS:IP beim
8086. Warum weiß man hier - in einem dedizierten MIKROCONTOLLER Forum
- so etwas nicht?
W.S.
W.S. schrieb:> In C kann man im Prinzip jede irgendwo vorkommende Variable mit 'extern> typ name' oder schlichtweg über das Einbinden der .h (sofern dort diese> Variable erwähnt ist) erreichen.
Das ist falsch.
W.S. schrieb:> Hätte man in C ein Modulkonzept, was wie in Pascal ganz klar festlegt,> was irgend eine andere Instanz überhaupt sehen kann und was nicht, dann> bräuchte man sowas wie 'volatile' überhaupt nicht. Grund: der Compiler> könnte selbst feststellen, ob in der Zwischenzeit, wo der gerade> aktuelle Code läuft, von woanders ein Zugriff überhaupt möglich ist oder> nicht.
Und mit diesem Modulkonzept weiß der Compiler dann, wann sich ein
Hardwareregister ändert? Verkaufst du mir so ein Modul? Dann kann ich
meine Kristallkugel entsorgen...
Bist du dir sicher, dass du const in C verstanden hast? Wie genau
erklärst du
1
#include<stdlib.h>
2
intmain(){
3
intconstfoo=rand();
4
returnfoo;
5
}
Wird die Zufallszahl zur Laufzeit in den Flash/schreibgeschützten RAM
geschrieben?
W.S. schrieb:> Gröhl... Wer es nicht begreift, daß 'weak' eine zwingend einzuführende> Sache ist, die ganz speziell für das Programmieren von> Cortex-Architekturen erforderlich ist, der hat die letzten 10 Jahre> geschlafen.
Kannst du etwas genauer erklären, warum man für Cortex unbedingt week
braucht? Und warum man wegen dieser einen Architektur weak im C-Standard
einführen muss?
W.S. schrieb:> Im Grunde könnte der Compiler für jeden Lesezugriff auf eine Variable> eben auf diese zugreifen. Macht er aber aus Optimierungsgründen oftmals> nicht.
So weit noch richtig.
> Jedoch kann ein C-Compiler bei globalen Variablen oder gar> Hardware-Registern eben nicht feststellen, ob sich der Inhalt eben> dieser Variable aus Gründen ändern kann, die außerhalb des> Sichtbereiches der vorliegenden Quelle stehen.
Und das stimmt eben so nicht. Wie schon oben geschrieben, geht es nicht
um alle Änderungen außerhalb des Sichtbereichs des Quellcodes, sondern
um welche außerhalb des normalen Programmflusses. Also sobald
Nebenhäufigkeiten durch Threads, Interrupts oder gleichzeitige Zugriffe
durch externe Hardware vorkommen. Genau dann braucht man volatile, und
genau dafür ist es auch gemacht. Ob dies nun innerhalb eines Moduls oder
über mehrere Module hinweg passiert, ist dafür komplett unerheblich.
> Hätte man in C ein Modulkonzept, was wie in Pascal ganz klar festlegt,> was irgend eine andere Instanz überhaupt sehen kann und was nicht, dann> bräuchte man sowas wie 'volatile' überhaupt nicht.
Und wie sorgt dein Pascal-Modulkonzept dafür, dass der Compiler bei
einer Schleife wie:
1
while(true)
2
{
3
if(interrupt_flag)
4
{
5
led_pin=!led_pin;
6
interrupt_flag=false;
7
}
8
}
weiß, dass interrupt_flag plötzlich irgendwann mitten drin durch eine
ISR verändert werden kann? Und wie sorgt es dafür, dass für die Variable
led_pin, die in diesem Fall ein Hardware-Register ist, auch auf jeden
Fall immer ein vollständiger Schreibzugriff erfolgt, damit die LED auch
tatsächlich toggelt?
> In C kann man im Prinzip jede irgendwo vorkommende Variable mit 'extern> typ name' oder schlichtweg über das Einbinden der .h (sofern dort diese> Variable erwähnt ist) erreichen.
Ja, aber das hat erst mal nichts, aber überhaupt nichts, mit volatile zu
tun.
> Damit ist der Compiler ausgehebelt, er kann nicht feststellen, ob die> Variable von woanders her erreichbar ist oder nicht.
So lange ich (ohne Nebenläufigkeiten) keinen externen Code aufrufe, kann
dieser auch nicht auf die Variable zugreifen, da er gar nicht zur
Ausführung kommt. Deshalb braucht man dafür auch kein volatile. Mit
Nebenläufigkeiten braucht man volatile, allerdings ist das nicht
abhängig davon, ob der Code "woanders" steht oder nicht. Für das obige
ISR-Flag ist volatile nötig, sowohl wenn der Code in der selben C-Datei
steht, als auch, wenn er in einer anderen steht. Der Compiler weiß
nämlich nicht, dass die ISR nicht wie eine normale Funktion aufgerufen
werden muss, damit sie ausgeführt wird, sondern vielmehr durch externe
Hardware getriggert den Programmfluss plötzlich mittendrin unterbricht,
ohne dass dort je irgendwo ein Aufruf stehen würde.
> 2. und warum benötigt const eine Wertfestlegung? Ist dir der tiefere> Grund dafür bewußt?
Der ist doch ziemlich trivial. Wie soll da sonst je ein sinnvoller Wert
rein kommen, wenn nicht bei der Initialisierung? Mit const sichere ich
zu, dass ich später den Wert nicht mehr ändern werde. Es gibt also nur
eine einzige Stelle, wo man sie mit einem Wert belegen kann.
> 3. Der Grund ist, daß diese 3.1415 eben nicht in irgendwelche> Maschinenbefehle eingebaut wird, sondern tatsächlich eine Variable ist,> die jedoch im CODE steht.
Nein. Wo die steht, ist immer noch Implementierungsdetail. C macht da
keinerlei Vorgaben dazu.
> Im Mikrocontroller also im Flash, am PC je nach OS in einem> schreibgeschützten (oder nicht schreibgeschützten) Stück RAM (wäre vom> Prinzip her dasselbe wie Flash: R/O und nicht R/W).
Kann der Compiler so implementieren, muss er aber nicht. Und ist auch
oft nicht. Das hat auch erst mal nichts damit zu tun, ob es um einen PC
oder einen µC geht. Eine solche Unterscheidung kennt C gar nicht.
Ein Gegenbeispiel gibt es auch: AVR. Eine extern-Variable, die einfach
als const definiert ist, landet dort im RAM.
> Das ist etwas anderes als das Vereinbaren einer Variablen, für die man> ja nur Platz reservieren muß. Hast du das jetzt begriffen?
Es ist nichts anderes.
>> Deine Erklärung ist einfach falsch. "const" sagt dem Compiler, dass der>> Wert dieser Variablen vom Programm nicht geändert werden darf.>> Siehe oben, du liegst falsch. Der Hauptgrund ist, daß diese Variable ein> Teil des zu erzeugenden Codes wird und nicht, daß der Compiler weiß, daß> man sie nicht beschreiben darf. Das ist ne Schlußfolgerung, die zwar> logisch, am PC jedoch oftmal völlig falsch ist.
Es ist exakt umgekehrt.
> Erinnere dich mal an die Zeiten von DOS: dort konnte man const vereinbaren> und dennoch drauf herumschreiben. Ja, das ging.
Klar, wobei dabei nach C schon immer undefiniertes Verhalten rauskam.
Und in der Praxis hat es auch nicht immer funktioniert, je nach
Optimierungsverhalten des Compilers. Denn er darf ja auf Grund meiner
Zusicherung "const" annehmen, dass sich der Inhalt niemals ändert und
das entsprechend bei seinen Optimierungen berücksichtigen.
> Also begreife mal:> const ist dafür, daß etwas in den Code kommt - und zwar nicht implizit> in den Maschinenbefehlen, sondern explizit als typisierte und mit Wert> versehene Variable.
Kann beides sein, kann auch was anderes sein. Das bleibt komplett dem
Compiler überlassen, und es gibt in der Praxis alle Varianten. Wie du
das als Beleg für deine dem entgegenstehende Theorie sehen kannst,
erschließt sich mir beim besten Willen nicht.
> volatile ist dafür, daß man dem Compiler ansagt, daß die Variable auch> von anderen Instanzen geändert werden kann
Der wichtige Teil, der hier wieder fehlt: gleichzeitig! Wenn ich eine
Funktion ganz einfach aufrufe, sie eine Variable verändert und dann
wieder zurückkehrt, ist volatile selbstverständlich vollkommen
überflüssig, egal ob diese Funktion oder die Variable in der selben oder
einer anderen C-Datei definiert ist.
> Hab das soeben noch einmal erklärt, siehe dieser Beitrag. Es gibt> keinerlei sonstigen Grund für 'volatile'.
Oh mann… es gibt ausschließlich "sonstige Gründe", weil der von dir
angebrachte Grund einfach Unsinn ist.
> Auch nicht in irgend einem Standard: der Grund für die Notwendigkeit von> volatile in C ist nicht, daß es im Standard steht, sondern daß man dem> Compiler etwas ansagen muß, was er aufgrund eines Mangels in der> Sprachdefinition von selbst nicht wissen kann. So herum.
Auch nicht. Das volatile ist gerade das, was dafür sorgt, dass es diesen
Mangel in der Sprachdefinition nicht gibt.
> So, Leute - im Grunde ärgert es mich nicht, daß ihr so tief mit der Nase> in der C-Furche steckt, sondern es ist bedauerlich, daß ihr es nicht für> nötig haltet, die Nase mal zu erheben und über den Rand der Furche zu> schauen.
Mich ärgert es allerdings, dass du so daneben liegst und da so
hartnäckig daran festhältst, ohne mal darüber zu reflektieren, ob es
nicht vielleicht doch eben du bist, der hier falsch liegt.
W.S. schrieb:> Frank M. schrieb:>> Deine Erklärung ist einfach falsch. "const" sagt dem Compiler, dass der>> Wert dieser Variablen vom Programm nicht geändert werden darf.>> Siehe oben, du liegst falsch.
Tut mir leid, ich habe an dieser Stelle keine Lust mehr, mit jemandem zu
diskutieren, der überhaupt keine Ahnung hat, dies aber vehement vorgibt.
Ich bleibe bei meiner Aussage.
Lerne erstmal C, bevor Du weiter mit solchen Behauptungen kommst. Wenn
Du es tatsächlich geschafft hast, unter DOS in C eine const-Variable
tatsächlich zu ändern, war der verwendete Compiler schlichtweg
fehlerhaft. Das Schlüsselwort "const" gibt es für C seit 1984 (C++:
1983).
Rolf M. schrieb:>> volatile ist dafür, daß man dem Compiler ansagt, daß die Variable auch>> von anderen Instanzen geändert werden kann>> Der wichtige Teil, der hier wieder fehlt: gleichzeitig!
Gleichzeitig ist da wohl der falsche Begriff. volatile sagt dem
Compiler, daß sich die Variable JEDERZEIT durch Vorgänge, die völlig
ausserhalb seines Vorstellungsvermögens (sprich : Ausserhalb des Scopes
der Sprachdefinition) liegen, ändern kann.
Oliver
W.S. schrieb:> Nö. Eigentlich ist das eben nicht der Sinn des Ganzen, sondern der Sinn> (und die Anwendung) ist, daß eben diese "Variable" nicht im RAM> angeordnet sein soll, sondern im Flash.
Zitat aus dem Standard (hier C++17 draft, aber egal):
1
134)The implementation may place a const object that is not volatile in a read-only region of storage. Moreover, the
2
implementation need not allocate storage for such an object if its address is never used.
Die Anordnung im "Flash" ist unverbindlich und implementationsabhängig,
und eine Existenz im Speicher überhaupt ist explizit nur dann gefordert,
wenn es unvermeidlich ist. Das kann daher gar nicht der Sinn des Ganzen
sein.
Oliver
Frank M. schrieb:> Tut mir leid, ich habe an dieser Stelle keine Lust mehr, mit jemandem zu> diskutieren, der überhaupt keine Ahnung hat, dies aber vehement vorgibt.> Ich bleibe bei meiner Aussage.
Das ist dein Problem.
Und ich bleibe bei meiner Aussage: const ist dafür da, eine KONSTANTE
und zwar eine typisierte Konstante zu erzeugen. Alles andere ist
nebensächlich, einschließlich Jörgs Herumhacken auf irgendwelchen
Standards. manchmal kommt mir Jörg vor wie Herr Palmström:
https://www.oppisworld.de/morgen/palm09.html
Anstatt den digitalen Tatsachen ins Auge zu sehen, blickt er lieber in
den Standard - und was da nicht steht, das gibt es auch nicht.
Uff.
So, jetzt weißt du wieder nicht, was eine typisierte Konstante ist. Ich
hab das ja weiter oben schon gesehen, hielt deinen dummen Spruch jedoch
für einen Scherz. Nun sehe ich, daß du das ernst meinst.
Also schaue dir mal das an:
1
inPascal:
2
var
3
SimplePi=3.1415;
4
TypisisertPi:double=3.1415;
5
6
oderinC:
7
#define SimplePi 3.1415
8
constdoubleTypisisertPi=3.1415;
Erkennst du an diesem Beispiel den gravierenden Unterschied zwischen
SimplePi und TypisiertPi ?
SimplePi wird bei Bedarf lediglich in irgendwelchen Maschinenbefehlen
verwendet, aber TypisiertPi erzeugt Code, also etwas, das nicht nur
Platz belegt, sondern auch mit einem Inhalt daherkommt und folglich
beim PC in die .EXE und damit auf die Disk kommt und am µC eben in den
Flash (wie ich bereits sagte).
Und letzteres gilt auch dann, wenn TypisiertPi beim Programmstart in den
RAM kopiert wird. Aus der Luft kommt es ja nicht, also muß es im
gespeicherten Code vorhanden sein.
Kapierst du das Ganze jetzt endlich?
W.S.
W.S. schrieb:> einschließlich Jörgs Herumhacken auf irgendwelchen Standards
Definierst du dir eigentlich auch deine eigenen Schrauben, oder hälst du
dich dort doch lieber an Standards?
Kann ja sein, dass du dir deine eigene Programmiersprache definierst,
aber es wäre dann fair gegenüber den anderen Forennutzern, wenn du
dieser zumindest einen anderen Namen geben würdest, "WS" vielleicht -
damit die anderen das nicht mit einer einigermaßen populären und
standardisierten Sprache verwechseln, was du da so definierst.
Sorry, mehr kann man dazu leider nicht sagen. Vernünftige Begriffe, auf
die sich alle anderen geeinigt haben, willst du ja schließlich nicht
verwenden.
W.S. schrieb:> SimplePi wird bei Bedarf lediglich in irgendwelchen Maschinenbefehlen> verwendet, aber TypisiertPi erzeugt Code, also etwas, das nicht nur> Platz belegt, sondern auch mit einem Inhalt daherkommt und folglich> beim PC in die .EXE und damit auf die Disk kommt und am µC eben in den> Flash (wie ich bereits sagte).
Kannst du kein Englisch, oder warum verstehst du den, von Oliver S.
zietierten, Ausschnitt aus dem Standard nicht? Oder verstehe ich nicht
was du mit "erzeugt Code" und "belegt Platz" ausdrücken willst?
Walter T. schrieb:> Ich will in einer .c-Datei ein "Default" einer> (struct)-Konfigurationsvariablen anlegen, die aber in einer anderen> Datei überschreiben können.
Das ist nur sinnvoll, wenn is unterschiedliche Generieungsvarianten
gibt, und die werden üblicherweise über die Generierungsumgebung
verwaltet, z.B. über ein Makefile. Und genau dort kannst du
unterschiedliche Generierungsvarianten vor Belegung "A" oder "B"
festlegen.
Resultat wären etwa:
* Unterschiedliche Präprozessor-Defines je nach Variante, also gcc -D...
* Unterschiedliche Module mit der Vorbelegung wie module-A.c und
module-B.c, wobei nur genau eines der Module wirklich gelinkt wird.
W.S. schrieb:> Und ich bleibe bei meiner Aussage: const ist dafür da, eine KONSTANTE> und zwar eine typisierte Konstante zu erzeugen. Alles andere ist> nebensächlich
Das ist auf Quelltextebene richtig, mit allen Vorteilen einer
typischeren Programmierung gegenüber einer define-Konstanten. Im
kompilierten Programmcode landet die const-Variable aber nur, wenn der
Compiler die nicht wegoptimieren kann. Meistens kann und tut er das
aber.
Oliver
W.S. schrieb:> Kapierst du das Ganze jetzt endlich?
Du hast mal wieder nix kapiert!
Der Verleich mit dem precompiler und einer const ist ja echt mal wieder
hanebüchen.
Sowas kann nur von dir kommen.
Nur mal so als tip:
ARM z.B. legt lokales direkt hinter den Codeblock.
Das wäre jetzt dein "erzeugt Code" und "belegt Platz".
Das const double kommt übrigens nicht ind en Flash bei ARM, der Compiler
is mal wieder schlauer als du ;)
1
voidws_kann_mal_wieder_nix(void){
2
printf("thats pi: %f",SimplePi);
3
}
SimplePi ist einmal const und einmal das define.
Dann jeweils mal copiled und:
Bei beiden kommt übrigens raus:
Die "komisch" disassemblierten Befehle ab 8000d0c sind übrigens die
lokalen Konstanten ;)
DU solltest eben einfach mal leise sein wenn sich die Erwachsenen
unterhalten!
Mw E. schrieb:> DU solltest eben einfach mal leise sein wenn sich die Erwachsenen> unterhalten!
Bitte nicht auf diesem Niveau.
W.S. ist streitbar (und natürlich sind alle anderen die Geisterfahrer,
nur er nicht), aber diese Tonart brauchen wir nicht im Forum.
Jörg W. schrieb:> Mw E. schrieb:>> DU solltest eben einfach mal leise sein wenn sich die Erwachsenen>> unterhalten!>> Bitte nicht auf diesem Niveau.
Das ist halt das Niveau von W.S., an das sich die anderen hier anpassen:
W.S. schrieb:> Soviel Nicht-Denken-Wollen ärgert mich.>> Also für die Langsamdenker mal im Einzelnen:W.S. schrieb:> Gröhl... Wer es nicht begreift,W.S. schrieb:> hielt deinen dummen Spruch jedoch für einen Scherz
Rolf M. schrieb:> Das ist halt das Niveau von W.S., an das sich die anderen hier anpassen:
Stimmt auch wieder.
Da in diesem Thread sowieso alles gesagt worden ist, was zum Thema
gehört, würde ich Rolfs Worte einfach mal als Abschlussworte so stehen
lassen.
Thread beobachten
Seitenaufteilung abschalten