Modulare Programmierung, SchnittstellenDesign .. passende Literatur ?
-
Informatiker lernen aber sowas wie Model-View-Controller. Das als Schlagwort.
Dazu waer eben Literatur ned schlecht ....
Darueber werden keine Buecher geschrieben, denn sobald das Manuskript fertig ist, ist das Wissen veraltet. Foren, Blogs oder Newsgroups sind die bessere Anlaufstellen.
Auch scheint euerer Problem nicht Literatur zu sein, sondern fehlende Richtlinien.
-
knivil schrieb:
Informatiker lernen aber sowas wie Model-View-Controller. Das als Schlagwort.
Ein studierte Informatik würde niemals solche Probleme vorfinden wie bei RHBaum?
-
RHBaum! Der Ansatz ist ja schon mal richtig. COM-Objekte lässt man erzeugen, d.h. der Client-Code besorgt sich das Objekt nur. Und für die Freigabe ist auch nicht der Client-Code zuständig! Deshalb zählen die COM-Objekte ihre Referenzen selbst. Das kann man in "Modernes C++ Design" im Kapitel über Smartpointer nachlesen. Der Intrusiv-Smartpointer aus Boost (und C++11?) ist sogar für solche Fälle gedacht! Schau dir mal die Doku zu intrusive_ptr an.
So löst man auch das Thema "unterschiedliche C++-Runtime-Version", in dem man die DLL "mal machen lässt".
Zeus! Sehr guter Artikel! Danke!
nn! Die COMs sind C++, aber da am Ende eh alles nur nach Maschinencode kompiliert, kannst du natürlich auch COM über C ansprechen, genauso wie es auch über Delphi und vielen anderen Sprachen geht. Aber wer will freiwillig COM-Objekte mit C nutzen, wenn er es mit C++ kann?
Strings werden natürlich nur Roh im Interface genutzt. Stimmt. Weil std::basic_string halt keine binäre Klasse ist sondern nur ein Template. Liegt in der Natur der Sachde. Ändert aber nichts daran, das ich vom Host-Code (DLL) ein binären String-Objekt-Typ nutzen könnte, also sowas wie IMyString mit echten Methoden.
Es ist aber einfacher zu sagen: der Host-Code gibt mir den rohen String, und ich pack gleich eine Kopie in mein String-Objekt. Strings sehe ich als PODs an.
-
Auch scheint euerer Problem nicht Literatur zu sein, sondern fehlende Richtlinien.
Nein, das geht tiefer !
Setz mal 5 Programmierer an einen Tisch, und lass sie über Regeln disskutieren.
Wir sind keine IT Abteilung ... das merkt man grad hier deutlich.
Uns fehlen die ressourcen und vor allem Leute (oder ein Projektleiter) die fundiert sagen koennten, "so ists richtig und so nicht" !Ciao ...
-
Artchi schrieb:
Aber wer will freiwillig COM-Objekte mit C nutzen, wenn er es mit C++ kann?
Niemand. Das habe ich auch nicht gesagt.
Wo ich dir entschieden widerspreche ist die Behauptung
Artchi schrieb:
Die COMs sind C++
Das ist falsch.
COM-Interfaces lassen sich durch Methoden von C++ Klassen darstellen. Das ist der Weg, wie COM in C++ abgebildet wird. Aber nicht alle C++ Konstrukte lassen sich 1:1 in COM abbilden.
Visual Basic 6 "Objekte" waren COM Objekte, das war eine 1:1 Abbildung. Deswegen schreibe ich noch lange nicht COM wäre Visual Basic.
Die Aussage
Artchi schrieb:
Soweit mir bekannt, kann man bei DLLs, COM und ActiveX Compiler-unabhängig C++-Schnittstellen anbieten.
stimmt nur für COM und ActiveX (und für C und C++/CLI), für C++ ist sie falsch.
Die ABIs der Windows C++ Compiler der einzelnen Hersteller (und mancher ihrer Compilerversionen) unterscheiden sich. Wie ein Compiler das Layout einer Klasse im Speicher anrichtet ist nicht genormt.
Das ist bei COM anders. Dort werden nur Interfaces und die Basistypen exportiert. Alle Datentypen außer den Grundtypen werden wieder als Interfaces realisiert und i.a. durch Factories erzeugt. Ich zitier mal Wikipedia
Eine Schnittstelle erfüllt die Funktion einer abstrakten Klasse, die lediglich virtuelle Elementfunktionen enthält, die (wegen der Trennung von Deklaration und Implementierung) in der VTable alle auf 0 gesetzt werden. Die C-Version einer Schnittstelle ist entsprechend eine Struktur, die Funktionszeiger enthält. Die erzeugten COM-Objekte nutzt man dabei über Zeiger auf deren Schnittstellen.
Wenn ein COM-Objekt eine Schnittstelle implementiert, muss es alle Methoden der Schnittstelle überschreiben, also die VTable füllen. Dabei sind mindestens die drei Methoden von IUnknown zu implementieren, die für das Lebenszyklusmanagement zuständig sind und eventuell vorhandene, weitere implementierte Schnittstellen offenlegen.
C++/CLI und das C++/CX für die nächste COM-Version umgehen die Problematik durch Metadaten. Da kann man auch Klassen mit Datenmembern exportieren.
Wenn man die Behauptung "C++ aus DLL exportiert ist COM" ernstnimmt, wäre ja auch exportiertes Qt, wie im obigen Beispiel, COM. Was ja offenkundig nicht der Fall ist. Könnte man exportierte C++ Klassen aus DLLs in anderen Compilerversionen ohne Probleme verwenden, hätte der Threadersteller ja wohl keine Mühe mit dem Wechsel von VS 2005 auf 2008 oder 2010.
Und um es noch mal zu sagen:
Ich bevorzuge für unsere eigenen Module C++ Schnittstellen in den DLLs. Aber ohne Verweise auf externe Libs wie Qt in den Schnittstellen.
Da das nur mit einer Compilerversion funktioniert, gibt es für einige wenige externe Schnittstellen kleine schlanke C-Interfaces. Die haben sich als robuster und portabler erwiesen als COM.
Für unsere und externe Schnittstellen zu C# verwenden wir heute C++/CLI statt C-Exporte und PInvoke. Wer mag, kann die .net Interfaces dann auch gerne über COM benutzen.
Ach ja, was ist an dem Buch, was ich empfohlen habe, so schlecht, dass es hier ignoriert wird ? Es behandelt ziemlich genau diese Thematik, auch im Kontext von Patterns.
-
"...und ne eigene registrierung der COM-Module ohne regestry versucht zu entwickeln..."
COM geht auch ohne Registry, indem man Manifeste verwendet.
-
COM ist in Windows derart tief verwurzelt, das ich mir auf Anhieb nicht so recht vorstellen kann was man damit nicht erschlagen kann sofern das notwendige Know-How vorhanden ist. Nein es ist keine 1:1 Umsetzung von C++, man muß Probleme gelegentlich schon etwas anders durchdenken und lösen als in C++. Aber unter Windows ist es meines Erachtens immer noch der binärkompatible Objektstandard, wenn man kein .NET verwenden will/kann. Wobei .NET selbst ganz wesentlich COM verwendet. Und originellerweise basiert eines der neuesten "Kinder" von Microsoft, nämlich WinRT, auf COM.
-
Chew-Z schrieb:
COM ist in Windows derart tief verwurzelt,
Das ist gleichzeitig Vor- und Nachteil. Wenn man Qt benutzt, um portabel zu sein, ist COM eher ein Problem.
Chew-Z schrieb:
Und originellerweise basiert eines der neuesten "Kinder" von Microsoft, nämlich WinRT, auf COM.
"Kind" ist eine gute Beschreibung. Es ist quasi das gemeinsame "Kind" von COM und .net. Und C++/CX ist quasi ein C++ mit eingebauten COM-Schnittstellen.
-
Wenn du nicht auf Windows festgelegt sein willst/musst bleibt eigentlich nur noch CORBA übrig.
-
RHBaum schrieb:
- Wir wollen einen Buildwerver aufsetzen ... Durch die unterschiedlichen Abhaengigkeiten, also QT versionen, Visual Studio versionen und von uns noch einigen Build-Varianten komm ich auf eine maximal Mögliche Anzahl von Kombination von 4 (uns bekannte Qt versionen im EInsatz) * 3 (uns bekannte Visual Studio Versionen im Einsatz) * 4(unserer Varianten) * 2 (Release Debug Build) = 96 Tragets !!! pro (von usn nach aussen gegebenen ) Modul und Version !
Das ist doch schon mal ein guter Grund, warum kein Qt in den Interfaces für Kunden sein sollte. Da spart ihr euch schon mal ne Menge Targets.
-
Ach ja, was ist an dem Buch, was ich empfohlen habe, so schlecht, dass es hier ignoriert wird ? Es behandelt ziemlich genau diese Thematik, auch im Kontext von Patterns.
Ich ignorier es nicht, aber ich kenn den Inhalt noch ned, also kann ich nix drueber sagen ^^
Aber ich arbeite dran (leider soll die Kindle-version ziemlich verhunzt sein, was das layout betrifft, deshalb gehts ned so schnll ^^)Das ist doch schon mal ein guter Grund, warum kein Qt in den Interfaces für Kunden sein sollte. Da spart ihr euch schon mal ne Menge Targets.
Nein, fuer unsere Entwickler und unsere Project-Manager ist es ein Grund ein Tool zu suchen, was diese Anzahl an Targets managen kann !
Auf die Idee, das dieses problem hausgemacht ist, kommen sie nedDas beste was passieren kann, ist das nen Werkstudent engagiert wird, der nen Build-tool raussuchen soll, was diese Anzahl an Targets schafft und ueber extensives Scripting so anzupassen ist, das es mit unserem System funktioniert.
Das schlimmste was passieren kann, das wir die externen(innerbretrieblich, aber von anderen Abteilungen) Anforderungen nicht bedienen koennen, und den anderen Abteilungen die Kosten fuer eine angepasste version fuer Ihre Umgebung aufgedruckt werden. Bis irgendwann mal nen Chef ans Ruder kommt, der die Sache hinterfragt und dann die richtigen Konsequenzen zieht ...
Ciao ...
-
Nachtrag nochmal:
So schlimm wie hier geschildert siehts ja eigentlich doch ned aus.
Gegenüber dem Zustand früher tut sich ja etwas, meiner Ansicht nach auch in die richtige Richtung. Nur iss das ja wie immer sehr schwer und zähIch tu mich eben nur schwer solche Design Themen durchzudruecken und zu begruenden, ohne den entsprechende fachlichen Refernzen.
Ich bin halt nur einer von 5 Programmierern, zwar seit 10 Jahren im Projekt, aber damit auch ned am längsten.Die anderen Programmierer sind eher mehr ... sagen wir mal praxisorientiert. deren Welt sind eher die GUI's und was es fuer tolle Bibliotheken dafuer gibt.
Während ich mehr so auf die c/c++ Style Themen druecke, und mehr die unsichtbaren Dinge im Hintergrund mache, und Bibliotheken fuer die anderen baue. Wenn was performant sein muss, landets meist auch bei mir ...Ciao ...
-
RHBaum schrieb:
Ach ja, was ist an dem Buch, was ich empfohlen habe, so schlecht, dass es hier ignoriert wird ? Es behandelt ziemlich genau diese Thematik, auch im Kontext von Patterns.
Ich ignorier es nicht, aber ich kenn den Inhalt noch ned, also kann ich nix drueber sagen ^^
Sorry, ich meinte eigentlich nicht dich damit. Es ging mir eher um die Antwort, dass das in jedem Patternbuch stehe, was meiner Meinung nach so nicht stimmt.
Was das Buch selber angeht, habe ich auch die Printversion. Die ist vom Layout ok und vom Text her gut zu lesen.Im Zusammenhang mit dem genannten "Patterns kompakt" würde ich dir gerne noch ein anderes Buch vom gleichen Autor empfehlen, den "Knigge für Softwarearchitekten".
http://www.gernotstarke.de/publikationen/page5/index.htmlIst nur ein winziges Büchlein, behandelt auch nicht die technischen Aspekte, sondern eher die menschlichen und organisatorischen Faktoren.
Mach mal bei Amazon den "Blick ins Buch". Möglicherweise wird die Lektüre dich weiterbringen.
-
RHBaum schrieb:
Das ist doch schon mal ein guter Grund, warum kein Qt in den Interfaces für Kunden sein sollte. Da spart ihr euch schon mal ne Menge Targets.
Nein, fuer unsere Entwickler und unsere Project-Manager ist es ein Grund ein Tool zu suchen, was diese Anzahl an Targets managen kann !
Auf die Idee, das dieses problem hausgemacht ist, kommen sie nedEine QA Abteilung, die alle Targets testen müsste habt ihr wohl nicht, die würden das wohl auch nicht mit machen.