Arlleex 183 12 марта Опубликовано 12 марта · Жалоба 10 минут назад, Forger сказал: Например, если тип называется с большой буквы, то точно также может называться его объект: TimeMs timeMs = 0; Если смешивать, то такие записи будут невозможны. Почему невозможны - вполне возможны🙂 В том то и прикол - что очень даже возможны и компилятор этому не препятствует. struct TimeMs { int counter; }; TimeMs TimeMs {10}; // -> запросто Правда, если ниже объявления объекта нужно будет обратиться к типу, то это уже проблема: надо приписывать ключевое слово struct. Возможно, разница именований действительно имеет смысл. Тогда почему библиотекари стандарта пишут все с маленькой буквы? Всякие std:: и т.д. - все это с маленькой буквы. Им, получается, можно?🙂 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
EdgeAligned 86 12 марта Опубликовано 12 марта · Жалоба А в стандартных библиотеках, как Си, так и С++, вообще все только маленькими буквами. Возможно, просто для визуального отделения стандартных либ от пользовательских. А вот если взять FreeRTOS или даже Cube HAL, там будут уже иное оформление. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 12 марта Опубликовано 12 марта · Жалоба 1 hour ago, Arlleex said: Тогда почему библиотекари стандарта пишут все с маленькой буквы? старинные средневековые традиции, скрепы )) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
EdgeAligned 86 13 марта Опубликовано 13 марта (изменено) · Жалоба Блин, не туда кнопочку нажал 🙂 .... Изменено 13 марта пользователем EdgeAligned Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
selax 20 13 марта Опубликовано 13 марта · Жалоба Вообще обсуждаемое нпзывается codestyle, т.е. правила оформления кода. Они не обязательны, но в любом серьёзном проекте они есть. Либо свои, либо чужие. Оно нужно чтобы код был красивым, читаемым и самодокументируемым. Ну и одинаково выглядящим во всём проекте, само собой. Я, например, во всех проектах стараюсь использовать Google Codestyle: https://google.github.io/styleguide/cppguide.html Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 13 марта Опубликовано 13 марта · Жалоба В 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; Разворачивай хоть что, хоть в чем. 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 183 13 марта Опубликовано 13 марта · Жалоба 14 минут назад, juvf сказал: Разворачивай хоть что, хоть в чем. Я про конкатенацию ## и получение на основе одних макросов - других. Это работает как текстовая замена с определенными правилами разворачивания макросов. И ничего другое, в том числе, enum-ы, туда не применимо. То, что Вы показали - является тривиальным примером однократной текстовой замены, все остальное делается компилятором, а не препроцессором. Но в общем к процессу именований это не относится)) Коллеги. Я лишь хочу отметить, что вот каждый из вас хоть и считает "правильно вот так, а вот так - хуже или вовсе плохо", а тем не менее - у всех свое. Да, в чем-то есть одинаковости, но по сути - каждый пишет как ему удобнее, с выработанным стилем. Вот привели примеры гугловских или своих кодстайлов - ну а какой от них толк, если весь остальной мир (включая писателей стандартных библиотек) - пишет по-другому? Ведь один фиг мы пишем проекты не на 100% состоящие из только наших исходников. Много заимствований - и во всех свои стили. И получается чистый зоопарк - тут кэмлкейс, там - функции с большой буквы через _, здесь - префиксы у переменных, а у четвертых постфиксы у типов. КОШМАР. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
EdgeAligned 86 13 марта Опубликовано 13 марта · Жалоба jufv, вы малость не поняли о чем я говорил. А, ладно, фик с ним, с мобильника объяснять неудобно. Я говорил о том, что enum class это уже не просто enum, а строго типизированный класс перечисления. И о том, что простой enum имеет свои проблемы, о которых выше писал. Если вы не поняли этого, то ладно, нет смысла объяснять , проехали Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
one_eight_seven 6 13 марта Опубликовано 13 марта · Жалоба 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$ Ещё раз призываю эволюционировать, сначала самому попробовать что-то сделать, а не постить влажные фантазии с апломбом гуру. 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 13 марта Опубликовано 13 марта · Жалоба В 13.03.2024 в 10:39, EdgeAligned сказал: что простой enum имеет свои проблемы Это Вы немного не поняли о чем я говорил. И причем тут проблемы енума и понимание того, каким методом была задана константа? 1 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
one_eight_seven 6 13 марта Опубликовано 13 марта (изменено) · Жалоба 11 hours ago, Arlleex said: Тогда почему библиотекари стандарта пишут все с маленькой буквы? Всякие std:: и т.д. - все это с маленькой буквы. Им, получается, можно?🙂 Да всем можно. Код так более читаем для большинства людей. Плюс не надо думать и запоминать правила - всегда пишешь одинаково, и думаешь о том, как правильнее назвать. Если занимаешься интересными вещами, то заниматься подсчётом строк, вспоминать как по разному оформлять одинаковые по своей сути сущности - отвлекает. Поэтому, в библиотеках, да и во многих программах просто пользуются минимальным набором правил. по оформлению. Типа всё константное - ALL_CAPS_SNAKE (и-то не обязательно), всё остальное - lower_case_snake, или вообще всё - lower_case_snake Код может быть написан читаемым и в lower_case и в CamelCase, в стиле кодирования важнее другие вещи - правильное именование, объединение того, что должно быть объединено, и разделение разных сущностей по естественным границам, малые методы, делающие одно действие, понятно и явно написанные; комментарии, описывающие намерение или предупреждающие о чём-либо, а не реализацию (будто реализацию из кода не видно) Изменено 13 марта пользователем one_eight_seven Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 18 13 марта Опубликовано 13 марта · Жалоба 2 часа назад, Arlleex сказал: Я лишь хочу отметить, что вот каждый из вас хоть и считает "правильно вот так, а вот так - хуже или вовсе плохо", а тем не менее - у всех свое. Это стили кодирования пишут для групп программистов. Когда в одном проекте несколько человек. Когда пишешь один - вообще пофиг как именуешь и форматируешь. Главное чтоб тебе самому было понятно. Но даже для себя одного полезно сформулировать эти правила, чтобы потом их придерживаться. Это поможет потом поддерживать проект, когда нужно будет вернуться к нему через год-другой. 2 часа назад, Arlleex сказал: а какой от них толк, если весь остальной мир (включая писателей стандартных библиотек) - пишет по-другому? Из этого тоже можно извлечь пользу: сразу видно, что идёт вызов библиотечного кода 🙂 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
EdgeAligned 86 13 марта Опубликовано 13 марта · Жалоба Так, чето вы не в ту степь ушли. Я вообще-то говорил про различие между enum и enum class и про то, что во втором случае enum class - это строго типизированная штука. А не про то, чего там увидит программист или компилятор. Вы, прежде чем кидаться словами, поймите, о чем речь идет, а потом уже будете обвинять других. Сбавьте обороты. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 13 марта Опубликовано 13 марта · Жалоба В 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? Разницы нет. 2 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
EdgeAligned 86 13 марта Опубликовано 13 марта · Жалоба А причем тут FROST и eFROST? Ааа, понял, вы просто не знаете, что такое строгая типизация. Ну ладно, принято. Все, проехали эту тему, больше не возвращаемся, если для вас это сложно. Всё-Всё, больше не затрагиваю тему типов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться