Здравствуйте, rg45, Вы писали:
r> ·>Да не даёт const ровным счётом ничего. r> Ну вот на этот счет у меня немного другое мнение. То, что он не гарантирует неизменности объектна, не означает, что он не дает НИЧЕГО. Это защита от непреднамеренного ошибочного изменения данных. А относительно примера, который ты привел выше — программист должен понимать опасность такого дизайна. И если даже такое где-то встрется, то, наверное, это следует рассматривать как какую-то вынужденную исключительную меру, а не как общий случай. Да, способов выстрелить себе в ногу в C++ больше, чем в других языках. По-моему, это ни для кого не секрет.
Разговор был начат, что без const жизнь не мила, и другие языки страдают от его отсутствия.
Конечно, что-то он даёт. Но то что он даёт — делается например, в той же java с помощью интерфейсов, которые дают ещё много чего интересного.
Т.е. я имел в виду, что не даёт ровным счётом ничего по сравнению с другими подходами.
Я бы сказал что он даже немножечко вредит. Вон тут сколько народу, прожжённых плюсовиков вроде как, а запутались в трёх соснах, и не видят где можно выстрелить себе в ногу.
Здравствуйте, ·, Вы писали:
·>Разговор был начат, что без const жизнь не мила, и другие языки страдают от его отсутствия. ·>Конечно, что-то он даёт. Но то что он даёт — делается например, в той же java с помощью интерфейсов, которые дают ещё много чего интересного. ·>Т.е. я имел в виду, что не даёт ровным счётом ничего по сравнению с другими подходами. ·>Я бы сказал что он даже немножечко вредит. Вон тут сколько народу, прожжённых плюсовиков вроде как, а запутались в трёх соснах, и не видят где можно выстрелить себе в ногу.
Ну, холиварьте потихоньку. Меня только не втягивайте
--
Справедливость выше закона. А человечность выше справедливости.
Re[60]: Когда это наконец станет defined behavior?
Здравствуйте, ·, Вы писали:
S>>·>Так я про константность. Не путай. S>>Матчасть, матчасть! ·>Угу. Разберись.
Ну я то наслышан и о том, как оно в C++, и как оно в D. Это вы здесь пытаетесь лепить горбатого.
·>Вопросы-то какие возникли?
Да. Например: вы всегда настолько интеллектуальны или только в тредах про C++?
·>Давай, просвети: Как сделать банальное переименование в сотне файлов за 1 секунду? Только про search&replace не рассказывай.
Давай, расскажи мне как переслать деньги человеку в другой город, только про почтовые переводы и переводы с карты на карту не рассказывай.
Тупить еще не надоело?
S>>·>Если ты будешь придираться к тому, что константный объект и константная ссылка на объект — не одно и то же S>>Не одно. ·>Я знаю.
А почему этого не видно?
·>Только рояли в нашем случае не играет.
Еще как играет. Константного объекта нет.
S>>·>Ты без ссылок твой константный объект даже как параметр не сможешь никуда передать, а значит толку в таком объекте мало. S>>Во-первых, могу передать по значению. ·>Ох, да. Я забыл. "Память — не ресурс!" — девиз С++. Я ничего не попутал?
Попутали и много чего. Берега в первую очередь. Как и здравый смысл.
·>А вообще если ты передаёшь по значению, то с таким же успехом можно передавать и неконстантный объект.
Если только передавать, то с таким же успехом. Только вот в случае:
const A a;
... // (1)
f(a);
В точке (1) компилятор бьет меня по рукам за попытки модифицировать `a`. В случае неконстантного объекта никакого контроля нет. И по мере развития кода в точке (1) может произойти непреднамеренная модификация.
S>>Во-вторых, константные ссылки могут быть на неконстантные объекты. Поэтому не нужно путать теплое с мягким. Хотя без знания матчасти это сложно, да. ·>Угу. Только причём тут константные объекты за которых ты так топишь?
Если я вас до сих пор не смог объяснить, то дальше не стоить и пытаться. Мне за ваше образование не платят.
S>>Это никак не контролируется компилятором. Это раз. ·>Как и в плюсах.
Можно было бы в очередной раз отправить вас учить матчасть, но это, увы, бесполезно. Так что вопрос о вашем интеллектуальном уровне становится еще более актуальным.
S>>Это все порождает новые сущности. Это два. ·>Не порождает.
Главное верить. Ведь новые сущности в дополнение к классу -- это не новые сущности, это вообще ничто. Суслик наоборот: их видят, но их нет. Ага.
·>Я тебе уже объяснял — вместо двух полных имплементаций методов const/non-const
Вы вообще C++ видели? Необходимость делать const/non-const методы возникает очень редко и в специфических случаях. Например, когда вы реализуете контейнеры или builder pattern. И то, и другое можно отнести к разработке библиотек. В прикладном коде const и non-const версия одного и того же метода -- это экзотика.
·>Состояние объекта обнаруживается по результату операций с ним. Иммутабельный объект имеет неизменное внешнее состояние. И getX обязан выдавать один и тот же результат вне зависимости от когда или где он был вызван.
С чего бы он был обязан? С того, что вы привыкли к такому соглашению об именовании?
S>>HashMap в Java -- это records? Как вы получите константный HashMap в Java? ·>Map.ofEntries(entry(1, "a"), entry(2, "b"));
И вам не стыдно?
The Map.of, Map.ofEntries, and Map.copyOf static factory methods provide a convenient way to create unmodifiable maps. The Map instances created by these methods have the following characteristics:
* They are unmodifiable. Keys and values cannot be added, removed, or updated. Calling any mutator method on the Map will always cause UnsupportedOperationException to be thrown.
Вам возвращается не HashMap, а некая непонятная реализация интерфейса Map. Для которой компилятор не может проверить, модифицируете ли вы возвращенный экземпляр или нет. Вы спокойно можете вызывать мутирующие методы и будете разбираться с проблемами в run-time.
Ахренеть, дайте два!
·>Это как? Ты можешь разделить либо ссылку между тредами (без возможности защитить ссылаемое от изменений)
Объект константный, его не нужно защищать.
·>Верим. Просто вы ещё и привираете, что компилятор вас спасает и сохраняет благодаря молитве "const".
Да, получение ошибки от компилятора -- это "привираете". Дяденька, да вы поехавший.
Re[60]: Когда это наконец станет defined behavior?
Здравствуйте, ·, Вы писали:
·>Разговор был начат, что без const жизнь не мила, и другие языки страдают от его отсутствия.
Вы попутали. Не другие языки страдают, а при переходе на другие языки ощущается отсутствие const. Т.е. страдают не языки, а разработчики. По крайней мере те, кто научились const использовать себе во благо.
Re[61]: Когда это наконец станет defined behavior?
Здравствуйте, so5team, Вы писали:
S>·>Разговор был начат, что без const жизнь не мила, и другие языки страдают от его отсутствия. S>Вы попутали. Не другие языки страдают,
Не попутал. Просто выразился другими словами. Думаю всем очевидно, что ЯП — вещь неодушевлённая и страдать сам по себе не может.
S>а при переходе на другие языки ощущается отсутствие const. Т.е. страдают не языки, а разработчики. По крайней мере те, кто научились const использовать себе во благо.
Это верно. Я сам таким был, я уже это говорил. Но это не беда. Беда в том, что некоторые (не будем показывать пальцем) такие разработчики почему-то необоснованно обобщают и считают, что это не их субъективное восприятие, сила привычки, а объективная проблема дизайна языка, которую ощущают все разработчики, даже те, кто освоили такой ЯП на профессиональном уровне.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[62]: Когда это наконец станет defined behavior?
Здравствуйте, ·, Вы писали:
·>Думаю всем очевидно, что ЯП — вещь неодушевлённая и страдать сам по себе не может.
У языка могут быть объективные недостатки (вроде недостаточность выразительных возможностей, недостаточно строгая типизация, недостаточная безопасность (отсутствие тех или иных гарантий/проверок) и т.д., и т.п.) из-за которых вполне можно говорить, что "страдает язык".
Например, чистый C страдает от ущербности. А C++ от сложности. Они оба страдают от небезопасности.
·>Беда в том, что некоторые (не будем показывать пальцем) такие разработчики почему-то необоснованно обобщают и считают, что это не их субъективное восприятие, сила привычки, а объективная проблема дизайна языка, которую ощущают все разработчики
Вы и цитатой сможете это подтвердить? Особенно утверждения про "проблему дизайна, которую ощущают все разработчики".
Re[63]: Когда это наконец станет defined behavior?
Здравствуйте, so5team, Вы писали:
S>·>Думаю всем очевидно, что ЯП — вещь неодушевлённая и страдать сам по себе не может. S>У языка могут быть объективные недостатки (вроде недостаточность выразительных возможностей, недостаточно строгая типизация, недостаточная безопасность (отсутствие тех или иных гарантий/проверок) и т.д., и т.п.) из-за которых вполне можно говорить, что "страдает язык". S>Например, чистый C страдает от ущербности. А C++ от сложности. Они оба страдают от небезопасности.
Ок. Принято. Я под страданием ЯП понимал именно страдание тех, кто его использует.
S>·>Беда в том, что некоторые (не будем показывать пальцем) такие разработчики почему-то необоснованно обобщают и считают, что это не их субъективное восприятие, сила привычки, а объективная проблема дизайна языка, которую ощущают все разработчики S>Вы и цитатой сможете это подтвердить? Особенно утверждения про "проблему дизайна, которую ощущают все разработчики". https://rsdn.org/forum/cpp/8526192
Как вы предлагаете обходиться без таких вещей как константные ссылки/указатели?
В такой формулировке вопрос подразумевает, что это недостаток от которого плохо всем разработчикам. Возможно, я не так понял.
Я предложил интерфейсы, final, records, тебя не устроило. И пытаешься доказать, что мною предолженное проблему не решает. Ты ожидаешь прямую замену const, а на самом деле ЯП просто подразумевает другие подходы и поэтому проблема не ощущается вообще никак.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[64]: Когда это наконец станет defined behavior?
Здравствуйте, ·, Вы писали:
S>>Вы и цитатой сможете это подтвердить? Особенно утверждения про "проблему дизайна, которую ощущают все разработчики". ·>https://rsdn.org/forum/cpp/8526192
Как вы предлагаете обходиться без таких вещей как константные ссылки/указатели?
·>В такой формулировке вопрос подразумевает, что это недостаток от которого плохо всем разработчикам.
Когда речь про "ощущают" то нужно, чтобы разработчики понимали что у них есть, а чего они лишены.
Для меня очевидно, что далеко не все разработчики на Java (а так же упомянутых в том сообщении Ruby и Python) осознают что дает дополнительный контроль со стороны компилятора. А раз не осознают, что вряд ли и ощущают.
·>Я предложил интерфейсы, final, records, тебя не устроило. И пытаешься доказать, что мною предолженное проблему не решает.
Так это очевидно, что не решают. Вы же привели пример с Map.ofEntities, который возвращает экземпляр интерфейса Map, но как только мы удаляемся от вызова Map.ofEntities, то нам не видно, скрывается ли за этим Map-ом мутабельный или иммутабельный объект (unmodifiable в терминологии из Java Doc). Соответственно, ничто в compile-time не мешает вызвать нам у этого Map-а мутирующий метод.
Когда как в языках с поддежкой константности (C++, D, Rust) мы могли бы иметь const (или immutable в D) экземпляр, у которого нельзя было бы вызывать мутирующие методы и это бы проверялось в compile-time.
Собственно, об этом и шла речь, что разбираться с тем, что мутабельно, а что нет, в C++ оказывается проще (для меня), чем в Java, Ruby или Python.
Re[61]: Когда это наконец станет defined behavior?
Здравствуйте, so5team, Вы писали:
S>>>Матчасть, матчасть! S>·>Угу. Разберись. S>Ну я то наслышан и о том, как оно в C++, и как оно в D. Это вы здесь пытаетесь лепить горбатого.
Но слушать не хочешь как в других яп.
S>·>Давай, просвети: Как сделать банальное переименование в сотне файлов за 1 секунду? Только про search&replace не рассказывай. S>Давай, расскажи мне как переслать деньги человеку в другой город, только про почтовые переводы и переводы с карты на карту не рассказывай.
Отличная аналогия. Ты не поверишь: я в жизни не пользовался ни почтовым переводом, ни переводом между картами.
А вот ты и знать не хочешь, что другие способы перевода существуют, в том числе и более современные, быстрые и/или надёжные. Например, можно просто урл мессагой послать. Или по номеру мобильника. Или чек курьером отправить. Или запейпалить. Или биток скинуть. И т.п. Но ты упорно пытаешься доказать, что без почтового перевода или карт настоящие шотландцы переводы невозможны.
S>Тупить еще не надоело?
Надоело. Кончай уже.
S>·>Я знаю. S>А почему этого не видно?
Потому что: S>·>Только рояли в нашем случае не играет.
S>Еще как играет. Константного объекта нет.
Если бы и был, проблему не решает.
S>>>Во-первых, могу передать по значению. S>·>Ох, да. Я забыл. "Память — не ресурс!" — девиз С++. Я ничего не попутал? S>Попутали и много чего. Берега в первую очередь. Как и здравый смысл.
Так всё-таки. Не съезжай темы. Как _сам_ константный объект куда-нибудь передать?
S>·>А вообще если ты передаёшь по значению, то с таким же успехом можно передавать и неконстантный объект. S>Если только передавать, то с таким же успехом. Только вот в случае: S>В точке (1) компилятор бьет меня по рукам за попытки модифицировать `a`. В случае неконстантного объекта никакого контроля нет. И по мере развития кода в точке (1) может произойти непреднамеренная модификация.
Именно. Лучшее что можно сделать с константным объектом — иметь его внутри одного метода и никуда больше. Вот только толку всё равно мало. Насколько это важно и необходимо — у меня большие сомнения.
Как правило наоборот, в пределах одного метода объекты требуется пилить и кромсать. А наружу выдавать безопасный результат.
Увидеть что объект меняется в пределах одного метода — легко. Вот и получается, что если const что и помогает решить, так это какую-то тривиальную проблему. Зато цена этого — значительное усложнеие всего яп и кода.
S>>>Во-вторых, константные ссылки могут быть на неконстантные объекты. Поэтому не нужно путать теплое с мягким. Хотя без знания матчасти это сложно, да. S>·>Угу. Только причём тут константные объекты за которых ты так топишь? S>Если я вас до сих пор не смог объяснить, то дальше не стоить и пытаться. Мне за ваше образование не платят.
Я сказал конкретно: "Ты без ссылок твой константный объект даже как параметр не сможешь никуда передать, а значит толку в таком объекте мало.". Ты начал говорить про defensive copy и "неконстантные объекты". Зачем мне такое образование в софизмах?
S>>>Это все порождает новые сущности. Это два. S>·>Не порождает. S>Главное верить. Ведь новые сущности в дополнение к классу -- это не новые сущности, это вообще ничто. Суслик наоборот: их видят, но их нет. Ага.
Какие _новые_? был const, стал интерфейс. Это замена, а не новое. Шило на мыло.
S>·>Я тебе уже объяснял — вместо двух полных имплементаций методов const/non-const S>Вы вообще C++ видели? Необходимость делать const/non-const методы возникает очень редко и в специфических случаях. Например, когда вы реализуете контейнеры или builder pattern. И то, и другое можно отнести к разработке библиотек. В прикладном коде const и non-const версия одного и того же метода -- это экзотика.
А что ты подразумевал под some_application_domain_type? Пример приведи, где там будет const/non-const?
S>·>Состояние объекта обнаруживается по результату операций с ним. Иммутабельный объект имеет неизменное внешнее состояние. И getX обязан выдавать один и тот же результат вне зависимости от когда или где он был вызван. S>С чего бы он был обязан? С того, что вы привыкли к такому соглашению об именовании?
Причём тут именование? У record именование будет просто x(). Обязан как следсвтие иммутабелности — если состояние не меняется, то оно неразличимо в любой момент времени.
S>>>HashMap в Java -- это records? Как вы получите константный HashMap в Java? S>·>Map.ofEntries(entry(1, "a"), entry(2, "b")); S>И вам не стыдно?
Я думал, что ты уже понял, что ровно той же константности, что есть плюсах в java нет. Есть практические задачи и механизмы их решения.
Надо рассматривать конкретный сценарий и тогда можно говорить о разных подходах как писать хороший код, какие механизмы ЯП использовать.
В данном случае я вам предложил неизменяемую мапу, которая может быть безопасно передана в другие треды и т.п.
Зачем конкретно вам нужен HashMap неясно. Ведь если подумать, то внезапно выяснится, что если у тебя есть конкретные данные, то HashMap может быть не нужен. Например, если у тебя мапа размером 1, то нет никакого смысла создавать HashMap c fillfactor, резервировать бакеты и т.п., эффективнее иметь специальную реализацию мапы размером 1. Этим Map.of и занимается.
S>
The Map.of, Map.ofEntries, and Map.copyOf static factory methods provide a convenient way to create unmodifiable maps. The Map instances created by these methods have the following characteristics:
S>* They are unmodifiable. Keys and values cannot be added, removed, or updated. Calling any mutator method on the Map will always cause UnsupportedOperationException to be thrown.
Потому что это immutable. S>Вам возвращается не HashMap, а некая непонятная реализация интерфейса Map. Для которой компилятор не может проверить, модифицируете ли вы возвращенный экземпляр или нет. Вы спокойно можете вызывать мутирующие методы и будете разбираться с проблемами в run-time.
Так ведь всё то же самое:
void some(const std::map<..> &data)
{
validateData(data);
callSomething();// были ли тут вызваны мутирующие методы data? Разбирайся в run-time
useData(data);// здесь у нас та же data что выше или может быть уже другая, не та, которую мы провалидировали?
}
А с многопоточкой так ещё хуже. Так что иммутабельность — нужна, ибо решает вполне серьёзные проблемы. Константность — не нужна.
S>·>Это как? Ты можешь разделить либо ссылку между тредами (без возможности защитить ссылаемое от изменений) S>Объект константный, его не нужно защищать.
Как выяснили константный объект невозможно передать между тредами.
S>·>Верим. Просто вы ещё и привираете, что компилятор вас спасает и сохраняет благодаря молитве "const". S>Да, получение ошибки от компилятора -- это "привираете". Дяденька, да вы поехавший.
А вы хамите в очередной раз.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[65]: Когда это наконец станет defined behavior?
Здравствуйте, so5team, Вы писали:
S>Когда речь про "ощущают" то нужно, чтобы разработчики понимали что у них есть, а чего они лишены.
Так я знаю. У меня несколько лет опыта на плюсах есть, правда давнего.
S>Для меня очевидно, что далеко не все разработчики на Java (а так же упомянутых в том сообщении Ruby и Python) осознают что дает дополнительный контроль со стороны компилятора. А раз не осознают, что вряд ли и ощущают.
Я уже писал о своих ощущениях во время перехода с плюсов на яву.
S>·>Я предложил интерфейсы, final, records, тебя не устроило. И пытаешься доказать, что мною предолженное проблему не решает. S>Так это очевидно, что не решают. Вы же привели пример с Map.ofEntities, который возвращает экземпляр интерфейса Map, но как только мы удаляемся от вызова Map.ofEntities, то нам не видно, скрывается ли за этим Map-ом мутабельный или иммутабельный объект (unmodifiable в терминологии из Java Doc). Соответственно, ничто в compile-time не мешает вызвать нам у этого Map-а мутирующий метод.
Не мешает. Но не грозит неизвестными последствиями, как в случае веры в то, что наличие const защищает от изменений (на что, например, напоролись T4r4sB и rg45 тут
, а ведь наверняка у них опыта в плюсах поболее моего).
S>Когда как в языках с поддежкой константности (C++, D, Rust) мы могли бы иметь const (или immutable в D) экземпляр, у которого нельзя было бы вызывать мутирующие методы и это бы проверялось в compile-time. S>Собственно, об этом и шла речь, что разбираться с тем, что мутабельно, а что нет, в C++ оказывается проще (для меня), чем в Java, Ruby или Python.
А ты всё ещё не понимаешь, что immutable != 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?
Еще раз: у вас есть объект 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
·>Как выяснили константный объект невозможно передать между тредами.
, а ведь наверняка у них опыта в плюсах поболее моего).
Боюсь, этот пример нужно обсуждать с ними, а не со мной. Я не понял, чего там хотели достичь.
·>А ты всё ещё не понимаешь, что immutable != const.
Повторю и здесь:
Вы еще не поняли, что иммутабельность можно пытаться обеспечить разными способами. Можно врукопашную, как в Java, когда у вас все на честном слове. Можно с помощью средств языка. В C++ таковыми являются const.
Re[63]: Когда это наконец станет defined behavior?
Здравствуйте, so5team, Вы писали:
S>>>Ну я то наслышан и о том, как оно в C++, и как оно в D. Это вы здесь пытаетесь лепить горбатого. S>·>Но слушать не хочешь как в других яп. S>Это вы про Java во множественном числе?
Я отвечал на твой кокнретный вопрос "При программировании на Java... Как вы предлагаете обходиться без таких вещей как константные ссылки/указатели?". Ну я и предложил.
S>Так я программировал на Java (за деньги, т.е. профессионально), так что слегка наслышан тоже.
Если опыт был серьёзный, то тогда неясно откуда такое непонимание.
S>·>А вот ты и знать не хочешь S>Сударь, у вас проблемы с квантором всеобщности. Вы говорили, что будут проблемы при переименовании. Я же не говорил, что их не будет. Я говорил о том, что их может и не быть. И таки да, во многих случаях простой search&replace работает без проблем.
Хреново он работает.
S>>>Еще как играет. Константного объекта нет. S>·>Если бы и был, проблему не решает. S>Какую такую проблему?
Защиты данных от нежелательных изменений. Даже кривой legacy подход с UnsupportedOperationException это позволяет.
S>>>·>Ох, да. Я забыл. "Память — не ресурс!" — девиз С++. Я ничего не попутал? S>>>Попутали и много чего. Берега в первую очередь. Как и здравый смысл. S>·>Так всё-таки. Не съезжай темы. Как _сам_ константный объект куда-нибудь передать? S>Темы передать константный объект и не было, это вы по ходу выдумали. Я говорил, что константный объект можно расшарить между тредами как пример.
Как расшарить-то??! Ты рассказал как передать ссылку (хоть на константный, хоть не константный, что ломает всю идею на корню), либо defensive copy, за которую меня упрекал.
S>Да, расшарить можно по константной ссылке. Если у вас константные ссылки вызывают проблемы, то я не виноват. Константная ссылка не делает данные константными.
S>·>Увидеть что объект меняется в пределах одного метода — легко. S>Не всегда.
Если сложно разобраться что делает данный конкретный метод — это либо хреновый яп, либо хреново написанный метод.
S>·>Я сказал конкретно: "Ты без ссылок твой константный объект даже как параметр не сможешь никуда передать, а значит толку в таком объекте мало.". Ты начал говорить про defensive copy и "неконстантные объекты". Зачем мне такое образование в софизмах? S>Ну что мне делать, если вы выдвигаете идиотский тезис "Ты без ссылок твой константный объект даже как параметр не сможешь никуда передать, а значит толку в таком объекте мало." и требуете от меня ведения дискуссии в рамках этой откровенной идиотии?
Ты так и не рассказал как же _передать_ (копирование это не передача) константный объект куда-то, чтобы он там и оставался гарантированно константным (чтобы туда нельзя было передать неконстантный).
S>·>Какие _новые_? S>В C++ у нас был MyApplicationType с const и non-const методами. В случае `MyApplicationType&` и `const MyApplicationType&` мы все еще имеем один и тот же тип, но с разными органичениями.
С т.з. системы типов C++ — типы разные, не выдумывай. Попробуй расскажи о принципиальной разнице "const MyApplicationType" и "ConstMyApplicationType" с практической точки зрения.
S>В Java у нас был MyApplicationType, затем к нему добавились MyApplicationTypeMutableIface и MyApplicationTypeImmutableIface. Никаких новых сущностей, ага. Шило на мыло, понятненько.
Зачем?! "MyApplicationType" и "ConstMyApplicationType". Было два, стало два.
S>·>А что ты подразумевал под some_application_domain_type? Пример приведи, где там будет const/non-const? S>Да вот, хотя бы: https://github.com/Stiffstream/arataga/blob/master/arataga/acl_handler/first_chunk.hpp#L123-L168
Ну и? Что тут даёт const? От тут тупо не нужен. В java полный аналог будет:
class first_chunk_for_next_handler_t
{
first_chunk_t chunk;
int remaining_bytes;
first_chunk_t chunk()
{
return this.chunk;
}
first_chunk_t giveaway_chunk()
{
var chunk = this.chunk;
this.chunk = null;
return chunk;
}
int remaining_bytes()
{
return remaining_bytes;
}
}
S>·>Причём тут именование? У record именование будет просто x(). Обязан как следсвтие иммутабелности — если состояние не меняется, то оно неразличимо в любой момент времени. S>Еще раз: у вас есть объект o, у которого вы вызываете метод getX. Схерали метод getX должен иметь непосредственное отношение к состоянию объекта o?
Результат метода зависит от состояния объекта.
S>·>Есть практические задачи и механизмы их решения. S>Например, есть ссылка на Map и нужно понять, можно ее менять или нет.
Это средство, а не цель. Понять чтобы что? Методу по логике вещей qwerAsdf либо нужно менять Map, либо не нужно. Если не нужно — он менять не будет. А если нужно, то ты хоть тресни, он будет, вне зависимости что ты туда _желаешь_ передать. Придётся передавать то, что нужно, а не то что хочется.
S>·>Так ведь всё то же самое: S>·>void some(const std::map<..> &data) S>·>{ S>·> validateData(data); S>·> callSomething();// были ли тут вызваны мутирующие методы data? Разбирайся в run-time S>Вы опять путаете теплое с мягким. Это некорректное сравнение.
Это именно то что создаёт проблему, которую сложно искать.
S>Сравнивать нужно: S>
S>std::map<...> data;
S>...
S>mutator(data); // Мутирующие методы data могли быть вызваны.
S>reader(data); // Если там кто-то дернул мутирующие методы через const_cast, то это преднамеренная диверсия.
S>
А это какую проблему решает? Если кто-то поменяет сигнатуру метода reader, то в этом месте это тупо всё тихо поломается. Глядя на этот код только — ничего сказать нельзя. Тебе нужно видеть все сигнатуры и верить, что эти сигнатуры не поменяются.
О const_cast я даже не заикаюсь. Взрываться всё и без него может. Если ты всё ещё не догадался как это происходит в случае callSomething() — могу рассказать. Я уже показывал аналог тут
, константа константой константу погоняет, а всё тихо сломалось.
S>·>А с многопоточкой так ещё хуже. S>Не обязательно. It depends.
Конечно. Но совершенно не depends от const. Пользы от const — ноль в данном случае.
S>·>Так что иммутабельность — нужна, ибо решает вполне серьёзные проблемы. Константность — не нужна. S>Вы еще не поняли, что иммутабельность можно пытаться обеспечить разными способами. Можно врукопашную, как в Java, когда у вас все на честном слове. Можно с помощью средств языка. В C++ таковыми являются const. Можно научиться использовать const себе во благо. А можно убеждать себя, что и без const можно жить. Можно, кто ж спорит. Но лучше с const
Не подходит const для реализации иммутабельности.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[67]: Когда это наконец станет defined behavior?
Здравствуйте, so5team, Вы писали:
S>·>Но не грозит неизвестными последствиями, как в случае веры в то, что наличие const защищает от изменений S>Ну так и не нужно верить в то, чего нет.
Да. А ты веришь что const от чего-то защищает.
S>const позволяет бить по рукам за попытки модифицировать объект по константной ссылке или указателю.
Только это ни от чего не защищает.
S>·>(на что, например, напоролись T4r4sB и rg45 тут
, а ведь наверняка у них опыта в плюсах поболее моего). S>Боюсь, этот пример нужно обсуждать с ними, а не со мной. Я не понял, чего там хотели достичь.
Им казалось, что const защищает map от модификации значений ключей, и что благодаря этому инварианты map сломать нельзя. Как оказалось, им таки только казалось.
S>·>А ты всё ещё не понимаешь, что immutable != const. S>Повторю и здесь: S>
Вы еще не поняли, что иммутабельность можно пытаться обеспечить разными способами. Можно врукопашную, как в Java, когда у вас все на честном слове. Можно с помощью средств языка. В C++ таковыми являются const.
В С++ тоже всё на честном слове, но ещё заблуждение, что const от чего-то защищает.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[64]: Когда это наконец станет defined behavior?
Здравствуйте, ·, Вы писали:
·>Я отвечал на твой кокнретный вопрос "При программировании на Java... Как вы предлагаете обходиться без таких вещей как константные ссылки/указатели?". Ну я и предложил.
На что вам сказали, что этот подход не дает никаких иных гарантий, кроме "мамой клянусь". Так чтож вы так убиваетесь-то, вы так не убьетесь.
·>Если опыт был серьёзный, то тогда неясно откуда такое непонимание.
Непонимание того, что const-а в Java нет? Вы бы доказали, что такое недопонимание имеет место быть.
·>Хреново он работает.
А иногда вообще не работает. А иногда отлично работает.
S>>Какую такую проблему? ·>Защиты данных от нежелательных изменений.
Ох, ё, i-й раз.
const std::vector<std::string> immutable_data{ "Hello"s, "World"s };
immutable_data.push_back("!"s); // Да как так-то?!!! Да чтож это деется-то, а?
Не, ну реально хватит позориться.
·>Даже кривой legacy подход с UnsupportedOperationException это позволяет.
Только вот к возможностям языка это не имеет отношения.
·>Как расшарить-то??! Ты рассказал как передать ссылку (хоть на константный, хоть не константный, что ломает всю идею на корню), либо defensive copy, за которую меня упрекал.
Константную ссылку на константный объект. Какую идею это ломает Видимо, это что-то очень личное.
S>>Да, расшарить можно по константной ссылке. Если у вас константные ссылки вызывают проблемы, то я не виноват. ·> Константная ссылка не делает данные константными.
А где-то утверждается обратное? Хде?!!!
·>Если сложно разобраться что делает данный конкретный метод — это либо хреновый яп, либо хреново написанный метод.
Вы что, живете в стране розовых пони? Мне вот по работе приходится заглядывать в методы на сотни строк. Ничего хорошего в этом нет, но в объективной реальности это вот прям чуть ли не на каждом шагу.
·>Ты так и не рассказал как же _передать_ (копирование это не передача) константный объект куда-то, чтобы он там и оставался гарантированно константным (чтобы туда нельзя было передать неконстантный).
Я не утверждал про невозможность передать неконстанный объект по константной ссылке. Вы что-то путаете.
·>С т.з. системы типов C++ — типы разные, не выдумывай.
OK. Но сколько усилий нам нужно, чтобы получить эти разные типы?
·>Попробуй расскажи о принципиальной разнице "const MyApplicationType" и "ConstMyApplicationType" с практической точки зрения.
Это две разных сущности, существование которых нужно оправдать. А потом вспомнить про "не плодите сущности без надобности"
S>>В Java у нас был MyApplicationType, затем к нему добавились MyApplicationTypeMutableIface и MyApplicationTypeImmutableIface. Никаких новых сущностей, ага. Шило на мыло, понятненько. ·>Зачем?! "MyApplicationType" и "ConstMyApplicationType". Было два, стало два.
Дает указание компилятору на то, что его можно вызывать по константной ссылке, так и по неконстантной.
·>От тут тупо не нужен.
Да что вы говорите! Кто бы мог подумать...
·>В java полный аналог будет: ·>
·>class first_chunk_for_next_handler_t
·>{
·> int remaining_bytes()
·> {
// А потом кто-то с кривыми руками...
remaining_bytes--;
·> return remaining_bytes;
·> }
·>}
·>
S>>Еще раз: у вас есть объект o, у которого вы вызываете метод getX. Схерали метод getX должен иметь непосредственное отношение к состоянию объекта o? ·>Результат метода зависит от состояния объекта.
Повторюсь: схерали?
·>Методу по логике вещей qwerAsdf либо нужно менять Map, либо не нужно. Если не нужно — он менять не будет.
Как это гарантировать средствами языка?
·>А это какую проблему решает?
Проблему понимания константности в C++.
·>Если кто-то поменяет сигнатуру метода reader, то в этом месте это тупо всё тихо поломается. Глядя на этот код только — ничего сказать нельзя. Тебе нужно видеть все сигнатуры и верить, что эти сигнатуры не поменяются.
Если сигнатуры меняются, то наличие const в нужных местах приводит к ошибкам компиляции.
·>Я уже показывал аналог тут
, константа константой константу погоняет, а всё тихо сломалось.
Так там нет константы. Вы опять не выучили матчасть.
S>>·>А с многопоточкой так ещё хуже. S>>Не обязательно. It depends. ·>Конечно. Но совершенно не depends от const. Пользы от const — ноль в данном случае.
Ой, ё. А мужики-то и не знают!
·>Не подходит const для реализации иммутабельности.
У вас, давайте говорить определеннее.
Re[68]: Когда это наконец станет defined behavior?
Здравствуйте, ·, Вы писали:
S>>·>Но не грозит неизвестными последствиями, как в случае веры в то, что наличие const защищает от изменений S>>Ну так и не нужно верить в то, чего нет. ·>Да. А ты веришь что const от чего-то защищает.
От защищает от вызова методов, которые не помечены как const. И да, в это сложно не поверить, после того, как компилятор столько раз бил по рукам.
S>>const позволяет бить по рукам за попытки модифицировать объект по константной ссылке или указателю. ·>Только это ни от чего не защищает.
Да что вы говорите? И вам можно верить?
·>Им казалось, что const защищает map от модификации значений ключей, и что благодаря этому инварианты map сломать нельзя. Как оказалось, им таки только казалось.
Так в случае с reference_wrapper для const int там не было того самого const int.
Собственно, это одна из проблем с const& (и const*) о которой я вам раньше и говорил: они могут указывать на неконстантные данные.
Re[69]: Когда это наконец станет defined behavior?
Здравствуйте, so5team, Вы писали:
S>·>Да. А ты веришь что const от чего-то защищает. S>От защищает от вызова методов, которые не помечены как const.
Как и const-интерфейс. В чём поинт-то?
S>И да, в это сложно не поверить, после того, как компилятор столько раз бил по рукам.
С интерфейсом код такой написать тупо не получится, до компилятора дело даже не доходит.
S>>>const позволяет бить по рукам за попытки модифицировать объект по константной ссылке или указателю. S>·>Только это ни от чего не защищает. S>Да что вы говорите? И вам можно верить?
Правду. Конечно.
S>·>Им казалось, что const защищает map от модификации значений ключей, и что благодаря этому инварианты map сломать нельзя. Как оказалось, им таки только казалось. S>Так в случае с reference_wrapper для const int там не было того самого const int.
Они не знали, ну ладно, будем считать забыли. Как и ты, когда предлагал мне константные ссылки передавать в другие треды.
S>Собственно, это одна из проблем с const& (и const*) о которой я вам раньше и говорил: они могут указывать на неконстантные данные.
Именно. Что и сводит на нет полезность константных объектов.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[70]: Когда это наконец станет defined behavior?
Здравствуйте, ·, Вы писали:
S>>·>Да. А ты веришь что const от чего-то защищает. S>>От защищает от вызова методов, которые не помечены как const. ·>Как и const-интерфейс. В чём поинт-то?
Внутри этого вашего const-интерфейса кто-то что-то гарантирует?
S>>И да, в это сложно не поверить, после того, как компилятор столько раз бил по рукам. ·>С интерфейсом код такой написать тупо не получится
Да ладно!
Мне вот почему-то не помешало:
interface ConstFirstChunkForNextHandler {
int remainingBytes();
}
class FirstChunkForNextHandler implements ConstFirstChunkForNextHandler {
private int remainingBytes = 0;
public int remainingBytes() {
--remainingBytes;
return remainingBytes;
}
}
public class Main
{
public static void main(String[] args) {
ConstFirstChunkForNextHandler chunk = new FirstChunkForNextHandler();
System.out.printf("first call: %d\n", chunk.remainingBytes());
System.out.printf("first call: %d\n", chunk.remainingBytes());
}
}
S>>>>const позволяет бить по рукам за попытки модифицировать объект по константной ссылке или указателю. S>>·>Только это ни от чего не защищает. S>>Да что вы говорите? И вам можно верить? ·>Правду. Конечно.
С чего бы? Пока что вы вообще никак не продемонстрировали понимания предмета.
S>>·>Им казалось, что const защищает map от модификации значений ключей, и что благодаря этому инварианты map сломать нельзя. Как оказалось, им таки только казалось. S>>Так в случае с reference_wrapper для const int там не было того самого const int. ·>Они не знали, ну ладно, будем считать забыли.
Нет, они не обратили внимания в запарке спора.
·>Как и ты, когда предлагал мне константные ссылки передавать в другие треды.
Странно, у меня все работает:
#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) {
return std::thread{ [&v, iterations] {
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 };
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();
}
Проблема на вашей стороне.
·>Именно. Что и сводит на нет полезность константных объектов.
У вас каша в голове. И проблемы не только с воображением, но и с логикой.
Re[65]: Когда это наконец станет defined behavior?
Здравствуйте, so5team, Вы писали:
S>·>Я отвечал на твой кокнретный вопрос "При программировании на Java... Как вы предлагаете обходиться без таких вещей как константные ссылки/указатели?". Ну я и предложил. S>На что вам сказали, что этот подход не дает никаких иных гарантий, кроме "мамой клянусь". Так чтож вы так убиваетесь-то, вы так не убьетесь.
Как и подход с const. Они эквивалентны логически, синтаксис только отличается.
S>·>Если опыт был серьёзный, то тогда неясно откуда такое непонимание. S>Непонимание того, что const-а в Java нет? Вы бы доказали, что такое недопонимание имеет место быть.
Не понимание как можно "обходиться без таких вещей как константные ссылки/указатели".
S>·>Хреново он работает. S>А иногда вообще не работает. А иногда отлично работает.
Ага. Отлично, от других.
S>>>Какую такую проблему? S>·>Защиты данных от нежелательных изменений. S>Ох, ё, i-й раз. S>
S>const std::vector<std::string> immutable_data{ "Hello"s, "World"s };
S>immutable_data.push_back("!"s); // Да как так-то?!!! Да чтож это деется-то, а?
S>
Ровно то же что и с ConstObj obj = new Obj();obj.change();. Отличие по сути только в отсутствии пробела в "Const Obj".
S>·>Как расшарить-то??! Ты рассказал как передать ссылку (хоть на константный, хоть не константный, что ломает всю идею на корню), либо defensive copy, за которую меня упрекал. S>Константную ссылку на константный объект. Какую идею это ломает Видимо, это что-то очень личное.
Этого мало. Надо чтобы не было возможности передавать ссылку на неконстантный объект. Иначе это вся затея коту под хвост.
S>·>Если сложно разобраться что делает данный конкретный метод — это либо хреновый яп, либо хреново написанный метод. S>Вы что, живете в стране розовых пони? Мне вот по работе приходится заглядывать в методы на сотни строк. Ничего хорошего в этом нет, но в объективной реальности это вот прям чуть ли не на каждом шагу.
В таком методе не будет никаких "mutator", "reader" будет:
Qwer data = nmqwert();
zdfkgjq(data);
ouqengtn(data);
qhrign(data);
Вот теперь расскажи где тут что меняется, а где нет, и чем тут помог const.
S>·>Ты так и не рассказал как же _передать_ (копирование это не передача) константный объект куда-то, чтобы он там и оставался гарантированно константным (чтобы туда нельзя было передать неконстантный). S>Я не утверждал про невозможность передать неконстанный объект по константной ссылке. Вы что-то путаете.
Ты обещал, что передавать константные ссылки другим тредам — безопасно. Нет, это не так.
А вот иммутабельные объекты — действительно безопасно.
S>·>С т.з. системы типов C++ — типы разные, не выдумывай. S>OK. Но сколько усилий нам нужно, чтобы получить эти разные типы?
В каких попугаях мерить будем?
S>·>Попробуй расскажи о принципиальной разнице "const MyApplicationType" и "ConstMyApplicationType" с практической точки зрения. S>Это две разных сущности, существование которых нужно оправдать. А потом вспомнить про "не плодите сущности без надобности"
Я написал "const MyApplicationType" и "ConstMyApplicationType".
S>>>В Java у нас был MyApplicationType, затем к нему добавились MyApplicationTypeMutableIface и MyApplicationTypeImmutableIface. Никаких новых сущностей, ага. Шило на мыло, понятненько. S>·>Зачем?! "MyApplicationType" и "ConstMyApplicationType". Было два, стало два. S>О да, стало сильно легче.
Я не обещал легче, я говорил ровно столько же. А ты вот лишниего нафантазировал.
S>>>Да вот, хотя бы: https://github.com/Stiffstream/arataga/blob/master/arataga/acl_handler/first_chunk.hpp#L123-L168 S>·>Ну и? Что тут даёт const? S>Дает указание компилятору на то, что его можно вызывать по константной ссылке, так и по неконстантной.
Мне пофиг на компилятор. Что это даёт юзерам компилятора?
S>·>От тут тупо не нужен. S>Да что вы говорите! Кто бы мог подумать...
Да. Подумай, тебе может даже понравится.
S> // А потом кто-то с кривыми руками... S> remaining_bytes--;
Ох, ну господи. Добавь "final" в декларацию remaining_bytes, я забыл при копипасте: final int remaining_bytes;. Вселенная спасена?
S>>>Еще раз: у вас есть объект o, у которого вы вызываете метод getX. Схерали метод getX должен иметь непосредственное отношение к состоянию объекта o? S>·>Результат метода зависит от состояния объекта. S>Повторюсь: схерали?
А от чего ещё-то? Для иммутабельного-то типа?
S>·>Методу по логике вещей qwerAsdf либо нужно менять Map, либо не нужно. Если не нужно — он менять не будет. S>Как это гарантировать средствами языка?
_Если надо_, то создать интерфейс с соответсвующими методами. В интерфейсе ты можешь точно зафиксировать что qwerAsdf может делать, а что не может. Притом не обязательно ограничиваться константностью.
S>·>А это какую проблему решает? S>Проблему понимания константности в C++.
Очень важная и нужная проблема (нет).
S>·>Если кто-то поменяет сигнатуру метода reader, то в этом месте это тупо всё тихо поломается. Глядя на этот код только — ничего сказать нельзя. Тебе нужно видеть все сигнатуры и верить, что эти сигнатуры не поменяются. S>Если сигнатуры меняются, то наличие const в нужных местах приводит к ошибкам компиляции.
В приведённном тобой месте — не приводит.
S>·>Я уже показывал аналог тут
, константа константой константу погоняет, а всё тихо сломалось. S>Так там нет константы. Вы опять не выучили матчасть.
Там то, что предложил rg45 в качестве "решения". И заявил, что это т.к. позволяет "сслаться на константные данные". Нет, не позволяет.
S>>>·>А с многопоточкой так ещё хуже. S>>>Не обязательно. It depends. S>·>Конечно. Но совершенно не depends от const. Пользы от const — ноль в данном случае. S>Ой, ё. А мужики-то и не знают!
Я рад, что ты узнал что-то новое.
S>·>Не подходит const для реализации иммутабельности. S>У вас, давайте говорить определеннее.
Ок. Начни с того, что объясни создателям D что они ошиблись вводя "immutable" при наличии "const". Ведь по-твоему можно только "const" обойтись.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[66]: Когда это наконец станет defined behavior?