*.dll oder *.exe
-
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.
-
Mal abgesehen davon das das Projekt mit Klassen in Dynamisches Bibilotheken völlig unportabel wird.
-
Dafür gibts doch das COM.
-
Original erstellt von rapso:
**ich schreibe die engine am anfang meißt gleich in ne DLL rein, damit man von anfang an ein seperat arbeitendes modul hat. sogar wenn du planst die engine nur einmal für ein einziges spiel zu verwenden hast du den vorteil, dass du beim rebuild nicht die engine sourcen mitkompilieren mußt.
zudem kommt man später immer auf die idee, dass man die engine ja noch weiter nutzen könnte...
**das alles ist doch NULL grund für ne dll. da würde ne lib reichen.
-
kratzt es mich ob es ne dynamische oder statische lib ist?
rapso->greets();
-
Original erstellt von rapso:
**kratzt es mich ob es ne dynamische oder statische lib ist?
**nur ne million fallstricke bei dlls, die bei libs nicht sind. angefangen bei der versionsverwaltung über gemeinsame verwendung einer dll von zwei exes gleichzeitig, dem zwang zu rentrantem code, der problematik des erzeugens und zerstörens dll-globaler variablen, wem schickt man die exceptions, bin hin zu schlechter debugger-unterstützung und den scherzkeksen, die wegen der ersten dll dem user ne setup.exe reinzwingen wollen.
haste das alles bewußt in kauf genommen, um den vorteil zu haben, daß mehrere projekte sich den code auf der platte teilen können (ja, ms-office benutzt dahingehend sinnvollerweise dlls), dann isses ok. sonst aber eigentlich nicht.
-
Original erstellt von rapso:
**kratzt es mich ob es ne dynamische oder statische lib ist?rapso->greets();**
ob es DICH kratzt oder nicht spielt eigentlich keine rolle. denn ursprünglich wollte "Blue Angel" wissen, ob man dll's verwenden soll oder nicht. ICH sagte dazu, dass man es nicht machen sollte. garade für anfänger gibt es keinen grund es zu tun, es bringt nur nachteile. dll's sollten nur in den fällen benutzt werden, wenn man nicht darum herum kommt. z.B. wenn man eine 1 GigaByte lib schreiben soll und diese von 20 verschiedenen programmen gleichzeitig genutzt werden soll, man aber nur 2 GigaByte Ram hat.
[ Dieser Beitrag wurde am 01.04.2003 um 15:24 Uhr von KXII editiert. ]
-
ne lib sollte code und nicht daten enthalten, ob du nun deine festplatten mit dlls voller daten vollmachst oder nicht, ist auch egal.
ob man eine dll verwendet oder lib ist egal wenn man von anfang an ordentlich codet, und gerade für anfänger ist es wichtig das gleich richtig zu machen sonst bekommen sie die lib nicht mehr aus ihrer exe gestöpselt und ob man ne extra dll verwendet oder nicht ist egal, man der compiler kann die dll automatisch beim start der exe an diese linken lassen, dafür braucht man die dll nicht manuel laden, das geht automatisch wenn man will, da fällt "dem anfänger" nichtmal auf wenn "er" ne lib verwende die dynamisch oder static ist... naja, es seiden er scheitert an der hürde ein "how to make a *.dll"-tutorial durchzuarbeiten.
hmm... aber ich bin offen für das kotra was eine *.dll von einer statischen lib dermassen beim coden unterscheidet wenn das framework steht.
rapso->greets();
-
Original erstellt von volkard:
**[quote]Original erstellt von rapso:
[qb]kratzt es mich ob es ne dynamische oder statische lib ist?
**nur ne million fallstricke bei dlls, die bei libs nicht sind. angefangen bei der versionsverwaltung über gemeinsame verwendung einer dll von zwei exes gleichzeitig, dem zwang zu rentrantem code, der problematik des erzeugens und zerstörens dll-globaler variablen, wem schickt man die exceptions, bin hin zu schlechter debugger-unterstützung und den scherzkeksen, die wegen der ersten dll dem user ne setup.exe reinzwingen wollen.[/QB][/QUOTE]
das hab ich gerade übersehen...
also meine dll entwickle ich meißtens in einem framework zusammen mit den exe (das text projekt) das stell ich die dll auf dependent compilation, also wird jedesmal ne aktuelle version für die exe erstellt, falls sich etwas geändert hat, was beide module betrifft. daher hab ich keine probleme mit versionen, aber ne abfrage dafür hab ich trotzdem.
"der problematik des erzeugens und zerstörens dll-globaler variablen" glaubst du, wenn jemand ne lib hat und am ende das ding in eine dll stopfen muss, dass es dann einfacher ist? ich glaube dann gibt es soviele abhängigkeiten, dass das ding explodiert.. hmm.. außerdem ging ich von einer dll die OOP ist, da hab ich nur ein globales objekt (pro modul) und das steckt bei mir in der dll von dem ich nur den interfacepointer rausgebe, danach ist alles genauso als würde man im exe-code rummanchen, aber es steckt ausgliedbar in der dll.
"bin hin zu schlechter debugger-unterstützung " hmm.. also bei mir läuft mit .NET alles perfekt, früher hatte ich bei vc++5 probs beim einbinden von dynamisch geladenen dlls ins debuggen, aber auch das ließ sich lösen. deswegen würde ich das als problem streichen.
wem schickt man die exceptions, ich sehe da nicht das problem, arbeite sehr viel mit exceptions zwischen den modulen, dafür gibt es halt ein extra modul das diese exceptions managed und einmal gecodet kann man das immer wieder verwenden.
"die wegen der ersten dll dem user ne setup.exe" trolle gibt es immer
Original erstellt von volkard:
haste das alles bewußt in kauf genommen, um den vorteil zu haben, daß mehrere projekte sich den code auf der platte teilen können (ja, ms-office benutzt dahingehend sinnvollerweise dlls), dann isses ok. sonst aber eigentlich nicht.alles in dlls reinzustecken ist ja dumm, aber wenn man sich ne lib erstellt hat man auch viele vorteile, z.B. kann man eine debug dll mit ansonsten release dlls nutzen. wenn ich das weglasse bekomm ich manchmal netma 25% der performance, weil viel zu viele überflüssige constructoren und destroctoren aufgerufen werden (also mit ein grund für die langsammkeit)
außerdem lässt sich dann viel leichter versionsänderungen vornehmen, sonst muss man bei jeder moduländerung alle anderen dinge mitlinken. ich hab hier exe's gesehen die mit debuginfo 140MB hatten, da ist meine kleine dll mit 1.5MB richtig angenehm zu verteilen.
es gibt wahrscheinlich genausoviel nach wie vorteile
deswegen juckt mich sowas nicht, am ende steck ich eh meine lib in ne dll, weil nicht jeder den ich kenne nen linker hat um mal eben was zu testen. (ich meine damit nicht coder)
rapso->greets();
-
Original erstellt von rapso:
außerdem ging ich von einer dll die OOP ist, da hab ich nur ein globales objekt (pro modul) und das steckt bei mir in der dll von dem ich nur den interfacepointer rausgebe, danach ist alles genauso als würde man im exe-code rummanchen, aber es steckt ausgliedbar in der dll.ja, aber
Foo& getInstance() { static Foo foo; return foo; }wann stirbt foo?
Wenn die exe ihren link zur dll fallenläßt, oder erst, wenn die dll echt entladen wird? und wohin die fehlermeldung wenn im destruktor von foo was nicht geht? solche fragen meinte ich. und das im destruktor fliegende assert, aber die exe ist schon zu und die connection zum debugger auch.
daß es meistens gut geht, ist mir auch klar. aber die von mir genannten fallstricke fühlen sich für mich eigentlich noch nicht entschärft an.ps: außerdem ging ich von einer dll die OOP ist, und genau darin liegt das problem!
-
daten werden eigentlich, falls sie nicht shared sind, sofort nach abbruch des links (also unload) freigegeben, die werden freigegeben bevor der link aus ist _soweit_ich_ weiß...
aber in büchern wie effektive c++ wird auch drauf hingewiesen dass man dinge die schiefgehen können nicht in destructoren und constructoren schieben, sondern eine extra funktion dafür haben sollte... das würde ich dann auch empfehlen.
natürlich sollte man die finger von allem lassen, womit man sich nicht genug auskennt oder zumindestens glaubt es zu wissen (Wie ich mit denn dlls), aber wenn man spiele bastelt sollte man schon diese relativ einfach technik einer dll verstehen und nutzen können, weil es viele vorteile gibt.. ich persöhnlich kenne auch keine vernünftige engine die in einer lib daherkommt
rapso->greets();
