LINUX.ORG.RU

История изменений

Исправление 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}? Список и его значение имеют абсолютно разные типы и к ним могут предъявляться разные требования -- не нужно шланговать.