*.dll oder *.exe
-
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.
-
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();
