KP>Я много лет за такое по рукам бил, особенно, если кто-то додумывался учудить подобное в заголовочном файле. Привести в чувства проект с горой "using namespace std" то еще веселье
Вот спасибо.
Я 2 курсу про это дело с первой лабы талдычу.
Они, естественно, не понимают, за что такой беспредел — нельзя писать в заголовочных файлах.
Тащу Герба Саттера, читаю совет 59 из евоной с Александреску книжки.
Все равно пишут, сволочи...
Вычищаю безжалостно и возвращаю лабу на доработку — ВСЕГДА
Теперь буду сюда посылать. На 4 буквы...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Это последствия копирования из книг учебных примеров. Там ради компактности кода используют что-то типа
cout << "Hello, Wolrd!\n";
При этом using namespace std; даже не пишется, а подразумевается. Вот народ и получает синдром утенка, от которого сложно избавиться. Умение критически относиться к авторитету приходит со временем. Нужно с одной стороны сохранить интерес к изучаемому предмету, чтобы усваивать полезную информацию, однако, с другой быть готовым к тому, что автор может быть не прав, и отфильтровывать нерелевантную отсебятину, а тут опыт требуется.
Другое тяжелое последствие привыкания к примерам из книжек — любовь к египетским скобкам. В книжке учебный пример ты все равно читаешь внимательно до каждой запятой, а в production коде скобка на отдельной строке очень помогает структурировать код для быстрого просмотра. В некоторых языках даже прикручивают обязательный линтер, который не даст собрать код, если скобка не там. К счастью в моем любимом Kotlin это лишь на уровне рекомендаций от создателей языка (видимо, сказывается ИТМО'шное прошлое).
Вообще, примеры из книжек нехило-так травмируют психику студентов-программистов.
Здравствуйте, Masterspline, Вы писали:
M>Это последствия копирования из книг учебных примеров. Там ради компактности кода используют что-то типа M>
M>cout << "Hello, Wolrd!\n";
M>
M>При этом using namespace std; даже не пишется, а подразумевается. Вот народ и получает синдром утенка, от которого сложно избавиться. Умение критически относиться к авторитету приходит со временем. Нужно с одной стороны сохранить интерес к изучаемому предмету, чтобы усваивать полезную информацию, однако, с другой быть готовым к тому, что автор может быть не прав, и отфильтровывать нерелевантную отсебятину, а тут опыт требуется.
M>...
M>Вообще, примеры из книжек нехило-так травмируют психику студентов-программистов.
+1
А есть еще горе-преподы. Живой пример: младшенькая моя приступила к занятиям на втором курсе примата и вот, алилуйя, начали они изучать C++. Вчера притащила учебный пример реализации комплексного числа, написанного преподавателем, с заданием "разобраться в программе". Я глянул, а там и пресловутое "using namespace std" тут как тут, помимо прочего. Используется правда в области видимости функций, но только лишь из-за пары несчастных std::cout и std::endl. Я ей тут же показываю это обсуждение, рассказываю про грабли. Есть, конечно, еще надежда, что препод в какой-то момент скажет им: "дети, using директивы — это зло...". Но это вряд ли, я чувствую.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Masterspline, Вы писали:
M> К счастью в моем любимом Kotlin это лишь на уровне рекомендаций от создателей языка (видимо, сказывается ИТМО'шное прошлое).
Такая же рекоммендация как в JavaScript добровольно-принуждённая
Боюсь придётся смириться и писать как от вас этого ожидают все остальные программисты включая создателей языка.
Formatting
Use 4 spaces for indentation. Do not use tabs.
For curly braces, put the opening brace in the end of the line where the construct begins, and the closing brace on a separate line aligned horizontally with the opening construct.
if (elements != null) {
for (element in elements) {
// ...
}
}
(Note: In Kotlin, semicolons are optional, and therefore line breaks are significant. The language design assumes Java-style braces, and you may encounter surprising behavior if you try to use a different formatting style.)
Здравствуйте, LaptevVV, Вы писали:
LVV>Они, естественно, не понимают, за что такой беспредел — нельзя писать в заголовочных файлах. LVV>Тащу Герба Саттера, читаю совет 59 из евоной с Александреску книжки. LVV>Все равно пишут, сволочи... LVV>Вычищаю безжалостно и возвращаю лабу на доработку — ВСЕГДА LVV>Теперь буду сюда посылать. На 4 буквы...
Всё равно будут писать, пока сами по граблям не походят. Тогда вспомнят твои советы и исправятся.
Здравствуйте, _NN_, Вы писали:
_NN>После того как в очередной раз сломали код из-за добавления новых символов в std , как std::predicate, моё терпение лопнуло. _NN>Пространство имён std не резиновые.
_NN>В общем я теперь агитирую только using std::something или явное std::something.
_NN>Есть ещё кто пишет using namespace std ?
_NN>https://en.cppreference.com/w/cpp/concepts/predicate
Для std:: — никогда
Для остальных namespaces — только в сильно локальных скопах (к примеру — функции) и только если префикс из неймспейсов сильно длинный получается (3-4 вложенных неймспейса)
Здравствуйте, AleksandrN, Вы писали:
AN>Всё равно будут писать, пока сами по граблям не походят. Тогда вспомнят твои советы и исправятся.
Надо грабли аккуратно просто расставить.
Скажем назвать переменную predicate, string_view, launder, begin и т.п. со стандартом С++03 всё соберётся.
Потому берём С++11, там одна часть программы отвалится, а потом переходим на С++17 и ещё.
Со второго раза дойдёт.
Здравствуйте, _NN_, Вы писали:
_NN>Есть ещё кто пишет using namespace std ?
У меня торчит в глобальном хедере (который юзается при формировании pch).
Но последние несколько лет (три или четыре), планомерно обновляю код с явным указанием std:: и прочих (своих) пространств имен.
Причем не из-за конфликтов, а из за тупняка подсветки символов в VS.
Может через год/два и изничтожу этот using namespace std
UPD. Вообще про правила организации и пространств имен я читал, наверное, лет 20 назад. Тогда думал — что-то дядьки мудряд. А въехал только в 2011 году когда с чистого листа начал программировать на шарпе. Теперь вот, последние девять лет, привожу в порядок код на плюсах
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
_NN>>Есть ещё кто пишет using namespace std ?
КД>У меня торчит в глобальном хедере (который юзается при формировании pch).
КД>Но последние несколько лет (три или четыре), планомерно обновляю код с явным указанием std:: и прочих (своих) пространств имен.
Перечитал, подумал...
По хорошему надо бы не std::, а ::std:: указывать.
Поставлю себе
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Masterspline, Вы писали:
M>Другое тяжелое последствие привыкания к примерам из книжек — любовь к египетским скобкам.
"-1"и "" Не надо свою вкусовщину выдавать за истину в последней инстанции
M>>Другое тяжелое последствие привыкания к примерам из книжек — любовь к египетским скобкам. S>"-1"и "" Не надо свою вкусовщину выдавать за истину в последней инстанции
Уверен, ты понимаешь, что мне насрать на твои "-1". Меня вообще мало интересуют посты без практически полезной информации.
Когда будет, что сказать по делу — приходи. Я рассказал, чем плохи на практике египетские скобки, а от тебя увидел лишь понты и пустой трындеж. Если для тебя читаемость кода — это вкусовщина, то для меня нет.
И я в курсе, что есть много любителей египетских скобок.
Здравствуйте, Masterspline, Вы писали:
M>Уверен, ты понимаешь, что мне насрать на твои "-1".
"Три дня я гналась за вами, чтобы сказать как вы мне безразличны!"
M>Меня вообще мало интересуют посты без практически полезной информации.
Ну вот твои персональные предпочтения расстановки скобочек являются эталонным примером этого.
M>Когда будет, что сказать по делу — приходи.
на кывте является хорошим тоном объяснять оценку "-1" в профильных форумах
M>Я рассказал, чем плохи на практике египетские скобки
Пока ты рассказал о своих предпочтениях в довольно агрессивной манере.
M>а от тебя увидел лишь понты и пустой трындеж.
Ок.
M>Если для тебя читаемость кода — это вкусовщина, то для меня нет.
У тебя проблемы с чтением когда Chrome, Qt, etc? Надо больше практики
M>И я в курсе, что есть много любителей египетских скобок.
Ну так может это не так принципиально как ты думаешь?
КД>У меня есть вопрос по этой теме. КД>Как без "using namespace std" находятся свободные операторы сравнения (==, !=, ...) для классов определенных в пространстве std? КД>Например, для std::string.
Есть такой механизм, Argument Dependent Lookup (ADL). Когда компилятор видит в коде вызов функции, он ищет кандидатов на подставновку, в том числе, и в пространствах имен фактических параметров. Это также относится и к операторам, поскольку они и есть функции по сути. В стандарте языка это описано в пункте 6.4.2 Argument-dependent name lookup.
Открытый интерфейс класса образуют не только открытые функции-члены, но и функции, не являющиеся членами. Принцип Интерфейса гласит: для класса X все функции (включая функции, не являющиеся членами), которые "упоминают X" и "поставляются вместе с X" в одном и том же пространстве имен, являются логической частью X, поскольку образуют часть интерфейса X
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Skorodum, Вы писали:
M>>а от тебя увидел лишь понты и пустой трындеж. S>Ок.
Это потому, что вы никак не доказываете своего утверждения.
M>>Если для тебя читаемость кода — это вкусовщина, то для меня нет. S>У тебя проблемы с чтением когда Chrome, Qt, etc? Надо больше практики
У меня нет проблем с чтением кода. У меня есть наблюдение: в коде с "египетским скобкам" я нахожу ошибки чаще, чем в коде где скобки выровнены по столбцам и строкам.
Здравствуйте, B0FEE664, Вы писали:
BFE>Это потому, что вы никак не доказываете своего утверждения.
Бремя доказаетельства лежит на утверждающих, что один стиль однозначно лучше другого
BFE>У меня нет проблем с чтением кода. У меня есть наблюдение: в коде с "египетским скобкам" я нахожу ошибки чаще, чем в коде где скобки выравнены по столбцам и строкам.
Анекдотные доказательства
Здравствуйте, Skorodum, Вы писали:
BFE>>У меня нет проблем с чтением кода. У меня есть наблюдение: в коде с "египетским скобкам" я нахожу ошибки чаще, чем в коде где скобки выровнены по столбцам и строкам. S>Анекдотные доказательства
Это не доказательство. Это личное наблюдение, для статистики ничго не значащие.
А вот, наверное, с помощью анализатора PVS-Studio можно провести исследование, в каком коде плотность ошибок больше: с "египетским скобкам" или с Allman style. Где разработчики мерчендайзеры анализатора? Что скажите?
Здравствуйте, B0FEE664, Вы писали:
BFE>Это не доказательство. Это личное наблюдение, для статистики ничго не значащие.
Предположу, что кода в K&R стиле намного больше (с ходу: Linux, boost, Qt).
BFE>А вот, наверное, с помощью анализатора PVS-Studio можно провести исследование, в каком коде плотность ошибок больше: с "египетским скобкам" или с Allman style. Где разработчики мерчендайзеры анализатора? Что скажите?
Тут много других факторов, которые влияют на вероятность ошибки намного сильнее, чем стиль скобок, для их исключения надо проверить много проектов
