Перейти к содержанию
    

Forger

Свой
  • Постов

    2 638
  • Зарегистрирован

  • Посещение

  • Победитель дней

    3

Forger стал победителем дня 1 мая 2023

Forger имел наиболее популярный контент!

Репутация

17 Хороший

2 Подписчика

Информация о Forger

  • Звание
    Гуру
    Гуру

Контакты

  • ICQ
    Array

Посетители профиля

5 810 просмотров профиля
  1. старинные средневековые традиции, скрепы ))
  2. Чтобы отделить тип от объекта. Это принципиально разные вещи, т.к. одно никогда не сможет стать другим. Например, если тип называется с большой буквы, то точно также может называться его объект: TimeMs timeMs = 0; Если смешивать, то такие записи будут невозможны.
  3. тогда может быть стоит всякие глобальные объекты запихнуть в некие временные глобальные классы, дав им нужный функционал для отслеживания конкуррентного доступа (мьютекс, критическая секция .. )? насколько помню, я пошел именно таким путем, и в последствии такие классы стали синглтонами, а как известно синглтон - это известный костыль, который своим существованием говорит, что он временный и не стоит на него сильно опираться ))
  4. видимо вы не поняли мой вопрос )) вообще, зачем вообще как-тот выделять глобальные от локальных? может показать самому себе особый риск их использования?
  5. так зачем это нужно - выделять их из общей массы? просто давно не пользовался глобальными обеъектами и как-то подзабыл )
  6. А зачем это нужно? К слову, у меня вообще нет глобальных объектов, кроме локальных с припиской static. Но и когда были, тоже не делал разницы.
  7. А в этом нет нужды - помнить, ибо любая простая переменная когда-то может стать тяжелым классом и впрочем наоборот ) Если еще и этим забивать голову, то код превратиться в некую шифровку, которая становится практически нечитаемой через месяц-полгода паузы над проектом.
  8. а для меня это оказалось весьма пагубной практикой, и в основном от этого как раза довольно жирного (для меня) минуса: Для себя понял одном самое важное в куче правил - чем их меньше и чем они проще, тем легче потом работать со своим же кодом через какое-то время. У меня есть самое главное и простое правило: все типы строго с Большой буквы, а их объекты - с маленькой. Без исключений. Никаких префиксов в типах и именах. Т.е. все как в жизни ) Впрочем, опять уходим во вкусовщину ))
  9. Если уж наделять структуры такими заумными возможностями, то, что мешает их надели уже неким "функционалом", некими действиями? 😉 Ведь структура - это по сути класс, а значит может не только хранить данные, но и выполнять разные действия с их передачей, приемом, контролем целостности. Для этого им нужно дать методы передачи своих команд. Например, "дать" во владение некий порт обмена или передать ей метод для работы с тем или иным портом или даже списком портов Таким образом рождается некая иерархия команд: есть базовые, а есть те, которые построены на их основе и дают больше возможностей. Такие команды должны уметь работать с итераторами (списками), чтобы не "перебирать" их вручную. Другой вопрос - насколько это нужно в том или ином проекте. Чем плоха самая обычная структура с безымянным union и т.п? Зачем так усложнять? Ведь должна быть цель, оправдывающая такие усложнения )
  10. стараюсь структурам не делать двойников по содержанию, но с разными именами, иначе это путает, впрочем, это скорее вкусовщина
  11. должно быть так: using sTxMsgRequest = sTxMsgCommand;
  12. неправильно записано, using используется иначе, у меня компилируется: using sTxMsgCommand = struct { uint32_t cmd, crc; }; sTxMsgCommand command;
  13. да, есть такое )) к слову я давно перешел на using, его проще читать, логично выглядит что ли ))
×
×
  • Создать...