Czy powinienem martwić się o wyrównanie podczas rzucania wskaźnikami?

To nie jest w porządku, naprawdę. Wyrównanie może być błędne, a kod może naruszać ścisłe aliasing. Należy rozpakować go wyraźnie.

i1 = data[0] | data[1] << 8 | data[2] << 16 | data[3] << 24;

Itd. Jest to zdecydowanie dobrze zdefiniowane zachowanie, a jako bonus, jest również niezależne od endianess, w przeciwieństwie do obsady wskaźników.

W przykładzie, który tutaj pokazujesz, to co robisz będzie bezpieczne dla prawie wszystkich nowoczesnych procesorów iff początkowy wskaźnik znaków jest poprawnie wyrównany. Ogólnie rzecz biorąc, nie jest to bezpieczne i nie gwarantuje działania.

Jeśli początkowy wskaźnik znaku nie jest prawidłowo wyrównany, będzie to działać na x86 i x86_64, ale może nie działać na innych architekturach. Jeśli masz szczęście, to po prostu da ci awarię i naprawisz swój kod. Jeśli masz pecha, niepodpisany dostęp zostanie naprawiony przez obsługę pułapki w Twoim system operacyjny i będziesz miał fatalną wydajność bez żadnych oczywistych informacji zwrotnych, dlaczego jest tak wolny (mówimy o powolnym dla jakiegoś kodu, to był ogromny problem na Alfie 20 lat temu).

Nawet na x86 & co, niepodpisany dostęp będzie wolniejszy.

Jeśli chcesz być bezpieczny dzisiaj i w przyszłości, po prostu memcpy zamiast wykonywać takie zadanie. Nowoczesny kompilator prawdopodobnie będzie miał optymalizacje dla memcpy i zrobi dobrze, a jeśli nie, memcpy sam będzie miał wykrywanie wyrównania i zrobi najszybszą rzecz.

Również Twój przykład jest błędny w jednym punkcie: sizeof (int) nie zawsze wynosi 4.

Poprawnym sposobem rozpakowania char buforowanych danych jest użycie memcpy:

unsigned char data[4 * sizeof(int)];
int i1, i2, i3, i4;
memcpy(&i1, data, sizeof(int));
memcpy(&i2, data + sizeof(int), sizeof(int));
memcpy(&i3, data + 2 * sizeof(int), sizeof(int));
memcpy(&i4, data + 3 * sizeof(int), sizeof(int));

Rzutowanie narusza aliasing, co oznacza, że kompilator i optymalizator mogą swobodnie traktować obiekt źródłowy jako niezainicjalizowany.

Odnośnie Twoich 3 pytań:

1. nie, dereferowanie wskaźnika rzutu jest ogólnie niebezpieczne, ze względu na aliasing i wyrównanie.
2. Nie, w C++ casting W Stylu C jest zdefiniowany w kategoriach reinterpret_cast.
3. Nie, C i C++ zgadzają się na aliasing oparty na cast. Jest różnica w traktowaniu aliasingu opartego na Unii (C dopuszcza to w niektórych przypadkach; C++ nie).

Update: Przeoczyłem fakt, że rzeczywiście mniejsze typy mogą być nienaruszone w stosunku do większych, jak to może być w twoim przykładzie. Możesz usunąć ten problem, odwracając sposób, w jaki oddajesz tablicę : zadeklaruj tablicę jako tablicę int i prześlij ją do char *, Gdy chcesz uzyskać do niej dostęp w ten sposób.

// raw data consists of 4 ints
int data[4];

// here's the char * to the original data
char *cdata = (char *)data;
// now we can recast it safely to int *
i1 = *((int*)cdata);
i2 = *((int*)(cdata + sizeof(int)));
i3 = *((int*)(cdata + sizeof(int) * 2));
i4 = *((int*)(cdata + sizeof(int) * 3));

Nie będzie żadnego problemu z tablicą typów prymitywnych. Problemy z wyrównaniem występują przy radzeniu sobie z tablicami danych strukturalnych (struct w C), jeśli pierwotny typ tablicy jest większy niż typ tablicy , patrz aktualizacja powyżej.

Powinno być całkowicie ok, aby oddać tablicę znaków do tablicy int, pod warunkiem, że zastąpisz offset 4 sizeof(int), aby dopasować rozmiar int na platformie, na której ma działać kod.

// raw data consists of 4 ints
unsigned char data[4 * sizeof(int)];
int i1, i2, i3, i4;
i1 = *((int*)data);
i2 = *((int*)(data + sizeof(int)));
i3 = *((int*)(data + sizeof(int) * 2));
i4 = *((int*)(data + sizeof(int) * 3));

Zauważ, że otrzymasz endianness Problemy tylko wtedy, gdy udostępnisz te dane w jakiś sposób z jednej platformy na drugą z inną kolejnością bajtów. W przeciwnym razie powinno będzie dobrze.

Możesz pokazać mu, jak rzeczy mogą się różnić w zależności od wersji kompilatora:

• GCC 4.3.4
• GCC 4.7.2

Oprócz wyrównania istnieje drugi problem: standard pozwala na rzucenie int* na char*, ale nie na odwrót (chyba że {[1] } został pierwotnie rzucony z int*). zobacz ten post po więcej szczegółów.

To, czy musisz się martwić o wyrównanie, zależy od wyrównania obiektu, z którego pochodzi wskaźnik.

Jeśli rzucisz na typ, który ma bardziej rygorystyczne wymagania wyrównania, nie jest przenośny.

Baza tablicy char, tak jak w twoim przykładzie, nie musi mieć dokładniejszego wyrównania niż dla typu elementu char.

Jednak wskaźnik do dowolnego typu obiektu może być konwertowany na char * i Wstecz, niezależnie od wyrównania. Wskaźnik char * zachowuje mocniejsze wyrównanie oryginału.

Możesz użyć Unii, aby utworzyć tablicę znaków, która jest bardziej wyrównana:

union u {
    long dummy; /* not used */
    char a[sizeof(long)];
};

Wszyscy członkowie Związku zaczynają pod tym samym adresem: na początku nie ma wyściółki. Gdy obiekt Unii jest zdefiniowany w storage, musi mieć wyrównanie, które jest odpowiednie dla najbardziej ściśle wyrównanego elementu.

Nasze union u powyżej jest wystarczająco wyrównane dla obiektów typu long.

Ograniczenia mogą spowodować awarię programu po przeniesieniu go na niektóre architektury. Lub może działać, ale z łagodnym lub poważnym wpływem na wydajność, w zależności od tego, czy błędnie dopasowane dostępy do pamięci są zaimplementowane w sprzęcie (kosztem niektórych dodatkowych cykli) lub w oprogramowaniu (pułapki do jądra, gdzie oprogramowanie emuluje dostęp, kosztem wielu cykli).