[C++] Schutz vor Änderungen in Klassen

[jokey2]

Wenn es solch einen Schutzmechanismus geben soll, müßte die Information ob ein Mitglied der Klasse public oder private ist in der Bibliothek selbst, also im Objektcode, hinterlegt sein.

Ich glaube, genau das ist es, was Kriz meint.

Es sollte ausreichend sein wenn man dem Kunden untersagt Änderungen an den Headern vorzunehmen. Sollten dennoch Änderungen vorgenommen werden liegt ein Vertragsbruch vor und der Kunde ist sowieso auf sich allein gestellt.

Ganz genau! Ich würde zwar nicht gleich von Vertragsbruch sprechen, aber wenn der Kunde selber in der Headerdatei rumpfuscht, dann ist er für die Folgen dieser Änderung auch selbst verantwortlich. Wenn Du in Dein Auto selber einen anderen Vergaser einbaust und der Motor geht kaputt, kannst du ja auch nicht den Autohersteller dafür verantwortlich machen.

Natürlich wäre es nett, so ein Feature in C++ zu haben, aber meiner Meinung nach ist es nicht unbedingt nötig, da es sich da eher um eine rechtliche Frage hanbdelt und nicht um eine Programmiertechnische.

 

[Daniel Toplak]

Hi,

das Problem mit DLLs ist, daß sie nicht portabel sind. Ich brauche meistens eine Lösung, die portabel ist. Eine DLL gehört (leider) nicht dazu. Gut, auf *NIX-Systemen könnte man noch mit SOs arbeiten, aber was wäre mir wirklich exotischen Systemen?

(Ich möchte btw. nicht als "Proprietärsfreund" gelten, sowas liegt mir fern. In der Freizeit programmiere ich ausschließlich nur OpSo, aber im Beruf muß ich auf solche Dinge achten.)

Es ist schade, daß es keine gute Lösung für dieses Problem gibt. Eventuell sollte ich mal den Meister selber anmailen, was er dazu sagt. Falls ich eine Antwort bekommen sollte, poste ich die mal hier rein.

Das ist schon richtig wenn du portabel bleiben willst.
Aber deine kompilierten Libs sind genausowenig portabel, da sie ja nur auf der jeweiligen Plattform verwendet werden können auf der sie auch gebaut wurden.
Wenn die Anforderungen des Kunden auf mehrere Betriebssystem sind, dann musst du eben die DLL's z.B. für die entsprechenden Systeme bauen.
Eine Alternative wäre hier Java wobei es natürlich da auch nicht soweit her ist mit Code-Sicherheit.

 

[Kriz]

@deepthroat: Nein, ich verwechsel da rein garnichts. Ich habe erstmal in einem Projekt die Testlib kompiliert und anschließend in einem zweiten Projekt nur die Header und die Lib als Ressourcen verwendet. Es gab dort keine Sourcecodes, nur die Library. Und je nachdem wie ich die Header manipuliert habe, kam dieses oder jenes Ergebnis raus.

Wie du bereits erkannt hast, fehlt die Zugriffsqualifikation im Sourcecode, welcher später dann als Objektcode in der Library vorliegt. Darum kann man auch die Zugriffsrechte über die Header "bequem" aushebeln, ohne das der Compiler meckert. In der Library ist ein Zugriffsrecht de facto nicht existent und wird nur über die passende Header definiert.

Und dem Kunden zu untersagen, das er dies oder das lassen soll, kann man zwar machen (und ist auch unübersehbar in (von mir erstellten) Headerdateien enthalten), aber das ist nun wirklich keine Garantie.

Falls die Sch... wegen Manipulationen nicht läuft, bin sowieso immer erstmal ich dran schuld Aber die Retourkutsche kommt ebenso gleich zurück, hehe

@Daniel Toplak: Das ist richtig, daß auch Librarys nicht wirklich portabel sind. In den meisten Fällen benutzen meine Spezis genau wie ich GCC und die können mit .a Libs mehr anfangen als mit .lib Libs. Nur wenn jemand VisualC++ ect. benutzt, bekommt er eine .lib aufgebrummt. Da .a sowohl auf Windows als auch den meisten *NIX Systemen mit GCC verwendet werden können (sofern der Code plattformneutral gehalten ist), fahre ich damit sehr gut. Nur wenn eben plattformspezifische Dinge wie WinAPI ect. auftauchen, ist es mit der "Portabilität" natürlich vorbei...

 

[Daniel Toplak]

@Daniel Toplak: Das ist richtig, daß auch Librarys nicht wirklich portabel sind. In den meisten Fällen benutzen meine Spezis genau wie ich GCC und die können mit .a Libs mehr anfangen als mit .lib Libs. Nur wenn jemand VisualC++ ect. benutzt, bekommt er eine .lib aufgebrummt. Da .a sowohl auf Windows als auch den meisten *NIX Systemen mit GCC verwendet werden können (sofern der Code plattformneutral gehalten ist), fahre ich damit sehr gut. Nur wenn eben plattformspezifische Dinge wie WinAPI ect. auftauchen, ist es mit der "Portabilität" natürlich vorbei...

Äh sorry aber da bringst du was durcheinander.
Wenn du auf einer Plattform (z.B. Windows x86) deinen Code mit GCC compilierst und eine "statsiche Lib" mylib.a erstellst heisst das noch lange nicht das die Plattformunabhängig ist auch wenn kein Windows spezifischer Code drin ist.
Stichwort: Binärformat, das ist sehrwohl unterschiedlich.
Plattformunabhängigkeit in C/C++ heisst nur das der Source unabhängig kompiliert werden kann, aber nicht evtl. statischen Libs auch unabhängig gelinkt werden können.