C - lvalue address.

War room

29. mars 2014

Jeg pleier å lese en del på senga, og har nå startet på en bok som heter "Deep C Secrets", veldig spennanes bok. Men mange triks og metoder man ikkje har vært klar over på forhånd. Men det var et avsnitt som fikk meg til å gruble litt, jeg siterer:

Sitat av Deep C Secrets

The compiler allocates an address (or l-value) to each variable. This address is known at compiletime, and is where the variable will be kept at runtime. In contrast, the value stored
in a variable at runtime (its r-value) is not known until runtime.

Vis hele sitatet...

Hva gjelder dette? Vil det si at hvis jeg definerer en statisk variabel som allocares i stacken, så er adressen til denne variabelen forhåndsett? Vil dette også gjelde dynamisk allocaring i heap'en?

Og hvordan fungerer dette i praksis? Siden programmet som jeg kompilere kan jo ikkje vite om andre bruker akkurat den adressen i minnet? Jeg er klar over at moderne datamaskiner bruker virtuell minne, men har nokså begrensede kunnskaper rundt det.

etse

Ukjent

6.181 4.151

29. mars 2014

Husk at hvert program har et unikt adresseområde som den ikke deler med noen andre programmer - og kan dermed bruke adresserommet akkurat slik den ønsker. Dette kalles virtual-memory og dermed vil ikke adressen du har i selve programmet peke til den faktiske fysiske adressen i minnet - men vil ha OSet tolket om fra til en fysisk adresse (enten på SWAP-disk eller i minnet).

Dette betyr at 2 programmet fint kan ha verdier lagret på akkurat samme adresse, siden virtual memory vil gjøre at de lagres på forskjellige steder i minnet (på forskjellige page-files som det heter).

Vil anbefale å lære litt om operativsystemet sitt oppbygning om vil forstå kjærnen i C programmering, og alle de beste triksene

OS-kurset på universitetet har hjulpet meg veldig masse.

Sist endret av etse; 29. mars 2014 kl. 00:33.

0xFF

War room

Trådstarter Donor

2.408 1.141

29. mars 2014

Ja, det var det jeg tippet. Slo opp på virtual memory på wikipedia å det tok jo ikkje lange tiden før jeg innså hvordan det fungerer grovt sett.

Og var vel litt snar med første posten uten å tenke på hva jeg skrev, jeg forstår jo at dynamisk minne ikkje kan forutses, kompilatoren kan jo ikkje vite hvor mye minne jeg ønsker å allocere under runtime.

Men adressene til statisk minne blir altså forhåndbestemt under kompilering?

Takker etse.

etse

Ukjent

6.181 4.151

29. mars 2014

Så godt det er mulig, ja. Men dette gjelder ikke for minne du allokerer via Malloc, siden detter er dynamisk, og ikke statisk. Men faste variabler, som oftest ligger på stacken, vil ha bestemte adresse compile-time.

m0b

Administrator

5.008 3.420

29. mars 2014

Jeg vet ikke om dette fra et høyere nivå kan gi deg en analogi som kan være lettere å forstå bruksområdet på? http://msdn.microsoft.com/en-us/library/dd264741.aspx

Har selv brukt dette til å kunne instansiere klasser og/eller metoder basert på brukervalg man ikke vet om før brukeren faktisk utfører handlingen.

Sist endret av m0b; 29. mars 2014 kl. 02:07.

mywave

49 4

29. mars 2014

Sitat av 0xFF

Og var vel litt snar med første posten uten å tenke på hva jeg skrev, jeg forstår jo at dynamisk minne ikkje kan forutses, kompilatoren kan jo ikkje vite hvor mye minne jeg ønsker å allocere under runtime.

Men adressene til statisk minne blir altså forhåndbestemt under kompilering?

Vis hele sitatet...

Dynamisk inne (heap) kan du ikke vite noe som helst om på forhånd, siden programmet forespør operativsystemet om å få tilgang til mer minne, og operativsystemet bestemmer hvilken (virtuelle) addresse dette legges til. Enkelte operativsystemer (unix) kan en gå rundt dette ved å bruke mmap og si hvor det nye minne skal allokeres.

Statisk addressert minne kan bestemmes under kompilering (normalt kun brukt i embedding når en skal f.eks. snakke med hardware).
Statisk addresert minne kan bestemmes under linking. Men forskjellige operativsystemer har forskjellige regler på hva som er lov her. F.eks. DLL filer i windows MÅ være 100% dynamiske og må til og med være relocatable. Dvs at samme koden må kunne lastes inn til forskjellige minne-adresser inni forskjellige programmer og fremdeles fungere.

http://en.wikipedia.org/wiki/Relocation_(computing)
http://en.wikipedia.org/wiki/Linker_(computing)

0xFF

War room

Trådstarter Donor

2.408 1.141

29. mars 2014

Sitat av |d13m0b

Vis hele sitatet...

Jeg ser ikkje helt sammenhengen mellom den referansen du linker til og spørsmålet mitt. Vi snakker om C og ikkje C#. Selv om machinkodene etter compilering til to tilnærmet like programmer(C/C#) vil ha likhetstrekk med hverandre.

Sitat av mywave

Men forskjellige operativsystemer har forskjellige regler på hva som er lov her. F.eks. DLL filer i windows MÅ være 100% dynamiske og må til og med være relocatable. Dvs at samme koden må kunne lastes inn til forskjellige minne-adresser inni forskjellige programmer og fremdeles fungere.

Vis hele sitatet...

Jeg jobber typisk på Linux systemer, men dette minnet meg på et spørsmål jeg hadde for en stund siden da jeg tok på meg et lite oppdrag med å programmere et lite program i Windows, selve bruksområdet for programmet var vel ikkje helt etter boka, men hva kundene mine bruker programmene til er ikkje akkurat mitt problem.

Jeg er klar over at det er mulig, men hvor omfattende er det? Kan jeg lage en custom funksjon ala LoadLibrary () som allokerer X size størrelse i heap'en og bare leser DLL filen inn i den for så å lage funksjonspointere til funksjonens adresser? Eller må jeg ta hensyn til at DLL filen består av flere forskjellige segmenter som .data, .code, .text?

Sist endret av 0xFF; 29. mars 2014 kl. 14:51. Grunn: Automatisk sammenslåing med etterfølgende innlegg.

mywave

49 4

30. mars 2014

Sitat av 0xFF

Vis hele sitatet...

Hva sections en fil inneholder ønsker du som programmerer egentlig ikke å vite om. På unix systemer bruker du dlopen og dlsym for å laste inn et bibliotek, samt å finne symboler i den. Forskjellige operativsystemer kan ha forskjellige magi som skjer for dlopen. På Linux skjer det meste av magien i userspace som fører til en rekke mmap() kall. Du kan se dette i praksis med å utføre strace på nesten er hvilket som helst program. De fleste programmer er linket til .so filer for å fungere i segselv (runtime linking):

Kode

root@host:/# strace ls 2>&1|head
execve("/bin/ls", ["ls"], [/* 21 vars */]) = 0
brk(0)                                  = 0xf34000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f30f10be000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=20380, ...}) = 0
mmap(NULL, 20380, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f30f10b0000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)

På windows systemer (såvidt meg bekjent) er det faktisk kernel som håndterer dll loading.

Sist endret av mywave; 30. mars 2014 kl. 00:54.