# Bibliotheken in visual studio einbinden



## gragorl (24. Dezember 2016)

Fröhliche Weihnachten erst mal.

Also meine Frage ist, ob es möglich ist eine Bibliothek Zebu glew in visual Studio einzubinden, und zwar so, dass ich diese dann in jedem Projekt nutzen kann. Da ich es für sehr aufwändig halte in jedem neuen Projekt alle Bibliotheken einzubinden.

ich würde mich über schnelle Hilfe freuen.
MfG Gragorl


----------



## cwriter (24. Dezember 2016)

Hi


gragorl hat gesagt.:


> Fröhliche Weihnachten erst mal.


Danke gleichfalls.



gragorl hat gesagt.:


> Also meine Frage ist, ob es möglich ist eine Bibliothek Zebu glew in visual Studio einzubinden, und zwar so, dass ich diese dann in jedem Projekt nutzen kann. Da ich es für sehr aufwändig halte in jedem neuen Projekt alle Bibliotheken einzubinden.


Möglich ja, sinnvoll: Eher nicht. Den Ordnerpfad, worin sich die lib befinden soll, kannst du hinzufügen, was den Linkvorgang ein bisschen bremst, aber nicht "spürbar". Ich würde aber davon abraten, immer gleich die gesamte Lib zu verlinken, das bremst dann doch arg stark. D.h. du müsstest dann in jedem Projekt noch angeben, dass du die lib willst, aber nicht, wo sich die befindet.
(VS hat eigentlich eine recht angenehme Syntax (in den vorkompilierten Header einfügen):

```
#pragma comment(lib, "<libname>.lib")
```
, wodurch die Bibliothek in jedem Modus gelinkt wird.)

Hier wird das Ändern des Defaults eigentlich recht gut erklärt:
https://social.msdn.microsoft.com/F...de-directory-for-all-projects?forum=vcgeneral

Gruss
cwriter


----------



## gragorl (24. Dezember 2016)

Ich verstehe nicht was du mit gesamte lib meinst. Ich will es nur so einstellen dass ixh in all meinen Projekten die glew lib verwenden kann


----------



## cwriter (24. Dezember 2016)

gragorl hat gesagt.:


> Ich verstehe nicht was du mit gesamte lib meinst. Ich will es nur so einstellen dass ixh in all meinen Projekten die glew lib verwenden kann


Ja. Und wenn du dann in jedem Projekt automatisch gegen deine lib linkst, haben alle Executables diese Funktionen drin und werden gross und fett.
Wenn du nur den "lib-Pfad" (also wo deine Bibliothek liegt) als Standard setzt, ist das weniger problematisch, da du pro _Projekt_ sagen kannst, dass du die Bibliothek willst, und VS sucht dann in den angegebenen Pfaden. Wenn du direkt sagst, dass du immer gegen deine Lib linken willst, dann linkt VS auch _immer _dagegen, egal, ob du die Funktionen darin tatsächlich brauchst (möglicherweise sind neuere Iterationen klüger, aber ich würde mich nicht darauf verlassen).

Du kannst ja schon so die Lib in jedem Projekt benutzen, du musst es halt entsprechend einstellen 
Aber das willst du ja nicht:


gragorl hat gesagt.:


> Da ich es für sehr aufwändig halte in jedem neuen Projekt alle Bibliotheken einzubinden.


Ein automatisches Include/Link-System hat VS nicht. Also entweder linkst du immer alle deine Bibliotheken, die du jemals gebraucht hast, gegen dein neues Projekt und bekommst riesige (paar hundert MB) Programme. Oder du nimmst dir die Zeit, bei einem Projekt einmal die Libraries anzugeben. Oder du machst den Kompromiss, VS als Default zu sagen, wo es suchen soll und dann in jedem Projekt die Namen (nicht die Pfade) der Bibliotheken anzugeben (was allerdings auch nicht ideal ist, da du beim Kompilieren (eigentlich Linken) ein bisschen Zeit verlierst, was aber nicht ins Gewicht fallen sollte).

Der Hintergrund ist: Statische Bibliotheken (.lib, .a) werden quasi als Blob genommen, ein bisschen geschoren, was zusätzliche Linkerinformationen angeht, und dann in die .exe geschossen. Das macht die Programme grösser. Bei .dlls musst du ja auch .lib dazulinken, die Platzhalterfunktionen beinhalten, die dann dem OS sagen: "Hey, ich weiss nix, aber ich weiss, wo du die Funktion herbekommst". Das bläst aber auch das Programm auf (Vereinfacht gesagt: Statisches Linken ist gut für Programme, die schnell sein müssen und wenn die Bibliothek klein ist, Dynamisches Linken ist gut für grosse Standardbibliotheken, die wahrscheinlich auch von anderen Programmen verwendet werden). Aber bei beiden gilt: Wenn du es nicht brauchst, linke sie nicht in das Programm.
Die berühmte Autoanalogie wäre, wenn du an/in deinem Auto immer Schneeketten, Spikes, Sperrdifferential, Schwimmwesten, Gleitschirme, Campingkocher und Zelte hast, weil du alles irgendwann mal gebraucht hast, aber nun gemütlich innerorts zu Einkaufen fährst: Es ist zusätzlicher Ballast; alles für bestimmte Anwendungsfelder nützlich, ohne Frage, aber du brauchst nicht immer alles.
Also gibt es den Standard, dass du immer sagen musst, was du mitnehmen willst, und wo der Assistent es finden kann, wenn er für dich das Auto packen soll. (Das, sagtest du, wolltest du nicht).

Der nächste Schritt wäre, dem Assistenten zu sagen, wo die Dinge immer sind, er müsse sie halt nur an diesen Orten suchen. Der Assistent hat ein bisschen länger, um die Dinge aufzutreiben, aber schlussendlich geht es und du hast nicht einfach für nichts zu viel im Auto. Du musst aber sagen, _was_ du mitnehmen willst. (Das wäre mein "Kompromissvorschlag")

Wenn du aber sagst: "Ach, lass einfach alles im Auto bzw. lege einfach alles vor jeder Fahrt hinein", dann fährst du immer mit zu viel Ballast herum, und das ist nix gut. (Das scheint das zu sein, wonach du gefragt hast)

Fun Fact: Java ist so ein Allround-Bomber. Riesig, fett, vielseitig, aber verschwenderisch und (im Vergleich zu C/C++/(ASM)): Lahm und ineffizient.

Gruss
cwriter


----------



## gragorl (25. Dezember 2016)

mit einbinden meine ich
lib files als additional dependencies angeben
include files auch
dll.datei in projekt kopieren usw

das wir uns da richtig verstehen
bin mir da nicht ganz sicher

aber trotzdem danke für die antwort hab das alles jetzt scho ein bisschen besser verstanden


----------

