Доступ к полям структуры. Опции

[Oleg_IT]

Переношу код из AVR Studio (WINAVR) в Keil.
Компилятор выдаёт предупреждение на объявление, на стоку с "};"

Код

………
        struct {
            unsigned char Bit1        : 1;
            unsigned char Bit2        : 1;
        };
………….

..\Test.h(37): warning: #40-D: expected an identifier
И потом выдаёт ошибку на использование этих полей. Лечится это заданием имени структуры, например "} A1;", что не удобно, для меня. В WINAVR, в MinGW, в Visual Studio такого нет, только в Keil. Может быть это стандарт С++, не проверял и всех тонкостей языка не знаю. Можно какими-нибудь флажками убрать эту особенность?

[KnightIgor]

Компилятор выдаёт предупреждение на объявление, на стоку с "};"

Код

………
        struct {
            unsigned char Bit1        : 1;
            unsigned char Bit2        : 1;
        };
………….

..\Test.h(37): warning: #40-D: expected an identifier

Код

………
        struct mystruct_s {
            unsigned char Bit1        : 1;
            unsigned char Bit2        : 1;
        };

...
struct mystruct_s variable_a, variable_b;
...

variable_a.Bit1 = variable_b.Bit2;

………….

[Oleg_IT]

Приведите весь код, а то не понятно это внутри структуры, юниона или просто чистое объявление.

Это заголовок IP

Код

typedef struct IP_Head_v4_tag {
        struct {
            unsigned char IHL        : 4;   // IHL - 5
            unsigned char Version    : 4;   // Version - 4
        };

       struct {
            unsigned char Prec       : 3;   // Precedence - 3
            unsigned char D          : 1;   // Delay Normal - 0
            unsigned char T          : 1;   // Throughput Normal - 0
            unsigned char R          : 1;   // Relibility Normal - 0
            unsigned char Res1       : 2;   // Reserved - 00
        };

    unsigned short TotalLen;                // Total Length
    unsigned short Identif;                 // Идентификатор - 0

        struct {
            unsigned short FragOffset: 13;  // Fragment Offset - 0
            unsigned char MF         : 1;   // Fragment - 0 = Last Fragment
            unsigned char DF         : 1;   // Fragment - 1 = Don't Fragment
            unsigned char Res2       : 1;   // Reserved - 0
        };
        struct {
            unsigned char TTL        : 8;   // Time to Live < 1
            unsigned char Prot       : 8;   // Protocol
        };
    unsigned short Checksum;            // Header Checksum
    IPADDRESS IP_SRC_Adr;               // Source Address
    IPADDRESS IP_DST_Adr;               // Destination Address
} IP_Head_v4;

Со всеми перечисленными компиляторами (WINAVR, MinGW, Visual Studio) анонимные битовые поля структур работают правильно.

Для анонимных структур существует #pragma anon_unions.

Спасибо, проверю, а вдруг поможет.

Что-то я не понимаю, как эту структуру безымянную использовать.

Например так

Код

IP_Head_v4 IP_H;
IP_H.IHL = 5;

[pitt]

Просто хочу, как бывший советский гражданин, дать несколько советов.
Когда имеете дело со структурами, особенно отображающими пакеты данных, не забывайте endianness(простите не знаю как по-русски). Кроме того, советую включать файл stdint.h и использовать типы int8_t, uint16_t и тому подобное- это существенно облегчает как понимание, так и переносимость кода.

[MrYuran]

Просто хочу, как бывший советский гражданин, дать несколько советов.
Когда имеете дело со структурами, особенно отображающими пакеты данных, не забывайте endianness(простите не знаю как по-русски). Кроме того, советую включать файл stdint.h и использовать типы int8_t, uint16_t и тому подобное- это существенно облегчает как понимание, так и переносимость кода.

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

[pitt]

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

А вот это напрасно. Если кто-то упаковывается данные, то, скорее всего, кто-то будет распаковывать. Такие вещи хорошо включать в заголовочный файл, который используется с обеих сторон.
Выравнивание часто действительно может стать проблемой, но это другая тема. Особенно важно структурированность пакетов передачи и, по умолчанию, выравнивание побайтное. Подавляющее большинство компиляторов позволяют выравнивать так как надо заказчику. Методы могут быть различными.

[jcxz]

А вот это напрасно. Если кто-то упаковывается данные, то, скорее всего, кто-то будет распаковывать. Такие вещи хорошо включать в заголовочный файл, который используется с обеих сторон.
Выравнивание часто действительно может стать проблемой, но это другая тема. Особенно важно структурированность пакетов передачи и, по умолчанию, выравнивание побайтное. Подавляющее большинство компиляторов позволяют выравнивать так как надо заказчику. Методы могут быть различными.

Можно и методы сделать одинаковыми для C++. Я делаю так:

CODE

struct u16p8 {
u8 bytes[2];
operator u16() const { return u16load(&bytes); }
u16p8 & operator =(u32 val) { u16save(&bytes, val); return *this; }
};
struct u32p8 {
u8 bytes[4];
operator u32() const { return u32load(&bytes); }
u32p8 & operator =(u32 val) { u32save(&bytes, val); return *this; }
};

где: u16load(), u16save(), u32load(), u32save() - макросы, определённые по-разному в соответствии с платформой.
Если для Cortex-M3 и x86 к примеру u16load() будет:
#define u16load(p) (*(u16 *)p)
то для ARM7/9:
#define u16load(p) (*(u8 *)(p) | (u16)((u8 *)(p))[1] << 8)
Таким образом я совершенно свободно перетаскиваю структуры, описывающие пакованные структуры, между разными платформами.
Это очень полезно когда пишешь firmware и тут же пишешь клиентское ПО на PC (для этого устройства) и надо описать протокол взаимодействия - это можно делать в одном файле просто копируя его между двумя проектами.