Мне надоело мусолить вашу тупость, поэтому вымараю то, что без мата комментировать уже невозможно.
·>Надо чтобы не было возможности передавать ссылку на неконстантный объект.
Прикиньте, а мне бывают нужны и константные ссылки на неконстантные объекты. И я рад, что в C++ такая возможность есть.
S>>Я не утверждал про невозможность передать неконстанный объект по константной ссылке. Вы что-то путаете. ·>Ты обещал, что передавать константные ссылки другим тредам — безопасно.
Вы уверены, что я это утверждал?
·>Мне пофиг на компилятор.
А мне нет. Компилятор мне помогает.
·>Что это даёт юзерам компилятора?
Строгий компилятор помогает сократить затраты на разработку. Т.е. юзер выигрывает в сроках, качестве и стоимости.
·>Ох, ну господи. Добавь "final" в декларацию remaining_bytes, я забыл при копипасте: final int remaining_bytes;. Вселенная спасена?
Вы рехнулись? Этот элемент должен быть изменяемым.
Ах да, у вас же каша в голове.
S>>Повторюсь: схерали? ·>А от чего ещё-то?
Ответ вопросом на вопрос. Так и запишем. Вы не можете объяснить, у вас просто какой-то шаблон в мозгах отпечатался и за его пределы вы не можете выглянуть.
S>>·>Методу по логике вещей qwerAsdf либо нужно менять Map, либо не нужно. Если не нужно — он менять не будет. S>>Как это гарантировать средствами языка? ·>_Если надо_, то создать интерфейс с соответсвующими методами.
Т.е. никак. Об этом вам талдычат уже который раз.
S>>·>А это какую проблему решает? S>>Проблему понимания константности в C++. ·>Очень важная и нужная проблема (нет).
Тем не менее, обсуждается здесь именно она. Если вы не даете себе труда в нее вникнуть, то лучше бы вам вообще завершить этот разговор.
·>Ок. Начни с того, что объясни создателям D что они ошиблись вводя "immutable" при наличии "const". Ведь по-твоему можно только "const" обойтись.
А давайте вы вот это "по-твоему" подтвердите цитатами.
И еще я был бы признателен, если бы вы обратили внимание вот на эти мои слова
Здравствуйте, so5team, Вы писали:
S>>>·>Да. А ты веришь что const от чего-то защищает. S>>>От защищает от вызова методов, которые не помечены как const. S>·>Как и const-интерфейс. В чём поинт-то? S>Внутри этого вашего const-интерфейса кто-то что-то гарантирует?
Ок. То что "От защищает от вызова методов, которые не помечены" ты значит согласился. Возражений нет.
А внутри метода защита будет с помощью final.
S>>>И да, в это сложно не поверить, после того, как компилятор столько раз бил по рукам. S>·>С интерфейсом код такой написать тупо не получится S>Мне вот почему-то не помешало:
Ну добавь final.
S>Нет, они не обратили внимания в запарке спора. S>·>Как и ты, когда предлагал мне константные ссылки передавать в другие треды. S>Странно, у меня все работает:
Потому что ты работающий код написал. Мы говорим о возможности написать неработающий код который пропустит компилятор.
S> const vector_of_string immutable_data{ "Hello"s, "World"s };
Что помешает убрать const здесь? И помодифицировать immutable_data перед join()?
S>Проблема на вашей стороне.
А на вашей стороне потенциальные баги.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[67]: Когда это наконец станет defined behavior?
Здравствуйте, T4r4sB, Вы писали:
TB>·>Ровно то же что и с ConstObj obj = new Obj();obj.change();. Отличие по сути только в отсутствии пробела в "Const Obj".
TB>То есть надо для каждого класса отдельно описывать его константного "брата"?
А если объект нельзя менять только в определённых состояниях?
Re[67]: Когда это наконец станет defined behavior?
Здравствуйте, so5team, Вы писали:
s> Мне надоело мусолить вашу тупость, поэтому вымараю то, что без мата комментировать уже невозможно.
Попробуй включить мозг и всё получится.
s> ·>Надо чтобы не было возможности передавать ссылку на неконстантный объект. s> Прикиньте, а мне бывают нужны и константные ссылки на неконстантные объекты. И я рад, что в C++ такая возможность есть.
Ого. Ты, похоже, начинаешь что-то подозревать наконец-то. Теперь подумай почему в rust для нормального const понадобился borrow checker.
s> ·>Ты обещал, что передавать константные ссылки другим тредам — безопасно. s> Вы уверены, что я это утверждал?
Ты утверждал, что константность как-то что-то защищает при передаче данных между тредами и упомянул константные ссылки. И в итоге получилось то, что надо просто создать константный объект, передать ссылку на него другому треду, веря в то, что никто никогда не передаст ничего другое этому треду.
Что, внезапно, эквивалентно в java созданию иммутабельного объекта и передача его по ссылке, без всяких констатностей.
А если использовать иммутабельные типы,то и веры никакой не надо.
Это отвечает на твой начальный вопрос?
s> ·>Что это даёт юзерам компилятора? s> Строгий компилятор помогает сократить затраты на разработку. Т.е. юзер выигрывает в сроках, качестве и стоимости.
Что конкретно? Ты общими словами не отмазывайся.
s> ·>Ох, ну господи. Добавь "final" в декларацию remaining_bytes, я забыл при копипасте: final int remaining_bytes;. Вселенная спасена? s> Вы рехнулись? Этот элемент должен быть изменяемым.
Это вы заврались. В приведённом тобой коде он не был изменяемым. Точнее, он там вынужденно изменяемый из-за наличия operator=.
s> S>>Повторюсь: схерали? s> ·>А от чего ещё-то? s> Ответ вопросом на вопрос. Так и запишем. Вы не можете объяснить, у вас просто какой-то шаблон в мозгах отпечатался и за его пределы вы не можете выглянуть.
Потому что нет ничего другого в иммутабельном объекте от чего может зависеть результат вызова его метода.
s> Т.е. никак. Об этом вам талдычат уже который раз.
От того, что ты талдычишь фигню много раз, она не перестаёт быть фигнёй.
s> S>>Проблему понимания константности в C++. s> ·>Очень важная и нужная проблема (нет). s> Тем не менее, обсуждается здесь именно она.
Вопрос задал ты. Я на него как смог ответил. Тебе ответ не по вкусу, ну твои проблемы.
s> Если вы не даете себе труда в нее вникнуть,
Это твоя личная фантазия.
s> то лучше бы вам вообще завершить этот разговор.
s> ·>Ок. Начни с того, что объясни создателям D что они ошиблись вводя "immutable" при наличии "const". Ведь по-твоему можно только "const" обойтись. s> А давайте вы вот это "по-твоему" подтвердите цитатами. Здесь
что иммутабельность можно пытаться обеспечить разными способами. ... можно с помощью средств языка. В C++ таковыми являются const.
Ок. Я ошибся Ты тут утверждал, что только лишь попытаться можно (правда зачем, так и не объяснил, результат же известен, что нихера не выйдет). Согласись, что до тебя наконец-то дошло, что с помощью const нельзя обеспечить иммутабельность и можно разойтись.
s> И еще я был бы признателен, если бы вы обратили внимание вот на эти мои слова
: s> Один из самых фундаментальнейших. Правда, в C++ его до ума не довели. А в D слегка переборщили.
Его нельзя довести до ума. В этом и суть. Точнее для этого нужна тяжелая артиллерия в виде, например, borrow checker.
В D добавили const чтобы не отпугнуть таких как ты от языка, который претендовал на улучшенные плюсы. А для всего остального добавили immutable.
Здравствуйте, ·, Вы писали:
s>> Мне надоело мусолить вашу тупость, поэтому вымараю то, что без мата комментировать уже невозможно. ·>Попробуй включить мозг и всё получится.
В вашем случае мозг придется включать психиатрам во время вашего лечения. Ибо откровенные проблемы с логическим мышлением прямо на поверхности:
·>Согласись, что до тебя наконец-то дошло, что с помощью const нельзя обеспечить иммутабельность и можно разойтись.
Есть заявление "нельзя". Есть простейший пример, который демонстрирует обратное:
#include <string>
#include <vector>
#include <thread>
#include <iostream>
using namespace std::string_literals;
using vector_of_string = std::vector<std::string>;
[[nodiscard]]
std::thread
launch_thread(const vector_of_string & v, int iterations) {
// Здесь компилятор запрещает модифицировать v.return std::thread{ [&v, iterations] {
// Здесь компилятор запрещает модифицировать v.
std::size_t l{};
for(int i=0; i < iterations; ++i) {
for(const auto & s :v) l += s.size();
}
std::cout << "iterations: " << iterations << ", l=" << l << std::endl;
}};
}
int main() {
const vector_of_string immutable_data{ "Hello"s, "World"s };
// Здесь компилятор запрещает модифицировать immutable_data.
std::vector<std::thread> threads;
threads.push_back(launch_thread(immutable_data, 1'000));
threads.push_back(launch_thread(immutable_data, 2'000));
threads.push_back(launch_thread(immutable_data, 3'000));
for(auto & t : threads) t.join();
}
Итого: тезис "нельзя" опровергнут примером (даже несколькими примерами по ходу обсуждения).
Дальнейшее упрямство поциента должно являться предметом интереса у специалистов-мозгоправов.
PS.
·>Это вы заврались. В приведённом тобой коде он не был изменяемым. Точнее, он там вынужденно изменяемый из-за наличия operator=.
Нет. Просто ваш "эквивалент" вовсе и не эквивалент: это и не value type, и не допускает модификацию значения in place.
Здравствуйте, ·, Вы писали:
·>Не мешает. Но не грозит неизвестными последствиями, как в случае веры в то, что наличие const защищает от изменений (на что, например, напоролись T4r4sB и rg45 тут
, а ведь наверняка у них опыта в плюсах поболее моего).
·>Им казалось, что const защищает map от модификации значений ключей, и что благодаря этому инварианты map сломать нельзя. Как оказалось, им таки только казалось.
·>Они не знали, ну ладно, будем считать забыли. Как и ты, когда предлагал мне константные ссылки передавать в другие треды.
Добрый день, извини, не знаю, как тебя звать-величать по имени-отчеству.
Ты вынуждаешь меня нарушать правила форма и отвечать тебе из бана. Я писал тебе письмо с просьбой прекратить писать домыслы от моего имени. Но, то ли письмо мое не дошло, то ли ты его просто проигнорировал. Ничего мне казалось. И как я мог не знать о такой возможности, если я сам же и разбирал выше по коду практичестки тот же случай: http://rsdn.org/forum/cpp/8514772.1
Но, судя по тому, что ты пишешь потом, ты истолковал их как-то очень по-своему. Попробую написать немного другими словами: ты приводишь случай, который носит все признаки либо очень экзотической ситуации, либо просто дефективного дизайна. И ты этому случаю пытаешься придать статус какой-то всеобщей проблемы. Но это не так. В данном конкретном примере у программиста есть аж целых два способа избежать стрельбы себе в ногу: либо положить в мапу значение, либо объявить объект key изначально константным. Для чего может потребоваться использовать в качестве ключа мапы ссылку на неконстантый объек, я даже придумать сходу не могу, это точно или какая-то экзотика, или просто кривизна.
И в завершение еше раз повторяю мою огромную просьбу: пожалуйста, не нужно ничего здесь писать от моего имени или рассказывать о том, что мне показалось. Дай мне спокойно досидеть свой бан и не вынуждай меня нарушать правила форума. Договорились?
Здравствуйте, so5team, Вы писали:
s> ·>Согласись, что до тебя наконец-то дошло, что с помощью const нельзя обеспечить иммутабельность и можно разойтись. s> Есть заявление "нельзя". Есть простейший пример, который демонстрирует обратное:
Я вроде написал что оно работает на вере и даже рассказал как сломать. Небольшое изменение — и взлетит на воздух. В отличие, например, от rust или D с immutable.
Вот, если ты не понял: s>
// Здесь компилятор разрешает не добавлять const (случайно или по логике вещей) или банально забыть:
s> vector_of_string immutable_data{ "Hello"s, "World"s };
s> std::vector<std::thread> threads;
s> threads.push_back(launch_thread(immutable_data, 1'000));
s> threads.push_back(launch_thread(immutable_data, 2'000));
s> threads.push_back(launch_thread(immutable_data, 3'000));
// а потом добавить спецэффектов:
immutable_data.push_back("ups");
s> for(auto & t : threads) t.join();
s>
А уж если совсем с козырей зайти, то и с контролем времени жизни будет проблема — достаточно забыть t.join() и оно разлетится. Тут только borrow checker справляется (ну или gc как в java).
s> Итого: тезис "нельзя" опровергнут примером (даже несколькими примерами по ходу обсуждения).
s> Дальнейшее упрямство поциента должно являться предметом интереса у специалистов-мозгоправов.
А тебе бы пустырник для успокоения, да компрессик для охлаждения.
s> ·>Это вы заврались. В приведённом тобой коде он не был изменяемым. Точнее, он там вынужденно изменяемый из-за наличия operator=. s> Нет. Просто ваш "эквивалент" вовсе и не эквивалент: это и не value type, и не допускает модификацию значения in place.
В java другие подходы для организации кода. Внезапно. И там in-place практически не используется.
Здравствуйте, T4r4sB, Вы писали:
TB> ·>Ровно то же что и с ConstObj obj = new Obj();obj.change();. Отличие по сути только в отсутствии пробела в "Const Obj". TB> То есть надо для каждого класса отдельно описывать его константного "брата"?
Это плюсовикам кажется, что у каждого класса непременно нужна и важна константность на половине методов.
Интерфейсы пишутся по дизайну приложения, по конкретным бизнес-требованиям кода, а не по константности.
Здравствуйте, ·, Вы писали:
s>> ·>Согласись, что до тебя наконец-то дошло, что с помощью const нельзя обеспечить иммутабельность и можно разойтись. s>> Есть заявление "нельзя". Есть простейший пример, который демонстрирует обратное: ·>Я вроде написал что оно работает на вере
Вы здесь много откровенной херни написали.
·>и даже рассказал как сломать.
Чтобы сломать нужно избавиться от константности. И, внезапно, это будет разговор на совсем другую тему.
Пока же const в коде присутствует, компилятор бьет по рукам. И это очень хорошо.
Гораздо лучше, чем в Java, Ruby и Python.
·>В отличие, например, от rust или D с immutable.
Вам осталось доказать, что я где-то утверждал о превосходстве C++ над данными языками в этом аспекте.
·>Вот, если ты не понял:
·>// Здесь компилятор разрешает не добавлять const (случайно или по логике вещей) или банально забыть:
Специально для поциентов с проблемами восприятия: Чтобы сломать нужно избавиться от константности. И, внезапно, это будет разговор на совсем другую тему.
Re[73]: Когда это наконец станет defined behavior?
Здравствуйте, rg45_from_ban, Вы писали:
r> Ты вынуждаешь меня нарушать правила форма и отвечать тебе из бана. Я писал тебе письмо с просьбой прекратить писать домыслы от моего имени. Но, то ли письмо мое не дошло, то ли ты его просто проигнорировал.
Не вижу никаких писем, даже в спам-боксе.
Твоя цитата: r> программист МОЖЕТ обеспечить реальную константность адресуемых данных.
Я не с этим спорю. Но это заслуга программиста, а не const или проверки компилятора. В этом и есть мой поинт. Программист МОЖЕТ хоть на brainfuck с ассемблерными вставками работающий код, без всяких const.
Иными словами const не является какой-то важной и нужной фичей. Поэтому неудивительно, что другие ЯП как-то без него обходятся.
Я начал обсуждение с попытки ответить на вопрос: "Как вы предлагаете обходиться без таких вещей как константные ссылки/указатели?". (кстати про любимые so5team константные _объекты_ речи не шло).
r> такое где-то встрется, то, наверное, это следует рассматривать как какую-то вынужденную исключительную меру
Это, как правило, само вылазит в больших долго развивающихся проектах.
r> Для чего может потребоваться использовать в качестве ключа мапы ссылку на неконстантый объек, я даже придумать сходу не могу, это точно или какая-то экзотика, или просто кривизна.
Проблема в том, что нет возможности заставить компилятор иметь ссылку на _только_ константный объект. Там где у тебя используются константные ссылки, туда можно пихать всё что угодно. Следовательно наличие константной ссылки не гарантирует неизменность данных.
Более того, это ведёт к ложному чувству защищённости. Вот тут
T4r4sB откровенно заявляет, что const защищает ключи в хеш-мапе от изменений. И ты ему поставил плюсик, я это воспринял, что ты имеешь такое же мнение.
r> Дай мне спокойно досидеть свой бан и не вынуждай меня нарушать правила форума. Договорились?
Так это форум, хоть через год отвечай.
Здравствуйте, so5team, Вы писали:
s> ·>и даже рассказал как сломать. s> Чтобы сломать нужно избавиться от константности. И, внезапно, это будет разговор на совсем другую тему.
Константные ссылки таки остались, не знаю что ты подразумеваешь от избавления от константности.
Напомню твой вопрос: "При программировании на Java, Ruby или Python, где подобного понятия константной ссылки нет. Как вы предлагаете обходиться без таких вещей как константные ссылки/указатели?". Объектов тут и не было.
s> Пока же const в коде присутствует, компилятор бьет по рукам. И это очень хорошо.
Так он присутствует на ссылках, но по рукам не бьёт.
s> Гораздо лучше, чем в Java, Ruby и Python.
Ровно так же. Просто будет иммутабельный List и собственно всё. Вместо навешивания константности — навешиваешь неизменяемость. Вот и вся разница.
s> ·>// Здесь компилятор разрешает не добавлять const (случайно или по логике вещей) или банально забыть:
s> Специально для поциентов с проблемами восприятия:
Хамло ты гороховое. Но понимаю, C++ не даёт расслабляться. Тебе надо молоко за вредность требовать.
s>Чтобы сломать нужно избавиться от константности. И, внезапно, это будет разговор на совсем другую тему.
Чтобы избавиться, надо чтобы оно изначально там было. Я же написал, например, константность на объект можно забыть добавить изначально.
Здравствуйте, ·, Вы писали:
·>Константные ссылки таки остались, не знаю что ты подразумеваешь от избавления от константности.
Сперва вы убираете const с объявления immutable_value, а затем пишете "не знаю что ты подразумеваешь от избавления от константности". И после этого хотите, чтобы вас воспринимали психически здоровым человеком?
·>Напомню твой вопрос: "При программировании на Java, Ruby или Python, где подобного понятия константной ссылки нет. Как вы предлагаете обходиться без таких вещей как константные ссылки/указатели?". Объектов тут и не было.
на который вам было сказано, что там нет константных объектов.
И далее речь зашла о наличии толка от константных объектов и что с ними можно делать.
Поскольку разговор длится уже очень долго, то странно аппелировать лишь к его началу, когда был задан исходный вопрос о том, что в Java/Ruby/Python делают не имя константных ссылок/указателей.
s>> Пока же const в коде присутствует, компилятор бьет по рукам. И это очень хорошо. ·>Так он присутствует на ссылках, но по рукам не бьёт.
Он продолжает бить в launch_thread. Что уже немало.
·>Ровно так же.
Для клинических идиотов, разве что.
·>Вместо навешивания константности — навешиваешь неизменяемость. Вот и вся разница.
На колу мочало. Там все гарантии на уровне "мамой клянусь".
s>>Чтобы сломать нужно избавиться от константности. И, внезапно, это будет разговор на совсем другую тему. ·>Чтобы избавиться, надо чтобы оно изначально там было. Я же написал, например, константность на объект можно забыть добавить изначально.
И, внезапно, константности и не будет. И это опять же будет разговор на совсем другую тему.
Здравствуйте, so5team, Вы писали:
s> ·>Константные ссылки таки остались, не знаю что ты подразумеваешь от избавления от константности. s> Сперва вы убираете const с объявления immutable_value,
А что-то запрещает убирать? Или даже — а разве что-то заставляет писать?
s> а затем пишете "знаю что ты подразумеваешь от избавления от константности". И после этого хотите, чтобы вас воспринимали психически здоровым человеком?
Ты прочитай что я написал и не искажай мои слова.
s> ·>Напомню твой вопрос: "При программировании на Java, Ruby или Python, где подобного понятия константной ссылки нет. Как вы предлагаете обходиться без таких вещей как константные ссылки/указатели?". Объектов тут и не было. s> Объекты появились вскоре после этого:
Потому что ты понял, что сел в лужу с ссылками и указателями, которые вообще никаких полезных гарантий не дают.
s> И далее речь зашла о наличии толка от константных объектов и что с ними можно делать.
Как оказалось — только иметь их внутри метода. И собственно всё. Мой поинт был, что пользы от этого — маловато будет, кроме плюсов такое никуда тащить не стали (ну ладно, D ещё, для обратной совместимости с упёртыми девелоперами), зато иммутабельные объекты — нужны и полезны, и тащатся и используются повсюду. Если для тебя есть великая польза в полумерах в виде const, то пожалуйста. Пользуйся на здоровье, это не меняет ответ на твой изначальный вопрос "как же можно обходиться без" — да очень легко и просто.
s> Поскольку разговор длится уже очень долго, то странно аппелировать лишь к его началу, когда был задан исходный вопрос о том, что в Java/Ruby/Python делают не имя константных ссылок/указателей.
s> s>> Пока же const в коде присутствует, компилятор бьет по рукам. И это очень хорошо. s> ·>Так он присутствует на ссылках, но по рукам не бьёт. s> Он продолжает бить в launch_thread. Что уже немало.
Ок, это уже субъективное мнение и приоритеты. Дизайнеры многих более современных ЯП решили, что ооочень мало. И вообще того не стоит того, если учесть усложнение системы типов и различного кода, особенно библиотечного.
s> ·>Вместо навешивания константности — навешиваешь неизменяемость. Вот и вся разница. s> На колу мочало. Там все гарантии на уровне "мамой клянусь".
Ну да const на объекте — мамой клянусь. В чём твоё возражение-то?
s> И, внезапно, константности и не будет. И это опять же будет разговор на совсем другую тему.
Ты так и не рассказал, как же она там _гарантированно_ появится?
Здравствуйте, ·, Вы писали:
s>> ·>Константные ссылки таки остались, не знаю что ты подразумеваешь от избавления от константности. s>> Сперва вы убираете const с объявления immutable_value, ·>А что-то запрещает убирать?
Да. Желание разработчика получить профит от наличия const в языке. Если разработчик умеет это делать.
·>Или даже — а разве что-то заставляет писать?
Да. Опыт и здравый смысл.
s>> а затем пишете "знаю что ты подразумеваешь от избавления от константности". И после этого хотите, чтобы вас воспринимали психически здоровым человеком? ·>Ты прочитай что я написал и не искажай мои слова.
Прочитал и не исказил.
·>Потому что ты понял, что сел в лужу с ссылками и указателями, которые вообще никаких полезных гарантий не дают.
Звиздеть изволите. Ну или покажите хотя бы одно мое утверждение о том, что const ссылки/указатели дают гарантии.
s>> И далее речь зашла о наличии толка от константных объектов и что с ними можно делать. ·>Как оказалось — только иметь их внутри метода.
·>И собственно всё.
Нет. Просто вы не смогли осилить const в C++.
·>Мой поинт был, что пользы от этого — маловато будет
Аминь.
·>кроме плюсов такое никуда тащить не стали (ну ладно, D ещё, для обратной совместимости с упёртыми девелоперами)
ЕМНИП, в D1 вообще const-а не было. const и immutable туда притащили уже в D2, лет через 7-8 после появления D.
·>зато иммутабельные объекты — нужны и полезны, и тащатся и используются повсюду.
Только вот в Java у вас нет никакой помощи от компилятора в их реализации.
·>Пользуйся на здоровье, это не меняет ответ на твой изначальный вопрос "как же можно обходиться без" — да очень легко и просто.
Легко, просто, с ручным добавлением дополнительных сущностей и гарантиями уровня "мамой клянусь". Да, все так.
·>Ок, это уже субъективное мнение и приоритеты. Дизайнеры многих более современных ЯП решили, что ооочень мало.
Как будто я говорил что-то против этого.
·>И вообще того не стоит того, если учесть усложнение системы типов и различного кода, особенно библиотечного.
Для безруких идиотов, не отличающих одно от другого, возможно.
·>Ну да const на объекте — мамой клянусь. В чём твоё возражение-то?
Перечитайте разговор. Здесь было множество примеров того, как компилятор бьет по рукам при наличии const.
Даже если встать на откровенно идиотскую точку зрения (т.е. вашу) о том, что объявление const-объекта -- это уровень "мамой клянусь", то как только const на объекте появился, то далее компилятор начинает следить за работой с этим объектом. И это лучше, чем то, что вы вынуждены делать в Java.
s>> И, внезапно, константности и не будет. И это опять же будет разговор на совсем другую тему. ·>Ты так и не рассказал, как же она там _гарантированно_ появится?
Здравствуйте, so5team, Вы писали:
s> Да. Желание разработчика получить профит от наличия const в языке. Если разработчик умеет это делать. s> Да. Опыт и здравый смысл.
Т.е. "мамой клянус". Я знаю. Возражение-то в чём?
s> ·>Потому что ты понял, что сел в лужу с ссылками и указателями, которые вообще никаких полезных гарантий не дают. s> Звиздеть изволите. Ну или покажите хотя бы одно мое утверждение о том, что const ссылки/указатели дают гарантии.
Ок. То есть нет никаких гарантий, всё мамой клянус. На чём и порешим. Но тогда не требуй каких-то гарантий от других ЯП. А то, видите ли, ява ничего не гарантирует, зато в c++ молитва const позволяет писать правильный код.
s> ·>зато иммутабельные объекты — нужны и полезны, и тащатся и используются повсюду. s> Только вот в Java у вас нет никакой помощи от компилятора в их реализации.
У тебя опять память подводит. Есть final, record и даже sealed интерфейсы.
s> ·>Пользуйся на здоровье, это не меняет ответ на твой изначальный вопрос "как же можно обходиться без" — да очень легко и просто. s> Легко, просто, с ручным добавлением не дополнительных сущностей и гарантиями уровня "мамой клянусь". Да, все так.
Как и const. Всё верно.
s> ·>Ну да const на объекте — мамой клянусь. В чём твоё возражение-то? s> Перечитайте разговор. Здесь было множество примеров того, как компилятор бьет по рукам при наличии const.
И что? У тебя проблемы с логикой. Достаточно одного опровергающего примера и похрен на миллион подтверждающих.
s> Даже если встать на откровенно идиотскую точку зрения (т.е. вашу) о том, что объявление const-объекта -- это уровень "мамой клянусь", то как только const на объекте появился, то далее компилятор начинает следить за работой с этим объектом. И это лучше, чем то, что вы вынуждены делать в Java.
Ровно это же можно сделать с иммутабельными типами. Попробуй в функцию принимающую String запихать CharSequence.
s> ·>Ты так и не рассказал, как же она там _гарантированно_ появится? s> Примеры были показаны. Штудируйте матчасть.
Ты врёшь опять. В твоём примере показано, что необходимы: "Желание разработчика. Умение это делать. Опыт и здравый смысл". Гарантии не было.
Здравствуйте, ·, Вы писали:
s>> Да. Желание разработчика получить профит от наличия const в языке. Если разработчик умеет это делать. s>> Да. Опыт и здравый смысл. ·>Т.е. "мамой клянус". Я знаю. Возражение-то в чём?
В том, что в C++ есть возможность написать const для объекта. В Java нет.
s>> ·>Потому что ты понял, что сел в лужу с ссылками и указателями, которые вообще никаких полезных гарантий не дают. s>> Звиздеть изволите. Ну или покажите хотя бы одно мое утверждение о том, что const ссылки/указатели дают гарантии. ·>Ок.
Ок что? Где цитата, которая подтверждает, что я что-то утверждал или "что сел в лужу с ссылками и указателями"?
·>То есть нет никаких гарантий, всё мамой клянус.
Дяденька, вы реально настолько поехавший?
[[nodiscard]]
std::thread
launch_thread(const vector_of_string & v, int iterations) {
// Здесь компилятор запрещает модифицировать v.return std::thread{ [&v, iterations] {
// Здесь компилятор запрещает модифицировать v.
std::size_t l{};
for(int i=0; i < iterations; ++i) {
for(const auto & s :v) l += s.size();
}
std::cout << "iterations: " << iterations << ", l=" << l << std::endl;
}};
}
Попробуйте в этом коде просто так модифицировать v.
·>Но тогда не требуй каких-то гарантий от других ЯП.
Схерали?
·>А то, видите ли, ява ничего не гарантирует
Не гарантирует.
·>зато в c++ молитва const позволяет писать правильный код.
Да.
s>> ·>зато иммутабельные объекты — нужны и полезны, и тащатся и используются повсюду. s>> Только вот в Java у вас нет никакой помощи от компилятора в их реализации. ·>У тебя опять память подводит. Есть final, record и даже sealed интерфейсы.
Ну и как с помощью этого всего сделать из HashMap неизменяемый HashMap? Ну вот был HashMap, требуется сделать так, чтобы его модифицировать нельзя было.
·>Как и const. Всё верно.
Попробуйте заставить компилятор принять у вас такой код.
·>И что? У тебя проблемы с логикой. Достаточно одного опровергающего примера и похрен на миллион подтверждающих.
Хде, хде, блин, этот опровергающий пример? Пока ни одного не было. Были примеры с наличием const-ссылок, но отсутствием const-объектов.
·>Ровно это же можно сделать с иммутабельными типами.
Еще раз для клинических идиотов: дополнительные сущности, которые программист должен делать вручную (хоть и посредством IDE) без какого-либо контроля со стороны компилятора.
s>> ·>Ты так и не рассказал, как же она там _гарантированно_ появится? s>> Примеры были показаны. Штудируйте матчасть. ·>Ты врёшь опять.
Вы не сможете подтвердить это цитатами.
·>В твоём примере показано
Да, было показано:
int main() {
const vector_of_string immutable_data{ "Hello"s, "World"s }; // Все, гарантии появились.
Здравствуйте, so5team, Вы писали:
s> ·>Т.е. "мамой клянус". Я знаю. Возражение-то в чём? s> В том, что в C++ есть возможность написать const для объекта. В Java нет.
В java другие подходы для реализации ровно того же.
s> ·>Ок. s> Ок что? Где цитата, которая подтверждает, что я что-то утверждал или "что сел в лужу с ссылками и указателями"?
s> ·>То есть нет никаких гарантий, всё мамой клянус. s> Дяденька, вы реально настолько поехавший?
Где уж мне до вас, дяденька.
Thread
launch_thread(Iterable<String> v, int iterations) {
// Здесь компилятор запрещает модифицировать v.return new Thread(()-> {
// Здесь компилятор запрещает модифицировать v.var l = v.stream()
.limit(iterations)
.mapToInt(String::length)
.sum();
System.out.println("iterations: " + iterations + ", l=" + l);
});
}
Попробуйте этом коде просто так модифицировать v.
Да, там есть нюанс с Iterator, но это, к сожалению, исторический казус и плохое легаси. collections api в jdk не идеальный. Но это проблема конкретно JDK, а не ЯП.
s> ·>зато в c++ молитва const позволяет писать правильный код. s> Да.
Ок. Если тебе помогает, можешь молиться в сердце своём. А const в ЯП впендюривать не обязательно.
s> ·>У тебя опять память подводит. Есть final, record и даже sealed интерфейсы. s> Ну и как с помощью этого всего сделать из HashMap неизменяемый HashMap? Ну вот был HashMap, требуется сделать так, чтобы его модифицировать нельзя было.
Если в типе изначально не предусмотрена константность (не предусмотрены методы с const), то ты нихрена не сделаешь. В HashMap не предусмотрена константность.
Однако, объект HashMap можно сделать неизменяемым, например, с помощью Collections.unmodifiableMap.
s> ·>Как и const. Всё верно.
Для клинических идиотов повторю еще раз:
void mutate(ArrayList<String> v);
Iterable<String> immutable_value = new ArrayList<>(...);
mutate(immutable_value);
Попробуйте заставить компилятор принять у вас такой код.
s> ·>И что? У тебя проблемы с логикой. Достаточно одного опровергающего примера и похрен на миллион подтверждающих. s> Хде, хде, блин, этот опровергающий пример? Пока ни одного не было. Были примеры с наличием const-ссылок, но отсутствием const-объектов.
Именно. И это никак компилятором не проверяется. Всё на честном слове — не забыл (не смог, т.к. его надо было собрать из кусочков, например) поставить const на объекте — сработает. Не смог — не сработает. И компилятор будет молчать.
s> ·>Ровно это же можно сделать с иммутабельными типами. s> Еще раз для клинических идиотов: дополнительные сущности, которые программист должен делать вручную (хоть и посредством IDE) без какого-либо контроля со стороны компилятора.
Описывать const-методы программист тоже должен делать вручную. Т.е. решить какие вещи в данном типе могут, а какие не могут быть const.
s> ·>В твоём примере показано s> Да, было показано: s>
s> int main() {
s> const vector_of_string immutable_data{ "Hello"s, "World"s }; // Все, гарантии появились.
s>
Вопрос был: "как же константность объекта там _гарантированно_ появится?" Откуда в данной строчке будет гарантированно стоять модификатор const?
Здравствуйте, ·, Вы писали:
s>> ·>Т.е. "мамой клянус". Я знаю. Возражение-то в чём? s>> В том, что в C++ есть возможность написать const для объекта. В Java нет. ·>В java другие подходы для реализации ровно того же.
Как будто с вами кто-то спорил на тему того такие же они или нет. Мои тезисы касательно Java таковы:
a) требуется вводить новую сущность, интерфейс, который предоставляет read-only доступ к объекту и это не есть хорошо, т.к. это дополнительная (и по сути не нужная) сущность в программе, с которой программисту нужно иметь дело.
Ваши возражения (насколько я их запомнил):
— то, что дополнительная -- не проблема;
— создавать ее дешево за счет помощи IDE.
b) в реализации этой новой сущности со стороны языка нет никакого контроля за тем, выполняются ли там модификации состояния объекта или нет.
Ваши возражения (насколько я их запомнил):
— такого не бывает (у вас по крайней мере);
— есть final и records.
Мой контр-тезис по поводу второго возражения: final бесполезен если поле не value type, в общем, это для частных случаев, а не защита от модификации в общем.
Соответственно, я просто заключаю, что в C++ с const есть больше помощи со стороны собственно языка, чем в Java. Что хорошо и, как по мне, сильно лучше, чем в Java.
При этом я нигде не утверждал, что подход из C++ самый лучший. Напротив, говорил, что в Rust и D пошли еще дальше, и это хорошо, т.к. там смогли учесть опыт C++.
s>> Ок что? Где цитата, которая подтверждает, что я что-то утверждал или "что сел в лужу с ссылками и указателями"?
Таки что с цитатами?
·>Попробуйте этом коде просто так модифицировать v.
Т.е. const в C++ настолько плох, что вы не смогли модифицировать C++ный пример и были вынуждены переводить стрелки на Java.
s>> ·>У тебя опять память подводит. Есть final, record и даже sealed интерфейсы. s>> Ну и как с помощью этого всего сделать из HashMap неизменяемый HashMap? Ну вот был HashMap, требуется сделать так, чтобы его модифицировать нельзя было. ·>Если в типе изначально не предусмотрена константность (не предусмотрены методы с const), то ты нихрена не сделаешь.
Я все равно смогу объявить экземпляр этого типа как const. Насколько это будет полезно (возможно и будет, т.к. хотя бы указатели на него можно будет использовать) -- это второй вопрос. Но я любой тип могу использовать как const. И это делается средствами языка, а не приседаниями разработчика.
В этом так же принципиальное отличие C++ от Java. В лучшую сторону.
·>В HashMap не предусмотрена константность.
О том и речь.
·>Однако, объект HashMap можно сделать неизменяемым, например, с помощью Collections.unmodifiableMap.
И в compile-time никакой помощи от компилятора не будет.
Но да, она же вам и не нужна, проссыте великодушно.
·>Попробуйте заставить компилятор принять у вас такой код.
Т.е. const в C++ настолько плох, что вы не смогли модифицировать C++ный пример и были вынуждены переводить стрелки на Java.
И это не говоря о том, что вообще-то в C++ vector остается vector-ом с его методами data, at и operator(), тогда как приводя вектор к Iterable в Java вы теряете часть доступных методов.
s>> ·>И что? У тебя проблемы с логикой. Достаточно одного опровергающего примера и похрен на миллион подтверждающих. s>> Хде, хде, блин, этот опровергающий пример? Пока ни одного не было. Были примеры с наличием const-ссылок, но отсутствием const-объектов. ·>Именно. И это никак компилятором не проверяется. Всё на честном слове — не забыл (не смог, т.к. его надо было собрать из кусочков, например) поставить const на объекте — сработает. Не смог — не сработает. И компилятор будет молчать.
Мне что, нужно в очередной раз повторить, что const&/const* в C++ ничего не говорит о константности исходного объекта?
const&/const* имеют к константности только то отношение, что это единственный легальный способ ссылаться на const-объект. И если нам нужна именно константность, то говорить следует именно о const для объектов, а не о const&/const*.
Примеры когда const для объекта не обеспечивает константность приводить можно и это не сложно (даже без mutable). Кроме того, в C++ с const связаны и другие проблемы (контроль времени жизни, к примеру).
Однако, даже по совокупности, лично я никак не могу согласиться с тем, что от const в C++ мало толку.
·>Описывать const-методы программист тоже должен делать вручную. Т.е. решить какие вещи в данном типе могут, а какие не могут быть const.
Да, это часть работы по проектированию типа.
·> Вопрос был: "как же константность объекта там _гарантированно_ появится?" Откуда в данной строчке будет гарантированно стоять модификатор const?
Для клинических идиотов: не смысла обсуждать вероятность того, что сделает, а чего не сделает пользователь когда речь заходит о возможностях языка. Зато смысл есть обсуждать последствия того, что сделал или не сделал пользователь.
Вот, например, почему-то никто не стремится обсуждать вероятность того, что пользователь ошибется при вычислении значения i перед выполнением операции v[i]. И это правильно, т.к. вероятность совершения ошибки таки есть. Поэтому разумнее сосредоточиться на обсуждении последствий. И в C++ они фатальнее, чем в Java. В этом важное отличие между языками.
Аналогично и с const. Если программист не объявил объект как const, то константности у него нет. Поэтому и нет смысла обсуждать какие-то гарантии со стороны компилятора, ибо их нет.
А вот если программист таки const использовал, вот тогда есть смысл рассуждать о том, что гарантирует компилятор, что не гарантирует и насколько этому const-у можно доверять вообще.
Так что вопрос "как же константность объекта там _гарантированно_ появится?" идет прямиком в /dev/null как в силу своего идиотизма, так и из-за бесполезности.
Re[79]: Когда это наконец станет defined behavior?
Здравствуйте, so5team, Вы писали:
s>>> В том, что в C++ есть возможность написать const для объекта. В Java нет. S>·>В java другие подходы для реализации ровно того же. S>Как будто с вами кто-то спорил на тему того такие же они или нет. Мои тезисы касательно Java таковы: S>a) требуется вводить новую сущность, интерфейс, который предоставляет read-only доступ к объекту и это не есть хорошо, т.к. это дополнительная (и по сути не нужная) сущность в программе, с которой программисту нужно иметь дело.
Нет _новой_ сущности. Модификатор тоже неявно создаёт новый тип. Вместо неявного типа "const X" делается явный тип "ConstX".
S>Ваши возражения (насколько я их запомнил): S>- то, что дополнительная -- не проблема;
Нет. Главное возражение — что сущность не дополнительная, а ровно та же, но выраженная другим способом через другие средства ЯП.
Проблема const — это интрузивность. Это усложняет и так непростую систему типов. С другой стороны это частный случай определённого аспекта дизайна.
S>- создавать ее дешево за счет помощи IDE.
Это да. Если набирать всё дело в notepad, то придётся нажать больше кнопок. Тут согласен. Но я давно не набирал код в notepad. Поэтому проблема некритичная совершенно.
S>b) в реализации этой новой сущности со стороны языка нет никакого контроля за тем, выполняются ли там модификации состояния объекта или нет. S>Ваши возражения (насколько я их запомнил): S>- такого не бывает (у вас по крайней мере);
Мы рассмотрели твой пример с твоим chunk и там выяснилось, что const даже если бы и был, в java некуда было бы пристроить. Он там просто не нужен.
S>- есть final и records.
Верно. И они относятся к более полезной идее — иммутабельность, а не константность.
S>Мой контр-тезис по поводу второго возражения: final бесполезен если поле не value type, в общем, это для частных случаев, а не защита от модификации в общем.
Ровно настолько же бесполезен, как и const :
struct C
{
std::string *s = new std::string("hi");
const std::string &val() const {return *s;}
};
int main()
{
const C c;
std::cout << c.val() << std::endl;
*c.s = "bye";
std::cout << c.val() << std::endl;
}
, который ты жаве ставил в упрёк? Объект константный, а "модифицировать в общем" можно!
Мой тезис в том, что концепция const и уж тем более реализованная как в плюсах — очень спорной полезности. И в других ЯП уж точно не нужна. У меня есть даже сомнения в её полезности в самих плюсах, но уже не считаю себя экспертом по плюсам, т.к. уж лет 10 на нём не писал.
S>Соответственно, я просто заключаю, что в C++ с const есть больше помощи со стороны собственно языка, чем в Java. Что хорошо и, как по мне, сильно лучше, чем в Java.
Угу. Но он решает несущественную проблему. Эта же проблема с такими же усилиями решается другими, более универсальными средствами.
Конечно, есть небольшое пенальти за универсальность — чуть буковок больше в некоторых случаях (а в реальном проекте разницу и в микроскоп не разглядишь), но и собственно всё.
S>При этом я нигде не утверждал, что подход из C++ самый лучший. Напротив, говорил, что в Rust и D пошли еще дальше, и это хорошо, т.к. там смогли учесть опыт C++.
А некоторые пошли другим путём и выкинули константность вообще. Чем плохо-то?
s>>> Ок что? Где цитата, которая подтверждает, что я что-то утверждал или "что сел в лужу с ссылками и указателями"? S>Таки что с цитатами?
Не цитаты, а в целом тезисы которые ты выдвигаешь. Константность ссылкок-указателей элементарно заменяется интерфейсом, тут вообще неясно почему ты задал такой вопрос изначально. А константность объектов, на которую ты перешел — не заслуга компилятора, а средство, которое требует усилия и опыт программиста.
S>·>Попробуйте этом коде просто так модифицировать v. S>Т.е. const в C++ настолько плох, что вы не смогли модифицировать C++ный пример и были вынуждены переводить стрелки на Java.
Он плох в том, что он просто нахрен не нужен как лишняя фича ЯП, т.к. ровно то же делается на уже существующей концепции интерфейсов, которая более мощная и универсальная, делает const ссылкок-указателей тупо ненужным.
s>>> ·>У тебя опять память подводит. Есть final, record и даже sealed интерфейсы. s>>> Ну и как с помощью этого всего сделать из HashMap неизменяемый HashMap? Ну вот был HashMap, требуется сделать так, чтобы его модифицировать нельзя было. S>·>Если в типе изначально не предусмотрена константность (не предусмотрены методы с const), то ты нихрена не сделаешь. S>Я все равно смогу объявить экземпляр этого типа как const. Насколько это будет полезно (возможно и будет, т.к. хотя бы указатели на него можно будет использовать) -- это второй вопрос. Но я любой тип могу использовать как const. И это делается средствами языка, а не приседаниями разработчика.
Для тебя второй вопрос. Для меня — основной. Накой переусложнять ЯП, ради сомнительной околонулевой полезности.
S>В этом так же принципиальное отличие C++ от Java. В лучшую сторону.
Лучшесть — понятие относительное. Java нарочно делали языком простым, как можно проще, но не проще. Если тебе надо кучу фич и концептов, бери какую-нибудь Скалу, на той же платформе.
S>·>В HashMap не предусмотрена константность. S>О том и речь.
Ну тип такой. В чём возражение-то? В плюсах тоже можно написать тип и не предусмотреть константность. Это как-то повлияет на хорошесть плюсов?
S>·>Однако, объект HashMap можно сделать неизменяемым, например, с помощью Collections.unmodifiableMap. S>И в compile-time никакой помощи от компилятора не будет. S>Но да, она же вам и не нужна, проссыте великодушно.
Это особенности реализации конкретного api. Можно найти или реализовать свою библиотеку коллекций, если очень так хочется.
Скажем, в том же C# (который очень похож на java) сделали то что ты хочешь без всяких const, в фреймворке есть набор RO-интерфейсов. Например, List так же реализует IReadOnlyList. А так же есть ImmutableList. Т.е. и иммутабельность есть, и константность, и никакой встроенный в ЯП const нафиг не сдался. Т.е. это вопрос дизайна API и конкретных типов, а не наличия определённой фичи в ЯП.
S>·>Попробуйте заставить компилятор принять у вас такой код. S>Т.е. const в C++ настолько плох, что вы не смогли модифицировать C++ный пример и были вынуждены переводить стрелки на Java.
Я не понял как ты хотел чтобы я что-то модифицировал и с какой целью. Я привёл как аналгичный трюк const достигается без const, без использования специальных фич ЯП.
S>И это не говоря о том, что вообще-то в C++ vector остается vector-ом с его методами data, at и operator(), тогда как приводя вектор к Iterable в Java вы теряете часть доступных методов.
Это недостаток collections api в jdk, а не Java. Впрочем достать произвольный элемент всё ещё можно через skip/limit. В том же шарпе такой проблемы нет и const нет. Т.е. для реализации того что ты хочешь — const не нужен. Это надо блин просто взять и реализовать.
s>>> Хде, хде, блин, этот опровергающий пример? Пока ни одного не было. Были примеры с наличием const-ссылок, но отсутствием const-объектов. S>·>Именно. И это никак компилятором не проверяется. Всё на честном слове — не забыл (не смог, т.к. его надо было собрать из кусочков, например) поставить const на объекте — сработает. Не смог — не сработает. И компилятор будет молчать. S>Мне что, нужно в очередной раз повторить, что const&/const* в C++ ничего не говорит о константности исходного объекта?
Ну да. И это — проблема.
S>const&/const* имеют к константности только то отношение, что это единственный легальный способ ссылаться на const-объект. И если нам нужна именно константность, то говорить следует именно о const для объектов, а не о const&/const*.
Вопрос-то — а нужна ли нам константность объектов в принципе. Я считаю, что иммутабельность нужна, константность — нет. И это делается через List/ImmutableList/IReadOnlyList без каких-либо дополнительных фич в ЯП.
S>Примеры когда const для объекта не обеспечивает константность приводить можно и это не сложно (даже без mutable). Кроме того, в C++ с const связаны и другие проблемы (контроль времени жизни, к примеру). S>Однако, даже по совокупности, лично я никак не могу согласиться с тем, что от const в C++ мало толку.
Возможно, пусть так. Однако твой вопрос был о толке const в других ЯП.
S>·>Описывать const-методы программист тоже должен делать вручную. Т.е. решить какие вещи в данном типе могут, а какие не могут быть const. S>Да, это часть работы по проектированию типа.
Именно. По сути ты проектируешь пару типов — const/non-const. Всё то же, никаких дополнительных сущностей, как ты заявил выше.
S>·> Вопрос был: "как же константность объекта там _гарантированно_ появится?" Откуда в данной строчке будет гарантированно стоять модификатор const? S>Для клинических идиотов: не смысла обсуждать вероятность того, что сделает, а чего не сделает пользователь когда речь заходит о возможностях языка. Зато смысл есть обсуждать последствия того, что сделал или не сделал пользователь.
Вопрос стоял в том как же с помощью const _гарантированно_ защитить данные, которые передаются другим тредам. Как выяснилось — да никак, это лежит на совести и внимательности программиста: создал и передал константный объект — молодец, создал неконстантный объект, но не модифицировал — тоже молодец, а помодицифировал, ну сам виноват. Помощь от компилятора — нулевая. Полный эквивалент List+IReadOnlyList.
Решение только — использовать иммутабельные данные: если другой тред берёт тип ImmutableList, то у тебя 100% гарантия, проверяемая компилятором, что данные не поменяются. Ну или borrow checker.
Т.е. const объект не даёт никакой проверяемой компилятором защиты и в этом случае, только мамойклянус работает.
S>Вот, например, почему-то никто не стремится обсуждать вероятность того, что пользователь ошибется при вычислении значения i перед выполнением операции v[i]. И это правильно, т.к. вероятность совершения ошибки таки есть. Поэтому разумнее сосредоточиться на обсуждении последствий. И в C++ они фатальнее, чем в Java. В этом важное отличие между языками.
А мы не о вероятностях. А о том, что именно даёт конкретная фича ЯП. Пока выяснилось, что константный объект даёт лишь локальную защиту локальной переменной внутри метода. И собственно всё. Что можно сделать, например, вот так:
IReadOnlyList myConstList = new List(...);
S>Аналогично и с const. Если программист не объявил объект как const, то константности у него нет. Поэтому и нет смысла обсуждать какие-то гарантии со стороны компилятора, ибо их нет.
Моё мнение — практической пользы — маловато будет. Пусть это останется вкусовыми предпочтениями.
S>А вот если программист таки const использовал, вот тогда есть смысл рассуждать о том, что гарантирует компилятор, что не гарантирует и насколько этому const-у можно доверять вообще.
В чём разница-то с правильным выбором типов List/ImmutableList/IReadOnlyList?
S>Так что вопрос "как же константность объекта там _гарантированно_ появится?" идет прямиком в /dev/null как в силу своего идиотизма, так и из-за бесполезности.
Ну вот с иммутабельностью этот вопрос почему-то даже не появляется, внезапно. Иммутабельность — полезный концепт, т.к. действительно даёт полезные гарантии.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
, который ты жаве ставил в упрёк? Объект константный, а "модифицировать в общем" можно!
Да ознакомьтесь вы уже наконец с матчастью! Вам от незнания константы мерещатся там, где их нет, что приводит к дурацким утверждениям с вашей стороны, комментировать которые цензурно уже просто невозможно.
В чём поинт-то?
