const und fehlende const-correctness



  • Hallo zusammen,

    mich interessiert, wie ihr mit dem Problem umgeht:

    Ich habe eine Bibliothek, die nicht const-correct ist und möchte in meinem Code aber const-correct bleiben. Daher setze ich des öfteren const_cast , um constness wegzucasten.
    Wer von heute hat/hatte ähnliche Probleme, und wie seid ihr damit umgegangen?



  • Kommt drauf an.
    Wenn's wenige, nicht performance-kritische Stellen sind dann kopiere ich die Daten einfach für den Aufruf.

    Sonst: wenn ich mir sicher sein kann dass die Funktionen der Library da ein const stehen haben könnten, also wirklich niemals irgendwas modifizieren, dann caste ich.

    Und wenn beides nicht funktioniert, dann fang' ich an zu weinen.



  • Ich hatte einmal eine (C-)Bibliothek, die Strings nur als char* übernommen hat. Ich hab mir dann Funktionen geschrieben, die mir das casten übernommen haben, da ich sicher war, dass der String nicht verändert wird. Außerdem habe ich dem Entwickler eine Mail geschrieben, als Antwort kam, dass "es so als Bibliothekstandard festgelegt wurde" und sie es dehalb nicht ändern werden.

    Kurz darauf habe ich ne andere Bibliothek genommen.



  • Achja, vergessen...

    patrick246 schrieb:

    Ich hab mir dann Funktionen geschrieben, die mir das casten übernommen haben,

    Ich schreibe dann natürlich auch Wrapper-Funktionen -- zumindest für alles was an mehr als 2 Stellen aufgerufen wird.
    Den const_cast überall zu wiederholen wo man eine Funktion so einer Library aufruft wäre ja grässlich.


  • Mod

    patrick246 schrieb:

    Außerdem habe ich dem Entwickler eine Mail geschrieben, als Antwort kam, dass "es so als Bibliothekstandard festgelegt wurde" und sie es dehalb nicht ändern werden.

    Kurz darauf habe ich ne andere Bibliothek genommen.

    Richtige Entscheidung. Solche Bibliotheken haben entweder blöde Entwickler oder sind 'ne Totgeburt, da die Leute die Vorgaben festsetzen, blöd sind.

    Das witzige ist ja, dass ein im Nachhinein eingeführtes const keinen gültigen Code brechen würde (oder zumindest 99.99% des gültigen Codes), da alle Aufrufe nach wie vor well-formed sind, darunter natürlich die mit entsprechend gecasteten Argumenten. Ich denke fast, dass das mit der Vorgabe lediglich eine Ausrede war - aber naja, ist im Nachhinein auch egal und ändert nichts am Gesamtbild, denn faule Entwickler sind nicht viel besser.

    @hustbaer: Wie ist das so in der echten Arbeitswelt, hat man da Alternativen was die Libs angeht? Oder arbeitet ihr öfters mit Nischen-Libs, i.e. solche deren Gebiet spärlich vertreten ist?



  • Also wir sind in der Firma (quasi gesetzlich) auf eine externe Bibliothek angewiesen, die nach aussen "nur" eine C-API bietet (da sollte man dazu sagen, dass wir komplett in Java entwickeln) und sich vom Style her total altbacken anfühlt.

    Sowas wie einen std::string oder const char* als String-Argument erwarten ist da natürlich nicht. Daher wird fleissig std::string::c_str benutzt.

    Lustiger und paradoxerweise ist die Bibliothek intern selbst in C++ mit Boost und allem geschrieben. Und obwohl eigentlich jeder unabhängig vom System diese Lib benutzen können sollte, gibt es nur eine C-API und es wird/wurde alles dafür getan, dass Interna nicht nach aussen gelangen können, dass man z.B. das OpenSource setzen könnte. Nein, lieber 400MB Systemabhängige fertig kompilierte Bibliotheken alle 4 Wochen veröffentlichen und so schöne Abhängigkeiten halten...



  • @Arcoth
    Das schlimmste für mich sind Vendor-APIs.

    Also wenn du irgend ein Hardware-Teil einkaufst, was irgendwas macht wo es keine Standard API auf dem verwendeten System gibt.
    Bzw. wo der Treiber des Hardware-Teils diese Standard API einfach nicht implementiert.

    Beispiele für ersteres wären Münzprüfer, Banknotenleser etc.
    In der zweiten Kategorie sind dann z.B. einige Magnetkartenleser oder Ticketprinter zu finden.

    Die Libs die man vom Hersteller für die Komponenten bekommt sind dann manchmal echt OK aber manchmal auch der reine Horror.
    Einiges davon haben wir uns dann selbst geschrieben, da das Protokoll der Hardware offen dokumentiert war und der Aufwand es auch zuliess.
    Bei anderen hast du aber komplett verloren. z.B. weil die nötigen Informationen eben nicht verfügbar sind oder der Aufwand so immens wäre dass es nicht in Frage kommt. Da hilft dann oft wirklich nur mehr weinen. Oder sich ein anderes Teil suchen wo die Libs nicht so katastrohpal sind, was aber leider auch nicht immer in Frage kommt.

    Ist aber natürlich total verschieden, je nachdem in welchem Bereich man so arbeitet.
    In manchen Jobs wirst du überhaupt kaum was mit externen Libs zu tun haben.
    In anderen wirst du nix mit "nischigen" Libs zu tun haben aber voll viel mit "Standardzeugs" (zlib, SQLite, ...).
    Und in anderen wirst du sehr viel mit "nischigen" und/oder Vendor-APIs kämpfen.
    Oder auch superkuhl: du übernimmst ein Legacy-Projekt wo die schlechtesten Libs verwendet werden die man sich hätte aussuchen können, und musst das dann warten 🙂
    (Und natürlich ist nix gekapselt, was es dir unmöglich macht die Libs auszutauschen.)

    EDIT: OK, eigentlich gehören Ticketprinter eher in Kategorie 1. Denn die als normalen Drucker anzusprechen macht keinen grossen Sinn.



  • Daher setze ich des öfteren const_cast, um constness wegzucasten.

    Das ist aber eine lustige Auffassung von const-correctness. 😃

    Das ist ungefähr so, als ob man dir eine Safe gibt und du es total unfair findest, da nicht hineinsehen zu dürfen.



  • coder777 schrieb:

    Daher setze ich des öfteren const_cast, um constness wegzucasten.

    Das ist aber eine lustige Auffassung von const-correctness. 😃

    Das ist ungefähr so, als ob man dir eine Safe gibt und du es total unfair findest, da nicht hineinsehen zu dürfen.

    Ich verstehe das genau andersrum. Er castet das const von seinen eigenen Objekten weg, um sie als non-const der externen Lib zu übergeben



  • daddy_felix schrieb:

    coder777 schrieb:

    Daher setze ich des öfteren const_cast, um constness wegzucasten.

    Das ist aber eine lustige Auffassung von const-correctness. 😃

    Das ist ungefähr so, als ob man dir eine Safe gibt und du es total unfair findest, da nicht hineinsehen zu dürfen.

    Ich verstehe das genau andersrum. Er castet das const von seinen eigenen Objekten weg, um sie als non-const der externen Lib zu übergeben

    So sieht´s aus. Ich habe einige Stellen in meinem Quelltext, die in etwa so aussehen:

    void some_func( const SomeObj& obj )
    {
       obj.some_member.some_non_const_func();
    }
    

    und da muss ich das const wegcasten, weil sich der Compiler sonst beschwert, dass auf einem const referenzierten Objekt eine non-const Methode aufgerufen wird.


Log in to reply