*.dll oder *.exe

[rapso]

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();

[rapso]

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();

[volkard]

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!

[rapso]

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();

[TGGC]

Ich glaub der volkard ist genau so dumm wie ich. Diskutiert hier mit'm rapso rum, wo er doch ehh recht hat. Nee, nee, schlimm sowas...

[schlau]

raspo ist dumm

[volkard]

Original erstellt von rapso:
ich persöhnlich kenne auch keine vernünftige engine die in einer lib daherkommt

alle computerentscheidungen sind nämlich rein rational. der ibm-pc war die bessere hardware und hat sich deshalb durchgesetzt. vhs war metamax und video2000 technisch klar überlegen. windows war das bessere betriebssystem. und dlls sind auch besser als libs.
da geb ich mich geschlagen.

[Barikado]

DLLs haben keine Nachteile gegenüber statitischen Libs.

[rapso]

TGGC biste beleidigt? armer kerl

rapso->greets();

[rapso]

Original erstellt von volkard:
[quote]Original erstellt von rapso:
[qb]ich persöhnlich kenne auch keine vernünftige engine die in einer lib daherkommt

alle computerentscheidungen sind nämlich rein rational. der ibm-pc war die bessere hardware und hat sich deshalb durchgesetzt. vhs war metamax und video2000 technisch klar überlegen. windows war das bessere betriebssystem. und dlls sind auch besser als libs.
da geb ich mich geschlagen.[/QB][/QUOTE]

tja und linux ist so furchtbar dumm dass es quasi nur aus dlls besteht.. denn soweit ich weiß kann man jedes modul laden und die exportieren funktionen nutzen...

[volkard]

Original erstellt von rapso:
tja und linux ist so furchtbar dumm dass es quasi nur aus dlls besteht.. denn soweit ich weiß kann man jedes modul laden und die exportieren funktionen nutzen...

tja, da besteht ja wohl ein kleiner unterschied, ob du ein bs hast, das über tausend leute benutzen, wo es lächerlich wäre, man müßte fürs einstecken einer maus erstmal das bs neu compilieren, und ob du libs anbietest, die von 20 prozessen zugleich verwendet werden, oder obs nur ne grafik-engine ist, die sich nicht auf dem markt durchsetzen wird und die nie von mehr als einem programm gleichzeitig benutzt werden soll.

[Marc--us]

volkard bringt's mal wieder auf den Punkt!

[egg]

Hey, wenn man so denkt dann braucht man weder DLL noch Lib sondern kann den Quellcode direkt in sein Projekt übernehmen

[volkard]

Original erstellt von <egg>:
Hey, wenn man so denkt dann braucht man weder DLL noch Lib sondern kann den Quellcode direkt in sein Projekt übernehmen

die compilezeiten wären zu lang. und für ganz verschiedene sachen soll man auch ganz verschiedene verzeichnisse haben. immerhin soll die lib für alle zukünftigen games ja auch genommen werden können. mit ein paar klicks ist die lib drin, ganz ohne kopieren. und verbesserungen, die man macht, während man an einem spiel schraubt, bringen das andere auch voran. verschiedene muduln sind schon toll.

[rapso]

hmm.. wenn man davon immer ausgeht dass nur lamer hier fragen die es eh nie dazu bringen dass sie ne engine schreiben, die jemand verwendet, dann könnte man denen von vornhinein sagen dass sie es lassen sollen.

und wenn man etwas codet und es nur einmal verwenden will, dann braucht man auch keine statische lib, dann braucht man keine wirkliche modulisierung, denn wozu? reicht wenn man namespaces und klassen hat und wenn es fertig ist, dann mit dem spiel zusammen.

wenn man wirklich eine engine erstellt, dann besteht der core nur aus grundfunktionalität und erst durch weitere module, die man dann als plugins gestalltet, erstellt man das was die grafik zeichnet oder die kollision testet und was texturen dekomprimiert.
bei meiner engine muss ich nur eine dll aus dem standart framework erstellen und in die nötigen verzeichnisse packen, schon unterstützt der textureditor, leveleditor und die engine selber ein neues dateiformat und dank pluginmanager kann ich jedes dieser dateiformate in allen anderen aplikationen nutzen, egal ob screengrabber, imageconverter oder grafiker-script. wenn ich aber vorher die lib in jedes modul statisch einbauen würde, wäre ich ewig am durchcompilieren und linken (dauert bei den engines an denen ich arbeite schonmal ne ganze nacht, wenn es auf nur einem rechner läuft bzw laufen würde).

ich finde man sollte von anfang an richtig mit den *.dlls umgehen können, ansonsten klingt es für mich so wie leute die sagen dass man für spiele nur c und asm anstatt c++ nutzen sollte, weil es schneller ist oder weniger probleme gibt.. und blos keine templates, denn die sind sowieso evil..

statische libs würde ich nur für kleine module nutzen, z.B. gibt es ein paar mathlibs von AMD mit 3dnow optimiertem code oder eine kleine compressions libs z.B. bz2

rapso->greets();

ps. früher war ich auch unwillig dlls zu nutzen, aber heute kann ich mir nicht vorstellen dass in den firmen die ich kenne ein workflow möglich wäre, wenn alle alles statisch linken, alleine schon dadurch, dass erst interfaces erstellt und verteilt werden ohne funktionalität und es trotzdem möglich ist durch zu kompilieren ohne dass man auf nen anderen warten muss, der die woche lang urlaub hat... aber sicher, für eine person ohne ausblick auf zukünftige arbeit reicht auch statisches linken oder gar keine modulisierug, da geb ich jedem recht.

[volkard]

also ihr könnt neue dlls kriegen, obwohl der erteller in urlaub ist, aber neue libs gehen nicht?
ach nein, es ist die möglichkeit, bewußt mit ner alten dll zu leben, obwohl schon neue header verteilt sind? das ginge mit ner lib natürlich nicht. außer, man macht es einfach.
blödsinn. auch bei libs soll und muß man die inkludeabhängigkeiten reduzieren. während der entwicklung überall pimpl-idiom.
aber ich geb dir recht, daß bei kaputten libs, bei jeder änderung ne nacht lang compilieren dlls klar besser sind. die kann man löschen und man merkts erst tage später, wenn man glück hat.

zum anfang:

ich stell mir die Frage ob ich meine Engine in eine DLL tun soll oder sie in der exe drin lassen soll. Was meint ihr dazu?

ich meine, daß dll hier unfug ist. wenn die lib mal an viele leute weitergegeben werden soll, ist lib immernoch gut. und wenn du ne dll draus machen magst, weils cooler ist, kannste das auch immernoch machen. aber bis dahin spar die den mist besser. hauptaugenmerk soll bei der entwicklung der engine liegen, und nicht bei fallstricken um dlls.

[ Dieser Beitrag wurde am 01.04.2003 um 23:09 Uhr von volkard editiert. ]

[rapso]

mein fazit ist wäre anders:
wenn du dich gegen eine dll entscheidest, bloss weil du glaubst, dass du mit den problemen nicht klarkommst die damit auftretten könnten, dann wirst du dein ganzes dasein als programmierer entweder hassen oder auf unterster ebene verbringen.
irgendwann wirst du unkompliziert etwas tauschen wollen z.B. eine dll die debuginformationen ausgibt oder dir alles im wireframe anzeigt, in einer datei logt oder einen http server bietet der dir statusinformationen anzeigt z.B. über die polygonezahl oder objektmenge, dann wirst du es genießen einfach nur zwei dlls umzubenennen und nicht irgendwelche tools die man erstellt neu kompilieren zu müssen.

sicher dauert es ein wenig bis man mit dlls nützlich umgehen kann, aber am ende sparen sie viel arbeit... aber das ist mit allen techs so.

rapso->greets();