[Forger 17]

Just now, Arlleex said:

Например, для того, чтобы ясно представлять, что перед нами глобальная переменная, которая (возможно) вовсе extern из другого модуля. Кидается в глаза, сразу видна в строках, где применяется.

так зачем это нужно - выделять их из общей массы?

просто давно не пользовался глобальными обеъектами и как-то подзабыл )

[Arlleex 131]

22 минуты назад, AHTOXA сказал:

Вот, кстати, идеальное место для применения RAII. Создаётся тип CriticalSection, в конструкторе вызываются cpu_alloc_critical_section_context(csc) и cpu_entry_critical_section(csc), а в деструкторе - cpu_leave_critical_section(csc).

Видел такие трюки🙂 Но у меня есть еще куча .c-исходников, в которых эти дефайны используются. Оставил для совместимости пока что.

И кстати: в показанном фрагменте да - было бы удобно. А если внутри функции нужно защитить критической секцией всего лишь небольшой фрагмент? А потом - еще небольшой фрагмент (в этой же функции)?

Составным блоком {} отделять?

3 минуты назад, Forger сказал:

так зачем это нужно - выделять их из общей массы?

просто давно не пользовался глобальными обеъектами и как-то подзабыл )

Выработался некий приобретенный навык быстро ориентироваться в коде, полагаясь на подсказки: я не всегда могу работать за своим компом - редко, но, бывает, на объекте отладка (и доработка проекта) прямо в IDE-шке, в которой редактор, как правило, так себе.

[AHTOXA 14]

4 минуты назад, Arlleex сказал:

А если внутри функции нужно защитить критической секцией всего лишь небольшой фрагмент? А потом - еще небольшой фрагмент (в этой же функции)?

Составным блоком {} отделять?

Ну да, блоком. Или вынести этот кусок в inline-функцию.

[Forger 17]

4 minutes ago, Arlleex said:

Выработался некий приобретенный рефлекс

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

[Arlleex 131]

Только что, Forger сказал:

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

В общем-то да. Сразу видно, что функция меняет окружение - объекты "вне себя". За это цепляется внимание.

[Forger 17]

6 minutes ago, Arlleex said:

За это цепляется внимание.

тогда может быть стоит всякие глобальные объекты запихнуть в некие временные глобальные классы, дав им нужный функционал для отслеживания конкуррентного доступа (мьютекс, критическая секция .. )?

насколько помню, я пошел именно таким путем, и в последствии такие классы стали синглтонами, а как известно синглтон - это известный костыль, который своим существованием говорит, что он временный и не стоит на него сильно опираться ))

[juvf 10]

 

 

В 12.03.2024 в 01:14, one_eight_seven сказал:

нет никакой разницы, что перед глазами - класс, юнион, енум

плюсую. int temp = FROST; нет ни какой разницы FROST - это дефайн или енум. 

В 12.03.2024 в 01:44, Arlleex сказал:

#define my_macro_func(a, b) ((a) + (b)) // макрос-функция

нет ни какой разницы, с точки зрения конечного пользователя этой функции - она макрос, инлайн или обычная функция. Автор my_macro_func() принимает решение, как максимально эффективно её определить и решает сделать её макросом или функцией. Пользователя это не должно волновать. (более того, она вообще может быть и на асме определена, а может быть и из библиотеки взята, исходного кода которой у вас нет.) Тем более автор этой функции, может в любой момент переоформить её из макроса, в обычную функцию. Тогда Вам придется my_macro_func() переименовывать в my_func() - а это смена API. У пользователей посыпется сборка. 

В 12.03.2024 в 07:43, EdgeAligned сказал:

общепринятые правила именования - например, имена функций и методов - с ЗаглавнойБуквы

мне казалось, что общепринятые правила, это имена функций и методов - с маленькойБуквы. см printf(), strlen(), open(), .... 

 

мне мешают нотации/префиксы/постфиксный.  Я делаю все имена переменных/функцый - с маленькой, все имена типов/классов с большой. Наверно из Qt и FreeRTOS подчерпнул. Разделение слов - кэмл, без '_'.

[Arlleex 131]

18 минут назад, juvf сказал:

Тогда Вам придется my_macro_func() переименовывать в my_func() - а это смена API.

macro - это не признак макроса, это просто в качестве примера так было)) my_func() - тоже макрос, а вот myFunc() - уже функция.

Но тем не менее, да, при редактировании и взаимопревращениях одного в другое вполне может быть затронут большой объем исходников.

[EdgeAligned 53]

1 час назад, Arlleex сказал:

Кидается в глаза, сразу видна в строках, где применяется.о

Ну дак я ж говорю - подсветка синтаксиса, разные стили текста. Например так: (картинка размытая из-за пережатия форумом)

Цветовые схемы и стили могут быть выбраны любыми и настроены по вкусу

[Arlleex 131]

 эх, ладно. Всем спасибо.

[EdgeAligned 53]

6 часов назад, juvf сказал:

int temp = FROST; нет ни какой разницы FROST - это дефайн или енум. 

А теперь напишите enum class En {FROST } и попробуйте тоже самое -  int temp = FROST; 🙂

[one_eight_seven 3]

57 minutes ago, EdgeAligned said:

А теперь напишите enum class En {FROST } и попробуйте тоже самое -  int temp = FROST; 🙂

И в чём проблема? компилятор это найдёт и сообщит, программист поправит. И дальше в коде будет всё ещё понятнее.
Мы же не станем всерьёз обсуждать ситуацию, где надо читать и поддерживать код, который не то, что не работает - даже не компилируется!

Изменено 12 марта пользователем one_eight_seven

[EdgeAligned 53]

 

А вы не поняли, в чем проблема? 🙂 Окей, теперь напишите 

enum A {
  EN0, EN1
  };

enum B {
  EN0, EN1
  };

, затем потом напишите 

enum class A {
  EN0, EN1
  };

enum class B {
  EN0, EN1
  };

и сравните эти два варианта 🙂 В каком какие проблемы есть, что как работает или не работает?

 

 

20 часов назад, AHTOXA сказал:

вот рекомендации по кодированию одного из моих старых проектов.

Вообще-то, это называется "форматирование", и есть несколько авторских предустановок:

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

В принципе, это всё - вкусовщина. Поскольку ЕСКД на оформление нет, то положение скобочек и пробелов каждый определяет по своим вкусам. Главное, чтобы сам понимал и самому нравилось. Если же работаете в команде, то принимаете правила команды. Так что тут всё просто.

Цитата

for (auto a = 0; a < b; ++b)

Хех, надеюсь, это просто очепятка? 🙂 
PS. В этом случае auto не имеет различий от int. Примечательно, что часто встречаю запихивание auto где попало, без осмысления. По уму, auto применяется для автоматического выведения типа, где этот тип не может быть написан руками или руками его слишком длинно писать. То есть, когда тип является очень навороченным классом со всякой шаблонной лабудой, а не одним из базовых типов. В частности, в цикле for написать auto можно для итераторов из библиотеки STL, но не для базового типа int. 

Изменено 13 марта пользователем EdgeAligned

[Arlleex 131]

Вот почитал я сегодняшние посты по теме именований, и пришел к мысли, что вообще все лексические и языковые конструкции можно писать с маленькой буквы, потому что один фиг никакие явно или неявно созданные правила именований "ничего не гарантируют". Т.е. в оторванности от контекста любой идентификатор ничего не означает. Совершенно. Ну, разве что если его обозвать так, что он будет однозначно что-то говорить (префиксы этому помогали).

И в чем тогда смысл писать классы/пространства имен/типы с большой буквы?

[Forger 17]

6 minutes ago, Arlleex said:

И в чем тогда смысл писать классы/пространства имен/типы с большой буквы?

Чтобы отделить тип от объекта. Это принципиально разные вещи, т.к. одно никогда не сможет стать другим.

Например, если тип называется с большой буквы, то точно также может называться его объект:

TimeMs timeMs = 0;

Если смешивать, то такие записи будут невозможны.