[Mannequeen]

Jak działa pakowanie struktury przez pragma pack w przypadku gdy jedno pole to std::variant? Jest to bezpieczne? #programowanie #programista15k #cpp #cplusplus #it #programista50k #embedded

[zetisdead]

@Mannequeen: a czemu miałoby być niebezpieczne?

[Saly]

@zetisdead: struktury zawsze mają stały rozmiar. Zmiana rodzaju pakowania zmienia rozmiar jednej struktury, cała reszta pozostaje bez zmian. Zmiana layoutu może dodać/usunąć padding oraz zmienić kolejność pól w strukturze, nic więcej

Wariant pod spodem ma wartość oznaczającą który wariant jest aktywny i odpowiednią ilość miejsca na przechowanie dowolnego wariantu tj. zależną od największego wariantu.

[Mannequeen]

@Saly: Okay, a jak jest w drugą stronę? Jeżeli jednym z wariantów w std::variant jest spakowana struktura, to czy implementacja std::variant nie polega na wyrównaniu struktur w środku?

[Saly]

@Mannequeen: każda struktura zajmuje tyle samo miejsca. Struktury nie rozpłaszczają się jedna w drugiej, bo są traktowane jako black boxy o określonym rozmiarze. Jak sizeof == 9 to ta struktura będzie zajmowała zawsze co najmniej 9 bajtów.

pragma pack może zrobić tyle:
* posortować pola według rozmiaru. Pola o rozmiarze 8, 2 , 4, 1 lepiej posortować do 8, 4, 2, 1, dzięki czemu nie musisz mieć 8, 2, (padding 2),

[Nady93]

Pierwsze słyszę, żeby pragma pack mogła zmienić kolejność pól. Jesteś tego pewien @Saly?

[Saly]

@Nady93: szczerze mówiąc nie wiem. Bardziej chodziło mi o to co ogólnie takie optymalizacje zmieniające layout struktury mogą robić.

[Nady93]

@Saly: Generalnie takie przestawianie kolejności pól, żeby pozbyć się paddingów ma jak najbardziej sens, ale wydaje mi się, że musisz o to zadbać ręcznie. Na mój stan wiedzy żaden kompilator nawet z najbardziej agresywnymi optymalizacjami nie przestawi kolejności pól.

Odpowiadając na pytanie op @Mannequeen
pragma pack wokoło struktury która zawiera std::variant jest bezpieczne, sama zawartość std::variant nie będzie naruszona przez pakowanie, variant będzie traktowany jak każdy inny element struktury.

[Saly]

Generalnie takie przestawianie kolejności pól, żeby pozbyć się paddingów ma jak najbardziej sens, ale wydaje mi się, że musisz o to zadbać ręcznie.

@Nady93: wiem, że Rust tak robi. Go też chce, ale się ociąga. Języki z rodzinny C tak robią głównie dlatego, że legacy i ktoś uznał, że trzymanie się kolejności podanej przez użytkownika ma sens.

[BeginEnd]

@Nady93: wiem, że Rust tak robi. Go też chce, ale się ociąga. Języki z rodzinny C tak robią głównie dlatego, że legacy i ktoś uznał, że trzymanie się kolejności podanej przez użytkownika ma sens.

@Saly: Obiecałem, żonie że będę miły dzisiaj więc tak łagodnie rzecz ujmując wielką nieprawdę piszesz koledze @Mannequeen Żaden język, który ma stabilne ABI nie przestawia kolejność pól w strukturach. A C i C++

[Hauleth]

Na mój stan wiedzy żaden kompilator nawet z najbardziej agresywnymi optymalizacjami nie przestawi kolejności pól.

@Nady93: Nie w C i C++, bo standard tego wymaga. Inne (nowsze) języki mają taką możliwość.

@zetisdead z bardzo prostego powodu to będzie niebezpieczne - bo alignment może się rozjechać.

[Saly]

Żaden język, który ma stabilne ABI nie przestawia kolejność pól w strukturach.

@BeginEnd: stabilne ABI jest cechą implementacji a nie języka. C++ ma stabilne ABI, bo Linux przez swoją tradycję (dynamiczne linkowanie) tego wymaga, inaczej wszystko musiałoby być kompilowane ze źródeł. Rust nie ma takiego problemu, bo tam dynamiczne linkowanie to ciekawostka a nie norma a jak chcesz mieć stabilne ABI to używaj tego z C.

Nie wiem jak jest

[Passer93]

@Mannequeen std::variant nie ma nic do pragmy pack. Ta pragma służy tylko do ręcznego ustawiania alignmentu, dlaczego to miałoby w jakikolwiek sposób wpływać na std::variant? std::variant to zwykły kontener, cokolwiek wsadzisz do środka to będziesz to tam miał.

@Saly
@Hauleth: Mówienie, że w C++ kompilator nie przestawia data memberów też nie jest do końca precyzyjne. Do C++23 kompilator musiał tylko szanować porządek deklaracji w ramach jednego access specifier,