Programmiererforum

.h

.cpp

export module Vector; // defining the module called "Vector"

export class Vector {
public:
Vector(int s);
double& operator[](int i);
int size();
private:
double* elem; // elem points to an array of sz doubles
int sz;
};

export bool operator==(const Vector& v1, const Vector& v2) {
if (v1.size() != v2.size())
return false;
for (int i = 0; i < v1.size(); ++i) {
if (v1[i] != v2[i])
return false;
}
return true;
}

//Implementations; Not supposed to be exposed
Vector::Vector(int s) : elem{new double[s]}, sz{s} {}
double& Vector::operator[](int i) { return elem[i]; }
int Vector::size() { return sz; }

Ich lese gerade Bjarne Stroustrups A Tour of C++ (3. Auflage), das eine kurze Einführung in die C++20-Funktionen bietet. In dem Buch zeigt er, wie das Exportmodul das traditionelle Muster der Aufteilung von Deklarationen und Definitionen in separate Header ([code].h[/code]) und Quelle ([code].cpp[/code]) Dateien. In seinem Buch stellt er das selbstgebraute Vektorklassenmodul vor, um seinen Standpunkt zu erläutern:
[code]export module Vector; // defining the module called "Vector"

export class Vector {
public:
Vector(int s);
double& operator[](int i);
int size();
private:
double* elem; // elem points to an array of sz doubles
int sz;
};

export bool operator==(const Vector& v1, const Vector& v2) {
if (v1.size() != v2.size())
return false;
for (int i = 0; i < v1.size(); ++i) {
if (v1[i] != v2[i])
return false;
}
return true;
}

//Implementations; Not supposed to be exposed
Vector::Vector(int s) : elem{new double[s]}, sz{s} {}
double& Vector::operator[](int i) { return elem[i]; }
int Vector::size() { return sz; }
[/code]
Traditionell hatten wir separate Header-Dateien, um Funktionssignaturen offenzulegen (damit Verbraucher unserer Bibliothek wissen, wie sie sie aufrufen) und .cpp-Dateien, um Implementierungen zu verbergen. Bei Modulen sieht es jedoch so aus, als ob sich alles in derselben Datei befindet. Meine Frage ist:
[list]
[*]Wie verbirgt der Export in einer einzelnen Moduldatei tatsächlich die Implementierung vor Bibliotheksbenutzern?
[/list]
[list]
[*]Wenn sich die Implementierung in derselben Datei wie die Schnittstelle befindet, können Benutzer (oder irgendein konsumierender Compiler) dann nicht alles durch einfaches Hinsehen „sehen“. in Moduldatei?
[/list]
[list]
[*]Wann Beim Aufbau einer dynamischen Bibliothek (z. B. .dll oder .so) verlassen wir uns normalerweise auf Header-Dateien ([code].h[/code]), um dem Client-Code die Funktionssignaturen mitzuteilen. Benötigen wir bei Modulen immer noch eine separate „Header-äquivalente“ Datei oder übernimmt die Modulschnittstelle diese Rolle vollständig?
[/list]
Ich versuche es um zu verstehen, wie Module das Design in Bezug auf Sicherheit/Kapselung verbessern (oder vereinfachen) und gleichzeitig Compiler (und andere Benutzer) über Symbole und Signaturen informieren.
Ergänzung:
Ich habe die ausführlichen Antworten unter „Was genau sind?“ bereits gelesen C++-Module?“ in denen erläutert wird, wie Module auf hoher Ebene funktionieren, wie sie sich von Includes unterscheiden usw. Allerdings bin ich immer noch verwirrt über ein bestimmtes Szenario: [b]wenn ich alles (sowohl die öffentliche Schnittstelle als auch die private Implementierung) in einem einzigen Modul platziere Datei[/b], wie verstecke ich eigentlich meinen privaten Code vor Clients, während ich menschliche Entwickler über seine Funktionssignatur, Deklaration usw. benachrichtige? Wird nicht immer noch eine textbasierte Header-Datei benötigt? Mir geht es insbesondere um die praktische Verbreitung einer Closed-Source-Bibliothek.