[VC++] C# Internal in C++... habs immer noch nicht verstanden

[PacMani]

Dann würde ich aber die OO ad absurdum führen, wenn ich Audio-spezifische und Video-spezifische Funktionen einfach in eine einzelne private Klasse verschiebe.

[niwax]

Wieso denn? Eine private Klasse AudioTools und eine VideoTools wäre doch sogar eher OO als die Funktionen für die Dll sichtbar zu machen, aber für andere nicht und so zwei unterschiedliche Typen zu produzieren.

[gandro]

Pac-Man schrieb:  Prio. A ist bei diesem Projekt nämlich, dass der Nutzer der DLL wirklich nur das sieht, um jetzt z.B. einen Sound abzuspielen, und nicht Hilfsmethoden etc., die intern verwendet werden.

Wird den Benutzer nicht davon abhalten, die Hilfsmethoden trotzdem zu verwenden, falls er das will.

Ich hab wie gesagt so gut wie keine Ahnung von MSVC, aber nach bisschen googeln sind mir noch folgende Dinge eingefallen:

1. Warum machst du nicht einfach für jede Klasse (z.B. Application) eine erbende Klasse ApplicationAPI, wo du alle public Methoden drin hast, während alle geheimen protected Methoden in der Vaterklasse Application drin sind - und ApplicationAPI wird dann in die DLL exportiert.

2. Wie entscheidet der Compiler überhaupt, welche Symbole in die DLL exportiert werden, und welche nicht? Es gibt ja offenbar eine Export-Anweisung, kannst du nicht einfach standradmässig alle Symbole versteckt halten und nur die exportieren, die du willst?

[PacMani]

gandro schrieb:  1. Warum machst du nicht einfach für jede Klasse (z.B. Application) eine erbende Klasse ApplicationAPI, wo du alle public Methoden drin hast, während alle geheimen protected Methoden in der Vaterklasse Application drin sind - und ApplicationAPI wird dann in die DLL exportiert.

Das klingt noch am besten.

Ich dachte nur, ähnliches ginge auch ohne Verschieben von Methoden in andere Klassen, denn das Projekt an sich ist fertig, und jetzt alles rumzuschieben ist unpraktisch.
Irgendwas wie "public private:" (ja, so einen nicht funktionierenden Firlefanz spuckte bei meinen Suchen die Internetsuche teilweise aus) solle es es angeblich geben. Konnte ich nicht nutzen. Vermutlich nutzen die Personen, die das gepostet haben, einen Homebrew-Compiler... :S

gandro schrieb:  2. Wie entscheidet der Compiler überhaupt, welche Symbole in die DLL exportiert werden, und welche nicht? Es gibt ja offenbar eine Export-Anweisung, kannst du nicht einfach standradmässig alle Symbole versteckt halten und nur die exportieren, die du willst?

Soweit ich damit herumexperimentiert habe, hat der Compiler sofort rumgezickt, wenn eine exportierte Klasse eine nicht-exportierte Klasse nutzt. Von daher konnte ich durch Nicht-Export die Klasse nicht nach außen hin verstecken, weil ich sie exportieren musste.

Naja, also momentan bin ich ganz zufrieden mit dem Spaghetti-Friend-Classes. Ist zwar suboptimal, aber bezüglich des Aufwands gegenüber anderen auch von euch vorgeschlagenen Möglichkeiten (mit letztlich vermutlich saubererem Ergebnis) absolut aktzeptabel.
Es ist ja auch Copyright/Datenschutz/WasAuchImmer-mäßig nicht wichtig, ob der Nutzer nicht doch irgendwie an die von mir zu verstecken-versuchten Klassen rankommt. Es ist nur, dass ich den Nutzer nicht durch IntelliSense oder rumprobieren mit hundert Klassen verwirren möchte, sondern nur vier fünf Klassen die er wirklich braucht.
Aber natürlich verhindert eine gute Dokumentation eine solch mögliche Verwirrung. Nur liest die immer keiner und postet dann zig Forenthreads mit Betreff "Wie kann ich..." / "Geht das oder nicht?" / "Keine Ahnung wo..."... (erinnert mich an mich selbst gerade)