Здравствуйте, vdimas, Вы писали:


V>Ну вот на такое выдергивание я и высказал фи, бо в том же самом посте далее наблюдается:
V>

V>... пойти еще дальше и ввести некий модификатор clean для ф-ий и методов?

Ну а я отвечу фи на ваш способ выдергивания. Потому что в оригинале было не троеточие, а "или":

Или пойти еще дальше и ввести некий модификатор clean для ф-ий и методов?

Что кагбэ подразумевает равноправность решений по убиранию const_cast и введению модификатора clean.

V>Потому что, во-первых, речь шла не об иммутабельности, о ссылочной прозрачности. Это был контекст. Во-вторых, потому что с помощью const можно организовать меньше участков кода с той самой соблюдаемой ссылочной прозрачностью, чем бы мне хотелось. Но это не значит, что их нельзя организовать вообще.
Я не очень понимаю, как вы собираетесь организовывать "участки кода со ссылочной прозрачностью", выходя за пределы одного метода.
Вот мы имеем, скажем,

void foo(const int &x)
{
   cout << x; // 1
   bar();
   cout << x; // 2 
}

Можно ли в точке 2 заменить "адрес" x его "значением", закешированным в точке 1?

V>Вы все писали исключительно об иммутабельности, не понимая кое-какое важное отличие иммутабельности как от исходных требований, так и от реально происходящего в коде. Современный компилятор С++, если видит жизненный цикл значения, спокойно обходится даже без всяких const при оптимизации, не то, что без мифической иммутабельности.
Вы опять делаете необоснованные предположения о том, чего не понимают ваши оппоненты. Ключевое ограничение выделено.
Вопрос только в том, что жизненный цикл значения длиной в одно тело метода малоинтересен на практике. Интересна возможность собирать из мелких кубиков целостные решения, и выводить свойства целого из свойств частей.

V>На самом деле там ничего сложного, достаточно было быть внимательным к постам оппонентов.
V>То бишь, в своих постах я изначально исходил из очевидной для меня (но неочевидной для окружающих, как выяснилось) цели: можно ли организовать в некоей точке видимости исходный код так, чтобы вызываемые непрозрачные для компилятора низлежащие процедуры заведомо не нарушали ссылочной прозрачности относительно обложенных const данных? Ответ — можно. Как именно — я уже показал.
Ну вам же привели на ваше "можно" контрпримеры.

V>Для компилятора было бы достаточно знать жизненный цикл значений и было бы достаточно гарантий от вызываемого кода.
В том-то и проблема, что такой подход требует глобального анализа для "жизненного цикла значений".

Но не в том виде, как вы показали (когда ссылочной прозрачности относительно неких данных уже не было на входе процедуры), а из-за встроенных в сам язык конструкций по преодолению этой константности. Вот эти конструкции меня и раздражают.

V>Мы вообще что и ради чего обсуждаем? Я так предполагаю, что все в курсе, что суперкомпиляция на сегодня недоступна, что современным компиляторам запросто могут быть недоступны кишки вызываемых подпрограмм, поэтому именно от вызываемых подпрограмм требуются гарантии. Не от вызывающих. Что сами эти гарантии относительно вызываемых подпрограмм нужны исключительно для того, чтобы компиляторы могли делать все оптимизации, которые они могли бы делать в случае ссылочной прозрачности.
Ну покажите же мне, какие оптимизации может делать компилятор при компиляции foo(const int& x) по сравнению с компиляцией foo(int& x).

S>>Я верну его на место:

S>>

S>>А теперь, если вам хочется поговорить про гипотетический модификатор clean, то приведите пример того, как с его помощью вы собрались решать проблему, неразрешимую при помощи const.

V>Дык, я и не мог ответить на таким образом сформулированный вопрос пока видел непонимание работы const.
Нет никакого непонимания работы const.

V>Ведь вопрос связывает одно с другим. Я давал всё больше подсказок — но так и не увидел понимания. ОК, я сел и нахерачил это пост (выбрать на такой пост время тоже не просто).
То есть как обычно — у вас хватило времени налить воды, но кода с примером применения clean мы так и не увидели. ЧиТД.

S>>Медитировать, простите, я за вас не буду — вы опять обвините меня в том, что я вам приписываю неправильные мысли. Давайте уж как-то сами.
V>Ну конечно неправильные. Вы же ставили знак равенства м/у const и иммутабельностью, потом говорили, что это я, оказывается, ставлю, а потом показывали как же я не прав. )))
Никто не ставил знаков равенства. Говорили, что для изоляции чистого кода от мутабельного const не работает. И вы мне тут капсом пишете что нет, он для этого не работает. Зато, предположительно, будет работать clean. Но пока непонятно как. Давайте код в студию, а то без него разговор смысла не имеет.