C- Warning Message
 

Hallo!

Ich habe da ein Programm(in C) für meinen Taschenrechner(TI 200) geschrieben, doch bei einer Funktion gibts jedesmal eine Warning(jedoch keinen Error!!!), obwohl alles perfekt funktioniert.


Warning Message: Initialization discards qualifiers from pointer target type


Also vielleicht kann jemand helfen. Es läuft zwar alles prima, aber gerade deswegen kann ich nicht verstehen dass der Compiler eine Meldung ausspuckt!




Grüße,
Harri

also ich hab das ganze mal über gcc mit -Wall laufen lassen, der sagt mir nix.

ich seh auch auf anhieb keinen fehler.
welche zeile beschwert er sich eigentlich?

Jedesmal wenn ich erg="..." schreibe!


Naja, Hauptsache es läuft.



Viele Grüße,
Harri

Hmmm, meine C Kentnisse sind ja etwas eingerostet, aber sollte man nicht wo mal Speicher fuer erg reservieren?
Ev. regt er sich auf, dass man dem Pointer einen statischen String zuweist?

Ich dachte dass man das nur bei großen Daten machen muss. Bei dem Mini String sollte das also eigentlich nicht nötig sein!

Habs in Turbo C++ durchlaufen lassen, und dort gibts 0 Fehler/0 Warnungen!


Viele Grüße,
Harri

hi !

@m3_: stimmt, man muss für den string speicher reservieren.

wie groß der sting da ist, ist egal - ein "char" speichert genau 1 zeichen. also z.B. char buffer[20] verwenden

zuweisen kann man einen string (in C) nicht man muss dazu ein stringfunktion verwenden. z.B. strcpy(buffer,"stabil");

weoterer fehler: du vereinbarst in einer funktion einen char - dieser wird am stack angelegt. am ende der funktion gibts du einen zeiger auf eine stack variable zurück !
das führt früher oder später zu fehlern, da der stack nach dem verlassen der Fu. freigegeben wird, die variable also einfach zerstört wird.

Lösung: static verwenden, oder in der main funktion speicher für den string allokieren und die adresse dieses speichers an die aufgerufenen Fu. übergeben -
dort dann (wie auch jetzt) die zuweisung machen.

...ist in C++ oder C# alles einfacher, aber ich denke mal, das gibts am TI 200 nicht. :cool:

fg
-hannes

@biri: Danke fuer die Bestaetigung :D

Denkfehler ;)
Warum sollte das bei kleinen Strings nicht noetig sein?

Dann dreh mal den Warning-Level, ANSI-Compliance, etc. auf ;)

OK, danke für die Antworten.
Also das Allokieren hätte ich mir sparen können, das muss anscheinend nicht sein(lt. Compiler).
Wenn man static weglässt, so beschwert sich der Compiler auch nicht. Aber ich schätze mal, dass das static schon wichtig ist!?
Die Fehlermeldungen sind verschwunden, als ich die direkte Zuweisung gegen ein strcpy ausgtauscht habe. Aha, interessant...da ist man ja doch etwas verwöhnt von C++. Wieso hats denn mit direkter Zuweisung trotzdem funktioniert?

Gibts irgendwo eine Seite wo kurz die Eigenarten von C gegenüber C++ erklärt werden? Oder gibts außer bei den Strings eh nicht viel Unterschiede?(die Objektorientierung, Streams etc... jetzt mal weggelassen?)



Viele Grüße,
Harri



EDIT: Hab das malloc jetzt wieder weggetan, weil ich dann auch irgendwann free() ausführen müsste, und ich wüsste echt nicht wo ich das tun soll! Im _main() gibts die Variable nicht, und free() vor dem return ausführen wäre auch ein bisschen extrem sinnlos!

Hallo!

Ich meinte damit, dass man in C++ sich das Allokieren von kleinen Daten sparen kann, weils eh wurscht ist wenn sie unveränderbar groß sind. Denn ob jetzt 1byte nicht verwendet werden kann ist mir relativ wurscht. Bei großen Daten ist das wieder etwas heikler, v.a. am TI200.


Nö, leider:D
Aber ich bin eh schon froh dass es C fürn TI gibt, früher wurde fürn TI alles mit Assembler geschrieben!!! Da schreibt man mal 1 Seite nur um den String "Hallo Welt" auszugeben!


Viele Grüße,
Harri

Das malloc hab ich jetzt komplett weggetan.
Wenn ich static char* erg; schreibe, dann hängt sich der TI auf! (mit der Meldung Protectit memory violation verabschiedet er sich)
Wenn ich aber char erg[15]; schreibe, dann gibts keine Probleme.
Hat da jemand eine Erklärung dafür?


Grüße,
Harri

hi !

die von dir erwähnten sachen sind keine eigenarten von C gegenüber C++. Im Gegensatz zu C hat C++ Klassen, die gewisse Funktionalität kapseln - z.B. eine Stringklasse mit überladenem "+" und "=" Operator - deshalb ist da eine einfache Zuweisung von strings möglich. Intern führt die Klasse dann eine Speicheralokierung durch. (beim destruktor der klasse wird der spiecher wieder freigegeben).

die Zuweisung zum char* funktioniert natürlich - du brachst dazu keine "strcpy"-Funktion. Es wird allerdings nicht der string zugewiesen (d.h. kopiert), sondern die Speicheradresse, an der die Zeichenkette gespeichert ist. Dieser Speicher ist in deinem Fall am Stack, da er lokal angelegt wird, da in einer Funktion vereinbart. Nach der verlassen der Funktion wird der Speicher freigegeben, du hast jedoch noch einen Zeiger, der darauf verweist. Beim nächsten Zugriff darauf hättest du unter Windows eine memory-exception.
Was der TI macht, weiß ich nicht - ist aber sicher nicht die feine art.

s.o.

wenn du eine zeichenkette speicher willst, musst du auf jeden fall "char erg[15]" schreiben - wenn die zeichenkette nicht länger als 14 (!) Zeichen ist (+ ASCII Null).
vorteil von maloc ist, dass du dynamisch zur laufzeit die größe des alokierten Speichers bestimmen kannst.

Bei static wird die variable am heap angelegt, also beim Verlassen der Fu. nicht freigegeben.

was meinst du damit ?
was sind "kleine daten" ?

hab assembler nur am pc programmiert - stimmt, dauert recht lange, da was zu machen. :cool:

fg
-hannes

Hallo!
 

Danke für deine Antwort. War mal interessant zu wissen was sich eigentlich hinter dem einfachen = in C++ bei Strings verbirgt.

Beim TI funktionierts, aber wer weiß, vielleicht würde es ja irgendwann einmal zum Absturz kommen!


OK, war wohl ein Blödsinn. Ich meinte damit nur dass man damit Speicher während dem Programmablauf in Anspruch nehmen kann/freigeben kann. Und daher dachte ich dass man Allokieren vor allem für große Arrays etc. verwendet, wo man nach Gebrauch der Variable den Speicher wieder freigeben will.



Viele Grüße,
Harri

zeiger="Literal"; bedeutet: Weise zeiger die Anfangsadresse des Charfeldes "..." - in diesem Fall ist "Literal" gemeint - zu.

char *erg1; ist eine Adressvariable
char erg2[20]; ist ein Characterfeld mit 19+1 (Nullterminierter Sring) oder 20 Elementen.

erg1 ... nimmt Adressen durch eine Zuweisung - also durch den '=' Operator - an.

erg2 ... ist ein Label (Anfangsadresse eines Arrays = Feld = eindimensionale Matrix).

erg2="..."; geht nicht, da erg2 kein L-Wert ist. erg2 kann nicht neu gesetzt werden, da es (=eben das gegenständliche Label) auf eine unveränderliche Speicherplatzposition zeigt.

Ein L-Wert ist eine Variable oder ein Zeiger ...

mfg Kikakater

Wobei aus logischen Gründen diese Zeile
ersatzlos gestrichen werden kann.

Allerdings ist dieser Code problematisch. Nach dem Verlassen der Funktion char * stab(double hm) gibt es keine Garantie mehr, dass die Speicheradressen, die vorher "stabil", "indifferent" oder "labil" als Inhalt hatten, dies noch tun werden. Sobald eine Funktion verlassen wird, kann im Rechner der von der Funktion belegte Speicher wieder freigegeben werden. Es ist nämlich möglich, dass der RAM-Speicher vorübergehend auf die Festplatte ausgelagert wird (virtueller Speicher). Daher sollte tunlichst der Speicher explizit über malloc oder ein statisches Array reserviert werden. (static oder eben eine globale Variable). Dann ist aber ein strcpy erforderlich.

Das ist Gewohnheit und bleibt schön im Programmcode.

Wenn nicht alle logischen Fälle abgedeckt werden, wird auf den String "Fehler" verwiesen. Das ist nicht nur recht und billig, sondern programmatisch notwendig. Eine Redundanz hier in diesem Fall zu eleminieren ist strategisch nicht zu vertreten.


Dieser Code ist deswegen nicht problematisch, weil der Compiler Stringliterale am Heap ablegt, ggf. idente Stringliterale als eine Instanz (Vorkommen) zusammenzieht, falls dieser Schalter gesetzt wurde.

Diese Art von Initialisierung wandert somit auf den Heap (deutsch Halde) und ist per definitionem als statisch zu bezeichnen.

Ich kann hier leider nicht mit Gefühlsbeschwichtigungen dienen, dies sind die Tatsachen, Gegenbeweise noch ausstehend.