*.dll oder *.exe
-
Original erstellt von <camp>:
inline geht wohl, da inline sachen sowieso in den header oder etwas ähnliches gehörennein engine funktionen können dann nicht inline sein!
-
Man kann dann natürlich keine inline-Funktionen aus der dll aufrufen, aber diese (die Engine) kann doch intern (innerhalb der dll) inline-Funktionen verwenden, oder nicht?
-
ob man inline kann oder nicht ist eine designfrage, manche dinge laufen bei mir im interface inline z.B. parameter auslesen oder übergeben.
also ein interface beispiel
class CShaderConsts { private: float m_Data[96][4]; public: float* Const(int pos){return m_Data[96];} virtual void Apply() =NULL; };also ich wüste net weshalb das nicht laufen würde, klar kann man kein objekt dieser class erzeugen, aber über einen pointer darauf zugreifen und da die function "Const(int pos)" im header ist und nicht virtual wüste ich nicht, weshalb das nicht optimiert werden könnte)
könntest du das mit ähnlichen compileroptionen erklären? weil ich zuhause öfters mal dinge mit gcc und vc++ gemischt nutze, ich hatte noch nie das problem wegen irgendwelcher optionen, gibt es da was bestimmtes was du meinst (und ich vielleicht noch nicht gemacht hab) ?
rapso->greets();
ps. ich weiß nichtmal ob das ding sich compilieren lässt, also don't flame wegen codingstyle oder syntax bitte.
-
also ich wüste net weshalb das nicht laufen würde, klar kann man kein objekt dieser class erzeugen, aber über einen pointer darauf zugreifen und da die function "Const(int pos)" im header ist und nicht virtual wüste ich nicht, weshalb das nicht optimiert werden könnte).
Weil die Funktion in der DLL eine Adresse haben muss. Das Programm (die .exe) kann die Funktion nur über eine Adresse aufrufen. Also wird die Funktion über einen Funktionspointer aufgerufen. Wie soll denn im Programm (der .exe) ein Funktionsaufrufe durch Code ersetzt werden, welcher erst dynamisch zur Laufzeit feststeht?
-
versteh ich nicht. einfach in den header
-
Inline-Funktionen lassen sich halt nur innerhalb der dll selbst aufrufen und nicht von der exe aus, da in der compilierten dll inline-Funktionen ja eigentlich gar nicht mehr als Funktionen vorhanden sind. So verstehe ich das zumindest
-
Original erstellt von flenders:
Inline-Funktionen lassen sich halt nur innerhalb der dll selbst aufrufen und nicht von der exe aus, da in der compilierten dll inline-Funktionen ja eigentlich gar nicht mehr als Funktionen vorhanden sind. So verstehe ich das zumindestjo. aber die es gibt ja auch viele Funktionen a la XXX.getSomething() die nur eine private Variable kapseln und die können bei ner DLL nicht mehr inline gemacht werden.
-
Stimmt! Hört sich zumindest logisch an
-
Innerhalb der DLL können sie natürlich trotzdem inline gemacht werden aber sie werden trotzdem als normale Funktion in die DLL gelinkt, da ja irgendwas auf sie zugreifen könnte. Bei private Funktionen wär das ja nicht umbedingt notwendig aber wie die Compiler es da machen kA
-
Ja, es ist das CD3DFont, was mit dem DXSDK 8.0 kommt. Müsste man eigentlich auch aus den Sourcen heraus lesen können ;).
-
also wenn seine engine nicht pluginfähig machen möchte und sie auch nicht anderen z.b. mit einem sdk zur verfügung stellen möchte, dann sehe ich keinen vorteil den mir eine dll bringen würde. das mit dem rebuild-spar-effekt ist quatsch! mann kann normale lib's jederzeit getrennt von anderen sachen kompilieren, genau wie dll's. und der speicherplatz-spareffekt, wenn mehrere programme gleichzeitig gestartet werden, den kann man getrost ignorieren. die 1-2 mb pro exe sind im zeitalter von 1gb ram echt egal! und die speicherkapazität von ram steigt schneller als die größe selbstgeschriebener dll's/libs. mann kann seine engine als dll schreiben, aber "besser" programmiert man deswegen nicht.
-
Original erstellt von TGGC:
Ja, es ist das CD3DFont, was mit dem DXSDK 8.0 kommt. Müsste man eigentlich auch aus den Sourcen heraus lesen können ;).Source? Wo gibbet den denn?!?!?!
-
Den OSR Quellcode gibts auf meiner Seite, URL steht'n Stück weiter unten.
Um es noch kurz zu erwähnen, weil ich letztens wieder irgendwo eine gegenteilige Meinung las: Mit CD3DFont kann man sehr einfach Umlaute erzeugen, einfach an die Schleife, in der die Buchstaben erzeugt werden, dranhängen, ala if (zeichen == "!") zeichen="ö". So kann man jedes beliebiges Zeichen ersetzen.
-
Warum kann man denn nicht direkt ein "ö" in den String einbauen?
-
Original erstellt von Lars:
[quote]also ich wüste net weshalb das nicht laufen würde, klar kann man kein objekt dieser class erzeugen, aber über einen pointer darauf zugreifen und da die function "Const(int pos)" im header ist und nicht virtual wüste ich nicht, weshalb das nicht optimiert werden könnte).**
Weil die Funktion in der DLL eine Adresse haben muss. Das Programm (die .exe) kann die Funktion nur über eine Adresse aufrufen. Also wird die Funktion über einen Funktionspointer aufgerufen. Wie soll denn im Programm (der .exe) ein Funktionsaufrufe durch Code ersetzt werden, welcher erst dynamisch zur Laufzeit feststeht?**[/QUOTE]wenn man eine nicht virtuelle abstrakte funktion in eine class deklariert, dann muss man auch eine definition dazu liefern, wieso? weil die dann dazukompiliert wird.
wenn man also ein interface für eine dll hat und darin ist eine funktion definiert, dann wird die aus der exe genutzt, für nicht virtuelle funktionen gibt es keinen pointer in der klasse selber, somit ist es nicht so möglich sie aufzurufen wenn sie sich nur in der dll befände...rapso->greets();
-
Original erstellt von rapso:
...nicht virtuelle abstrakte Funktion...Was ist das?
-
Das würde ausserdem vorraussetzen, dass man den Source der .dll hättte und diesen in die .exe reinkompiliert, was dem Prinzip der .dll wiederspräche. Schliesslich soll die von fremden Projekten (muss natürlich der selbe Compiler sein) auch ohne den Source benutzt werden können. Alleine die Deklaration muss da doch reichen. Kenn mich allerdings net so damit aus...
-
class blalaber
{
public:
virtual void bla() =NULL;
};das wäre virtuell und abstrakt.
und ja, wenn du ein interface hast, das keine nicht virtuelle abstrakte funktion hat, dann mußt du die definition dieser funktion haben, sonst kompiliert der kompiler das nicht.
eine abstrakte klasse als interface zu benutzen wiederspricht auch dem prinzip für das sie genutzt werden sollten, deswegen gibt es auch keine sicherheit das richtige interface zu haben für den pointer den man aus einer dll bekommt. es ist aber meiner bescheidenen meinung nicht absurd eigene funktionen in der exe zu haben um auf die daten in einer dll zuzugreifen, das wäre halt ne inline funktion im interface würde ich sagen...
aber damit kann man sich ziemlich viel zerschiessen.
rapso->greets();
-
Original erstellt von TomasRiker:
Warum kann man denn nicht direkt ein "ö" in den String einbauen?Weil CD3DFont eine Textur erstellt, und dort normalerweise kein "ö" drauf ist. Umlaute werden deswegen bei der Ausgabe ignoriert.
-
Wenn die inline Funktionen in die .exe gepackt werden gehen aber alle Vorteile der .dll verloren.
Gehen wir mal davon aus die Engine ist in der .dll und der Rest in der .exe
Du willst dann z.B. die inline Funktion der Enginge erweitern. Dazu musst du aber nicht die Engine sondern den Rest des Codes neucompilieren. Absurd oder? Deswegen vertragen sich inline Funktionen meiner Meinung nach nicht mit .dlls.
