Сообщение Re[62]: Когда это наконец станет defined behavior? от 15.05.2023 12:05
Изменено 15.05.2023 12:11 so5team
Re[62]: Когда это наконец станет defined behavior?
Здравствуйте, ·, Вы писали:
S>>Ну я то наслышан и о том, как оно в C++, и как оно в D. Это вы здесь пытаетесь лепить горбатого.
·>Но слушать не хочешь как в других яп.
Это вы про Java во множественном числе?
Так я программировал на Java (за деньги, т.е. профессионально), так что слегка наслышан тоже.
·>А вот ты и знать не хочешь
Сударь, у вас проблемы с квантором всеобщности. Вы говорили, что будут проблемы при переименовании. Я же не говорил, что их не будет. Я говорил о том, что их может и не быть. И таки да, во многих случаях простой search&replace работает без проблем.
S>>Еще как играет. Константного объекта нет.
·>Если бы и был, проблему не решает.
Какую такую проблему?
S>>>>Во-первых, могу передать по значению.
S>>·>Ох, да. Я забыл. "Память — не ресурс!" — девиз С++. Я ничего не попутал?
S>>Попутали и много чего. Берега в первую очередь. Как и здравый смысл.
·>Так всё-таки. Не съезжай темы. Как _сам_ константный объект куда-нибудь передать?
Темы передать константный объект и не было, это вы по ходу выдумали. Я говорил, что константный объект можно расшарить между тредами как пример.
Да, расшарить можно по константной ссылке. Если у вас константные ссылки вызывают проблемы, то я не виноват.
·>Именно. Лучшее что можно сделать с константным объектом — иметь его внутри одного метода и никуда больше.
Ох, ё. Хватит уже позориться.
·>Увидеть что объект меняется в пределах одного метода — легко.
Не всегда.
·>Зато цена этого — значительное усложнеие всего яп и кода.
Ох, ё. Ох, ё. Да const -- это одна из вещей, которая делает программирование не C++ проще. Может быть научиться пользоваться const-ом для кого-то сложно. Но, как показывает (мой) опыт, научить людей понимать указатели (да и ссылки тоже) бывает куда сложнее.
·>Я сказал конкретно: "Ты без ссылок твой константный объект даже как параметр не сможешь никуда передать, а значит толку в таком объекте мало.". Ты начал говорить про defensive copy и "неконстантные объекты". Зачем мне такое образование в софизмах?
Ну что мне делать, если вы выдвигаете идиотский тезис "Ты без ссылок твой константный объект даже как параметр не сможешь никуда передать, а значит толку в таком объекте мало." и требуете от меня ведения дискуссии в рамках этой откровенной идиотии?
Для вас толку мало, OK, это зафиксировано. Вот только за всех не следует говорить.
·>Какие _новые_?
В C++ у нас был MyApplicationType с const и non-const методами. В случае `MyApplicationType&` и `const MyApplicationType&` мы все еще имеем один и тот же тип, но с разными органичениями.
В Java у нас был MyApplicationType, затем к нему добавились MyApplicationTypeMutableIface и MyApplicationTypeImmutableIface. Никаких новых сущностей, ага. Шило на мыло, понятненько.
·>А что ты подразумевал под some_application_domain_type? Пример приведи, где там будет const/non-const?
Да вот, хотя бы: https://github.com/Stiffstream/arataga/blob/master/arataga/acl_handler/first_chunk.hpp#L123-L168
·>Причём тут именование? У record именование будет просто x(). Обязан как следсвтие иммутабелности — если состояние не меняется, то оно неразличимо в любой момент времени.
Еще раз: у вас есть объект o, у которого вы вызываете метод getX. Схерали метод getX должен иметь непосредственное отношение к состоянию объекта o?
·>Я думал, что ты уже понял, что ровно той же константности, что есть плюсах в java нет.
Могу предположить, я об этом узнал задолго до того, как вы перешли с C++ на Java, года эдак с 1998-го.
·>Есть практические задачи и механизмы их решения.
Например, есть ссылка на Map и нужно понять, можно ее менять или нет.
·>Так ведь всё то же самое:
·>
·>А с многопоточкой так ещё хуже.
Не обязательно. It depends.
·>Так что иммутабельность — нужна, ибо решает вполне серьёзные проблемы. Константность — не нужна.
Вы еще не поняли, что иммутабельность можно пытаться обеспечить разными способами. Можно врукопашную, как в Java, когда у вас все на честном слове. Можно с помощью средств языка. В C++ таковыми являются const. Можно научиться использовать const себе во благо. А можно убеждать себя, что и без const можно жить. Можно, кто ж спорит. Но лучше с const
·>Как выяснили константный объект невозможно передать между тредами.
Ох, ё, три раза.
·>А вы хамите в очередной раз.
А вы тупить перестаньте.
S>>Ну я то наслышан и о том, как оно в C++, и как оно в D. Это вы здесь пытаетесь лепить горбатого.
·>Но слушать не хочешь как в других яп.
Это вы про Java во множественном числе?
Так я программировал на Java (за деньги, т.е. профессионально), так что слегка наслышан тоже.
·>А вот ты и знать не хочешь
Сударь, у вас проблемы с квантором всеобщности. Вы говорили, что будут проблемы при переименовании. Я же не говорил, что их не будет. Я говорил о том, что их может и не быть. И таки да, во многих случаях простой search&replace работает без проблем.
S>>Еще как играет. Константного объекта нет.
·>Если бы и был, проблему не решает.
Какую такую проблему?
S>>>>Во-первых, могу передать по значению.
S>>·>Ох, да. Я забыл. "Память — не ресурс!" — девиз С++. Я ничего не попутал?
S>>Попутали и много чего. Берега в первую очередь. Как и здравый смысл.
·>Так всё-таки. Не съезжай темы. Как _сам_ константный объект куда-нибудь передать?
Темы передать константный объект и не было, это вы по ходу выдумали. Я говорил, что константный объект можно расшарить между тредами как пример.
Да, расшарить можно по константной ссылке. Если у вас константные ссылки вызывают проблемы, то я не виноват.
·>Именно. Лучшее что можно сделать с константным объектом — иметь его внутри одного метода и никуда больше.
Ох, ё. Хватит уже позориться.
·>Увидеть что объект меняется в пределах одного метода — легко.
Не всегда.
·>Зато цена этого — значительное усложнеие всего яп и кода.
Ох, ё. Ох, ё. Да const -- это одна из вещей, которая делает программирование не C++ проще. Может быть научиться пользоваться const-ом для кого-то сложно. Но, как показывает (мой) опыт, научить людей понимать указатели (да и ссылки тоже) бывает куда сложнее.
·>Я сказал конкретно: "Ты без ссылок твой константный объект даже как параметр не сможешь никуда передать, а значит толку в таком объекте мало.". Ты начал говорить про defensive copy и "неконстантные объекты". Зачем мне такое образование в софизмах?
Ну что мне делать, если вы выдвигаете идиотский тезис "Ты без ссылок твой константный объект даже как параметр не сможешь никуда передать, а значит толку в таком объекте мало." и требуете от меня ведения дискуссии в рамках этой откровенной идиотии?
Для вас толку мало, OK, это зафиксировано. Вот только за всех не следует говорить.
·>Какие _новые_?
В C++ у нас был MyApplicationType с const и non-const методами. В случае `MyApplicationType&` и `const MyApplicationType&` мы все еще имеем один и тот же тип, но с разными органичениями.
В Java у нас был MyApplicationType, затем к нему добавились MyApplicationTypeMutableIface и MyApplicationTypeImmutableIface. Никаких новых сущностей, ага. Шило на мыло, понятненько.
·>А что ты подразумевал под some_application_domain_type? Пример приведи, где там будет const/non-const?
Да вот, хотя бы: https://github.com/Stiffstream/arataga/blob/master/arataga/acl_handler/first_chunk.hpp#L123-L168
·>Причём тут именование? У record именование будет просто x(). Обязан как следсвтие иммутабелности — если состояние не меняется, то оно неразличимо в любой момент времени.
Еще раз: у вас есть объект o, у которого вы вызываете метод getX. Схерали метод getX должен иметь непосредственное отношение к состоянию объекта o?
·>Я думал, что ты уже понял, что ровно той же константности, что есть плюсах в java нет.
Могу предположить, я об этом узнал задолго до того, как вы перешли с C++ на Java, года эдак с 1998-го.
·>Есть практические задачи и механизмы их решения.
Например, есть ссылка на Map и нужно понять, можно ее менять или нет.
·>Так ведь всё то же самое:
·>
·>void some(const std::map<..> &data)
·>{
·> validateData(data);
·> callSomething();// были ли тут вызваны мутирующие методы data? Разбирайся в run-time
Не должно их там было быть. Если кто-то внутри воспользовался const_cast-ом, то с почти 100% вероятностью это ошибка.
·>}
·>·>А с многопоточкой так ещё хуже.
Не обязательно. It depends.
·>Так что иммутабельность — нужна, ибо решает вполне серьёзные проблемы. Константность — не нужна.
Вы еще не поняли, что иммутабельность можно пытаться обеспечить разными способами. Можно врукопашную, как в Java, когда у вас все на честном слове. Можно с помощью средств языка. В C++ таковыми являются const. Можно научиться использовать const себе во благо. А можно убеждать себя, что и без const можно жить. Можно, кто ж спорит. Но лучше с const
·>Как выяснили константный объект невозможно передать между тредами.
Ох, ё, три раза.
·>А вы хамите в очередной раз.
А вы тупить перестаньте.
Re[62]: Когда это наконец станет defined behavior?
Здравствуйте, ·, Вы писали:
S>>Ну я то наслышан и о том, как оно в C++, и как оно в D. Это вы здесь пытаетесь лепить горбатого.
·>Но слушать не хочешь как в других яп.
Это вы про Java во множественном числе?
Так я программировал на Java (за деньги, т.е. профессионально), так что слегка наслышан тоже.
·>А вот ты и знать не хочешь
Сударь, у вас проблемы с квантором всеобщности. Вы говорили, что будут проблемы при переименовании. Я же не говорил, что их не будет. Я говорил о том, что их может и не быть. И таки да, во многих случаях простой search&replace работает без проблем.
S>>Еще как играет. Константного объекта нет.
·>Если бы и был, проблему не решает.
Какую такую проблему?
S>>>>Во-первых, могу передать по значению.
S>>·>Ох, да. Я забыл. "Память — не ресурс!" — девиз С++. Я ничего не попутал?
S>>Попутали и много чего. Берега в первую очередь. Как и здравый смысл.
·>Так всё-таки. Не съезжай темы. Как _сам_ константный объект куда-нибудь передать?
Темы передать константный объект и не было, это вы по ходу выдумали. Я говорил, что константный объект можно расшарить между тредами как пример.
Да, расшарить можно по константной ссылке. Если у вас константные ссылки вызывают проблемы, то я не виноват.
·>Именно. Лучшее что можно сделать с константным объектом — иметь его внутри одного метода и никуда больше.
Ох, ё. Хватит уже позориться.
·>Увидеть что объект меняется в пределах одного метода — легко.
Не всегда.
·>Зато цена этого — значительное усложнеие всего яп и кода.
Ох, ё. Ох, ё. Да const -- это одна из вещей, которая делает программирование не C++ проще. Может быть научиться пользоваться const-ом для кого-то сложно. Но, как показывает (мой) опыт, научить людей понимать указатели (да и ссылки тоже) бывает куда сложнее.
·>Я сказал конкретно: "Ты без ссылок твой константный объект даже как параметр не сможешь никуда передать, а значит толку в таком объекте мало.". Ты начал говорить про defensive copy и "неконстантные объекты". Зачем мне такое образование в софизмах?
Ну что мне делать, если вы выдвигаете идиотский тезис "Ты без ссылок твой константный объект даже как параметр не сможешь никуда передать, а значит толку в таком объекте мало." и требуете от меня ведения дискуссии в рамках этой откровенной идиотии?
Для вас толку мало, OK, это зафиксировано. Вот только за всех не следует говорить.
·>Какие _новые_?
В C++ у нас был MyApplicationType с const и non-const методами. В случае `MyApplicationType&` и `const MyApplicationType&` мы все еще имеем один и тот же тип, но с разными органичениями.
В Java у нас был MyApplicationType, затем к нему добавились MyApplicationTypeMutableIface и MyApplicationTypeImmutableIface. Никаких новых сущностей, ага. Шило на мыло, понятненько.
·>А что ты подразумевал под some_application_domain_type? Пример приведи, где там будет const/non-const?
Да вот, хотя бы: https://github.com/Stiffstream/arataga/blob/master/arataga/acl_handler/first_chunk.hpp#L123-L168
·>Причём тут именование? У record именование будет просто x(). Обязан как следсвтие иммутабелности — если состояние не меняется, то оно неразличимо в любой момент времени.
Еще раз: у вас есть объект o, у которого вы вызываете метод getX. Схерали метод getX должен иметь непосредственное отношение к состоянию объекта o?
·>Я думал, что ты уже понял, что ровно той же константности, что есть плюсах в java нет.
Могу предположить, я об этом узнал задолго до того, как вы перешли с C++ на Java, года эдак с 1998-го.
·>Есть практические задачи и механизмы их решения.
Например, есть ссылка на Map и нужно понять, можно ее менять или нет.
·>Так ведь всё то же самое:
·>void some(const std::map<..> &data)
·>{
·> validateData(data);
·> callSomething();// были ли тут вызваны мутирующие методы data? Разбирайся в run-time
Вы опять путаете теплое с мягким. Это некорректное сравнение.
Сравнивать нужно:
·>А с многопоточкой так ещё хуже.
Не обязательно. It depends.
·>Так что иммутабельность — нужна, ибо решает вполне серьёзные проблемы. Константность — не нужна.
Вы еще не поняли, что иммутабельность можно пытаться обеспечить разными способами. Можно врукопашную, как в Java, когда у вас все на честном слове. Можно с помощью средств языка. В C++ таковыми являются const. Можно научиться использовать const себе во благо. А можно убеждать себя, что и без const можно жить. Можно, кто ж спорит. Но лучше с const
·>Как выяснили константный объект невозможно передать между тредами.
Ох, ё, три раза.
·>А вы хамите в очередной раз.
А вы тупить перестаньте.
S>>Ну я то наслышан и о том, как оно в C++, и как оно в D. Это вы здесь пытаетесь лепить горбатого.
·>Но слушать не хочешь как в других яп.
Это вы про Java во множественном числе?
Так я программировал на Java (за деньги, т.е. профессионально), так что слегка наслышан тоже.
·>А вот ты и знать не хочешь
Сударь, у вас проблемы с квантором всеобщности. Вы говорили, что будут проблемы при переименовании. Я же не говорил, что их не будет. Я говорил о том, что их может и не быть. И таки да, во многих случаях простой search&replace работает без проблем.
S>>Еще как играет. Константного объекта нет.
·>Если бы и был, проблему не решает.
Какую такую проблему?
S>>>>Во-первых, могу передать по значению.
S>>·>Ох, да. Я забыл. "Память — не ресурс!" — девиз С++. Я ничего не попутал?
S>>Попутали и много чего. Берега в первую очередь. Как и здравый смысл.
·>Так всё-таки. Не съезжай темы. Как _сам_ константный объект куда-нибудь передать?
Темы передать константный объект и не было, это вы по ходу выдумали. Я говорил, что константный объект можно расшарить между тредами как пример.
Да, расшарить можно по константной ссылке. Если у вас константные ссылки вызывают проблемы, то я не виноват.
·>Именно. Лучшее что можно сделать с константным объектом — иметь его внутри одного метода и никуда больше.
Ох, ё. Хватит уже позориться.
·>Увидеть что объект меняется в пределах одного метода — легко.
Не всегда.
·>Зато цена этого — значительное усложнеие всего яп и кода.
Ох, ё. Ох, ё. Да const -- это одна из вещей, которая делает программирование не C++ проще. Может быть научиться пользоваться const-ом для кого-то сложно. Но, как показывает (мой) опыт, научить людей понимать указатели (да и ссылки тоже) бывает куда сложнее.
·>Я сказал конкретно: "Ты без ссылок твой константный объект даже как параметр не сможешь никуда передать, а значит толку в таком объекте мало.". Ты начал говорить про defensive copy и "неконстантные объекты". Зачем мне такое образование в софизмах?
Ну что мне делать, если вы выдвигаете идиотский тезис "Ты без ссылок твой константный объект даже как параметр не сможешь никуда передать, а значит толку в таком объекте мало." и требуете от меня ведения дискуссии в рамках этой откровенной идиотии?
Для вас толку мало, OK, это зафиксировано. Вот только за всех не следует говорить.
·>Какие _новые_?
В C++ у нас был MyApplicationType с const и non-const методами. В случае `MyApplicationType&` и `const MyApplicationType&` мы все еще имеем один и тот же тип, но с разными органичениями.
В Java у нас был MyApplicationType, затем к нему добавились MyApplicationTypeMutableIface и MyApplicationTypeImmutableIface. Никаких новых сущностей, ага. Шило на мыло, понятненько.
·>А что ты подразумевал под some_application_domain_type? Пример приведи, где там будет const/non-const?
Да вот, хотя бы: https://github.com/Stiffstream/arataga/blob/master/arataga/acl_handler/first_chunk.hpp#L123-L168
·>Причём тут именование? У record именование будет просто x(). Обязан как следсвтие иммутабелности — если состояние не меняется, то оно неразличимо в любой момент времени.
Еще раз: у вас есть объект o, у которого вы вызываете метод getX. Схерали метод getX должен иметь непосредственное отношение к состоянию объекта o?
·>Я думал, что ты уже понял, что ровно той же константности, что есть плюсах в java нет.
Могу предположить, я об этом узнал задолго до того, как вы перешли с C++ на Java, года эдак с 1998-го.
·>Есть практические задачи и механизмы их решения.
Например, есть ссылка на Map и нужно понять, можно ее менять или нет.
·>Так ведь всё то же самое:
·>void some(const std::map<..> &data)
·>{
·> validateData(data);
·> callSomething();// были ли тут вызваны мутирующие методы data? Разбирайся в run-time
Вы опять путаете теплое с мягким. Это некорректное сравнение.
Сравнивать нужно:
void mutator(std::map<...> & data);
void reader(const std::map<...> & data);
std::map<...> data;
...
mutator(data); // Мутирующие методы data могли быть вызваны.
reader(data); // Если там кто-то дернул мутирующие методы через const_cast, то это преднамеренная диверсия.·>А с многопоточкой так ещё хуже.
Не обязательно. It depends.
·>Так что иммутабельность — нужна, ибо решает вполне серьёзные проблемы. Константность — не нужна.
Вы еще не поняли, что иммутабельность можно пытаться обеспечить разными способами. Можно врукопашную, как в Java, когда у вас все на честном слове. Можно с помощью средств языка. В C++ таковыми являются const. Можно научиться использовать const себе во благо. А можно убеждать себя, что и без const можно жить. Можно, кто ж спорит. Но лучше с const
·>Как выяснили константный объект невозможно передать между тредами.
Ох, ё, три раза.
·>А вы хамите в очередной раз.
А вы тупить перестаньте.