[C++] struct en data lokaties

[elgringo]

Ik lees vanuit een externe DLL (van siemens) een * naar een aantal (1024) structs uit. De struct is alsvolgt:

C++:

typedef struct {
    unsigned short BlkType;         // Bausteintyp                          2
    unsigned short BlkNumber;       // Bausteinnummer                       2
    char BlkName[8];                // Bausteinname                         8
    unsigned char BlkVersion;       // Bausteinversion                      1
    unsigned long BlkLength;        // Bausteinlänge                        4
    struct tm BlkTimestamp1;        // Zeitstempel zu der Bausteinnummer    36
    struct tm BlkTimestamp2;        // Zeitstempel zu der Bausteinnummer    36
    unsigned char blkSecurity[4];   // Baustein Schutzstufe                 4
} BST_STAT_TYPE;

(tm is een struct met 9 ints, 36 byte groot)

Vanuit deze link ga ik er van uit dat hij 93 bytes groot moet zijn en hij is 96
Echter neemt de unsigned char geen 1 byte in, maar 4.

96 bytes aan data (kol 1=data, kol 2 = nummer (1-97), kol 3 = opmerking):

10 1 Bloktype
0 2
11 3 Bloknummer
0 4
0 5 Naam
0 6
0 7
0 8
0 9
0 10
0 11
0 12
1 13 versie
0 14
0 15
0 16
84 17 Begin lengte
13 18
0 19
0 20
32 21 tm1 sec
0 22
0 23
0 24
17 25 tm1 min
0 26
0 27
0 28
21 29 tm1 uur
0 30
0 31
0 32
26 33 tm1 dag
0 34
0 35
0 36
5 37 tm1 maand
0 38
0 39
0 40
107 41 tm1 jaar -1900
0 42
0 43
0 44
0 45
0 46
0 47
0 48
0 49
0 50
0 51
0 52
0 53
0 54
0 55
0 56 laatste tm1
33 57 begin tm2 sec
0 58
0 59
0 60
10 61 tm2 min
0 62
0 63
0 64
15 65 tm2 uur
0 66
0 67
0 68
16 69 tm2 dag
0 70
0 71
0 72
3 73 tm2 maand
0 74
0 75
0 76
105 77 tm2 jaar-1900
0 78
0 79
0 80
0 81
0 82
0 83
0 84
0 85
0 86
0 87
0 88
0 89
0 90
0 91
0 92 eind tm2
0 93
0 94
0 95
0 96
10 97

Dit is ook dit de data te zien.

Echter vraag ik me af hoe dat kan.

[Woy]

Wordt hij niet op 4 bytes (32 bits)gealligned?

In dat geval neemt je unsigned char 4 bytes ruimte in in plaats van 1. Dan kom je weer goed uit.

[google=struct alignment c++]

[ Voor 47% gewijzigd door Woy op 12-06-2007 16:09 ]

[remco_k]

elgringo schreef op dinsdag 12 juni 2007 @ 15:52:
Echter neemt de unsigned char geen 1 byte in, maar 4.

Het kan aan mij liggen maar:

code:

unsigned char blkSecurity[4];

is een array van unsigned chars, 4 stuks om precies te zijn.
Het lijkt me dus redelijk logisch dat die 4 bytes opsnoept.

Dus snap ik niet waarom je zegt 'Echter neemt de unsigned char geen 1 byte in, maar 4.'
Ik kom overigens ook op 93 uit.
Waar heb je die 96 vanaf geleid?

Edit:
Fuck niet goed gekeken... Het ging over de eerste unsigned char...
Logisch...

[ Voor 14% gewijzigd door remco_k op 12-06-2007 16:29 ]

[Woy]

remco_k schreef op dinsdag 12 juni 2007 @ 16:22:
[...]
Waar heb je die 96 vanaf geleid?

Waarschijnlijk

C++:

sizeof( BST_STAT_TYPE );

En dat verschil komt denk ik door structure alignment en padding.

[.oisyn]

de unsigned char BlkVersion neemt 4 bytes in beslag omdat de long BlkLength op 4 bytes aligned wilt zijn. Gebruik #pragma pack als je geen alignment wilt gebruiken. Echter, je moet er wel zeker van zijn dat de DLL dezelfde alignmentsettings gebruikt, anders ben je de sjaak. Ik weet niet waar dit vandaan komt, maar waarschijnlijk is de DLL gecompileerd met dezelfde alignment settings als jouw project.

[ Voor 41% gewijzigd door .oisyn op 12-06-2007 16:29 ]

[remco_k]

Met ^^ en rwb eensch. Goed gezien.
Denk dat de TS er verder niets aan hoeft te doen dus.

[ Voor 4% gewijzigd door remco_k op 12-06-2007 16:33 ]

[elgringo]

Hij komt van een externe dll waar ik niets aan kan veranderen. Maar .oisyn, #pragma pack zorgt ervoor dat hij wel 1byte wordt. Wat heeft het voordeel om hem NIET te gebruiken (tenzij hij extern aangeleverd word natuurlijk) omdat hij dan kleiner kan worden.

[Woy]

Waarschijnlijk is het sneller om gealigned geheugen te benaderen dan spul dat niet gealigned is.

[MLM]

snelheid inderdaad. en tenzij je dit struct heel veel keer gaat alloceren, zou ik gewoon die 3 bytes extra geheugen voor lief nemen

[remco_k]

Het hangt er ook een beetje vanaf hoe je de variabelen in de struct gaat toewijzen. Doe je een soortgelijk als memcpy(=snelste) of via een union dan zal je eerst zeker moeten weten hoeveel bytes de dll 'had bedacht' voor die unsigned char, maar zo aan de data te zien, zijn dat er ook 4.
Je hebt het snel genoeg getest imo.

Vroeger, in het MSX1/2 , Atari 1040st en commodore Amiga tijdperk (en daarvoor) zouden we over deze 3 'loze' bytes zijn gevallen. Vandaag de dag is dat niet interessant tenzij je deze struct veelvuldig (>100 ofzo) gaat instantieren.

Ik zou de alignment hetzelfde gebruiken zoals de dll dat doet. Ongeacht de manier van het invullen van de variabelen.

[.oisyn]

MLM schreef op woensdag 13 juni 2007 @ 09:43:
snelheid inderdaad. en tenzij je dit struct heel veel keer gaat alloceren, zou ik gewoon die 3 bytes extra geheugen voor lief nemen

Alsof allocaties byte-granulariteit hebben (in grote arrays of uit fixed pools kan het natuurlijk wel zinnig zijn)

[ Voor 10% gewijzigd door .oisyn op 13-06-2007 12:05 ]

[schoene]

remco_k schreef op woensdag 13 juni 2007 @ 11:01:
Vroeger, in het MSX1/2 , Atari 1040st en commodore Amiga tijdperk (en daarvoor) zouden we over deze 3 'loze' bytes zijn gevallen. Vandaag de dag is dat niet interessant tenzij je deze struct veelvuldig (>100 ofzo) gaat instantieren.

>100? dan heb je toch wel 300 bytes te veel gereserveerd. Wat een zonde

[remco_k]

schoene schreef op woensdag 13 juni 2007 @ 12:04:
[...]

>100? dan heb je toch wel 300 bytes te veel gereserveerd. Wat een zonde

Hangt van het doel af.
Als deze 100 structs door een 1200 baud serieel verbindinkje moeten worden gefrommeld, dan zou ik er wel een keer extra over nadenken.

[.oisyn]

Als dat zo was dan zou ik sowieso eens extra na gaan denken over de inhoud van de struct in termen van bits ipv bytes, en Name en Security een variabele lengte geven ipv een vaste lengte, als dat mogelijk is

[MSalters]

Yep, en die struct tm is ook redelijk ridicuul over een 1200 baud lijn.