3. C anstatt C++ Code in vielen Bibliotheken! Warum?

C anstatt C++ Code in vielen Bibliotheken! Warum?

  • A

    RHBaum schrieb:

    Nur C-schnittstellen sind compilerunabhaengig definiert. Symbole fuer Klassennamen erzeugt jeder compiler anders, so dass client(.exe) und server(.dll / .lib oder was auch immer ) nur bei gleicher compilerversion zusammen passen wuerden.

    Das stimmt und ist sehr ärgerlich. Warum gibt es vom Standard denn keine Festlegung dafür?

    0
  • ?

    Hat wohl auch viel mit der darunter liegenden Rechnerarchitektur und dem unwillen der Compilerhersteller zu tun. Das einzigste System, welches ich zur Zeit kenne, dass den Austausch von Klassen über Programmiersprache hinweg erlaubt ist wohl .NET.

    0
  • T

    Teilweise auch Lizenprobleme, etwa LGPL...

    0
  • N

    TrueTom schrieb:

    Teilweise auch Lizenprobleme, etwa LGPL...

    Hu?

    0
  • T

    6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.

    You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things:

    * a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)
    * b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.
    * c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution.
    * d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place.
    * e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy.

    Für eine Library die etwa Templates verwendet, kommt nur Punkt a) in Frage, was die Anzahl der Anwender etwas einschränkt.

    0
  • T

    audacia schrieb:

    RHBaum schrieb:

    Nur C-schnittstellen sind compilerunabhaengig definiert. Symbole fuer Klassennamen erzeugt jeder compiler anders, so dass client(.exe) und server(.dll / .lib oder was auch immer ) nur bei gleicher compilerversion zusammen passen wuerden.

    Das stimmt und ist sehr ärgerlich. Warum gibt es vom Standard denn keine Festlegung dafür?

    Das lässt sich zemlich leicht umgehen, indem man in der Dll eine Funcktion GetAPI definiert, die einem einen Zeiger auf ene Klasse zurückliefert.

    0
  • N

    TrueTom schrieb:

    Für eine Library die etwa Templates verwendet, kommt nur Punkt a) in Frage, was die Anzahl der Anwender etwas einschränkt.

    Das interpretierst Du meines Erachtens einfach nicht richtig.

    0
  • T

    nman schrieb:

    TrueTom schrieb:

    Für eine Library die etwa Templates verwendet, kommt nur Punkt a) in Frage, was die Anzahl der Anwender etwas einschränkt.

    Das interpretierst Du meines Erachtens einfach nicht richtig.

    Ohne Begründung ist diese Aussage hinfällig. 🙄

    Ein Anwender des Programms muss die Library verändern können, was bei Templates ohne den Quelltext des Programms schwierig ist...

    0
  • N

    TrueTom: Lies das doch bitte mal genau und mach dann irgendwo einen neuen Thread auf, in dem Du erklärst, was daran das Problem sein soll; hier ist das Offtopic.
    Ich weiß nicht, was Du für bedenklich hältst.

    0
  • T

    nman schrieb:

    TrueTom: Lies das doch bitte mal genau und mach dann irgendwo einen neuen Thread auf, in dem Du erklärst, was daran das Problem sein soll; hier ist das Offtopic.
    Ich weiß nicht, was Du für bedenklich hältst.

    Weder halte ich das für bedenklich noch ist es Offtopic, aber sei's drum...

    0
  • N

    Gut, dann poste hier, was genau das Problem sein soll.
    Lizenzen nicht zu verstehen, heißt nicht, dass man sich aussuchen kann, was sie bedeuten könnten.

    0
  • A

    TrueTom schrieb:

    Ein Anwender des Programms muss die Library verändern können, was bei Templates ohne den Quelltext des Programms schwierig ist...

    Ist das Vorhandensein des Quellcodes nicht sowieso Voraussetzung? Somit gibt es das Problem nicht, welches auch immer du meinst.

    0
  • A

    TrueTom schrieb:

    audacia schrieb:

    RHBaum schrieb:

    Nur C-schnittstellen sind compilerunabhaengig definiert. Symbole fuer Klassennamen erzeugt jeder compiler anders, so dass client(.exe) und server(.dll / .lib oder was auch immer ) nur bei gleicher compilerversion zusammen passen wuerden.

    Das stimmt und ist sehr ärgerlich. Warum gibt es vom Standard denn keine Festlegung dafür?

    Das lässt sich zemlich leicht umgehen, indem man in der Dll eine Funcktion GetAPI definiert, die einem einen Zeiger auf ene Klasse zurückliefert.

    Wie stellst du dir das denn vor? Dein Programm weiß dann immer noch nicht, wo die Memberfunktionen sind, die es aufrufen muß...

    0
  • T

    audacia schrieb:

    Wie stellst du dir das denn vor? Dein Programm weiß dann immer noch nicht, wo die Memberfunktionen sind, die es aufrufen muß...

    Wie ich mir das vorstelle? Hmm, ich will jetzt nicht den Spruch von Dieter Nuhr bringen, auch wenn er so schön passen würde. War wohl mein Fehler, in ein deutsches Forum zu posten. 🙄

    (Und damit der Post nicht ganz so sinnlos ist: Mach Dich mal schlau, wie virtual Funktionen in C++ implementiert werden. Danke.)

    0
  • J

    TrueTom: Wenn ich Dir nicht sage wie die Funktionen meiner Klasse

    class Geheim
{
// Funktionsnamen nicht bekannt :)
};

    heißen, dann kannst Du sie auch nicht aufrufen. Übrigens auch nicht wenn ich sie virtual mache.

    0
  • T

    Jester schrieb:

    TrueTom: Wenn ich Dir nicht sage wie die Funktionen meiner Klasse heißen, dann kannst Du sie auch nicht aufrufen. Übrigens auch nicht wenn ich sie virtual mache.

    Das ist sicherlich richtig, ich versteh allerdings nicht, worauf Du hinaus willst?

    0
  • J

    Dann erklär doch bitte mal genauer wie das mit dem GetAPI funktionieren soll.

    0
  • A

    TrueTom schrieb:

    Wie ich mir das vorstelle? Hmm, ich will jetzt nicht den Spruch von Dieter Nuhr bringen, auch wenn er so schön passen würde. War wohl mein Fehler, in ein deutsches Forum zu posten.

    Einer von uns macht einen Denkfehler. Und er sollte sich nicht dazu herablassen, arrogante Sprüche von sich zu geben.

    Und damit der Post nicht ganz so sinnlos ist: Mach Dich mal schlau, wie virtual Funktionen in C++ implementiert werden. Danke.

    *Arroganz-mal-übergeh* Wieso virtual? Eine DLL soll eine Klasse exportieren anstatt der C-Funktionen, das hat doch mit virtual nichts zu tun!

    Vielleicht reden wir allerdings auch aneinander vorbei. Dann sieh dir folgenden Code an:

    Headerdatei für DLL:

    class class_to_export_by_dll
{
private:
    int i;
public:
    void set_i (int new_i);
    int get_i (void);
};

    Sourcedatei für DLL:

    #include <iostream>

void class_to_export_by_dll::set_i (int new_i)
{
    std::cout << i << " |-> " << new_i << std::endl;
    i = new_i;
}
int class_to_export_by_dll::set_i (void)
{
    return (i);
}

    Aufrufeprogramm-Sourcedatei:

    #include <iostream>
#include "dllheaderdatei.hpp"
using namespace std;

int main (void)
{
    class_to_export_by_dll c1;
    c1.set_i (52);
    cout << c1.get_i () << endl;

    return (0);
}

    Und nun erkläre mir bitte, wie die DLL dem Programm sämtliche Member-Funktionsaddressen über eine GetAPI-Funktion bekannt machen soll (falls es das war, wovon du redest 😃 )!

    Moritz

    0
  • T
     

    // SuperSoftPlugin.hpp

class SuperSoftPlugin
{
public:
    virtual void TestFunc1() = 0;
    virtual void TestFunc2() = 0;
}

    // MyPluginDll.cpp

class MySuperSoftPlugin : public SuperSoftPlugin
{
    // ...
}

SuperSoftPlugin *GetPlugin()
{
    return new MySuperSoftPlugin;
}

    #include "SuperSoftPlugin.hpp"

int main (void)
{
    SuperSoftPlugin *MyPlugin = GetPlugin();

    MyPlugIn->TestFunc1();
    MyPlugIn->TestFunc2();

    return 0;
}
    0
  • J

    TrueTom: Was wenn jetzt mein Compiler und der, der die dll erstellt hat unterschiedliche Namen für die rein virtuellen Funktionen erstellen?
    Stichwort: name-mangling

    Du hast das Problem nur mit ner Klasse ummantelt und viel syntaktischen Zucker drangeschmiert. Das Problem bleibt aber das selbe.

    0
Anmelden zum Antworten