Hallo! Wie schon im Betreff zu lesen: Kann man eine Konstante in C verändern? Evtl. mit Tricks oder so? Ich persönlich will sowas nicht machen, habe aber bald Prüfung in Programmieren und eine Frage könnte so lauten. Danke schon mal im Voraus!
sucheRAT schrieb: > Kann man eine Konstante in C verändern? manchmal ja, manchmal nein. Wenn sie normal const ist und im RAM liegt könnte man das const wegcasten. Aber es kann genauso sein, das die Variable vom Compiler komplett eingespart wird oder das sie in einem ReadOnly Speicher liegt. Dann kannst du sie nicht ändern.
Hallo! Danke für die schnelle Antwort! Das heißt, wenn ich schreibe:
1 | const long var=3; |
2 | |
3 | (long)var=1; |
dann ist var=1? Lassen das die Compiler so zu? Oder nur manche? var bleibt aber noch eine Konstante oder? Du schreibst: >Aber es kann genauso sein, das die >Variable vom Compiler komplett eingespart wird oder das sie in einem >ReadOnly Speicher liegt. Dann kannst du sie nicht ändern. Gilt das auch für normale PCs? (Also keine uC oder so)
Peter II schrieb: > sucheRAT schrieb: >> Kann man eine Konstante in C verändern? > > manchmal ja, manchmal nein. Wenn sie normal const ist und im RAM liegt > könnte man das const wegcasten. Prima Tipp, voll der Griff ins Klo. C99 6.7.3 §5:
1 | If an attempt is made to modify an object defined with |
2 | a const-qualified type through use of an lvalue with |
3 | non-const-qualified type, the behavior is undefined. |
Johann L. schrieb: > Prima Tipp, voll der Griff ins Klo: mir ist selber klar, das man es nicht machen sollte, er wollte wissen ob es geht. Und ja es gibt Möglichkeiten auch const Variablen zu ändern.
sucheRAT schrieb: > Das heißt, wenn ich schreibe: > const long var=3; > > (long)var=1; > > dann ist var=1? > Lassen das die Compiler so zu? Oder nur manche? Nein, das geht nicht. Das geht: void main(void) { const long var=3; long *ptr; ptr = (long *) &var; *ptr = 1; }
Hallo, was lernen Programmierer die Konstanten benutzen und diese dann zur Laufzeit verändern wollen??? Vielleicht wie sie Variablen anlegen die sich nicht verändern lassen... Wenn ich eine Konstante brauche nehme ich sie und will diese ebend nicht verändern. Wenn ich was verändern will nehm ich halt eine Variabel. Oder macht man das bei esoterischem Programmieren... das ist wie Namentanzen. Da muss ich mein Unverständnis zum Ausdruck bringen. Also warum, wozu... Grüße aus Berlin
Könntest du den Schritt "ptr = (long *) &var;" bitte erklären? Castest du die Adresse von var zu einem Zeiger, den du den Zeiger ptr gleichsetzst?
sucheRAT schrieb: > Könntest du den Schritt "ptr = (long *) &var;" bitte erklären? wenn du das nicht versteht, dann solltest du doch Lieber Pointer lernen als fragen wie "kann man const ändern".
Rene Schube schrieb: > Da muss ich mein Unverständnis zum Ausdruck bringen. Du bringst Dein Unverständnis zum Ausdruck -- hättest Du aber bleiben lassen können. So unsinnig ist die Frage ja nicht, da man in C vieles hinbiegen kann, und insbesondere, da auf eine mögliche Prüfungsfrage verwiesen wurde. Na ja, immerhin habe ich gelernt, dass es den Herrn Johann L. hier wieder gibt, von dem hatte ich vor Jahren mal etwas kluges gelesen.
Konstanten residieren im ROM. Sie sind in klassischen Systemen nicht änderbar(weil in EPROMs). In Atmel µControllern gibt es allerdings die Möglichkeit, den Flash-Speicher (entspricht dem ROM) im laufenden BNetrieb zu ändern. Es geht also. Die Frage ist nur, wie oft willst du das machen? Das Datenblatt gibt 10.000 Schreibzyklen für den Flash an. Es würde höchstens für Korrekturen von Parametern gehen, die sich im Langzeitbetrieb ändern.
klausr schrieb: > sucheRAT schrieb: >> Das heißt, wenn ich schreibe: >> const long var=3; >> >> (long)var=1; >> >> dann ist var=1? >> Lassen das die Compiler so zu? Oder nur manche? > > Nein, das geht nicht. Das geht: > > void main(void) > { > const long var=3; > long *ptr; > ptr = (long *) &var; > *ptr = 1; > } So einfach gehts dann wohl doch nicht. int main(int argc, char* argv[]) { const int a=100; int * p; p = (int *) &a; *p = 1; printf("%i\n",a); printf("Hello World!\n"); return 0; } Wenn man das in MS-C++ mit dem Debugger Zeile für Zeile ausführt, dann wird zwar nach Ausführen von *p=1 im Debugger a=1 angezeigt, aber printf("%i\n",a) druckt weiterhin 100 für a aus. Der Compiler hat also bereits beim Kompilieren die Konstanten an verschiedenen Stellen bereits eingetragen.
Mücke schrieb: > Konstanten residieren im ROM. bei einem PC nicht. Dort liegen sie genauso im Ram wie normale Variablen.
@Peter II: Bei Zeigern kenne ich mich eh aus, ich verstehe nur den genannten Ausdruck nicht. Es macht ja im Normalfall keinen Sinn, einen Zeiger auf Konstante zu definieren. Normal würde man schreiben: long var; long *ptr; ptr= &var; Und wenn man einem Zeiger einen anderen Zeiger zuweist, schreibt man: ptr1=ptr2; Wenn die Typen unterschiedlich sind (geht das überhaupt??) würde man vermutlich schreiben müssen: long *ptr1; int *ptr2; ptr1=(long *)ptr2; Den Code "ptr = (long *) &var;" verstehe ich aber nicht. Deshalb wäre es nett, wenn du ihn mir erklären würdest. Und nochmal: Ich will sowas nicht machen. Aber mein Professor will vielleicht bei meiner Prüfung von mir wissen, wie es gehen KÖNNTE. @Helmut: Heißt das jetzt, es geht doch nicht? Oder hängt das vom Compiler/BS ab? Wo geht´s? Wo nicht?
Peter II schrieb: > bei einem PC nicht. Dort liegen sie genauso im Ram wie normale > Variablen. Ja klar, also wäre es doch einfach, den Offset dieser Konstanten im File zu ermitteln, um dann beim beim nächsten Laden derselben deren Inhalt zu ändern. Ich dachte, es ginge um eingebettete Systeme.
Salewski schrieb: > Rene Schube schrieb: >> Da muss ich mein Unverständnis zum Ausdruck bringen. > > Du bringst Dein Unverständnis zum Ausdruck -- hättest Du aber bleiben > lassen können. > So unsinnig ist die Frage ja nicht, da man in C vieles hinbiegen kann, > und insbesondere, da auf eine mögliche Prüfungsfrage verwiesen wurde. Mein Unverständnis gilt für das warum! Das man in C alle möglichen Schweinereien machen kann ist klar. Aber eine Konstante ist und bleibt konstant sowie eine Variable ebend variabel ist. So ist es gut und es gibt keinen Grund das zu ändern. In einer Prüfung sollte auch nicht abgefragt werden wie man sich ins Knie schiessen kann. Obwohl das ja der Sinn hinter C ist :) Grüße
Wenn Du einen cast nicht erkennst ... Lies Dir das mal durch: http://www.imb-jena.de/~gmueller/kurse/c_c++/c_const.html
sucheRAT schrieb: > Es macht ja im Normalfall keinen Sinn, einen Zeiger auf Konstante zu > definieren. und warum nicht. Warum sollte es kein Zeiger auf einen Konstanten String geben? const char* s = "adasdf";
Peter II schrieb: > und warum nicht. Warum sollte es kein Zeiger auf einen Konstanten String > geben? Schlechtes Beispiel, denn: Den kann man im occupierten Specherbereich suchen. Such mal nach einer unreferenzierten 64-bit Realzahl.
Rene Schube schrieb: > In einer Prüfung sollte auch nicht abgefragt werden wie man sich ins > Knie schiessen kann. Warum nicht? Eigentlich sogar mit recht -- man sollte schon wissen was einem mit C alles widerfahren kann. Da hat man eine Konstante definiert, gibt sie dann später aus, und wundert sich, weil man mit irgendwelchen wilden Zeigeroperationen willkürlich im Speicher herumgewirbelt hat. Aber vielleicht sollte doch jemand nochmal auf den Fragesteller antworten, da ist scheinbar noch einiges unklar. Zeiger auf Konstanten machen ja durchaus Sinn, was ihm wohl nicht so ganz klar ist. Ich werde dazu aber nichts sagen, ich bin kein C Experte, das Beispiel von Helmut S. hätte ich nicht unbedingt erwartet.
Nochmals: - Ich weiß, was ein Zeiger ist. - Ich weiß, was ein cast ist. - Ich weiß, was eine Konstante ist. Was ich nicht weiß, ist, was genau dieser Befehl macht: ptr = (long *) &var; Also diese Kombination von cast und Zuweisung. So wäre es mir logisch: ptr=&var; Die Adresse der Konstanten wird einem Zeiger zugewiesen. Meine Frage ist nun, warum das so nicht geht, also warum man die Adresse noch zu einem long-Zeiger casten muss.
sucheRAT schrieb: > Meine Frage ist nun, warum das so nicht geht, also warum man die Adresse > noch zu einem long-Zeiger casten muss. OK, wenn Du nur ein const hast macht der Compiler idR dasselbe wie mit #define also er schreibt den Wert direkt ins Compilat. Nimmst Du nun einen Pointer auf die Konstante muß der Compiler das dynamisch erledigen weil er ja weiß das da etwas darauf zeigt. Und nun überlege mal warum man nun einen expliziten cast braucht ...
Helmut S. schrieb: > Der Compiler hat also bereits beim Kompilieren die Konstanten an > verschiedenen Stellen bereits eingetragen. Genauer, der preprocessor nimmt die Ersetzung im Quelltext vor und der Compiler sieht nur die Zahl. Der inderekte Weg (Umweg) über pointer geht natürlich nur im RAM. Genau so kann man auch den Code zur Laufzeit verändern, aber nur im RAM.
Johann L. schrieb: > Peter II schrieb: >> sucheRAT schrieb: >>> Kann man eine Konstante in C verändern? >> >> manchmal ja, manchmal nein. Wenn sie normal const ist und im RAM liegt >> könnte man das const wegcasten. > > Prima Tipp, voll der Griff ins Klo. C99 6.7.3 §5: > >
1 | > If an attempt is made to modify an object defined with |
2 | > a const-qualified type through use of an lvalue with |
3 | > non-const-qualified type, the behavior is undefined. |
Genau das, und nichts anderes ist die richtige Antwort. Sag dem Prof, das es gegen die Spezifikationen verstößt; aber je nach Compiler natürlich möglich sein könnte. Ein Prof der nicht-spezifiziertes Programmieren unterstützt sollte es nicht geben.
RamRam schrieb: > Genauer, der preprocessor nimmt die Ersetzung im Quelltext vor und der > Compiler sieht nur die Zahl. Also ist dann 3 keine "konstante long Variable" sondern nur mehr "3" und es muss zu einer Variable gecastet werden. Warum dann nicht: ptr=&((long)var); ??? Bin jetzt total verwirrt....
RamRam schrieb: > Genauer, der preprocessor nimmt die Ersetzung im Quelltext vor und der > Compiler sieht nur die Zahl. Na??? Ich würde nicht erwarten, dass der Preprocessor das macht.
Beim Schreiben auf eine Konstante haut Dir der Compiler eine Fehlermeldung um die Ohren. Mit einem Cast sagst Du dem Compiler: "Ich weiß es besser als Du, schalte mal Deine Fehlererkennung ab". Ein Cast ohne Sinn und Verstand ist also kein Programmiertrick, sondern schlichtweg Unsinn. Wenn Du also sagst, mit einem Cast geht es, würde ich Dir als Prüfer eine glatte 6- geben.
sucheRAT schrieb: > @Peter II: > .... > > @Helmut: > > Heißt das jetzt, es geht doch nicht? Oder hängt das vom Compiler/BS ab? > Wo geht´s? Wo nicht? Die bisher vorgeschlagen Lösung funktioniert nicht mit MS-C++. Dieser Compiler ist so "schlau" und trägt überall im Programm an den Stellen in denen die Konstante als Wert verwendet wird deren Wert ein, also nicht den Verweis auf die const-Variable. Vielleicht könnte ja mal jemand das mit dem GCC testen. Im Moment phantasieren hier doch eine Menge Leute ohne es je probiert zu haben. Helmut
Helmut S. schrieb: > Die bisher vorgeschlagen Lösung funktioniert nicht mit MS-C++. du musst es nur richtig machen:
1 | const int i = rand(5); |
2 | |
3 | // i ändern siehe oben
|
4 | |
5 | printf("i=%d", i ); |
hier kann er kaum etwas wegoptimieren.
sucheRAT schrieb: >> Genauer, der preprocessor nimmt die Ersetzung im Quelltext vor und der >> Compiler sieht nur die Zahl. Bei #define ja, bei const nicht. > Also ist dann 3 keine "konstante long Variable" sondern nur mehr "3" Nein. Eine const ist dort nicht verwendbar, wo der Compiler einen konstanten Ausdruck erwartet. Anders in C++.
Helmut S. schrieb: > So einfach gehts dann wohl doch nicht. Naja, das, was wir hier treiben, ist auch undefined behavior. Der gcc-4.6.3 x86 gibt brav "3" und "1" aus, ob mit oder ohne Optimierung, wenn ich bei meinem Code printfs einfüge. Wichtig: Das es irgendwie "geht", heißt nicht, dass das legaler Code ist!
Habe es gerade probiert:
int main()
{
const long a=3;
long *ptr;
ptr=&a;
*ptr=1;
printf("a= %ld\n",a);
return 0;
}
funktioniert auch. Es kommt 1 am Bildschirm bei der Ausgabe.
Es gibt natürlich auch eine Warnung.
Bei der Lösung von Peter II gibt´s dann auch keine Warnung.
Ich verwende CodeBlocks unter Linux mit dem Compiler GCC.
Die Warnung lautet konkret: "Zuweisung streicht Qualifizierer »const« von Zeiger-Zieltyp"
RamRam schrieb: > Genauer, der preprocessor nimmt die Ersetzung im Quelltext vor und der > Compiler sieht nur die Zahl. Es erstaunt mich immer wieder, welche phantastischen Fähigkeiten dem Präprozessor angedichtet werden.
Jetzt wirds interessant. Der gleiche Quelltext, einmal als C und einmal
als C++ kompiliert, bringt unterschiedliche Ergebnisse!
klaus@LittlX:~/src$ gcc -Wall const1.c
klaus@LittlX:~/src$ ./a.out
1
Hello World!
klaus@LittlX:~/src$ gcc -Wall const1.cpp
klaus@LittlX:~/src$ ./a.out
100
Hello World!
klaus@LittlX:~/src$ cat const1.c
#include <stdio.h>
int main(int argc, char* argv[])
{
const int a=100;
int * p;
p = (int *) &a;
*p = 1;
printf("%i\n",a);
printf("Hello World!\n");
return 0;
}
klaus@LittlX:~/src$ cat const1.cpp
#include <stdio.h>
int main(int argc, char* argv[])
{
const int a=100;
int * p;
p = (int *) &a;
*p = 1;
printf("%i\n",a);
printf("Hello World!\n");
return 0;
}
klausr schrieb: > Jetzt wirds interessant. Der gleiche Quelltext, einmal als C und einmal > als C++ kompiliert, bringt unterschiedliche Ergebnisse!Klar. 7 Wenn du es mit einem Pascal-Compiler übersetzt, dann auch. C und C++ sind zwar ähnlich, aber nicht identisch. Und du hast exakt einen der Unterschiede gefunden. In C++ ist const vergleichbare mit einer lexikalische Konstante. In C nicht. In C geht beispielsweise dies nicht: const int N = 10; static int a[N]; In C++ hingegen schon.
Peter II schrieb: > Helmut S. schrieb: >> Die bisher vorgeschlagen Lösung funktioniert nicht mit MS-C++. > > du musst es nur richtig machen: > > const int i = rand(5); > > // i ändern siehe oben > > printf("i=%d", i ); > > hier kann er kaum etwas wegoptimieren. Wenn der const i so wie oben rand() zugewiesen wird, dann funktioniert es auch in MS-C++. Wer macht denn Konstanten mit rand()?
Helmut S. schrieb: > Wer macht denn Konstanten mit rand()? ist doch nur ein Beispiel. Es kann doch auch sein das es eine Funktion gibt.
1 | void foo( const int& a ) { |
2 | // a dürfte nie geändert werden, kann aber ...
|
3 | }
|
4 | |
5 | int i = 12; |
6 | |
7 | foo( i ); |
A. K. schrieb: > In C++ ist const vergleichbar mit einer lexikalische Konstante. Um keine Haarspalter auf den Plan zu rufen: Es ist nicht damit identisch. Nur ist eben in C++ eine const auch dort verwendbar, wo die Sprache einen konstanten Ausdruck verlangt. In C nicht.
Helmut S. schrieb: > Wer macht denn Konstanten mit rand() Keiner, denn es handelt sich um eine initialisierte Variable, die als const deklariert wird. Es wird Speicher (RAM) verwendet und die Initialisierung erfolgt erst zu Laufzeit. Bei direkter Angabe einer Zahl wird beim Übersetzen optimiert und direkt die Zahl eingesetzt.
RamRam schrieb: > Bei direkter Angabe einer Zahl wird beim Übersetzen optimiert und direkt > die Zahl eingesetzt. Ein C Compiler kann das machen, muss es aber nicht.
Kannst ja noch die verschiedenen Optimierungseinstellungen durchprobieren. Ist aber in etwa so sinnvoll wie Kaffeesatzlesen.
A. K. schrieb: > Ein C Compiler kann das machen, muss es aber nicht. Jaaaaaaaaaaaaa!!! Aber bei einer initialisierten Variable kann er es noch nicht einmal!
RamRam schrieb: > Jaaaaaaaaaaaaa!!! Aber bei einer initialisierten Variable kann er es > noch nicht einmal! Doch, manchmal schon. ;-) Wenn er weiss, dass sich der Wert nicht ändert.
RamRam schrieb: > Aber bei einer initialisierten Variable Ok, bei einer zur Laufzeit initialisierten Variable ... Offtopic: Bitte weniger Klugsch.. und mehr zur Sache beitragen.
RamRam schrieb: > Ok, bei einer zur Laufzeit initialisierten Variable ... Auch da darf er. > Bitte weniger Klugsch.. und mehr zur Sache beitragen. Das eigentliche Thema ist m.E. längst geklärt.
Salewski, Stefan schrieb: > Rene Schube schrieb: >> In einer Prüfung sollte auch nicht abgefragt werden wie man sich ins >> Knie schiessen kann. > > Warum nicht? Eigentlich sogar mit recht -- man sollte schon wissen was > einem mit C alles widerfahren kann. Das Problem ist, daß es funktionieren kann_ aber nicht _muss. Es können je nach Zielplattform, Compiler und dessen Parameter wie Optimierung völlig unterschiedliche Dinge passieren. Ausprobieren ist daher für die Beantwortung der Frage sinnlos, weil es keine allgemeingültige Antwort gibt. Die korrekte Antwort auf die Frage wäre, daß das Verhalten des Programms ab der Stelle (also nicht nur das Verhalten der einen Zeile, sondern des kompletten restlichen Programm-Ablaufs) undefiniert ist, wenn man es versucht.
> Ich persönlich will sowas nicht machen, habe aber bald Prüfung > in Programmieren und eine Frage könnte so lauten. Das wäre dann eine Trickfrage. Ungefähr so, wie in der Führerscheinprüfung: Es ist nachts, 4 Uhr früh. Sie fahren über Land, weit und breit ist nichts und sie kommen an eine mit einer Ampel geregelte Kreuzung. Die Ampel zeigt in Ihrer Fahrtrichtung rot. Dürfen sie diese Ampel überfahren, da es doch 4 Uhr früh ist, sie alle anderen Fahrtrichtungen auf 5 Kilometer einsehen können und sie sich sicher sind, dass von allen anderen Fahrtrichtungen keine Fahrzeuge kommen?
Rolf Magnus schrieb: > Salewski, Stefan schrieb: >> Rene Schube schrieb: >>> In einer Prüfung sollte auch nicht abgefragt werden wie man sich ins >>> Knie schiessen kann. >> >> Warum nicht? Eigentlich sogar mit recht -- man sollte schon wissen was >> einem mit C alles widerfahren kann. > > Das Problem ist, daß es funktionieren kann_ aber nicht _muss. Es > können je nach Zielplattform, Compiler und dessen Parameter wie > Optimierung völlig unterschiedliche Dinge passieren. Ausprobieren ist > daher für die Beantwortung der Frage sinnlos, weil es keine > allgemeingültige Antwort gibt. Die korrekte Antwort auf die Frage wäre, > daß das Verhalten des Programms ab der Stelle (also nicht nur das > Verhalten der einen Zeile, sondern des kompletten restlichen > Programm-Ablaufs) undefiniert ist, wenn man es versucht. Absolut richtig. Es schadet aber auch nichts, wenn man ein paar typische mögliche Fehlerbilder kennt. Denn die Umkehrung ist im allgemeinen in der Praxis sehr viel schwieriger: Aus dem Fehlerbild zu erkennen, wo ein potentielles Problem sitzen könnte. Denn auch wenn das Verhalten undefiniert ist, und es theoretisch möglich wäre, dass das Programm die Festplatte formatiert oder den 3. Weltkrieg auslöst (zumindest wäre es aus C Sicht ein zulässiges Programmverhalten), so sind es in der Praxis dann doch lediglich ein paar typische Szenarien, die auftreten. So lange im Hinterkopf behalten wird, dass es sich immer noch um einen Fehler handelt, selbst wenn das Programmverhalten das erwartete ist, so lange spricht m.M nach nicht viel dagegen, da mal ein paar Versuche zu starten um zu sehen, was alles tatsächlich passieren kann.
Salewski schrieb: > da auf eine mögliche Prüfungsfrage verwiesen wurde. Sollte das ja wohl irgendwo mal behandelt worden sein... und dann sollte man das in den Lernunterlagen nachschlagen und die Frage ggf. in dem Konkretem Kontext stellen. 7 ist auch eine Konstante und mancher bezeichnet auch ein Define als Konstante... "const" wurde ja erst von den Antwortenden in den Raum geworfen.
Läubi .. schrieb: > 7 ist auch eine Konstante und mancher > bezeichnet auch ein Define als Konstante... "const" wurde ja erst von > den Antwortenden in den Raum geworfen. Also: die Frage wörtlich nehmen: sucheRAT schrieb: > Kann man eine Konstante in C verändern? Antwort: Ja. Am einfachsten, indem man mit dem Editor einen anderen Wert in den Sourcecode schreibt. ("zur Laufzeit" o.Ä. ist ja nicht gefordert)
Εrnst B✶ schrieb: > sucheRAT schrieb: >> Kann man eine Konstante in C verändern? > > Antwort: > Ja. > Am einfachsten, indem man mit dem Editor einen anderen Wert in den > Sourcecode schreibt. Aber dann muss der Editor in C geschrieben sein! :-))))
>> Am einfachsten, indem man mit dem Editor einen anderen Wert in den >> Sourcecode schreibt. In Anbetracht der Tatsache, dass es sich um eine potentielle Prüfungsfrage handelt, würde ich sogar genau diese Antwort forcieren ;) Ralf
Da es eine Pruefungsfrage ist, gibt es nur eine richtige Antwort: Die, die der Pruefer erwartet. Es ist leider so, dass Lehrkraefte auch bis rauf an die Universitaeten durch Halbwissen und Scheuklappendenken glaenzen. In meinem Studium habe ich viele Professoren mit seltsamen Pruefungsfragen erlebt, aber nicht einmal davon gehoert, dass es fuer C++ und andere Sprachen Standards gibt.
Gaja schrieb: > Da es eine Pruefungsfrage ist, gibt es nur eine richtige Antwort: Die, > die der Pruefer erwartet. Das kann ich bestätigen. Bestes Beispiel war unsere Dozentin für "Betrieblichekommunikation" (also deutsch): In der Klausur sollten wir die Gliederung für einen Geschäftsbrief aufschreiben. Als Hilfsmittel war der Duden erlaubt. Also haben wir das Beispiel für einen Geschäftsbrief aus dem Duden abgeschrieben, ist ja schließlich der Duden. Und was soll man sagen? gab natürlich keine Punkte dafür, weil das was im Duden stand, anders war, als das was wir im Unterricht hatten. Fazit: Selbst wenn es im Duden bzw. in Fachbüchern steht ist es falsch, wenn die Lehrkraft anderer Meinung ist! Und für sowas gibt es leider Beispiele wie Sand am Meer.
Läubi .. schrieb: > Sollte das ja wohl irgendwo mal behandelt worden sein... und dann sollte > man das in den Lernunterlagen nachschlagen und die Frage ggf. in dem > Konkretem Kontext stellen. 7 ist auch eine Konstante und mancher > bezeichnet auch ein Define als Konstante... "const" wurde ja erst von > den Antwortenden in den Raum geworfen. Im Kontext von ISO C ist von den dreien nur 7 eine Konstante. Εrnst B✶ schrieb: > Also: die Frage wörtlich nehmen: > > sucheRAT schrieb: >> Kann man eine Konstante in C verändern? > > Antwort: > Ja. > Am einfachsten, indem man mit dem Editor einen anderen Wert in den > Sourcecode schreibt. Dann hat man es aber nicht in C geändert, sondern im Editor. Man müßte dann vielleicht ein C-Programm schreiben, das den Quellcode entsprechend ändert. Gaja schrieb: > Es ist leider so, dass Lehrkraefte auch bis rauf an die Universitaeten > durch Halbwissen und Scheuklappendenken glaenzen. In meinem Studium habe > ich viele Professoren mit seltsamen Pruefungsfragen erlebt, aber nicht > einmal davon gehoert, dass es fuer C++ und andere Sprachen Standards > gibt. Viele haben auch noch nicht gehört, daß es nicht nur Standards, sondern sogar Normen gibt ;-) Mein Prof hat damals immerhin gleich in der ersten Vorlesung gesagt, daß bei ihm "ANSI C" auf dem Programm steht. Es war halt nur leider keins. Insofern bringt's halt auch nix, wenn er zwar weiß, daß es das gibt, aber leider nicht, was drin steht. Naja, mein Digitaltechnik-Prof hat auch ganz überzeugt erzählt, daß man beim x86 geschickterweise genau ein Byte als kleinste adressierbare Einheit gewählt hat. Nunja, kein Wunder, wenn man bedenkt, wie der Begriff "Byte" definiert ist.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.