Änderungen von Variablen in Variable speichern

vista

LordJaxom schrieb:

Wenn man sowas dann schön wrappt, hat man genau einen "bösen" Cast im Programm und kann ansonsten über den Wrapper schön mit konstanten Strings oder std::strings hantieren

aha
ich nähere mich so langsam der erleuchtung
dann ist es also so, dass das willkürliche setzen und entfernen des 'const' attributes allein aus dem grund existiert, damit man von C++ aus alte C-funktionen aufrufen kann?
ein kleiner zweifel bleibt aber noch: du sagtest dass wenn das ursprungsobjekt 'const' ist und man das const entfernt, undefiniertes verhalten provoziert wird.
in deinem beispiel (verwendung von alten C-funktionen) gehst du stillschweigend davon aus, dass das entfernen von 'const' zumindest soweit funktioniert, als das die richtige adresse übergeben wird.
kann man das?
nach meinen verständnis bedeutet undefiniertes verhalten, dass das ergebnis einer solchen aktion absolut unvorhersehbar ist. oder nehme ich da wieder etwas zu wörtlich?

Simon2 schrieb:

Du vergleichst hier den Teufel mit Beelzebub: casts sind "einigermaßen böse", #defines sind "sehr böse" ...
Verzichte auf Beides und Du wirst ein glücklicherer Programmierer sein.

wie du an LordJaxoms beispiel sehen kannst, ist ein cast manchmal nötig.
oder kennst du einen besseren weg, wie man die C-funktion aufrufen könnte?

Simon2

vista schrieb:

...
wie du an LordJaxoms beispiel sehen kannst, ist ein cast manchmal nötig.
oder kennst du einen besseren weg, wie man die C-funktion aufrufen könnte?

Ja - ohne cast.

Ich weiß, dass man im Zusammenhang mit APIs bisweilen nicht drumherumkommt (deswegen schrieb ich auch "einigermaßen"), aber es ist auch dann oft das schlechte Design der API dafür verantwortlich (ggf. geht's sprachbedingt nicht besser - ändert aber nichts daran).
Niemand hätte den Designer von

/* Ältere aber bewährte C-API */
void draw_text(xy_image* img, xy_font* font, int x, int y, char* text);

daran gehindert, den letzten Parameter als char const* zu deklarieren - wenn er denn wirklich beabsichtigt, text nicht zu ändern.

Allerdings haben ältere C-(NICHT C++ !)-Compiler bisweilen ein etwas seltsames Versändnis von const und monieren IMO unbedenkliche Zuweisungen und andere wieder nicht, wie z.B.:

char *nonconst_p = "Simon2"; // => keine Fehlermeldung
      // seltsam: Der Compiler weiß, dass der Literal "Simon2" nicht mehr geändert werden darf;
      // trotzdem ist die Zuweisung zu einer nonconst-Variable erlaubt. (aus Tradition auch im C++-Standard)
   char const *const_p = nonconst; // alter C-Compiler: Warning: incompatible types
      // Wenn ich zusichere, via const_p den Speicher NICHT zu verändern, obwohl
      // nonconst das zuließe: Was stört ihn das ?
      // Besonders krude: In diesem Fall verweist nonconst letztlich auf einen unveränderbaren Bereich,
      // dem ein const-Ponter sowieso besser anstände.

So gesehen habe ich ein gewisses Verständnis für diese Probleme ...

Gruß,

Simon2.

LordJaxom

Simon2 schrieb:

Niemand hätte den Designer von
/* Ältere aber bewährte C-API */
void draw_text(xy_image* img, xy_font* font, int x, int y, char* text);
daran gehindert, den letzten Parameter als char const* zu deklarieren - wenn er denn wirklich beabsichtigt, text nicht zu ändern.

Von hätte hamwer nix

Im Ernst, ich habe dieses Beispiel gewählt weil ich genau dieses Problem neulich hatte. Aufgabe war, Hintergrundbilder für eine DVD zu erstellen (Text auf Vorlage rendern, um genau zu sein), und dafür eine Bibliothek zu verwenden, die möglichst verbreitet oder auf einer Standardinstallation sogar schon vorhanden war.

Die Wahl fiel auf GD, weil das die Standardlösung für Bilderzeugung in Perl ist und Perl samt GD::Graph zur Standardausstattung der Distribution gehörte. Als ordentlicher C++ler habe ich natürlich GD gewrappt und intern mit std::strings hantiert. Und die Textfunktionen von GD nehmen alle ein char*. Ich habe den Maintainer seinerzeit angesprochen, und er gab mir Recht, dass GD const-correcter sein könnte, jedoch habe er momentan nicht die Zeit sich darum zu kümmern (davon ab ist die letzte Release von GD schon einige Zeit her, das Ding gilt soweit als stable). Dabei hat er mir übrigens auch garantiert dass die Texte tatsächlich nur gelesen werden.

@vista:
Ich kenne den exakten Passus im Standard nicht, aber ich habe es immer so gehandhabt, dass das undefinierte Verhalten durch "wegcasten und schreiben" hervorgerufen wird, nicht durch "wegcasten aber trotzdem nur lesen". Hat bisher auch immer geklappt

Simon2

LordJaxom schrieb:

Simon2 schrieb:
Niemand hätte den Designer von
/* Ältere aber bewährte C-API */
void draw_text(xy_image* img, xy_font* font, int x, int y, char* text);
daran gehindert, den letzten Parameter als char const* zu deklarieren - wenn er denn wirklich beabsichtigt, text nicht zu ändern.
Von hätte hamwer nix :)...

Ich weiß - deswegen gibt's ja auch die casts (schön, dass man in C++ ein Mittel hat, mit dem man auf die Designfehler anderer reagieren kann)... und deswegen braucht man die auch bisweilen. Trotzdem sind sie IMO ein "böseres" Sprachmittel als for, const, class, ....

Gruß,

Simon2.