[Forger 17]

Можно сделать его на пару миилиардов элементов, а при использовании поле его займет 4 байта. С const struct несколько не то. Надо ещё подумать

С const struct все то же самое - вы явно создается один экземпляр, а чтобы сделать второй, то нужно дать этой структуре другое имя, но если не будете ее использовать, то любой современный компилятор вырежет ее из финальной прошивки за ненадобностью.

Однако, если уж так сильно волнуетесь за буквально байты экономии FLASH памяти, то просто не засовывайте в const struct содержимое всей "война и мир", а оставляйте только то, что нужно в данном проекте.

Чтобы уйти от соблазна "случайно" создать второй экземпляр этой структуры, то скрывайте ее область видимости по максимуму и забудьте уже про этот typedef ))

 

Как вариант, объявить эту структуру const и тут же проинициализировать (как я привел в примере выше) прямо внутри одной функции, которая уже разбирая ее, будет вызывать другие функции, которые ничего не будут знать о вашей чудо-структуре.

 

[Nixon 3]

Может ещё кому полезно будет:

В анонимных структурах и union'ах для исключения лишнего уровня вложенности можно не писать название переменной структуры.

Например как в примере с union выше достаточно написать

struct DeviceInfo;

и поля данной структуры будут на уровне самой структуры. Если конечно нет коллизий с другими переменными.

Очень помогает в экономии ресурса клавиатуры :)

[Forger 17]

Например как в примере с union выше достаточно написать

struct DeviceInfo;

и поля данной структуры будут на уровне самой структуры. Если конечно нет коллизий с другими переменными.

В данном случае смысл как раз в том, чтобы deviceInfo нужно было явно указывать в коде, давая понять, с чем именно работаем.

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

Подобные "промашки" (сужу по своему опыту) всегда сопровождается одними из самых скверных багов :smile3046:

 

А сам факт анонимности union действительно очень полезен, особенно, если union внутри своего уровня всего один. Код становится короче и не нужно думать, как ее назвать B)

[Nixon 3]

Я без привязки к вашему примеру. Просто довольно полезная фишка. Особенно если есть множество структур в которые входит одинаковый блок (чисто протокольные штучки типа заголовка и т.д. ) . Многократно копировать этот блок глупо. Вводить лишний уровень вложенности тоже. Помогает подобное анонимное объявление. Заменяет собой лишний #define можно сказать.

[Forger 17]

Просто довольно полезная фишка. Особенно если есть множество структур в которые входит одинаковый блок (чисто протокольные штучки типа заголовка и т.д. ) . Многократно копировать этот блок глупо. Вводить лишний уровень вложенности тоже. Помогает подобное анонимное объявление. Заменяет собой лишний #define можно сказать.

Согласен :)

 

Особенно если есть множество структур в которые входит одинаковый блок

Я это сделал несколько иначе (см. тот пример) - одинаковый блок вынес наружу (command), а все остальное разместил внутри анонимного union.

[Сергей Борщ 119]

Выше выяснили, что так вот просто через enum компиляторонезависимо не выйдет.

Я устал в который раз повторять: enum class eMyenum : char { t1, y2, t3}. В Стандарте с 11-го года. Можете не верить. Пробуйте черех union.

 

[DASM 0]

Я устал в который раз повторять: enum class eMyenum : char { t1, y2, t3}. В Стандарте с 11-го года. Можете не верить. Пробуйте черех union.

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

[DASM 0]

Вот нашел ответ, как удобно пользовать enum class.

 

В общем хорошее обсуждение https://stackoverflow.com/questions/8498300...th-enum-classes

Все это краткостью записи не отличается, но иначе никак

 

вроде все идеи, от макросов до boost и создания своего класса, и типизирование шаблона array по этому enem class

 

[Nixon 3]

Я устал в который раз повторять: enum class eMyenum : char { t1, y2, t3}. В Стандарте с 11-го года. Можете не верить. Пробуйте черех union.

Не обязательно enum class : type. Достаточно enum : type.

[DASM 0]

Не обязательно enum class : type. Достаточно enum : type.

О, кстати такой вариант

enum  meE : char {
        E1,
        E2,
        EMAX
};

int main()
{    
    meE e = E1;
}

Избавляет от необходимости писать meE e =meE::E1;

Правда при этом тип такого enum имеет неявное преобразование в int

но зато полностью решает мою проблему underlyng типа в VS как int и не приводит к необходимости модификации кода. Самый четкий и полезный ответ, собственно это на данный момент и было надо

[Nixon 3]

О, кстати такой вариант

enum  meE : char {
        E1,
        E2,
        EMAX
};

int main()
{    
    meE e = E1;
}

Избавляет от необходимости писать meE e =meE::E1;

Именно. Называется integral type unscoped enum.

 

Но в программе с большим количеством enum'ов лучше все же enum class или enum в классе (второй менее жесткий по приведению типов, но такой же структуированный).

[Kabdim 0]

По факту тип указанный в энуме, года 3 назад работал как надо не везде. У меня выходило что жизнеспособный вариант для портируемого кода без сериализации - форсировать размеру энума в 32 бита "k..Max = UINT32_MAX". Это похоже все понимают единообразно. По крайней мере из того что я пробовал на тех версиях компиляторов, который были года 3 назад, на тех опциях оптимизации которые мне были интересны. Проблемы были с gcc.

[DASM 0]

Да, лучше. Но пока не знал об этом - много писанины сделать, оную править теперь с шаблонами, итераторами просто нет времени. На следующий проект конечно буду знать и учту. Спасибо.

 

По факту тип указанный в энуме - филькина грамота ни к чему его не обвязывающая. Единственный жизнеспособный вариант для портируемого кода без сериализации - форсировать размеру энума в 32 бита "k..Max = UINT32_MAX". Это похоже все понимают единообразно. По крайней мере из того что я пробовал на тех версиях компиляторов, который были года 3 назад.

вот в варианте Никсона непохоже это на филькину грамоту совсем, работает именно как надо. Уверен можно найти в стандарте описание этого

"3) Opaque enum declaration for an unscoped enumeration must specify the underlying type." это конечно не текст стандарта, но ресурс вполне заслуживающий доверия

https://en.cppreference.com/w/cpp/language/enum

[Nixon 3]

В стандарте то стандарте, но не совсем "С", точнее совсем не "С". C++11 это.

[Kabdim 0]

"3) Opaque enum declaration for an unscoped enumeration must specify the underlying type."

Почему они так написали - понятно, пишут так что бы их поняли без буквоедства, но кмк тут они переборщили с обобщением. В стандарте следующее:

For an enumeration whose underlying type is fixed, the values of the enumeration are the values of the

underlying type.

...

Two enumeration types are layout-compatible if they have the same underlying type.

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

 

Впрочем я на эту тему не хочу спорить. Даже если последний абзац - ошибочная интерпретация, есть различие между стандартом и реализациями в компиляторах. Повторюсь, когда я тестировал, сделать на наборе интересующие платформы <-> интересующие компиляторы типизируемые энумы работающим одинаково не получилось.

 

Я этим занимался от байтоедства, толстый бутлоадер нужно было утрамбовать в размеры которые для него отведены и при этом сохранить общую кодовую базу с утилитами на компе. В целом даже примитивная сериализцаия лучше, чем прямые преобразования типов в байтовый поток и обратно.

 

УПД Поправил цитату стандарта, скопировалось неправильно.