запутался с пониманием выдержки из книги: structs

всем здравия.

есть пример в книжке, в котором расписано как реорганизовать данные для одного конкретного примера (см. ниже), чтобы более оптимизированно использовать эти самые данные.

но на нижеописанном этапе застопорился - не могу разложить все по полочкам. может кто-нибудь пояснит, почему все здесь именно так, а не иначе.
буду благодарен.

Код (Text):

1. struct Address
2. {
3.     char    *streetName;
4.     char    *zipCode;
5.     short    houseNumber;
6. } ;
7.  
8. union Location
9. {
10.     Address    adr;
11.     int        poBox;
12. } ;
13.  
14. struct Client            // sizeof(Client) = 20 bytes
15. {
16.     char    *name;
17.     short    cityCode;
18.  
19.     char        locationSelector;
20.     Location    loc;
21. } ;

Код (Text):

1. struct ClientAdr            // sizeof(ClientAdr) = 16 bytes
2. {
3.     char    *name;
4.     char    *streetName;
5.     char    *zipCode;
6.     short    houseNumber;
7.     short    cityCode;
8. } ;
9.  
10. #pragma pack(push,2)
11. struct ClientPoBox        // sizeof(ClientPoBox) = 10 bytes
12. {
13.     char    *name;
14.     short    cityCode;
15.     int    poBox;
16. } ;
17. #pragma

собссно, непонимание начинается с абзаца, обозначенного "##" и далее. непойму все sizeof() нижерасписанных этих структур в статье.
в частности, почему sizeof(Client) = 20 bytes, sizeof(ClientAdr) = 16 bytes, sizeof(ClientPoBox) = 10 bytes ?

 

sizeof(Address) == 4+4+2+2(вследствие выравнивания) == 12
sizeof(Location) == 12
sizeof(Client) == 4+2+1+1(выравнивание)+12 == 20
sizeof(ClientAddr) == 4+4+4+2+2 == 16
sizeof(ClientPoBox) == 4+2+4+0(т.к. выравнивание здесь по 2 байтам вместо 4 по умолчанию) == 10

 

maxdiver,
спасибо за пояснение; теперь прояснилось насчет sizeof! а то я стопорился на sizeof(Location), т.к. забыл что размер объединений принимается равным размеру наибольшего элемента, который это объединение содержит.

теперь понял это утверждение

если клиент в примере определяется по его PoBox номеру, то выходит, что используются поля char *name (4 байта), short cityCode (2 байта), и по-идее int PoBox (4 байта), итого, 10 байт, и с учетом дефолтного выравнивания на 4 байта, получается 12 байт. тем самым имеем, что структура Address становится излишней для идентификации клиента в примере, и отсюда эти "лишние" 20 - 12 = 8 байт, про которые в тексте и говорится.

теперь оффтопная эзотерическо-практическая часть)
теперь, касаемо непосредственного применения этого решения с разбиением структуры идентификации клиента на 2 струкруты (первая занимает 16 байт, вторая - 10).
допустим у нас есть клиент, который идентифицируется по его адресу, т.е. нужно в базу (или еще куда-то) закинуть его инфу как структуру ClientAdr, и есть второй клиент, который в отличие от первого идентифицируется по CityCode, т.е. инфу о нем уже надо сохранять как структуру ClientPoBox (дабы не растрачивать излишние ненужные байты, к чему и стремится это решение с двумя структурами).
вопрос -- находит ли такой способ применение в реальных задачах, и если да, то каким образом ведется работа сразу с двумя этими "storage places": создаются и поддерживаются эти две разные базы (но тогда нам уже будет необходимо опрашивать эти 2 базы в случае поиска конкретного клиента, имея в качестве ключа поиска только его имя (name)? неужели эффективнее постоянно опрашивать 2 базы, чем тупо использовать одну базу с структурами описанными в начале первого поста, пускай тем самым и проигрывая по суммарному размеру, отведенному под структуры?

 

Ну тут видимо вопрос сводится к тривиальному: время или память.
А если добавить-таки в каждую структуру в начало её sizeof, то время получим то же, а память (при условиях, указанных в условии) всё равно будет экономиться

p.s. "условия, указанные в условии" - классно сказано ))

 

maxdiver

да, согласен. )