Hvad er tidlig og sen binding?
On november 18, 2020 by adminJeg bliver ved med at høre om tidlig og sen binding, men jeg forstår ikke, hvad de er. Jeg fandt følgende forklaring, som jeg ikke forstår:
Tidlig binding henviser til tildeling af værdier til variabler under designtiden, mens sen binding henviser til tildeling af værdier til variabler i løbetid.
Kunne nogen definere de to typer binding og sammenligne dem?
Kommentarer
- kompileringstid vs runtime.
- Her er en god læsning om emnet: da.wikibooks.org/ wiki / Introduction_to_Programming_Languages / …
Svar
Der er to hovedkoncepter i forvirring: binding og indlæsning. Det er sammensat af begrebet DataBinding, som et sted i midten ofte gør begge dele. Efter at have overvejet det, vil jeg tilføje endnu et koncept for at afslutte trifecta, afsendelse.
Typer
Sen binding : type er ukendt indtil variablen udøves under kørselstid; normalt gennem opgave, men der er andre måder at tvinge en type på; dynamisk typede sprog kalder dette en underliggende funktion, men mange statisk typede sprog har en eller anden metode til at opnå sen binding
Implementeret ofte ved hjælp af [specielle] dynamiske typer, introspektion / refleksion, flag og kompilatorindstillinger eller gennem virtuelle metoder ved at låne og udvide dynamisk forsendelse
Tidlig binding : typen er kendt inden variablen udøves under kørselstid, normalt ved hjælp af en statisk, deklarativ måde
Implementeret ofte ved hjælp af standard primitive typer
Funktioner
Statisk afsendelse : kendt, specifik funktion eller subrutine ved kompileringstidspunktet; det er utvetydigt og matches af signaturen
Implementeret som statiske funktioner; ingen metode kan have den samme signatur
Dynamic Dispatch : ikke en bestemt funktion eller subrutine ved kompileringstidspunktet; bestemmes af konteksten under udførelsen. Der er to forskellige tilgange til “dynamisk afsendelse”, der adskilles af, hvilken kontekstuel information der bruges til at vælge den passende funktionsimplementering.
I enkelt [ dynamisk ] afsender , kun typen af forekomst bruges til at bestemme den passende funktionsimplementering. I statisk-typede sprog betyder dette i praksis, at instansstypen bestemmer, hvilken metodeimplementering der anvendes uanset den referencetype, der er angivet, når variablen erklæres / tildeles. Da kun en enkelt type – typen af objektforekomsten – bruges til at udlede den passende implementering, kaldes denne tilgang “enkelt forsendelse”.
Der er også multiple [ dynamisk ] afsendelse , hvor inputparametertyper også hjælper med at bestemme, hvilken funktion implementering der skal kaldes til. Fordi flere typer – både typen af forekomsten og typen (e) af parameteren / parametrene – påvirker hvilken metodeimplementering der er valgt, denne tilgang kaldes “multiple dispatch”.
Implementeret som virtuelle eller abstrakte funktioner; andre spor inkluderer tilsidesatte, skjulte eller skyggefulde metoder.
NB: Hvorvidt metodeoverbelastning involverer dynamisk afsendelse er sprogspecifik. For eksempel sendes overbelastede metoder i Java statisk.
Værdier
Lazy Loading : strategi til objektinitialisering, der definerer værditildeling indtil behov ; tillader, at et objekt er i en i det væsentlige gyldig, men bevidst ufuldstændig tilstand og venter, indtil dataene er nødvendige, inden de indlæses; ofte fundet særlig nyttig til at indlæse store datasæt eller vente på eksterne ressourcer
Implementeret ofte ved målrettet ikke at indlæse en samling eller en liste i et sammensat objekt under konstruktør- eller initialiseringsopkald, indtil en nedstrøms opkalder beder om at se indholdet af den samling (f.eks. get_value_at, get_all_as osv.).Variationer inkluderer indlæsning af metaoplysninger om samlingen (som størrelse eller nøgler), men udeladelse af de faktiske data; giver også nogle mekanismer en mekanisme, der giver udviklere en ret sikker og effektiv implementeringsplan for singleton
Ivrig indlæsning : strategi til objektinitialisering, der straks udfører alle værditildelinger for at have alle de data, der er nødvendige for at være komplette, før de betragter sig selv som i en gyldig tilstand.
Implementeret ofte af tilvejebringelse af sammensatte objekter med alle deres kendte data så hurtigt som muligt, som under et konstruktøropkald eller initialisering
Data Binding : involverer ofte oprettelse af et aktivt link eller kort mellem to kompatible informationsstrømme så ændringer til den ene reflekteres tilbage i den anden og omvendt; For at være kompatible skal de ofte have en fælles basetype eller interface
Implementeret ofte som et forsøg på at give renere, konsistent synkronisering mellem forskellige applikationsaspekter (f.eks. visningsmodel at se, model til controller osv.) og taler om begreber som kilde og mål, slutpunkter, binde / opbinde, opdatere og begivenheder som on_bind, on_property_change, on_explicit, on_out_of_scope
EDIT NOTE: Sidste større redigering for at give beskrivelse eksempler på, hvordan disse ofte forekommer. Specifikke kodeeksempler afhænger helt af implementeringen / runtime / platformen
Kommentarer
- Dette svar synes for specifikt til objektorienterede sprog.
- @Jack Jeg har ikke ‘ Jeg har det ikke sådan, jeg synes, det er et fremragende, der dækker mange aspekter.
Svar
Alt, hvad der besluttes af kompilatoren under kompilering, kan henvises til TIDLIG / KOMPIL TID Binding og alt, hvad der skal afgøres på RUNTIME kaldes LATE / RUNTIME binding.
For eksempel
Metode Overbelastning og metode Tilsidesættelse .
1 ) I Overbelastning af metode din metode kalder metoderne ar Det besluttes af kompilatoren i den forstand, at hvilken funktion der skal kaldes, bestemmes af din kompilator på kompileringstidspunktet. Derfor er det TIDLIG BINDING .
2) I metode Overriding bestemmes det ved RUNTIME hvilken metode der er vil blive kaldt. Så det omtales som SEN BINDING .
Forsøgte at holde det enkelt og let at få. Håber dette hjælper.
Svar
Sen binding er når adfærd vurderes ved kørsel. Det er nødvendigt, når du virkelig vil bestemme, hvordan du handler ud fra de oplysninger, du kun har, når programmet kører. Det klareste eksempel er efter min mening den virtuelle funktionsmekanisme, specifikt i C ++.
class A { public: void f() {} virtual void g() {} }; class B : public A { void f() {} virtual void g() {} }; int main() { A* a = new B; a->f(); a->g(); }
I dette eksempel kalder a->f()
faktisk void A::f()
, fordi det er tidligt (eller statisk ) bundet, og så tænker programmet ved kørsel det bare som en markør til en A
-typevariabel, mens a->g()
vil faktisk kalde void B::g()
, fordi compileren, da g()
er virtuel, injicerer kode for at finde adressen på den korrekte funktion for at ringe til runtime.
Kommentarer
- ” Runtime “? Du ‘ taler om C ++. C ++ kompilerer direkte til maskinkode, det behøver ikke ‘ ikke brug for en runtime for at løse virtuelle metoder.
- @tdammers C ++ har faktisk brug for et kørselsbibliotek, men ikke til virtuelle opkald. Hvis du læser omhyggeligt, vil du ‘ bemærke, at dette svar siger, at kompilatoren ” injicerer kode for at finde adressen på den korrekte funktion [ …] ved runtime “.
- Nå, men den ” kode at slå op på adressen for den korrekte funktion ” er grundlæggende bare en type agnostisk to-trins markørafvigelse efterfulgt af et funktionsopkald. Der er ingen ” tænkning ” involveret; den eneste grund til, at det fungerer pålideligt, er, at compileren foretager typekontrollen på kompileringstidspunktet ; ved kørsel stoler den genererede kode på, at kompilatoren har udført typekontrol hjemmearbejde. Hvis du bruger usikre rollebesætninger (f.eks.C-stil markørkast), kan du lovligt behandle C ++ – objekter som genstand for den forkerte klasse, men deres vtabeller bliver fuldstændig ødelagt, og koden bryder bare.
- @tdammers Jeg forsøgte at holde mig væk fra den slags svar, fordi det ‘ er en implementeringsdetalje af kompilatorer, som måske eller måske ikke er sandt for en esoterisk kompilator. Det der betyder noget er konceptet.
- @tdammers Og ved ” runtime ” mener jeg ” programmet ved kørsel “. Det er klart, at C ++ ikke ‘ t administreres. Men da du viste mig, kan det medføre forvirring, jeg ‘ ændrer det til den fulde ordlyd.
Svar
hvis du er fortrolig med funktionsmarkører, vil dette være et eksempel. De definerede funktioner kan siges at være tidlig binding. hvorimod hvis du bruger Funktionspegepunkter, er dens sene binding.
int add(int x,int y) { return x+y; } int sub(int x,int y) { return x-y; } int main() { //get user choice int(*fp)(int,int); //if add fp=add; //else if sub fp=sub; cout<<fp(2,2); }
her tilføjer funktioner og sub er funktioner (dens adresse er bundet ved kompilering af tidslinker)
men funktionsmarkøren er for sen binding af fp kan kalde enten tilføj eller sub afhængigt af brugervalg [ved kørsel].
Svar
Kun tidlig og sen binding giver mening i sammenhæng med typer og ikke den måde, du beskriver det på. Næsten meget alle moderne sprog er skrevet i den forstand, at alle værdier har faste typer. Forskellen kommer ind, når vi ser på dynamisk vs statisk typede sprog. I dynamisk typede sprog har variabler ikke typer, så de kan henvise til værdier af enhver type, og det betyder, at når du kalder på en metode på et objekt, der henvises til af en eller anden variabel, er den eneste måde at afgøre, om dette opkald er gyldigt eller ej, er at slå op i klassen for objektet og se om metoden faktisk eksisterer. Dette giver mulighed for nogle seje ting som at tilføje nye metoder til klasser ved kørselstid, fordi den egentlige metodeopslag udsættes indtil sidste øjeblik. De fleste kalder denne tilstand af anliggender sent bindende.
I en statisk skrevet sprog har variabler typer, og når de er erklæret, kan de ikke referere til nogen værdi, der ikke er af samme type. Dette er ikke strengt sandt, men lad os antage det for nu. Hvis du nu ved, at variablen kun nogensinde vil henvise til værdier af en bestemt type, er der ingen grund til at finde ud af, om et metodekald er gyldigt eller ikke på kørselstidspunktet, fordi du kan bestemme gyldigheden, før koden nogensinde køres. Dette kaldes tidlig binding.
Et eksempel til demonstration af sen binding i rubin:
a = 1 # a is an integer at this point a.succ # asking for its successor is valid class A def method_a # some code end end a = A.new a.method_a # this is also valid a.succ # this is not valid class A # we can re-open the class and add a method def succ # some more code end end a.succ # now this is valid
Ovenstående handlingssekvens er ikke muligt på et sprog som Java, hvor alle typer er faste i løbetid.
Svar
I stedet for at give dig en akademisk definition I vil prøve at vise dig nogle af forskellene ved hjælp af et virkeligt verdenseksempel ved hjælp af VBA:
Tidlig binding:
Dim x As FileSystemObject Set x = New FileSystemObject Debug.Print x.GetSpecialFolder(0)
Dette kræver, at der indstilles en henvisning til “Microsoft Scripting Runtime” -komponenten på designtid . Det har den fordel, at du allerede får en fejlmeddelelse ved kompileringstidspunktet, når du har en tastefejl i FileSystemObject
eller metodenavne som GetSpecialFolder
.
Sen binding
Dim x As Object Set x = CreateObject("Scripting.FileSystemObject") Debug.Print x.GetSpecialFolder(0)
Dette kræver ikke, at der skal indstilles en reference på forhånd, oprettelsen af forekomsten og typen beslutsomhed vil bare ske i løbetid. Compileren klager ikke på kompileringstidspunktet, når du prøver at kalde en ikke-eksisterende metode til x
, dette vil kun føre til en kørselstidsfejl, når den specifikke linje udføres .
Så ulempen ved sen binding er, at du ikke har nogen stærk type, der kontrollerer her. Men det er også fordelen – lad os sige, at du har en komponent, hvor der findes flere versioner, og hver nyere version giver nogle ekstra funktioner. (Et virkeligt eksempel er MS Office-komponenter, som Excel COM-grænsefladen) Sen binding tillader du skriver kode, der fungerer sammen med alle disse versioner – du kan først bestemme den specifikke komponentversion, og hvis du finder ud af, at du kun har en ældre version tilgængelig, skal du undgå at udføre funktionsopkald, der ikke fungerer med den version.
Svar
Det mest almindelige eksempel på sen binding er måske løsning af internet-URLer. Det understøtter dynamiske systemer og store systemer uden at forsøge at linke og binde hvert websted i verden, før du kan nå noget, men på den anden side medfører det noget overhead (DNS-opslag, meget mindre IP-routing) ved kørsel.
På denne baggrund er de fleste sorter af binding i sprogmiljøer mere eller mindre tidlige på kompileringstidspunktet eller linktidspunktet.
Hver type har omkostninger og fordele.
Kommentarer
- Kan du placere en reference til denne definition af binding?Jeg har ikke hørt om at løse internetadresser som ” binding “, selvom binding er handlingen med at løse navne, antager jeg nogen har argumenteret at begrebet tidlig / sen binding kan anvendes til løsning af URI til internetadresser. Men dette er ikke en almindelig fortolkning, og begrebet tidlig / sen binding er forud for det tidspunkt, hvor computere ofte var forbundet til internettet.
Skriv et svar