header ohne private member ausliefern?

hallo,

früher, als es noch nicht-FOSS-bibliotheken gab, hat man ja header + .dll oder .so ausgeliefert. hat man da dieselben header genommen wie beim compilieren der bibliothek oder die private member rausgestrippt, damit niemand auf die implementation kommt?

Sebastian Pizer

"private member"? Du meinst Elemente bei Klassen und Structs?

Wenn eine Klassen- bzw Struct-Definition im Header steht, dann kann man da nicht einfach die Elemente rauslassen. Du hättest dann eine Verletzung der ODR (one definition rule). Also, inkonsistente aber vollständige Definitionen eines Typs.

Je nach dem, was Du machen willst, kann man unvollständige Typen oder auch abstrakte Klassen nutzen:

Beispielsweise "Factory Pattern":

class abstrakes_dings {
public:
  virtual ~abstrakes_dings() {}
  virtual long foo() const = 0;
  virtual void bar(long) = 0;
};

std::auto_ptr<abstrakes_dings> fabrik(std::string blah);

Beispielsweise "Abstrakte Datentypen" a la C:

struct cdings; // Deklaration = unvollständiger Typ

struct cdings* cdings_create(char const* blah);
void cdings_destroy(struct cdings*);
long cdings_foo(struct cdings const*);
void cdings_bar(struct cdings*, long);

Oder "Pimpl" aka "Compiler Firewall"

class dings
{
  class impl;  // Deklaration = unvollständiger Typ
  impl* pimpl; // "pointer to implementation"
public:
  dings(std::string blah);
  ~dings();
  dings(dings const& d);

  void swap(dings & with) { std::swap(pimpl,with.pimpl); }
  dings& operator=(dings d) { this->swap(d); return *this; }

  long foo() const;
  void bar(long);
};

inline void swap(dings & a, dings & b) { a.swap(b); }

Der Rest (cdings, impl oder eine konkrete Klasse, die von abstraktes_dings erbt) wird dann in einer Cpp-Datei definiert.

Gruß,
SP

knivil

compilieren der bibliothek oder die private member rausgestrippt, damit niemand auf die implementation kommt?

http://www.parashift.com/c++-faq-lite/classes-and-objects.html#faq-7.6 und folgendes ...

Eins meiner Lieblingszitate:

Encapsulation prevents mistakes, not espionage.

Sebastian Pizer

Ich muss zugeben, dass ich Gaen Erik eventuell falsch verstanden habe. Implementierungsdetails zu verstecken hat vor allem den Vorteil, dass die binäre Schnittstelle sich seltener ändert und man damit nicht alles oft neukompilieren muss. Eine "DLL" sollte sogar Implementierungsdetails so gut verstecken wie möglich -- nicht unbedingt um etwas zu verheimlichen, sondern um die Schnittstelle möglichst "stabil" zu machen.

Gruß,
SP

knivil

Die Implementation zu kapseln, weil sie sich vielleicht oft aendert, ist ein guter Grund. Aber private Member zu verstecken, um Schabernack zu verhindern, ist ein schlechter Grund.

hustbaer

Sebastian Pizer schrieb:

"private member"? Du meinst Elemente bei Klassen und Structs?

Structs? Du meinst Strukturen?

hustbaer

Gaen Erik schrieb:

hallo,

früher, als es noch nicht-FOSS-bibliotheken gab, hat man ja header + .dll oder .so ausgeliefert. hat man da dieselben header genommen wie beim compilieren der bibliothek oder die private member rausgestrippt, damit niemand auf die implementation kommt?

Private Member entfernen funktioniert nicht wirklich. Soll heissen: wenn man das macht, kann es schnell passieren, dass der Code, der gegen das veränderte Header-File compiliert wurde, nichtmehr funktioniert.

Sebastian Pizer

hustbaer schrieb:

Sebastian Pizer schrieb:

"private member"? Du meinst Elemente bei Klassen und Structs?

Structs? Du meinst Strukturen?

Genau die. Kein Grund die Augen zu verdrehen. Mir ging's hier nicht darum, jemanden zu verbessern. Ich wollte in erster Linie wissen, ob ich ihn richtig verstanden habe. Man kann natürlich auch andere "private" Dinge (Funktionen und Objekte) "verstecken" (internal linkage).

hustbaer schrieb:

Private Member entfernen funktioniert nicht wirklich. Soll heissen: wenn man das macht, kann es schnell passieren, dass der Code, der gegen das veränderte Header-File compiliert wurde, nichtmehr funktioniert.

Das ist mir, ehrlich gesagt, ein bissel zu wischiwaschi.

Die Antwort ist ganz einfach. Gibt es mehrere Klassen- bzw Strukturdefinitionen, die sich widersprechen, ist das eine Verletzung der ODR. Verletzung der ODR = undefiniertes Verhalten.

Wenn man eine Definition nicht "verraten" will, kann man es bei einer Deklaration lassen. Dann handelt es sich aber um unvollständige Typen, mit denen man einige Dinge nicht anstellen kann: Automatische Objekte anlegen oder per delete löschen zum Beispiel.

Gruß,
SP

hustbaer

Ich verdrehe die Augen, weil der Begriff "member" im C++ Standard ziemlich klar ist. Siehe "9.2 Class members" (etc.). So klar, dass ich nicht glauben mag, dass er dir nicht geläufig ist. Und mit der "böses Englisch, das muss Deutsch werden" Einstellung kann ich genau garnichts anfangen.

Das ist mir, ehrlich gesagt, ein bissel zu wischiwaschi.

Ich schätze für jemanden der schon überhaupt so eine Frage stellt, wird die Aussage "Verletzung der ODR" nicht gerade klarer sein. Deswegen wollte ich es nochmal klar, und aus der Praxis sagen: es kann Probleme geben. Was soll daran wischiwaschi sein?

Vor allem da ich aus Erfahrung weiss, dass viele Anfänger (und leider nicht nur Anfänger) sich total unbeeindruckt davon zeigen, ob etwas UB ist, oder nicht, solange es irgendwie funktioniert.

Sebastian Pizer

Ich zwinge hier keinem einen Sprachstil auf. Ich ziehe es nur vor, die deutschen Begriffe zu nennen, wenn ich sie kenne. Ob ihr "member" oder "Element" schreibt, ist mir wirklich egal. Ich gebe zu, das mag anders rübergekommen sein. Das hast Du einfach falsch bewertet. Mir hat einfach die Info gefehlt, um welche "member" bzw "Elemente" es geht. Dass es Klassen/Struktur-Elemente sind, habe ich mir schon gedacht. Nachfragen ist aber nicht verboten.

Du tust auch so, als wäre "Verletzung der ODR" das einzige, was ich dazu gesagt hätte. Ich habe erklärt, wofür die Abkürzung steht, was eine Verletzung in diesem Kontext bedeutet (inkonsistente Mehrfachdefinitionen der Klasse bzw Struktur) und glaube auch vermittelt zu haben, dass man solche Verletzungen zu vermeiden hat.

Bzgl wischiwaschi: Ich habe einen entsprechenden Qualifizierer benutzt: "bissel zu". Es klang auch so, als wäre das mit der ODR-Verletzung nicht ganz so schlimm. Im Endeffekt, war ich keinen Deut besser als Du. Ich habe gemeckert, weil mir die Erklärung nicht gefallen hat. Damit haben wir keinem geholfen.

Gruß,
SP

hustbaer

Sebastian Pizer schrieb:

Ich zwinge hier keinem einen Sprachstil auf. Ich ziehe es nur vor, die deutschen Begriffe zu nennen, wenn ich sie kenne. Ob ihr "member" oder "Element" schreibt, ist mir wirklich egal. Ich gebe zu, das mag anders rübergekommen sein. Das hast Du einfach falsch bewertet. Mir hat einfach die Info gefehlt, um welche "member" bzw "Elemente" es geht. Dass es Klassen/Struktur-Elemente sind, habe ich mir schon gedacht. Nachfragen ist aber nicht verboten.

OK.
Mir ist garnicht aufgefallen, dass er auch Namespace-Member gemeint haben könnte.
Sorry.

Was den Rest angeht: der OP hat glaube ich es schon das Interesse verloren