Сообщение Re[77]: Когда это наконец станет defined behavior? от 16.05.2023 16:55
Изменено 16.05.2023 16:56 ·
Re[77]: Когда это наконец станет defined behavior?
Здравствуйте, so5team, Вы писали:
s> ·>Т.е. "мамой клянус". Я знаю. Возражение-то в чём?
s> В том, что в C++ есть возможность написать const для объекта. В Java нет.
В java другие подходы для реализации ровно того же.
s> ·>Ок.
s> Ок что? Где цитата, которая подтверждает, что я что-то утверждал или "что сел в лужу с ссылками и указателями"?
s> ·>То есть нет никаких гарантий, всё мамой клянус.
s> Дяденька, вы реально настолько поехавший?
Где уж мне до вас, дяденька.
Попробуйте этом коде просто так модифицировать 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. Всё верно.
Для клинических идиотов повторю еще раз:
Попробуйте заставить компилятор принять у вас такой код.
s> ·>И что? У тебя проблемы с логикой. Достаточно одного опровергающего примера и похрен на миллион подтверждающих.
s> Хде, хде, блин, этот опровергающий пример? Пока ни одного не было. Были примеры с наличием const-ссылок, но отсутствием const-объектов.
Именно. И это никак компилятором не проверяется. Всё на честном слове — не забыл (не смог, т.к. его надо было собрать из кусочков, например) поставить const на объекте — сработает. Не смог — не сработает. И компилятор будет молчать.
s> ·>Ровно это же можно сделать с иммутабельными типами.
s> Еще раз для клинических идиотов: дополнительные сущности, которые программист должен делать вручную (хоть и посредством IDE) без какого-либо контроля со стороны компилятора.
Описывать const-методы программист тоже должен делать вручную. Т.е. решить какие вещи в данном типе могут, а какие не могут быть const.
s> ·>В твоём примере показано
s> Да, было показано:
s>
Вопрос был: "как же константность объекта там _гарантированно_ появится?" Откуда в данной строчке будет гарантированно стоять модификатор const?
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>Re[77]: Когда это наконец станет defined behavior?
Здравствуйте, so5team, Вы писали:
s> ·>Т.е. "мамой клянус". Я знаю. Возражение-то в чём?
s> В том, что в C++ есть возможность написать const для объекта. В Java нет.
В java другие подходы для реализации ровно того же.
s> ·>Ок.
s> Ок что? Где цитата, которая подтверждает, что я что-то утверждал или "что сел в лужу с ссылками и указателями"?
s> ·>То есть нет никаких гарантий, всё мамой клянус.
s> Дяденька, вы реально настолько поехавший?
Где уж мне до вас, дяденька.
Попробуйте этом коде просто так модифицировать 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. Всё верно.
Для клинических идиотов повторю еще раз:
Попробуйте заставить компилятор принять у вас такой код.
s> ·>И что? У тебя проблемы с логикой. Достаточно одного опровергающего примера и похрен на миллион подтверждающих.
s> Хде, хде, блин, этот опровергающий пример? Пока ни одного не было. Были примеры с наличием const-ссылок, но отсутствием const-объектов.
Именно. И это никак компилятором не проверяется. Всё на честном слове — не забыл (не смог, т.к. его надо было собрать из кусочков, например) поставить const на объекте — сработает. Не смог — не сработает. И компилятор будет молчать.
s> ·>Ровно это же можно сделать с иммутабельными типами.
s> Еще раз для клинических идиотов: дополнительные сущности, которые программист должен делать вручную (хоть и посредством IDE) без какого-либо контроля со стороны компилятора.
Описывать const-методы программист тоже должен делать вручную. Т.е. решить какие вещи в данном типе могут, а какие не могут быть const.
s> ·>В твоём примере показано
s> Да, было показано:
s>
Вопрос был: "как же константность объекта там _гарантированно_ появится?" Откуда в данной строчке будет гарантированно стоять модификатор const?
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>