А что мешает убрать спецификатор const, в случае необходимости изменения переменной?


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


Ну вот Кусто, по всей видимости, понял, что я имел ввиду .

А не факт, что придётся убрать только этот спецификатор. Например, может понадобиться заменять все const_iterator на iterator, потому что нам захотелось модифицировать контейнер, который мы раньше считали неизменным, используя итератор.


А ты уверен, что это такая уж полезная информация? Особенно если "далее по тексту" - это одна-две-три строчки (дальше переменная просто не живёт) и её неизменность и без того очевидна.





Это сообщение отредактировал(а) UnrealMan - 19.11.2007, 15:26

Думаю, если бы вопрос топикстартеру был интересен, вряд ли он ограничился бы единственным сообщением. Да и сам стиль вопроса меня наводит на мысль, что это была попытка породить дискуссию подобную этой

увы, я столкнулся с тем, что если в наследие досталась пачка местами кривого кода, в котором "забыли" порасставлять const, причём даже в самых очевидных местах и я не могу передать в функцию const char*, так как она принимает char*, хотя на деле его не изменяет, а эта функция используется повсеместно в самых разных местах и даже программах, и сама завязана на ещё одной такой же... то тут возникает логичный вопрос: переписать и переотладить тысячи строк кода или старые куски использовать по-старому, а уже новый код писать нормально.

Я же сказал - "не всегда", но надо стараться. Что я с большим рвением и делаю.



Кстати, да. И понял и поддерживаю.
Я тебя вообще хорошо понимаю, как-то так сложилось  Эх, про "Кусто" не забыл, значит ))


имхо, дискуссии без личных выпадов полезны, это же не флейм без темы.

Очень правильно. Тогда да, мы пойдём и заменим типы. А вот если наоборот, то есть если мы забудем поставить const там, где сейчас у нас константная работа и случайно запишем по итератору, то компилятор не даст по рукам и будет прав. Имхо, чем больше const там, где переменные константны, пускай даже сейчас, тем лучше.

Чем строже ведёт себя программист по отношению к коду, тем прямее получается код.

Да, довольно полезная. Через неделю в эту функцию вставят ещё пять строчек. А через месяц ещё пять. Много понадобится памяти, дабы запомнить, что где "должно" быть константным, но const не поставлено...

Ну и что? Это достоинство const, да. Но помимо достоинств, есть и недостатки. Что весомее? Тут нет однозначного "лучше". И лично я предпочту воздержаться от использования const. Начали-то с оператора ++, там префиксный ++ однозначно как минимум не хуже, чем постфиксный. В случае с const такой однозначности нет.


Ну, для тебя, может, полезная, для меня - абсолютно бесполезная и даже вредная.

const на скорость не влияет, поэтому показатель субъективный. Следовательно, я допускаю, что кому-то const использовать не всегда удобно.
Принято.


Ясно.

теоретически он может помочь оптимизатору.

не буду спорить, но товарищ Саттер насчет этого довольно резко высказывался 
(Герб Саттер "Новые сложные задачи на C++")

А может и наоборот нагадить, если по совету Мейерса возвращать константный объект вместо обычного. В критичном к скорости участке кода без const можно вызвать неконстантный метод прямо для временного объекта, вместо того, чтобы тупо создавать копию. Например, присваивание

result = a+b;

без const элементарно заменяется swap-ом

(a+b).swap(result);

операция swap в общем случае более затратна, чем присваивание. И к тому же, менее наглядна.


Посмотрел мнение Саттера по поводу const. Думаю, он прав. const редко дает оптимизацию, зато позволяет избегать ошибок.
А разговоры о том, что когда-то метод не менял свой параметр, а потом вдруг стал менять и в случае с использыванием const возникнет куча проблем - глупы. Если у тебя такое получилось, то сам виноват - неправильный дизайн. Лучше уж написать еще одну функцию, которая выполняет нужные действия, чем ловить баги от "неправомерного" использования старой (в надежде, что она не меняет параметр).
И вообще, зачем писать функции на сотни строк, в которых может возникнуть проблема замены большого количества "const_iterator" на "iterator"? Имхо, 30-60 строк на функцию/метод - больше не стоит без крайней необходимости.

Ну, тут уже другая дилема - всего не предусмотришь... Ессно, случаи разные бывают.


Не, не, не... Даже в 1-ой строке бывает минибаг, который сразу не увидишь и которого при строгой константности могло бы не быть. Ты же отлично знаешь сколько в С++ тонкостей .
Ещё один ньюанс: если ты НЕ видишь спецификатора const, то тебе нужно помимо общей логики работы последующих 3 строчек ещё и задумываться о возможности изменения данной переменной. Учитывая, опять же, невообразимое множество тонкостей языка - это, IMHO, совсем не нужная нагрузка на мозг.



Кстати, почему-то такие тупые "вопросы" почему-то частенько порождают такие интересные дискуссии .


Вся наша жизнь состоит из альтернатив. Универсальных решений/подходов не бывает. Но при прочих равных, я бы предпочёл поставить спецификатор const. К примеру, раньше мне было непонятно какое может быть применение у нестатических константных членов. Сейчас мне их применение очень даже понятно, и я переодически их использую(в частности в текущем проекте их просто туева хуча).

Таки да - на данный момент это исключительно теория . IIRC, даже в бустовом гайде для разработчиков либ есть rational относительно безполезности использования const.


Ну я бы не сказал что прям таки без крайней. У меня частенько возникает потребность писать "одноразовый" код, разбивать который на маленькие ф-ции большого смысла нет, а скорее даже может запутать. Да и таскать туда-сюда контекст в таких случаях бывает накладно.

Именно это я и имел в виду под "крайней необходимостью". Действительно, никакого смысла городить огород ради программы на 200 строчек.

Ты не понял . Не программы, а ф-ции . Ну у меня даже идей нет, относительно того, как можно провести декомпозицию некоторых ф-ций, специфика которых просто не предусматривает повторного использования, а дробить только ради принципа "не больше 50 срок" тоже смысла нет, ибо таскать с собой контекст в виде десятка переменных нерационально(я вообще молчу, если выходных переменных из данного участка кода > 1 - вообще ужас получается).

Для потенциально больших объектов swap гораздо лучше. Надо ли говорить, что в большом количестве случаев присваивание по ряду причин выгодно реализовывать, используя идиому swap?


Читай внимательней топик. Речь шла о переменных.


Это ещё зачем?


Ну так и не ищи себе вымышленных проблем.

Я все тогда понял. Просто ответил не очень корректно на два замечания. Не думаешь же ты, что я ради того, чтобы уложиться в 50 строчек буду "таскать контекст"? Ничего подобного. ладно, это уже офтопик.
Код из STL:Ты продолжаешь утверждать, что время выполнения 2-х присваиваний и одного конструктора копирования меньше, чем одного присваивания? 


Это сообщение отредактировал(а) bsa - 20.11.2007, 12:22