Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата Повстанець @ 27.01.11, 22:26

то защита класса в твоих руках. Гарантии получаются абсолютно аналогично -- константностью параметров.

Т.е. когда ты пишешь метод, ты должен знать, что тот другой объект может поменять значение твоего и передавать его тоже константой? А откуда ты это узнаешь? Код полезешь смотреть? Я нисколько не спорю что защита в твоих руках Я это наоборот - в этом уверен. В твоих и только в твоих, все остальное даст тебе только надежду, а не гарантию

Цитата --Ins-- @ 27.01.11, 22:30

Т.е. когда ты пишешь метод, ты должен знать, что тот другой объект может поменять значение твоего и передавать его тоже константой? А откуда ты это узнаешь? Код полезешь смотреть? Я нисколько не спорю что защита в твоих руках Я это наоборот - в этом уверен. В твоих и только в твоих, все остальное даст тебе только надежду, а не гарантию

Зачем код смотреть? Делаешь параметры константными и всё.

Цитата --Ins-- @ 27.01.11, 22:25

Цитата KILLER @ 27.01.11, 22:24

а тебе объясняют что в константных методах состояние объекта *this изменить нельзя...

Это я понимаю, что явно нельзя. А косвенно?

Цитата KILLER @ 27.01.11, 22:23

Нельзя его изменить

Мне показалось, что D_KEY говорит что можно

Ты то одно говоришь, то другое потому-что.
Да, ты можешь создать объект A, в него передать неконстантную ссылку на объект B, затем вызвать некий код, в который передаем константную ссылку на B и неконстантную ссылку на A, где сможем вызывать неконстантный метод у A, который сможет вызвать неконстантный метод того объекта класса B, который хранится у A. Если мы передадим в этот некий код в качестве константного объекта B тот же самый объект, на который ссылается A, то получим изменения объекта, о котором ты говоришь.
Но. Этот самый "некий" код не нарушает своего контракта, поскольку не делает ничего с объектом B. То, что его понял другой объект - его контракт никак не захватывает. С тем же успехом, это значение может быть поменяно из другого потока, например.

Цитата --Ins-- @ 27.01.11, 22:30

Т.е. когда ты пишешь метод, ты должен знать, что тот другой объект может поменять значение твоего и передавать его тоже константой? А откуда ты это узнаешь? Код полезешь смотреть? Я нисколько не спорю что защита в твоих руках Я это наоборот - в этом уверен. В твоих и только в твоих, все остальное даст тебе только надежду, а не гарантию

Нет. Если "тот другой" объект может поменять значение "твоего", то метод "того" объекта принимает неконстантную ссылку, и передать в этот метод константный объект не даст компилятор.

Цитата --Ins-- @ 27.01.11, 22:30

Т.е. когда ты пишешь метод, ты должен знать, что тот другой объект может поменять значение твоего и передавать его тоже константой?

Когда я пишу метод, я не обязан знать, что ты там в других объектах накодил. Я обязан снабдить этот метод интерфейсом, удовлетворяющим задаче этого метода и содержащий максимальные ограничения для написания безопасного кода.

--Ins--, так можно увидеть связь "компоновщика" с const?

Цитата Повстанець @ 27.01.11, 22:33

Делаешь параметры константными и всё.

Ну, сразу и все А если ты предполагаешь у этого объекта другого неконстантные методы вызвать. Понятно что притянуто, но мало ли... В любом случае все ясно Гарантия ваша далеко не 100%-ая, а лишь при условии аккуратного проектирования работает. А при нем и гарантии не нужны особенно-то. Даже наоборот - вот облом будет если тебе гарантировали, и не исполнили

Цитата --Ins-- @ 27.01.11, 22:36

А при нем и гарантии не нужны особенно-то.

Система гарантий как раз и позволяет строить безопасный код.

Цитата --Ins-- @ 27.01.11, 22:36

Ну, сразу и все А если ты предполагаешь у этого объекта другого неконстантные методы вызвать. Понятно что притянуто, но мало ли... В любом случае все ясно Гарантия ваша далеко не 100%-ая, а лишь при условии аккуратного проектирования работает.

Ну так работает же))

Цитата --Ins-- @ 27.01.11, 22:36

А при нем и гарантии не нужны особенно-то. Даже наоборот - вот облом будет если тебе гарантировали, и не исполнили

Вообще то нужны. Хотя... смотря как работаешь. Если в одиночку -- то на самодисциплину можно возложить не только константность. Например вполне можно положить на проверку на валидность входящих параметров, как таковых. Если точно знаешь, что они всегда валидны. В групповой разработке, либо написании библиотечного кода гарантии очень даже нужны.

Цитата --Ins-- @ 27.01.11, 22:36

Ну, сразу и все А если ты предполагаешь у этого объекта другого неконстантные методы вызвать. Понятно что притянуто, но мало ли... В любом случае все ясно Гарантия ваша далеко не 100%-ая

Она у нас на уровне логики и помощи со стороны компилятора. Вот ты зачем язык со статической типизацией используешь?
Вот и тут также. Это дополнительные возможности системы типов языка, которые позволяют тебе отлавливать ошибки как в логике, так и в "физике" еще на этапе компиляции.

Цитата

а лишь при условии аккуратного проектирования работает.

Аккуратно проектировать желательно всегда. Хотя Delphi толкает к плохому, согласен.

Цитата

А при нем и гарантии не нужны особенно-то.

Ошибаешься.

Цитата

Даже наоборот - вот облом будет если тебе гарантировали, и не исполнили

Так не получится.

Цитата D_KEY @ 27.01.11, 22:36

--Ins--, так можно увидеть связь "компоновщика" с const?

Как мне уже объяснили, для поля своего класса можно вызывать только константные методы, так что по части компоновщика - отбой. Но это не важно. Важно что в принципе ваша гарантия является таковой только при аккуратном проектировании

Цитата --Ins-- @ 27.01.11, 22:36

Гарантия ваша далеко не 100%-ая, а лишь при условии аккуратного проектирования работает. А при нем и гарантии не нужны особенно-то. Даже наоборот - вот облом будет если тебе гарантировали, и не исполнили

Я давно понял, что ты к этому клонишь. Но это не так. Она практически 100%-ая, малая толика остаётся на const_cast и прочие хаки.

Итак:
Delphi - гарантия 0%
C++ - гарантия больше 0% (при грамотном проектировании) 100%
С++ победил, я пошел спать

Цитата --Ins-- @ 27.01.11, 22:36

Гарантия ваша далеко не 100%-ая, а лишь при условии аккуратного проектирования работает. А при нем и гарантии не нужны особенно-то. Даже наоборот - вот облом будет если тебе гарантировали, и не исполнили

Ты просто не понимаешь как именно его можно изменить, да изменить можно, применив тот же const_cast, но это уже никакая не гарантия, и модификатор const у метода там нафик не нужен... Тоесть это что то типо:
Есть у тебя класс, к примеру для работы с большими числами, есть у него к примеру операция сложения, и в документации к интерфейсу этого класса гарантируется, что эта операция возвращает сумму двух больших чисел, ты ее юзаешь, и на практике выходит что ты получил не сумму а разность, вот о такой ты видимо гарантии говоришь??? Ну так это и называется говнокодом... А по нормальному(тоесть без хаков и без применения анальных технологий) гарантия 100%...

Цитата --Ins-- @ 27.01.11, 22:40

Важно что в принципе ваша гарантия является таковой только при аккуратном проектировании

--Ins--, на С++ неаккуратно программировать нельзя(может быть только в билдере можно смастерить что-то работающее средней сложности, не понимая С++). Хорошо это или плохо - вопрос отдельный.
Именно отсюда столько "неосиливших", именно отсюда уход от многих его концепций в более поздних языках.