История изменений
Исправление byko3y, (текущая версия) :
Вы у себя в коде используете
#define vl volatile
и вручную написанные функции по 350 строк длиной.
Возможно, для вас это нормально, а для меня – это откровенный говнокод, а автор криворукий говнокодер
И я рад за тебя, и также рад, что на моей нынешней работе мой код ревьюишь не ты, а более адекватные люди, которые не только смотрят на внешний узор, а еще и читают сам код.
Мне нужен, я использую, время от времени компилятор бьет мне по рукам и предотвращает ошибки
Я ни разу не спорю, что благодаря const возможно отловить некоторое число ошибок. Малое — потому что проверка очень куцая, есть много сценариев (которые я упомянул и которые избежели авторы стандартной либы), в которых она вообще не работает, как то контейнеры-ссылки. Я спорю именно с тем, что это количество настолько исчезающе мало, что не окупается дополнительной ментальной нагрузкой, вызванной необходимостью ублажать компилятор и копипастить функции для создания const/non-const перегрузок. Итоговый результат — плюс-минус ноль.
Что характерно, даже в мемуарах 1994 года Страуструп лишь однажды вскользь проронил, что const помогает отлавливать какие-то там ошибки. Основная цель модификатора const, которую он под разным соусом описывает в нескольких разрозненных разделах — это создание объектов-констант: их нужно как-то инициализировать, то есть, вызывать консторкторы и менять поля, после чего объект становится read-only, а потом еще и деструкторы должны как-то отработать, и снова объект как бы перестается быть константным. Как можно заметить, уже в своей первоначальной форме это был трешак со временными снятиями константности. Но это были именно константы, а не константные ссылки.
Грепание по сорцам Cfront 1.0 подтверждает мою идею — почти все использования const являются типом const char *
, то есть, указатель на строковую константу. У константных объектов методы были те же, что у неконстант — константные методы появились заметно позже, где-то ближе ко второй версии в 1989 году, где константные методы уже присутствовали.
Идею «заражающего» const в составных объектах распространили авторы STL, стандартной либы, и просто случайные коучи-продажники. В 1994 году у Страуструпа была только идея пары перегруженных функций (11.2.1. Fine-grain Resolution):
char* strtok(char*, const char*)
const char* strtok(const char*, const char*)
то есть, опять-таки, строго примитивные типы.
Если вспомнить тот простой факт, что стандарт пишут обычные люди, которые и ошибаются, и не имеют безграничных ресурсов, то тогда можно прийти к выводу, что далеко не все в C++ном стандарте доводят до ума сразу
А если еще вспомнить, что стандарты часто пишутся кретинами, которые больше ничего другого не умеют делать — то сразу всё встает на свои места. Конечно, картина испортилась, когда писанием стандартов C++ начал руководить гугл. А когда стандарты по JS начал писать Дуглас Крокфорд — JS внезапно стал адекватным языком и заполонил.
Так что сценарий с иммутабельным интрузивным списком константных значений, который почему-то должен временами быть мутабельным, для меня все еще остается загадкой
Ну как ты сделаешь иначе список const char *
? Список и его значение имеют абсолютно разные типы и к ним могут предъявляться разные требования — не нужно шланговать.
Исходная версия byko3y, :
Вы у себя в коде используете
#define vl volatile
и вручную написанные функции по 350 строк длиной.
Возможно, для вас это нормально, а для меня – это откровенный говнокод, а автор криворукий говнокодер
И я рад за тебя, и также рад, что на моей нынешней работе мой код ревьюишь не ты, а более адекватные люди, которые не только смотрят на внешний узор, а еще и читают сам код.
Мне нужен, я использую, время от времени компилятор бьет мне по рукам и предотвращает ошибки
Я ни разу не спорю, что благодаря const возможно отловить некоторое число ошибок. Малое — потому что проверка очень куцая, есть много сценариев (которые я упомянул и которые избежели авторы стандартной либы), в которых она вообще не работает, как то контейнеры-ссылки. Я спорю именно с тем, что это количество настолько исчезающе мало, что не окупается дополнительной ментальной нагрузкой, вызванной необходимостью ублажать компилятор и копипастить функции для создания const/non-const перегрузок. Итоговый результат — плюс-минус ноль.
Что характерно, даже в мемуарах 1994 года Страуструп лишь однажды вскользь проронил, что const помогает отлавливать какие-то там ошибки. Основная цель модификатора const, которую он под разным соусом описывает в нескольких разрозненных разделах — это создание объектов-констант: их нужно как-то инициализировать, то есть, вызывать консторкторы и менять поля, после чего объект становится read-only, а потом еще и деструкторы должны как-то отработать, и снова объект как бы перестается быть константным. Как можно заметить, уже в своей первоначальной форме это был трешак со временными снятиями константности. Но это были именно константы, а не константные ссылки.
Грепание по сорцам Cfront 1.0 подтверждает мою идею — почти все использования const являются типом const char *
, то есть, указатель на строковую константу. У константных объектов методы были те же, что у неконстант — константные методы появились заметно позже, где-то ближе ко второй версии в 1989 году, где константные методы уже присутствовали.
Идею «заражающего» const в составных объектах распространили авторы STL, стандартной либы, и просто случайные коучи-продажники. В 1994 году у Страуструпа была только идея пары перегруженных функций (11.2.1. Fine-grain Resolution):
char* strtok(char*, const char*)
const char* strtok(const char*, const char*)
то есть, опять-таки, строго примитивные типы.
Если вспомнить тот простой факт, что стандарт пишут обычные люди, которые и ошибаются, и не имеют безграничных ресурсов, то тогда можно прийти к выводу, что далеко не все в C++ном стандарте доводят до ума сразу
А если еще вспомнить, что стандарты часто пишутся кретинами, которые больше ничего другого не умеют делать — то сразу всё встает на свои места. Конечно, картина испортилась, когда писанием стандартов C++ начал руководить гугл. А когда стандарты по JS начал писать Дуглас Крокфорд — JS внезапно стал адекватным языком и заполонил.
Так что сценарий с иммутабельным интрузивным списком константных значений, который почему-то должен временами быть мутабельным, для меня все еще остается загадкой
Ну как ты сделаешь иначе список const char *[/inline}? Список и его значение имеют абсолютно разные типы и к ним могут предъявляться разные требования -- не нужно шланговать.