[Delphi] Verschil record/packed record

[Spinal]

Een kennis gebruikt een packed record en ikzelf een gewone record voor hetzelfde doel.
Wat is het verschil tussen deze twee?
Wat is het voordeel van de ene of de andere?

[Verwijderd]

packed wil zeggen dat de velden in het record in gecomprimeerde vorm worden opgeslagen.

[Creepy]

Op vrijdag 21 juni 2002 21:06 schreef Yakko het volgende:
packed wil zeggen dat de velden in het record in gecomprimeerde vorm worden opgeslagen.

En daarmee bedoel je?? De data in het record wordt echt niet ineens gecompirmeerd hoor..

Van community.borland.com
In 32 bit environments, records are automatically aligned on
32 bit boundaries when the $A+ compiler directive is in effect. This
is done by padding the record so each record will be located on a 32
bit boundary. If you are reading in data from a file containing
non-aligned records, the data may not be read in correctly if you are
using automatic record alignment. To turn off automatic record
alignment for a given record type, use the "packed" record attribute.
Globally turning off record alignment with the $A- is not recommended,
as much of the system requires record alignment to be on. The
following example demonstrates the size difference of a packed and
unpacked record.

[Verwijderd]

Op vrijdag 21 juni 2002 20:52 schreef ZanderZ het volgende:
Een kennis gebruikt een packed record en ikzelf een gewone record voor hetzelfde doel.
Wat is het verschil tussen deze twee?
Wat is het voordeel van de ene of de andere?

Het verschil is hoe Delphi dit record representeert. Als je een record maakt van 2 integers (a en b) en een string van 10 karakters (str), zou je de representatie van dat record als volgt verwachten:

4 bytes voor a
4 bytes voor b
10 bytes voor str

(Aangenomen dat we 4-byte integers hebben). Delphi representeert het echter niet standaard zo. Vaak staat er nog extra informatie in het record (de redenen voeren te ver om te noemen), bijv:

4 bytes voor a
2 bytes extra informatie
4 bytes voor b
10 bytes voor str

Soms is het handig als je een record in 1 keer kunt vullen (op byte-niveau). Als je nu in een keer 18 bytes (4+4+10) wil kopieren naar het record (dus het record in 1 keer vullen, op byte-niveau), dan gaat dit mis omdat Delphi er 2 bytes tussenduwt. Als je
"packed" mee geeft aan de declaratie, zet Delphi geen extra informatie in de structuur en wordt het record altijd zo gepresenteerd als je dat verwacht, in dit geval dus:

4 bytes voor a
4 bytes voor b
10 bytes voor str

Nu kun je wel er 18 bytes rechtstreeks in kopieren. Voor normaal gebruik maakt het echter niet veel uit, bijvoorbeeld de statements

record.a := 10;
record.b := 9;

gaan altijd goed, of je nu packed gebruikt of niet.

Ik hoop dat het een beetje duidelijk is.

[jelmervos]

Waarom gebruiken ze/we dan niet altijd een packed record? Waarom zijn er 2 verschillende?

[Creepy]

Voor optimalisatie redenen.

[b]Lang leve google die me dit gaf: http://www.drbob42.com/delphi/perform.htm[/b]
In Win32 land, this field alignment means faster execution compared to non-alignment, since DWORD-sized items on DWORD addresses are accessed much faster than on DWORD-odd addresses. Note that we must use this option with care if we're porting 16-bits Delphi code to 32-bit, since the record layout may change, which is especially harmful if we're reading or writing files that contain these (previously non-aligned) records. We must use the new keyword packed in these cases, to make sure the records are packed like before.

Packed niet gebruiken is "sneller" dus..

[Verwijderd]

packed records blijven gegarandeerd hetzelfde formaat houden in alle delphi versies. bij normale is dat niet zo.
dat is natuurlijk alleen van belang als je met verschillende delphi-versies werkt/gaat werken.

ook zijn normale records geoptimaliseerd (aligned) voor snelheid.
packed records voor grootte.

[Verwijderd]

Ik neem aan dat je packed of geen packed aangeeft bij de declaratie van de variabele en niet bij die van het type zelf??

Hoe heeft C/C++ dit opgelost?

[Creepy]

Het heeft weinig te maken met Delphi versies.. het heeft te maken met code voor een 16 bits of 32 bits platform.

Standaard zijn alle records in Delphi aligned, dus ik neem aan dat dat in C(++) op een 32 bits platform ook zo is... en dat packed is er volgens mij alleen om compatible te kunnen blijven met source van Delphi 1 en 2..... De compilers van Delphi 3 en hoger produceren geen 16 bits meuk meer.. dus als je een source van D3 hebt, en die wilt gebruiken in D6 hoef je echt niet te gaan stoeien met met packed.

Eigenlijk is het een non-issue...tenzij je 16 bits code port, en bijv. bestanden hier van inleest, of records op een 1 of andere manier uitwisselt..

Gewoon geen packed gebruiken....

Ook is het in Delphi mogelijk om bij de compiler opties aan te geven dat er wel of niet gebruik wordt gemaakt van aligning. Standaard staat dit aan ($A+}, en van Borland raden ze af om dit uit {$A-} te zetten.

[Elissen]

Dat Borland het afraad is omdat dat niet alleen voor je records geld, maar ook voor variabelen. Kun je je voorstellen wat er gebeurd als je voor een for-lusje een beetje ongelukkig in het geheugen geplaatste integer gebruikt? Yep, dat wordt langzamer. ALLES wordt dan in een keer achter elkaar gezet i.p.v. het snellere aligned.

[Verwijderd]

Op zaterdag 22 juni 2002 10:10 schreef Creepy het volgende:
Gewoon geen packed gebruiken....

Ik geloof dat het voordeel van packed hierboven al aangegeven is, indien je binaire records/structures naar een externe file wilt schrijven, kan het wel degelijk een uitkomst zijn. Anders zit je straks met een twee keer zo groot bestand. Dat is in sommige gevallen niet de bedoeling. En als je in je geheugen alles unpacked doet en in de routine voor het naar een file schrijven het naar een packed record converteerd, lijkt me dat geen slechte methode.

[Spinal]

Op zaterdag 22 juni 2002 12:47 schreef unteraarsch het volgende:
Anders zit je straks met een twee keer zo groot bestand. Dat is in sommige gevallen niet de bedoeling. En als je in je geheugen alles unpacked doet en in de routine voor het naar een file schrijven het naar een packed record converteerd, lijkt me dat geen slechte methode.

Dat is inderdaad niet de bedoeling... Het bestand moet dezelfde grootte behouden.

Er een packed record van maken is dus de oplossing... Bedankt iedereen