c ++ - Statisk/Dynamisk Runtime Linking

Indlæg af Hanne Mølgaard Plasc

Problem



Hvad er de bedste metoder til at vælge linkingsmetoden i VC ++? Kan noget/alt være statisk forbundet?


På et dynamisk forbundet projekt er den relative/absolutte placering af det linkede bibliotek vigtigt?


Hvad er fordele og ulemper?


tilføjet : Jeg henviste primært til lib-filer. Opfører de sig det samme som dll linking?

Bedste reference


Dynamiske links giver dig mulighed for at opgradere individuelle DLL'er uden at genkompilere dine applikationer. Derfor kan vinduer opgraderes, uden at din applikation bliver kompileret, fordi den dynamiske linker er i stand til at bestemme indgangspunkterne i dll'en, forudsat at metodenavnet eksisterer.


Statisk at forbinde din ansøgning har en fordel, fordi opkald til den linkede kode ikke indirekte, så de løber hurtigere. Dette kan have indflydelse på ekstremt præstationsafhængig kode.


Brug af DLL'er kan også hjælpe dig med at reducere dit hukommelsesfodaftryk, ligesom du kun indlæser bibliotekerne, når du har brug for dem, og du kan aflaste dem, når dine færdige (tænkt applikationsprogrammer kun skal indlæse et billedbrowserbibliotek, når du har et billede åbent osv.)


EDIT: Robert Gamble har tilføjet en kommentar, som jeg savnede: DLL'er er indlæst i hukommelsen, der deles af alle processer i operativsystemerne. Dette betyder, at hvis to programmer (eller to forekomster af dit program) bruger den samme DLL, vil de bruge den samme DLL indlæst i hukommelse, hvilket vil reducere din generelle hukommelsesforbrug yderligere.

Andre referencer 1


DLLs kan gøre for mindre runtime-workingset, hvis applikationen blev skrevet på en sådan måde, at konteksten skiftes mellem DLL'er (for eksempel til større applikationer kan du opdele applikationsfunktionaliteten i logiske grænser til implementeres inden for selvstændige DLL'er og tillade loader at indlæse ved runtime).


Selv om det er korrekt, at DLL'er primært er installeret/kopieret i samme mappe som .exe, er kravet om at overholde lasterens indlæsningsregler (som indeholder systemmappe (dårlig idé), PATH, nuværende katalog [[se LoadLibrary API Help dokumentation for en fuldstændig beskrivelse af forrangen]]).


Du har 'tilføjet' en kommentar vedrørende LIB-filer. I Både Dynamisk og Statisk, linker du med LIB-filer. Men i tilfælde af dynamisk belastning leverer du .exe sammen med alle afhængige DLL'er (LIB-filerne indeholder de eksporterede indgangspunkter for den tilsvarende DLL).


Jeg foretrækker DLL'er, da mine applikationer har tendens til at være større og segmenterede, og det giver mig mulighed for kun at levere de opdaterede komponenter (DLL'er). Vi adskiller selv forretningslogik fra præsentation i deres egne DLL'er [[tillader lokalisering af den eneste ressource-dll uafhængig af logikken.


Programmering ved hjælp af DLL'er gør det muligt for dig at tvinge dig til at overholde kontrakten for den eksporterede klasse/metode eller funktion.

Andre referencer 2


Den indlysende fordel at dll er, at du kan opgradere enkelte komponenter ikke kun hele applikationen (i teorien) og dele fælles komponenter (ved at indkapslere dem i dll'er). Desværre er der i praksis en vis bindende binding mellem dll (s) (selv når den er defineret godt). Det fører dig til at opgradere DLL i matchende sæt og isolere DLL'er, der ikke spiller godt sammen.


Hvis ikke gjort omhyggeligt opgradering, kan DLL føre til problemerne kendt som DLL Hell. [1]


I virkeligheden har en applikation tendens til at sætte alle de dll'er, de bruger i samme mappe som den eksekverbare. Dette tillader opgradering, men fremmer ikke deling. Opgradering består herefter af opgradering af sæt DLL'er i applikationskataloget, der synkroniseres med DLL i Windows Central Repository.