Co zapobiega nakładaniu się sąsiednich członków na zajęcia?

Rozważ następujące trzy structs:

class blub {
    int i;
    char c;

    blub(const blub&) {}
};

class blob {
    char s;

    blob(const blob&) {}
};

struct bla {
    blub b0;
    blob b1;
};

Na typowych platformach, na których intsą 4 bajty, rozmiary, wyrównania i całkowite wypełnienie ¹ są następujące:

  struct   size   alignment   padding  
 -------- ------ ----------- --------- 
  blub        8           4         3  
  blob        1           1         0  
  bla        12           4         6  

Przechowywanie elementów blubi blobelementów nie zachodzi na siebie , mimo że rozmiar 1 blobmógłby w zasadzie „pasować” do wypełnienia blub.

C ++ 20 wprowadza no_unique_addressatrybut, który pozwala sąsiednim pustym członkom na dzielenie tego samego adresu. Pozwala to również wyraźnie na opisany powyżej scenariusz użycia wypełnienia jednego elementu do przechowywania innego. Z preferencji (moje podkreślenie):

Wskazuje, że ten członek danych nie musi mieć adresu odrębnego od wszystkich innych niestatycznych członków danych swojej klasy. Oznacza to, że jeśli element członkowski ma pusty typ (np. Bezstanowy alokator), kompilator może go zoptymalizować, aby nie zajmował miejsca, tak jakby był pustą bazą. Jeśli element członkowski nie jest pusty, wszelkie wypełnienia ogona mogą zostać ponownie wykorzystane do przechowywania innych elementów danych.

Rzeczywiście, jeśli użyjemy tego atrybutu blub b0, wielkość blakropli spadnie do 8, więc blobrzeczywiście jest on przechowywany w blub postaci widocznej na godbolt .

Wreszcie dochodzimy do mojego pytania:

Jaki tekst w standardach (od C ++ 11 do C ++ 20) zapobiega temu nakładaniu się no_unique_address, w przypadku obiektów, których nie można w prosty sposób skopiować?

Muszę wykluczyć z powyższego obiekty trywialnie kopiowalne (TC), ponieważ w przypadku obiektów TC dozwolone jest przechodzenie std::memcpyz jednego obiektu do drugiego, w tym podobiektów składowych, a jeśli magazyn byłby nałożony, to by się zepsuło (ponieważ całość lub część magazynu ponieważ sąsiedni członek zostanie zastąpiony) ² .

¹ Obliczamy wypełnienie po prostu rekurencyjnie jako różnicę między rozmiarem struktury a rozmiarem wszystkich jej elementów składowych.

² Jest to dlaczego mam konstruktory kopia zdefiniowane: zrobić blubi blobnie trywialnie copyable .

Norma jest strasznie cicha, gdy mówi się o modelu pamięci, i nie bardzo wyraźnie mówi o niektórych terminach, których używa. Ale myślę, że znalazłem działającą argumentację (która może być nieco słaba)

Najpierw dowiedzmy się, co jest nawet częścią obiektu. [basic.types] / 4 :

Obiektowa reprezentacja obiektu typu Tjest sekwencją N unsigned charobiektów zajmowanych przez obiekt typu T, gdzie Njest równa sizeof(T). Reprezentacja wartości obiektu typu Tjest zbiorem bitów uczestniczących w reprezentowaniu wartości typu T. Bity w reprezentacji obiektu, które nie są częścią reprezentacji wartości, są bitami wypełniającymi.

Reprezentacja obiektowa b0składa się z sizeof(blub) unsigned charobiektów, czyli 8 bajtów. Bity wypełniające są częścią obiektu.

Żaden obiekt nie może zajmować przestrzeni innego obiektu, jeśli nie jest w nim zagnieżdżony [basic.life] /1.5 :

Żywotność obiektu otypu Tkończy się, gdy:

[...]

(1.5) pamięć ozajmowana przez obiekt jest zwalniana lub jest ponownie wykorzystywana przez obiekt, który nie jest zagnieżdżony w ([intro.object]).

Tak więc czas życia b0dobiegałby końca, gdy zajmowana przez nią pamięć byłaby ponownie wykorzystywana przez inny obiekt, tj b1. Nie sprawdziłem tego, ale myślę, że standardowy nakazuje, aby podobiektyw obiektu, który jest żywy, również powinien być żywy (i nie mogłem sobie wyobrazić, jak to powinno działać inaczej).

Więc przechowywania które b0 okupuje nie mogą być wykorzystywane przez b1. W standardzie nie znalazłem definicji „okup”, ale myślę, że rozsądną interpretacją byłaby „część reprezentacji obiektu”. W opisie obiektu opisującego cytat używane są słowa „podejmować” ¹ . W tym przypadku byłoby to 8 bajtów, więc blapotrzeba co najmniej jeszcze jednego b1.

Szczególnie w przypadku podobiektów (a więc między innymi elementów danych niestatycznych) istnieje również warunek [intro.object] / 9 (ale zostało to dodane w C ++ 20, thx @BeeOnRope)

Dwa obiekty z nakładającymi się okresami istnienia, które nie są polami bitowymi, mogą mieć ten sam adres, jeśli jeden jest zagnieżdżony w drugim lub jeśli co najmniej jeden jest podobiektem o zerowej wielkości i są one różnego rodzaju; w przeciwnym razie mają odrębne adresy i zajmują rozłączne bajty pamięci .

(moje podkreślenie) Tutaj znowu mamy problem, że „zajmuje” nie jest zdefiniowane i ponownie argumentowałbym, aby wziąć bajty w reprezentacji obiektu. Zwróć uwagę, że do tego [basic.memobj] / przypisu 29 znajduje się przypis

Zgodnie z zasadą „jak gdyby” implementacja może przechowywać dwa obiekty pod tym samym adresem maszyny lub nie przechowywać obiektu w ogóle, jeśli program nie może zaobserwować różnicy ([wykonanie wstępne]).

Co może pozwolić kompilatorowi na przełamanie tego, jeśli może udowodnić, że nie ma zauważalnego efektu ubocznego. Sądzę, że jest to dość skomplikowane w przypadku tak fundamentalnej rzeczy, jak układ obiektu. Być może dlatego ta optymalizacja jest podejmowana tylko wtedy, gdy użytkownik dostarczy informację, że nie ma powodu, aby mieć rozłączne obiekty poprzez dodanie [no_unique_address]atrybutu.

tl; dr: Wypełnienie może być częścią obiektu, a członkowie muszą być rozłączni.

¹ Nie mogłem się oprzeć dodaniu odnośnika, który może zajmować: Webster's Revised Unabridged Dictionary, G. i C. Merriam, 1913 (wyróżnienie moje)

2. Aby zachować lub wypełnić wymiary; zająć pokój lub przestrzeń; zakryć lub wypełnić; ponieważ obóz zajmuje pięć akrów ziemi. Sir J. Herschel.

Jakie standardowe indeksowanie byłoby kompletne bez indeksowania w słowniku?