Benutzt irgendwer dynamische Libs?

hustbaer

Morle schrieb:

hustbaer schrieb:

@Morle
Nicht wirklich. Die LIB kann auch unabhängig entwickelt/gewartet etc. werden.

Und 10 Programme neu übersetzen ist auch nur dann mehr Aufwand, wenn man keine guten Build-Skripte hat.

Ich habe beim Schreiben meines Ursprungsbeitrags schon damit gerechnet, dass sowas kommt. Es ging aber beim Ursprungsbeitrag gar nicht darum, wie die Vorteile wären man man dies und jenes hätte oder machen würde.

Schön dass du uns das wissen lässt. Aber worum ging es dann?

Ein weiterer Vorteil, den ich vergessen habe zu erwähnen: Bei DLLs ist man unabhängig vom Compiler und dessen Einstellungen der eigentlichen EXE Datei. Zumindest wenn man DLLs nur mit PODs benutzt und auf die Speicherverwaltung achtet. Reichen aus irgendwelchen Gründen keine PODs in der DLL Schnittstelle wird es bei uns übrigens immer eine echte LIB.

Ja, das kann ein Vorteil sein.

hustbaer schrieb:

Morle schrieb:

hustbaer schrieb:

@Morle
Nicht wirklich. Die LIB kann auch unabhängig entwickelt/gewartet etc. werden.

Und 10 Programme neu übersetzen ist auch nur dann mehr Aufwand, wenn man keine guten Build-Skripte hat.

Ich habe beim Schreiben meines Ursprungsbeitrags schon damit gerechnet, dass sowas kommt. Es ging aber beim Ursprungsbeitrag gar nicht darum, wie die Vorteile wären man man dies und jenes hätte oder machen würde.

Schön dass du uns das wissen lässt. Aber worum ging es dann?

Die Frage laut Topic war "Benutzt irgendwer dynamische Libs?" - Ja, ich.

Dann war im Verlauf die Frage, wieso eigentlich dynamische Libs wenn man auch statische nutzen kann. Ich habe darauf Antwort gegeben, von daher war doch "euch wissen zu lassen" gefordert.
Das es um was anderes ging, habe ich nicht gesehen.

hustbaer

Die Frage war

Benutzt hier irgendwer dynamische Bibliotheken (sprich .so oder *.dll)? Falls ja, warum?

Also ganz klar auch was die Vorteile (EDIT: OK, genaugenommen was der Grund ist, aber der ist eben oft "weil es die Vorteile X, Y und Z hat").
Und Vorteile sind eben nur so lange Vorteile, so lange es mit statischen LIBs nicht genau so gut geht.
Ist doch irgendwie klar, oder nicht?

hustbaer schrieb:

Es ging zuletzt um Gründe DLLs zu verwenden, wenn es nur eine einzelne EXE gibt.

@hustbaer: Lesen hilft. Ich bezog mich explizit auf eine Antwort welche auf einen meiner Posts folgte.

hustbaer schrieb:

Und wenn die 300 MB gross wird, dann hat man wohl sowieso ein Problem.

@hustbaer: Deinen eigenen Krempel lesen hilft noch mehr. Ich zitiere für dich nochmals:

hustbaer schrieb:

Und 10 Programme neu übersetzen ist auch nur dann mehr Aufwand, wenn man keine guten Build-Skripte hat.

Und zwar genau EINEN Post über meinem, zu welchem du mir erzählst, dass es zuletzt nur um einzelne EXE gehen sollte. Nein, DU selbst erzählst hier was von 10 Programmen.

Also lass dein Geblubber stecken. Wenn du keine Ahnung hast wie man professionell Software entwickelt, überlass das anderen.

hustbaer

@KuhTee
Du bissi doof, hm?

Meine Antwort (mit den 10 Programmen), die du zitiert hast, war eine Antwort an Morle - Beitrag von dir kann ich da keinen sehen.

Den Fehler aus einem Programm 10 zu machen hat allerdings schon Morle gemacht. Ich hab' bloss darauf geantwortet, weil es (=das Kompilieren) selbst bei 10 Programmen kein Problem wäre. Dass sich dabei ein deutlicher Nachteil bei der Binary-Gesamtgrösse ergeben könnte ist klar. Soweit waren wir vor ca. 100 Seiten in diesem Thread schon. Haste halt nicht mitbekommen oder nicht mitbekommen wollen.

Ich kann auch nix dafür wenn ihr hier immer wieder Aussagen von mir nur halb lest und dann dran rumkritisieren wollt.

Also lass du mal dein Geblubber stecken und nerv hier nicht rum.

hustbaer schrieb:

Und Vorteile sind eben nur so lange Vorteile, so lange es mit statischen LIBs nicht genau so gut geht.
Ist doch irgendwie klar, oder nicht?

Ehrlich gesagt nicht. Denn meine Entwicklungsumgebung weicht vom Ideal ganz erheblich ab - z.B. keine Build Scripte: Es werden einfach Delphi-Projekte kompiliert. Für einen Rebuild muss einer das Projekt auschecken, in Delphi öffnen, neu kompilieren klicken. Das mache ich dann jeweils für 10 Projekte.
Da bin ich mit einer DLL, die ich irgendwo reinwerfen kann, wesentlich schneller fertig.
Abgesehen davon, dass ich mir meine Ideal-Entwicklungsumgebung nicht aussuchen kann, haben wir hier nichtmal definiert, wie das Ideal überhaupt aussehen soll.

hustbaer

Morle schrieb:

hustbaer schrieb:

Und Vorteile sind eben nur so lange Vorteile, so lange es mit statischen LIBs nicht genau so gut geht.
Ist doch irgendwie klar, oder nicht?

Ehrlich gesagt nicht. Denn meine Entwicklungsumgebung weicht vom Ideal ganz erheblich ab - z.B. keine Build Scripte: Es werden einfach Delphi-Projekte kompiliert. Für einen Rebuild muss einer das Projekt auschecken, in Delphi öffnen, neu kompilieren klicken. Das mache ich dann jeweils für 10 Projekte.
Da bin ich mit einer DLL, die ich irgendwo reinwerfen kann, wesentlich schneller fertig.

OK. In dem Fall ist es für dich dann doch ein Vorteil, weil es mit deinem Projekten mit LIBs doch nicht so einfach geht.

Ich meinte nur es muss nicht immer ein Vorteil sein.
Bei meinen aktuellen Projekten wäre es egal, ich starte mein "Build.bat" File, warte 15 Minuten und hab dann ein fertiges Programmpaket.

Abgesehen davon, dass ich mir meine Ideal-Entwicklungsumgebung nicht aussuchen kann, haben wir hier nichtmal definiert, wie das Ideal überhaupt aussehen soll.

Jo. Ich arbeite noch mit VS 2005. Ist zwar schon schwer OK, vor allem im Vergleich zu VC++ 6 mit dem wir davor gearbeitet haben, aber VS 2012 wäre mir lieber.