Równoważnik rozmiaru C dla makr

Question

Więc optymalizuję niektóre kod przez rozwijanie niektórych pętli (tak, wiem, że powinienem polegać na moim kompilatorze, aby to zrobić dla mnie, ale nie pracuję z moim wyborem kompilatorów) i Chciałem zrobić to z wdziękiem, aby w przypadku zmiany rozmiaru danych z powodu pewnych zmian w przyszłości kod ulegnie eleganckiemu zniszczeniu.

Coś jak:

typedef struct { 
    uint32_t alpha; 
    uint32_t two; 
    uint32_t iii; 
} Entry; 

/*...*/ 

uint8_t * bytes = (uint8_t *) entry; 
#define PROCESS_ENTRY(i) bytes[i] ^= 1; /*...etc, etc, */ 
#if (sizeof(Entry) == 12) 
    PROCESS_ENTRY(0);PROCESS_ENTRY(1);PROCESS_ENTRY(2); 
    PROCESS_ENTRY(3);PROCESS_ENTRY(4);PROCESS_ENTRY(5); 
    PROCESS_ENTRY(6);PROCESS_ENTRY(7);PROCESS_ENTRY(8); 
    PROCESS_ENTRY(9);PROCESS_ENTRY(10);PROCESS_ENTRY(11); 
#else 
# warning Using non-optimized code 
    size_t i; 
    for (i = 0; i < sizeof(Entry); i++) 
    { 
     PROCESS_ENTRY(i); 
    } 
#endif 
#undef PROCESS_ENTRY 

ten nie działa, oczywiście, ponieważ sizeof nie jest dostępne dla pre-procesor (przynajmniej, że to, co wydawało się wskazywać this answer).

Czy istnieje łatwe obejście problemu, dzięki któremu mogę uzyskać sizeof strukturę danych do użycia z makrem C, czy też po prostu SOL?

Answer 1

Nie możesz zrób to w preprocesorze, ale nie musisz tego robić. Wystarczy wygenerować zwykły if w makra:

#define PROCESS_ENTRY(i) bytes[i] ^= 1; /*...etc, etc, */ 
if (sizeof(Entry) == 12) { 
    PROCESS_ENTRY(0);PROCESS_ENTRY(1);PROCESS_ENTRY(2); 
    PROCESS_ENTRY(3);PROCESS_ENTRY(4);PROCESS_ENTRY(5); 
    PROCESS_ENTRY(6);PROCESS_ENTRY(7);PROCESS_ENTRY(8); 
    PROCESS_ENTRY(9);PROCESS_ENTRY(10);PROCESS_ENTRY(11); 
} else { 
    size_t i; 
    for (i = 0; i < sizeof(Entry); i++) { 
     PROCESS_ENTRY(i); 
    } 
} 

sizeof jest stałym wyrażeniem, a porównując stała przed stała jest również stała. Każdy rozsądny kompilator C optymalizuje gałąź, która zawsze jest fałszywa podczas kompilacji - stałe składanie jest jedną z najbardziej podstawowych optymalizacji. Tracisz jednak #warning.

Answer 2

Jeśli używasz autoconf lub innego systemu konfiguracji kompilacji, możesz sprawdzić rozmiar struktur danych w czasie konfiguracji i napisać nagłówki (jak #define SIZEOF_Entry 12). Oczywiście jest to bardziej skomplikowane podczas kompilacji krzyżowej i takie, ale zakładam, że twoja architektura kompilacji i docelowa są takie same.

W przeciwnym razie masz pecha.

Answer 3

Jeśli chcesz mieć najmniejszy możliwy rozmiar struktury (lub dopasować ją do 4-bajtowej granicy lub cokolwiek innego), możesz użyć spakowanych lub wyrównanych atrybutów.

W Visual C++, można użyć #pragma pack, aw GCC można użyć __attribute __ ((pakowane)) i __ __attribute ((wyrównane (num-bajtów))

Answer 4

Jesteś pecha. - preprocesor nie wie nawet, czym jest struktura, nie mówiąc już o jakimkolwiek sposobie jej obliczenia.

W takim przypadku wystarczy # zdefiniować stałą wartość, aby poznać rozmiar struktury, a następnie statycznie potwierdzić, że jest on faktycznie równy rozmiarowi przy użyciu sztuczki o wielkości ujemnej.

Możesz również wypróbować po prostu if (sizeof(Entry) == 12) i zobacz, czy twój kompilator jest w stanie ocenić stan gałęzi podczas kompilacji i usunąć martwy kod. To nie jest takie wielkie pytanie.

Answer 5

To prawdopodobnie nie pomoże, ale jeśli masz możliwość, aby to zrobić w C++ można użyć szablonu powoduje kompilator do wysyłki do odpowiedniej pętli w czasie kompilacji:

template <std::size_t SizeOfEntry> 
void process_entry_loop(...) 
{ 
    // ... the nonoptimized version of the loop 
} 

template <> 
void process_entry_loop<12>(...) 
{ 
    // ... the optimized version of the loop 
} 

// ... 

process_entry_loop<sizeof(Entry)>(...); 

Answer 6

Przypominają się dwa inne podejścia - napisać małą aplikację, aby napisać rozwiniętą pętlę, lub użyć wersji Duff's device z oczekiwanym rozmiarem struktury.