Комментарии: 13

1. Boris

   • 09.12 2019 04:50:53

   Любые non-local без должного оборачивания это прям bad-guy way

   • Anton

     • 09.12 2019 04:51:36

     Где про это читать? Хочу мануал как правильно и почему так не правильно)

     • Boris

       • 09.12 2019 04:54:22

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

     • Anton

       • 09.12 2019 06:42:53

       1) Битовые поля - да их лучше не использовать т.к. их расположение в памяти сильно зависит от компилятора и иногда даже его версии. Например может возникнуть ситуация, когда такая структура передается по какому - то каналу связи на другую машину и там она будет интерпретирована неправильно. Также есть ряд случаев приводящих неопределенному поведению, например взятие указателя на битовое поле. 2) Глобальные переменные - зло, т.к. нарушают главный принцип разработки ПО - инкапсуляцию. Правильное ПО должно максимально состоять из самостоятельных компонентов, которые должны быть связаны между собой минимально насколько это возможно. Глобальные же переменные особенно те, которые расшариваются на всю программу в целом, могут быть изменены в любом месте этой программы и тем самым приводить к трудноотлаживаемым ошибкам. А так же сильно запутывают логику программы и тем самым усложняют её понимание.

       • Anton

         • 09.12 2019 06:46:42

         спасибо

       • Artem

         • 09.12 2019 06:53:16

         Спасибо, полезно, теперь ясно, как делать не надо:)

       • Igor

         • 09.12 2019 06:58:07

         Спорное утверждение про битовые поля. Особенно если учесть, что как правило для одного проекта используют один компилятор. По крайней мере читабельность, на мой взгляд, упрощается.

         • Anton

           • 09.12 2019 06:59:51

           Читабельность упрощается, но представьте себе ситуацию, вы начали записывать такие структуры на флешку, прошло время изделия уже в серии и вам потребовалось обновить прошивку, компилятор так же обновился и структуры стали не совместимы.

       • Dmitry

         • 09.12 2019 07:05:38

         А можно по подробнее, что именно там зависит от компилятора? В стандартах 98-х и 11-х плюсов про "зависит от компилятора" я ничего не увидел.

         • Anton

           • 09.12 2019 07:07:17

           Это скорее связано с реализацией выравнивания структур в памяти. Разные компиляторы и их версии могут делать это по разному.

           • Dmitry

             • 09.12 2019 07:11:32

             ну так выравнивание имеет отношение ко всем структурам, независимо от битовых полей. Имхо attribute ((packed)) - must have для всех протокольных вещей. В таком комплекте(packed и битовые поля) никаких неожиданностей не будет. Единственный минус битовых полей связан с работой со многими потоками - но это отдельная история(на хабре была статья - если надо - найду)

             • Anton

               • 09.12 2019 07:12:24

               https://en.cppreference.com/w/cpp/language/bit_field Multiple adjacent bit fields are usually packed together (although this behavior is implementation-defined) Ключевое слово - implementation-defined

               • Igor

                 • 09.12 2019 07:16:33

                 typedef struct { uint64_t engineTemp: 8; uint64_t engineRPM: 8; uint64_t unused2: 8; uint64_t unused3: 8; uint64_t unused4: 8; uint64_t unused5: 8; uint64_t unused6: 8; uint64_t unused7: 8; } map_0x380_t; В зависимости от пришедшего пакета я просто обращаюсь к значению через union Мне показалось это довольно удобным.