Wrapper scheiben, nur was nehmen COM Modul oder Plain DLL



  • Hi allerseits,

    ich habe ein Wrapper für das BroadCom SDK geschrieben, nur bin ich mir nicht schlüssig ob die Implementation als COM Modul wirklich das wahre ist.

    Was ist eure Meinung? Was sind aus eurer Sicht vor und Nachteile?

    Gruß und danke.

    MrB.



  • Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • COM ist aus Teletubby-Sprachen einfacher zu verwenden (C#, Java, Skriptsprachen, ...), eine einfache Win32 DLL ist dagegen aus C und C++ einfacher zu verwenden.



  • hustbaer schrieb:

    COM ist aus Teletubby-Sprachen einfacher zu verwenden (C#, Java, Skriptsprachen, ...), eine einfache Win32 DLL ist dagegen aus C und C++ einfacher zu verwenden.

    Witzig formuliert, aber dennoch irrelevant... 😃

    1. Hier spielt das Threading eine Rolle. Wer sollt die Threadsteuerung übernehmen? - Die Applikation oder das OS?

    2. COM ist ein Industriestandard der auch außerhalb der Windowsumgebung genutzt werden kann. Mit win32-dll siehe es anders aus.

    3. COM-Komponenten können beliebig in Applikationen wiederverwendet werden.

    4. Welche Variante leichter zu entwickeln wäre, ist stark von den Anforderungen abhängig - Threading Modell, Dependencies, Implementierung etc.



  • Prof84 schrieb:

    1. COM ist ein Industriestandard ....

    wie kommst du darauf? ich dachte immer, COM wäre eine proprietäre ms-technologie.

    Prof84 schrieb:

    1. COM-Komponenten können beliebig in Applikationen wiederverwendet werden.

    DLLs auch.
    🙂



  • library-freak schrieb:

    Prof84 schrieb:

    1. COM ist ein Industriestandard ....

    wie kommst du darauf? ich dachte immer, COM wäre eine proprietäre ms-technologie.

    Funktionalität

    Durch den Einsatz von COM erhält ein Programmierer die Möglichkeiten

    * sprachunabhängig,
    * versionsunabhängig,
    * plattformunabhängig,
    * objektorientiert,
    * ortsunabhängig,
    * automatisierend

    zu programmieren. Viele der Funktionen des „Windows Platform SDKs“ sind über COM zugänglich. COM ist die Basis, auf der OLE-Automation und ActiveX realisiert sind. Mit der Einführung des .NET-Frameworks verfolgt Microsoft allerdings die Strategie, COM unter Windows durch dieses Framework abzulösen. Im Folgenden werden die einzelnen Punkte der Aufzählung genauer erläutert.

    http://de.wikipedia.org/wiki/Component_Object_Model

    library-freak schrieb:

    Prof84 schrieb:

    1. COM-Komponenten können beliebig in Applikationen wiederverwendet werden.

    DLLs auch.
    🙂

    Nur wenn die Dependency es zulässt.



  • [quote="Prof84"]

    Durch den Einsatz von COM erhält ein Programmierer die Möglichkeiten
    * sprachunabhängig,
    * versionsunabhängig,
    * plattformunabhängig,
    * objektorientiert,
    * ortsunabhängig,
    * automatisierend
    zu programmieren.

    schön und gut, aber zu einem standard wird COM dadurch noch lange nicht. bestenfalls zu einem de-facto standard in der microsoft-welt.
    🙂



  • [quote="standards-freak"]

    Prof84 schrieb:

    Durch den Einsatz von COM erhält ein Programmierer die Möglichkeiten
    * sprachunabhängig,
    * versionsunabhängig,
    * plattformunabhängig,
    * objektorientiert,
    * ortsunabhängig,
    * automatisierend
    zu programmieren.

    schön und gut, aber zu einem standard wird COM dadurch noch lange nicht. bestenfalls zu einem de-facto standard in der microsoft-welt.
    🙂

    http://docs.rinet.ru/ZhPP/ch16.htm
    http://de2.php.net/manual/de/ref.com.php

    Z.B.:CAN ist auch Industiestandard, obwohl es von BOSCH entwickelt wurde.
    CORBA ist ebenfalls Industriestandard, obwohl es von der OSF entwickelt wurde und von der OMG weiter voran getrieben wird.



  • ist ja fein, aber was sagt es schon aus, wenn Java und PHP gewisse windows-features unterstützen?
    andersrum - im gegensatz zu CAN und CORBA hat COM ausserhalb der windows-welt so gut wie keine bedeutung.
    🙂



  • Egal ob ich eine DLL oder eine COM Komponente habe, mit Threading muss ich mich immer auseinandersetzen.
    Sowohl COM Komponenten als auch ein DLL Interface kann man entweder "threadsafe" als auch "singlethreaded" auslegen.
    COM kann hier einiges vereinfachen, allerdings ist das immer mit Vortisch zu geniessen. Nicht alle Szenarien funktionieren so problemlos wie man es sich wünschen würde. Gerade wenn Callbacks mit ins Spiel kommen wird die Sache mit COM eher komplizierter als einfacher.

    Was vorzuziehen ist hängt wie gesagt IMO stark davon ab mit was man sich auf der Client Seite leichter tut.
    Wenn Clients nicht ausschliesslich in Sprachen programmiert werden in denen es relativ einfach ist auf eine Win32 DLL Schnittstelle zuzugreifen, dann ist COM sicherlich eine Überlegung wert.

    Wenn von vornherein klar ist dass nur mit C oder C++ (oder evtl. Pascal, Modula II, ...) zugegriffen werden muss, dann ist COM vermutlich Overkill.


Log in to reply