Здравствуйте, rg45, Вы писали:

R>Не согласен. Сам по себе модификатор const не вынуждает писать дополнительные методы, а дает возможность программисту предоставить разные версии функций-членов для константного и не константного объектов — только в том случае, если это нужно!
Это не возможность, а обязанность. Как только они появляются то выясняется что нужно.
Не изменность данных может быть разной как по времени так и по форме.
Неизменность чего либо не обязательно неизменность участка памяти. Например одно и тоже целое число может быть представлено в разном виде но при этом оставаться этим же числом. Или более сложные формы инвариантов которые поддерживаются при работе программы.

R>Конечно, в каких-то простейших случаях могут возникать похожие на вид-функции члены, которые выглядят как дублирование, но это очень поверхностный взгляд, это во-первых.
Если кто-то обрабатывает const T& то сразу появляютcя методы ()const

R>Во-вторых, необходимость создания разных методов не является ни общим случаем, ни, тем более единственным — все зависит от семантики и дизайна класса.
R>Например, во многих случаях бывает достаточно одной только версии — константной.
Например метод size() должен быть константным или не обязательно?

R>если модификатор относится непосредственно к объекту.
А можно попросить не модифицировать только часть объекта или массива? А почему?

R>если модификатор пришел со ссылкой, у него просто другая семантика — но он является средством выдачи прав на чтение/запись.
Нафига эти церемонии в виде прав, тогда уж лучше токен на доступ приходит.

R>Так так и должно быть — const ни на что, кроме константности влиять и не должен. Опять не убедил.

Простой пример передали вам массив и просят его не менять. Можно сделать по разному
1. запретить любые записи в этот массив
2. в процессе работы функции меняем данные, но по выходу возвращаем в исходное состояние
В каждом варианте возможны разные виды оптимизаций, но d с++ только вар 1 с оговорками

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

R>Дальше вообще какая-то фантастика пошла.
Какая фантастика https://tour.dlang.org/tour/en/gems/contract-programming

Здравствуйте, kov_serg, Вы писали:

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

Здравствуйте, rg45, Вы писали:

R>Ты думаешь, если ты повторишь одно и тоже несколько раз, это зазвучит убедительнее?
возможно я просто хреново объясняю
const в c++ это просто частный инвариант причем который воспринимается по разному в разных ситуациях, что приводит к противоречиям (которые позволено компилятору, благодаря стандартизаторам, трактовать слишком вольно)

Здравствуйте, kov_serg, Вы писали:

R>>Ты думаешь, если ты повторишь одно и тоже несколько раз, это зазвучит убедительнее?
_>возможно я просто хреново объясняю
_>const в c++ это просто частный инвариант причем который воспринимается по разному в разных ситуациях, что приводит к противоречиям (которые позволено компилятору, благодаря стандартизаторам, трактовать слишком вольно)

Тем не менее, он играет важную роль. Например, когда мы видим:

class some_application_domain_type {...};

void do_something(const some_application_domain_type & o);

То мы понимаем, что объект в do_something отдается не для изменения (и что сам do_something не претендует на его изменение).

Да, здесь есть ряд оговорок и под капотом может быть разное, но по большей части такие аннотации делают код проще.
При программировании на Java, Ruby или Python, где подобного понятия константной ссылки нет, разбираться с кодом сложнее, т.к. изначально не ясно, будет ли do_something менять переданные ему аргументы или нет.

Тогда как в D константы (и не только) есть и там намного проще.

Как вы предлагаете обходиться без таких вещей как константные ссылки/указатели?

Неужели просто доверять программисту?

Здравствуйте, so5team, Вы писали:

S>Тем не менее, он играет важную роль. Например, когда мы видим:
S>

S>class some_application_domain_type {...};

S>void do_something(const some_application_domain_type & o);
S>

S>То мы понимаем, что объект в do_something отдается не для изменения (и что сам do_something не претендует на его изменение).

S>Да, здесь есть ряд оговорок и под капотом может быть разное, но по большей части такие аннотации делают код проще.
S>При программировании на Java, Ruby или Python, где подобного понятия константной ссылки нет, разбираться с кодом сложнее, т.к. изначально не ясно, будет ли do_something менять переданные ему аргументы или нет.

S>Тогда как в D константы (и не только) есть и там намного проще.

S>Как вы предлагаете обходиться без таких вещей как константные ссылки/указатели?

S>Неужели просто доверять программисту?
Нет просто описывать это отдельно от типа.

void do_something(some_application_domain_type & o) where o is immutable;

Здравствуйте, kov_serg, Вы писали:

S>>Как вы предлагаете обходиться без таких вещей как константные ссылки/указатели?

S>>Неужели просто доверять программисту?
_>Нет просто описывать это отдельно от типа.

_>void do_something(some_application_domain_type & o) where o is immutable;

Вы реально видите разницу между

void do_something(const some_application_domain_type & o);

и

void do_something(some_application_domain_type & o) where o is immutable;

Как по мне, так это все тот же фрагмент автопортрета Фаберже, но даже и не в профиль, а через неподходяшее отверстие.

Здравствуйте, so5team, Вы писали:

s> При программировании на Java
s> Как вы предлагаете обходиться без таких вещей как константные ссылки/указатели?
Принято вводить интерфейсы. Это позволяет определять любые группы методов обладающих определённым свойством, в том числе и константностью.
Как я понимаю, в плюсах интерфейс — это виртуальный вызов, дорого. Поэтому обычно не используется.

Здравствуйте, ·, Вы писали:

s>> Как вы предлагаете обходиться без таких вещей как константные ссылки/указатели?
·>Принято вводить интерфейсы. Это позволяет определять любые группы методов обладающих определённым свойством, в том числе и константностью.

И как такое свойство как "константность" проверяется в Java?

·>Как я понимаю, в плюсах интерфейс — это виртуальный вызов, дорого. Поэтому обычно не используется.

Вряд ли сильно дороже чем в Java

Upd. Константность в C++ появилась раньше, чем Java 1.0 вышла в свет.

Здравствуйте, so5team, Вы писали:

S>Вы реально видите разницу между
S>

void do_something(const some_application_domain_type & o);

S>и
S>

void do_something(some_application_domain_type & o) where o is immutable;

S>

S>Как по мне, так это все тот же фрагмент автопортрета Фаберже, но даже и не в профиль, а через неподходяшее отверстие.

Разница огромна. Вместо дополнительного типа у нас требования (ограничения) которые должна соблюдать функция. Они могут описывать разные виды ограничений.
Например:

void do_something(int o[3]) where o[1] is immutable; -- запрещено менять o[1]

void do_something(int o[3]) where o[1] is keep same; -- можно менять, но по выходу должно быть тоже значение что и при входе

void heap_op(int x[],int n) where x[0..n) is heap; -- на входе куча и на выходе должна быть куча x[k]<=x[2*k+{1,2}]

void do_something(some_type &o) where o keep up some_type.invariants;

Здравствуйте, kov_serg, Вы писали:

S>>Как по мне, так это все тот же фрагмент автопортрета Фаберже, но даже и не в профиль, а через неподходяшее отверстие.

_>Разница огромна.

Да, оказывается вы вещаете не о C++, а о каких-то своих фантазиях.

Этот ваш гипотетический язык пока только в ваших мечтах существует или уже есть какой-то работающий прототип?

Здравствуйте, so5team, Вы писали:

s>>> Как вы предлагаете обходиться без таких вещей как константные ссылки/указатели?
S>·>Принято вводить интерфейсы. Это позволяет определять любые группы методов обладающих определённым свойством, в том числе и константностью.
S>И как такое свойство как "константность" проверяется в Java?
В смысле имеет ли компилятор модель константности? Нет. Просто делается на уровне дизайна, т.е. тоже является частью системы типов. Иными словами, неясно почему именно константность должна быть каким-то особым свойством, которое должен проверять копилятор.
Скажем, "этот метод может только добавлять элементы в конец списка", а "этот метод может только читать" — это всё определённый контракты.

В любом случае это же просто ментальная пометка для человеков, всего лишь: "не претендует на его изменение". Ведь всё равно "do_something" может снять константность и навредить, или mutable может быть. Т.е. const это по сути контракт для человека, как и interface. Никакой разницы для машины нет.

S>·>Как я понимаю, в плюсах интерфейс — это виртуальный вызов, дорого. Поэтому обычно не используется.
S>Вряд ли сильно дороже чем в Java
В java есть virtual call elimination. В итоге виртуальные методы могут даже инлайниться. Или

Здравствуйте, ·, Вы писали:

S>>И как такое свойство как "константность" проверяется в Java?
·>В смысле имеет ли компилятор модель константности?

Да

·>Нет.

Оттож.

·>Просто делается на уровне дизайна, т.е. тоже является частью системы типов.

Иными словами "мамой клянусь"

·>Иными словами, неясно почему именно константность должна быть каким-то особым свойством, которое должен проверять копилятор.

Потому что человеку свойственно ошибаться. И когда компилятор бьет по рукам в compile-time, то это (как по мне) много лучше получения ошибок run-time.

·>В любом случае это же просто ментальная пометка для человеков, всего лишь: "не претендует на его изменение".

Не только для человека, это во-первых.

Во-вторых, и это уже очень и очень немало.

·>В java есть virtual call elimination.

В C++ тоже есть девиртуализация вызовов.

S>>·>Как я понимаю, в плюсах интерфейс — это виртуальный вызов, дорого. Поэтому обычно не используется.
S>>Вряд ли сильно дороже чем в Java
·>В java есть virtual call elimination. В итоге виртуальные методы могут даже инлайниться.
Да, про Java известно, что она, заинлайнив и специализировав всё и вся, может работать быстрее процессора, но почему-то всё равно тормозит (+ жрёт память)

Здравствуйте, so5team, Вы писали:

s> S>>И как такое свойство как "константность" проверяется в Java?
s> ·>В смысле имеет ли компилятор модель константности?
s> Да
Просто это частный и не самый интересный случай контракта, чтобы его прямо таки встраивать в компилятор.

s> ·>Просто делается на уровне дизайна, т.е. тоже является частью системы типов.
s> Иными словами "мамой клянусь"
В смысле то, что в get-методе он не даст _случайно_ поменять значение поля? Ну не знаю. Я не помню за последние ~10 лет каких-то ошибок связанных с этим.
Может это где-то и является проблемой, но я с этим не сталкиваюсь.

s> ·>Иными словами, неясно почему именно константность должна быть каким-то особым свойством, которое должен проверять копилятор.
s> Потому что человеку свойственно ошибаться. И когда компилятор бьет по рукам в compile-time, то это (как по мне) много лучше получения ошибок run-time.
Там где это действительно нужно, всегда можно сделать иммутабельный тип.

s> ·>В любом случае это же просто ментальная пометка для человеков, всего лишь: "не претендует на его изменение".
s> Не только для человека, это во-первых.
Только для человека. Компилятор с этим знанием ничего делать не сможет.

s> Во-вторых, и это уже очень и очень немало.
Кому как. А мне мало. Лучше бы он корректность компараторов проверял, вот тут ошибки так ошибки, и последствия вообще непредсказуемые, и хрен найдёшь. Но остаётся только мечтать...

s> ·>В java есть virtual call elimination.
s> В C++ тоже есть девиртуализация вызовов.
Наверное для этого придётся иметь статическую сборку со всеми либами и глобальную оптимизацию.
Ещё надо учесть, слово const было введено много лет назад, когда таких оптимизаций не было, и хоть что-то. Выбор виртуальных интерфейсов тупо не стоял.

Здравствуйте, ·, Вы писали:

·>Просто это частный и не самый интересный случай контракта, чтобы его прямо таки встраивать в компилятор.

Один из самых фундаментальнейших. Правда, в C++ его до ума не довели. А в D слегка переборщили.

Пользователям же Java/C#/Python/Ruby приходится уговаривать себя о том, что это не так уж и нужно.

·>В смысле то, что в get-методе он не даст _случайно_ поменять значение поля?

Как один из вариантов.

·>Ну не знаю.

А мне помогает. Раз-два в год компилятор явно показывает на проблемы в дизайне, когда есть константная ссылка, а объект хочется изменить.

И для этого не нужно городить интерфейсы.

·>Может это где-то и является проблемой, но я с этим не сталкиваюсь.

Аргумент из категории "у меня все работает".

·>Там где это действительно нужно, всегда можно сделать иммутабельный тип.

Так как в Java этот иммутабельный тип выражается кроме как гарантиями от разработчика "мамой клянусь"?

·>Только для человека. Компилятор с этим знанием ничего делать не сможет.

"Не верь глазам своим":

class demo {
  int i_{};

public:
  int value() const { return ++i_; } // Да, тут компилятор ничего сделать не сможет, ага ;)
};

·>Лучше бы он корректность компараторов проверял

Да и вообще нет кнопки "сделать зашибись!", так что "на помоечку", адназначна!

В Java компараторы компилятором проверяются?

·>Ещё надо учесть, слово const было введено много лет назад, когда таких оптимизаций не было, и хоть что-то. Выбор виртуальных интерфейсов тупо не стоял.

Выбор виртуальных интерфейсов встал перед Java-разработчиками из-за того, что Гослинг и Ко не смогли взять из C++ действительно лучшее, что в нем тогда было: ни константности, ни обобщенного программирования. Что поделать, знания C++ там застряли где-то на уровне 1989-го года, когда предтеча Java в проекте Oak задышала.

Здравствуйте, so5team, Вы писали:

s> Один из самых фундаментальнейших. Правда, в C++ его до ума не довели. А в D слегка переборщили.
Я тоже так думал, когда на плюсах много писал. И когда начал изучать java — очень не хватало и считал очень важным. Потом, с опытом, прошло.

s> ·>В смысле то, что в get-методе он не даст _случайно_ поменять значение поля?
s> Как один из вариантов.
Ну не знаю, может на этапе освоения программирования это и является проблемой, но и только и всего.

s> ·>Ну не знаю.
s> А мне помогает. Раз-два в год компилятор явно показывает на проблемы в дизайне, когда есть константная ссылка, а объект хочется изменить.
Так и с интерфейсами. Хочется дёрнуть этот метод, а он у класса, а в интерфейсе нет.

s> И для этого не нужно городить интерфейсы.
Нет никакого "городить". В плюсах приходится писать два варианта методов const|non-const, в java нужно только сигнатуру объявлять в интерфейсе. Кода даже меньше по итогу. А с современным IDE это всё элементарно рефакторится туда-сюда.

s> ·>Там где это действительно нужно, всегда можно сделать иммутабельный тип.
s> Так как в Java этот иммутабельный тип выражается кроме как гарантиями от разработчика "мамой клянусь"?
Что его значение никак не поменять. Нет способа "снять иммутабельность". Вроде можно через рефлексию (которую можно запретить), но без гарантий. Ещё теоретически можно через нативный вызов попортить участок памяти... но это уже не про java.

s> ·>Только для человека. Компилятор с этим знанием ничего делать не сможет.
s> int value() const { return ++i_; } // Да, тут компилятор ничего сделать не сможет, ага
А человек может.

s> В Java компараторы компилятором проверяются?
Нет, конечно. Надо AI встроить

s> ·>Ещё надо учесть, слово const было введено много лет назад, когда таких оптимизаций не было, и хоть что-то. Выбор виртуальных интерфейсов тупо не стоял.
s> Выбор виртуальных интерфейсов встал перед Java-разработчиками из-за того, что Гослинг и Ко не смогли взять из C++ действительно лучшее, что в нем тогда было: ни константности, ни обобщенного программирования. Что поделать, знания C++ там застряли где-то на уровне 1989-го года, когда предтеча Java в проекте Oak задышала.
Виртуальность по дефолту — было осознанным стратегическим решением. И, вроде неплохо вышло, получился вполне популярный яп.
Много чего упрощает, написание тестов, например.

Здравствуйте, so5team, Вы писали:

S>Да, оказывается вы вещаете не о C++, а о каких-то своих фантазиях.
Я к тому что надо что бы компилятор преобразовывал код на основе не верных предположений, используя наркоманские допущения из стандарта. А была возможность явно указывать все допущения, ограничения и предположения которые компилятор может смело использовать без необходимости что-то выдумывать. Все допущения по умолчанию как раз и являются источниками всех UB.

S>Этот ваш гипотетический язык пока только в ваших мечтах существует или уже есть какой-то работающий прототип?
Нет это можно делать на обычном C, но только с дополнительными телодвижениями.

Здравствуйте, ·, Вы писали:

s>> Один из самых фундаментальнейших. Правда, в C++ его до ума не довели. А в D слегка переборщили.
·>Я тоже так думал, когда на плюсах много писал. И когда начал изучать java — очень не хватало и считал очень важным. Потом, с опытом, прошло.

Или стокгольмский синдром

Я с момента появления Java несколько раз был вынужден ее использовать, и каждый раз натыкался на то, что в ней не хватает хотя бы константности из C++

·>Так и с интерфейсами. Хочется дёрнуть этот метод, а он у класса, а в интерфейсе нет.
·>Нет никакого "городить". В плюсах приходится писать два варианта методов const|non-const, в java нужно только сигнатуру объявлять в интерфейсе. Кода даже меньше по итогу. А с современным IDE это всё элементарно рефакторится туда-сюда.

А интерфейсы откуда берутся? Ладно бы Java позволяла отдельно определить тип, отдельно интерфейсы, да еще чтобы можно было автоматически объект привести к нужному интерфейсу (что-то вроде того, что в Go сделано). А то нужно сперва сделать интерфейс, потом в типе его имплементировать.

IDE, может быть, помогают писать ручками меньше, но всю эту кухню все равно в голове держать нужно.

И да, в C++ сейчас больше чем два варианта const|non-const: &, const &, && и, для ценителей, const &&
Правда, в C++23 вроде как это дело поправят, но как зачастую бывает в C++, через жопу.

s>> ·>Там где это действительно нужно, всегда можно сделать иммутабельный тип.
s>> Так как в Java этот иммутабельный тип выражается кроме как гарантиями от разработчика "мамой клянусь"?
·>Что его значение никак не поменять. Нет способа "снять иммутабельность"

Т.е. если программист не напишет setter, то тип считается иммутабельным?

s>> ·>Только для человека. Компилятор с этим знанием ничего делать не сможет.
s>> int value() const { return ++i_; } // Да, тут компилятор ничего сделать не сможет, ага
·>А человек может.

Тогда он ССЗБ. Компилятор его честно предупреждал. А вот когда даже таких предупреждений нет, то печально. Приходится городить интерфейсы и радоваться тому, что IDE это упрощает.

s>> В Java компараторы компилятором проверяются?
·>Нет, конечно. Надо AI встроить

О том и речь

·>Виртуальность по дефолту — было осознанным стратегическим решением. И, вроде неплохо вышло, получился вполне популярный яп.

Он не из-за этого стал популярным. Но речь о другом: авторы Java могли бы сделать его еще лучше сразу, если бы умели в C++ (а у меня есть сомнения, что умели). Однако, если бы они сразу взяли из C++ константаность и обобщенное программирование, то не факт, что язык настолько быстро и высоко взлетел бы.

Впрочем, это уже совсем другая история.

Здравствуйте, kov_serg, Вы писали:

S>>Да, оказывается вы вещаете не о C++, а о каких-то своих фантазиях.
_>Я к тому что надо что бы компилятор

Да-да-да, лучше быть богатым и здоровым, чем...

S>>Этот ваш гипотетический язык пока только в ваших мечтах существует или уже есть какой-то работающий прототип?
_>Нет это можно делать на обычном C, но только с дополнительными телодвижениями.

Посмотреть на это можно где-то?

Здравствуйте, so5team, Вы писали:

s> ·>Я тоже так думал, когда на плюсах много писал. И когда начал изучать java — очень не хватало и считал очень важным. Потом, с опытом, прошло.
s> Или стокгольмский синдром
Ага, но я не страдаю, я наслаждаюсь.

s> Я с момента появления Java несколько раз был вынужден ее использовать, и каждый раз натыкался на то, что в ней не хватает хотя бы константности из C++
Сила привычки и только.

s> А интерфейсы откуда берутся? Ладно бы Java позволяла отдельно определить тип, отдельно интерфейсы, да еще чтобы можно было автоматически объект привести к нужному интерфейсу (что-то вроде того, что в Go сделано). А то нужно сперва сделать интерфейс, потом в типе его имплементировать.
Просто другой mind-set. По кол-ву усилий — нисколько.

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

s> И да, в C++ сейчас больше чем два варианта const|non-const: &, const &, && и, для ценителей, const &&
s> Правда, в C++23 вроде как это дело поправят, но как зачастую бывает в C++, через жопу.
Мде... Больше — лучше!

s> ·>Что его значение никак не поменять. Нет способа "снять иммутабельность"
s> Т.е. если программист не напишет setter, то тип считается иммутабельным?
Иммутабельный тип имеет final-поля, которые нельзя изменить, нет никакого механизма снять final. А так же тип обычно тоже final (т.е. нельзя унаследоваться и переопределить поведение).

Можно делать некоторые исключения. Например, для lazy initialisation, когда в иммутабельном типе может быть non-final поле.

Константность это немного о другом. Это когда у тебя есть некий объект и в одном месте ты можешь его менять его состояние, а в другом — не можешь.
Если не зацикливаться на конкретно "менять", а обобщить до "совершать некие операции", то интерфейсы — оно и есть.

s> ·>А человек может.
s> Тогда он ССЗБ. Компилятор его честно предупреждал. А вот когда даже таких предупреждений нет, то печально. Приходится городить интерфейсы и радоваться тому, что IDE это упрощает.
Ты так говоришь, как будто это что-то плохое