[Arlleex 131]

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

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

TimeMs timeMs = 0;

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

Почему невозможны - вполне возможны🙂 В том то и прикол - что очень даже возможны и компилятор этому не препятствует.

struct TimeMs {
  int counter;
};

TimeMs TimeMs {10}; // -> запросто

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

Возможно, разница именований действительно имеет смысл.

Тогда почему библиотекари стандарта пишут все с маленькой буквы? Всякие std:: и т.д. - все это с маленькой буквы. Им, получается, можно?🙂

[EdgeAligned 53]

А в стандартных библиотеках, как Си, так и С++, вообще все только маленькими буквами. Возможно, просто для визуального отделения стандартных либ от пользовательских. А вот если взять FreeRTOS или даже Cube HAL, там будут уже иное оформление.

[Forger 17]

1 hour ago, Arlleex said:

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

старинные средневековые традиции, скрепы ))

[EdgeAligned 53]

Блин, не туда кнопочку нажал 🙂 ....

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

[selax 18]

Вообще обсуждаемое нпзывается codestyle, т.е. правила оформления кода. Они не обязательны, но в любом серьёзном проекте они есть. Либо свои, либо чужие. Оно нужно чтобы код был красивым, читаемым и самодокументируемым. Ну и одинаково выглядящим во всём проекте, само собой.

Я, например, во всех проектах стараюсь использовать Google Codestyle:

https://google.github.io/styleguide/cppguide.html

[juvf 10]

В 12.03.2024 в 21:16, EdgeAligned сказал:

А вы не поняли

что-то я действительно не понял. но я понял то, что Вы это сами не писали 😉 

В 12.03.2024 в 21:16, EdgeAligned сказал:

Окей, теперь напишите 

enum A {
  EN0, EN1
  };

enum B {
  EN0, EN1 //строка номер 36
  };

 

Написал. Компилятор выдал ошибку

Error[Pe101]: "EN0" has already been declared in the current scope (�Hat line 32�h)    myFile.cpp    36
Error[Pe101]: "EN1" has already been declared in the current scope (�Hat line 32�h)    myFile.cpp    36

    

В 12.03.2024 в 21:16, EdgeAligned сказал:

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

enum class A {
  EN0, EN1
  };

написал. И что? Что с этим дальше делать? Вы предлагаете int инициализировать типом A. А зачем? 

 

Теперь то, о чем я говорил. Допустим есть некий порог температуры.

Автор программы библиотеки задает эту константу так:

#define FROST 10

либо так

enum {FORST = 10};

Сделал, отдал в продакшин. 

Теперь прикладной программист пишет свой код с использованием вашей библиотеки

int temperature = FORST; //вот тут какая разница как в FORST попала 10? Тут прогер должен понимать, что создалась переменная типа int, и она инициализировалась значением 10. Это Эквивалент записи int temperature = 10;

 

ps даже если очень жжет использовать enum class, очень хочется, но не хотите при каждом использовании кастовать, то закастуйте дефайном

enum class A {
  EN0 = 10, EN1 = 20
  };

#define FORST (static_cast<int>(A::EN0))	//так
const int FORST2 = static_cast<int>(A::EN1);	//ну или даже так

int temp = FORST2 - FORST; //вот тут какая разница, как 10 и 20 попали/заменились на FORST и FORST2? эквивалент int temp = 10; Тут нужно понимать что в temp ляжет 10, которая вычислилась на этапе компиляции

 

pps 

В 12.03.2024 в 10:53, Arlleex сказал:

Макрос можно применять в разворачивании другого макроса. Enum так работать не будет🙂

#define asd(m)	(do(0){return 5*m;})
#define EN1    true
#define TEMP2   asd(5)
const int pi1 = 3;
enum { ANGLE1 = pi1*10 + (EN1 ? TEMP2: 13)};
enum class A{ASD = ANGLE1, ASD2 = ANGLE1 + 6};
enum {QWE0 = static_cast<int>(A::ASD2), QWE1, QWE2};
#define POIU (QWE2 - 31)

int angleOfHor = POIU; //в конечном счете это тоже самое, что и int angleOfHor = 32;

Разворачивай хоть что, хоть в чем.

 

[Arlleex 131]

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

Разворачивай хоть что, хоть в чем.

Я про конкатенацию ## и получение на основе одних макросов - других. Это работает как текстовая замена с определенными правилами разворачивания макросов. И ничего другое, в том числе, enum-ы, туда не применимо.

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

Коллеги. Я лишь хочу отметить, что вот каждый из вас хоть и считает "правильно вот так, а вот так - хуже или вовсе плохо", а тем не менее - у всех свое. Да, в чем-то есть одинаковости, но по сути - каждый пишет как ему удобнее, с выработанным стилем. Вот привели примеры гугловских или своих кодстайлов - ну а какой от них толк, если весь остальной мир (включая писателей стандартных библиотек) - пишет по-другому?

Ведь один фиг мы пишем проекты не на 100% состоящие из только наших исходников. Много заимствований - и во всех свои стили. И получается чистый зоопарк - тут кэмлкейс, там - функции с большой буквы через _, здесь - префиксы у переменных, а у четвертых постфиксы у типов. КОШМАР.

[EdgeAligned 53]

jufv, вы малость не поняли о чем я говорил. А, ладно, фик с ним, с мобильника объяснять неудобно. Я говорил о том, что enum class  это уже не просто enum, а строго типизированный класс перечисления. И о том, что простой enum имеет свои проблемы, о которых выше писал. Если вы не поняли этого, то ладно, нет смысла объяснять , проехали

[one_eight_seven 3]

20 minutes ago, EdgeAligned said:

jufv, вы малость не поняли о чем я говорил. А, ладно, фик с ним, с мобильника объяснять неудобно. Я говорил о том, что enum class  это уже не просто enum, а строго типизированный класс перечисления. И о том, что простой enum имеет свои проблемы, о которых выше писал. Если вы не поняли этого, то ладно, нет смысла объяснять , проехали

Это вы не поняли,  что буковка e перед eEN1 или eEN2 - вообще  ничего не  поменяет.

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

test.cpp: In function ‘int main()’:
test.cpp:12:13: error: ‘EN0’ was not declared in this scope
   12 |     int i = EN0;
      |             ^~~
test.cpp:12:13: note: suggested alternatives:
test.cpp:8:5: note:   ‘B::EN0’
    8 |     EN0, EN1
      |     ^~~
test.cpp:4:5: note:   ‘A::EN0’
    4 |     EN0, EN1
      |     ^~~
avi@mob:~/test$ 

Ещё  раз призываю эволюционировать, сначала самому  попробовать что-то сделать,  а не постить влажные фантазии с апломбом гуру.

[juvf 10]

В 13.03.2024 в 10:39, EdgeAligned сказал:

что простой enum имеет свои проблемы

Это Вы немного не поняли о чем я говорил. И причем тут проблемы енума и понимание того, каким методом была задана константа?

[one_eight_seven 3]

11 hours ago, Arlleex said:

Тогда почему библиотекари стандарта пишут все с маленькой буквы? Всякие std:: и т.д. - все это с маленькой буквы. Им, получается, можно?🙂

Да всем можно. Код так более читаем для большинства людей. Плюс не надо думать и запоминать правила - всегда  пишешь одинаково, и думаешь о том, как правильнее  назвать. Если занимаешься интересными вещами, то  заниматься подсчётом строк, вспоминать как  по разному оформлять одинаковые по своей сути сущности - отвлекает. Поэтому, в библиотеках, да и во многих программах просто пользуются минимальным набором правил. по оформлению. Типа  всё константное  - ALL_CAPS_SNAKE (и-то не обязательно), всё  остальное - lower_case_snake, или вообще  всё -  lower_case_snake

Код может  быть написан читаемым и в lower_case и в CamelCase, в стиле кодирования важнее другие вещи - правильное именование, объединение того, что должно быть объединено, и разделение разных сущностей по естественным границам, малые методы, делающие одно действие, понятно и явно написанные; комментарии,  описывающие намерение или предупреждающие о чём-либо, а не  реализацию (будто реализацию из кода не  видно)

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

[AHTOXA 14]

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

Я лишь хочу отметить, что вот каждый из вас хоть и считает "правильно вот так, а вот так - хуже или вовсе плохо", а тем не менее - у всех свое.

Это стили кодирования пишут для групп программистов. Когда в одном проекте несколько человек. Когда пишешь один - вообще пофиг как именуешь и форматируешь. Главное чтоб тебе самому было понятно.

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

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

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

Из этого тоже можно извлечь пользу: сразу видно, что идёт вызов библиотечного кода 🙂

[EdgeAligned 53]

Так, чето вы не в ту степь ушли. Я вообще-то говорил про различие между enum и enum class и про то, что во втором случае enum class - это строго типизированная штука. А не про то, чего там увидит программист или компилятор.

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

[juvf 10]

В 13.03.2024 в 13:30, EdgeAligned сказал:

Так, чето вы не в ту степь ушли. Я вообще-то говорил про различие между enum и enum class

это Вы не в ту степь ушли.   

Цитата

Цитата

В 12.03.2024 в 13:05, juvf сказал:

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

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

я сказал "int temp = FROST; нет ни какой разницы FROST - это дефайн или енум.". При чем тут различия между enum и enum class?

В 13.03.2024 в 13:30, EdgeAligned сказал:

поймите, о чем речь идет

Речь шла о том, что имя "FROST" писать как eFROST или как FROST? Разницы нет. 

[EdgeAligned 53]

А причем тут FROST и eFROST? Ааа, понял, вы просто не знаете, что такое строгая типизация. Ну ладно, принято. Все, проехали эту тему, больше не возвращаемся, если для вас это сложно. Всё-Всё, больше не затрагиваю тему типов.