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

s>> Да. Желание разработчика получить профит от наличия const в языке. Если разработчик умеет это делать.
s>> Да. Опыт и здравый смысл.
·>Т.е. "мамой клянус". Я знаю. Возражение-то в чём?

В том, что в C++ есть возможность написать const для объекта. В Java нет.

s>> ·>Потому что ты понял, что сел в лужу с ссылками и указателями, которые вообще никаких полезных гарантий не дают.
s>> Звиздеть изволите. Ну или покажите хотя бы одно мое утверждение о том, что const ссылки/указатели дают гарантии.
·>Ок.

Ок что? Где цитата, которая подтверждает, что я что-то утверждал или "что сел в лужу с ссылками и указателями"?

·>То есть нет никаких гарантий, всё мамой клянус.

Дяденька, вы реально настолько поехавший?

[[nodiscard]]
std::thread
launch_thread(const vector_of_string & v, int iterations) {
    // Здесь компилятор запрещает модифицировать v.
    return std::thread{ [&v, iterations] {
        // Здесь компилятор запрещает модифицировать v.
        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;
    }};
}

Попробуйте в этом коде просто так модифицировать v.

·>Но тогда не требуй каких-то гарантий от других ЯП.

Схерали?

·>А то, видите ли, ява ничего не гарантирует

Не гарантирует.

·>зато в c++ молитва const позволяет писать правильный код.

Да.

s>> ·>зато иммутабельные объекты — нужны и полезны, и тащатся и используются повсюду.
s>> Только вот в Java у вас нет никакой помощи от компилятора в их реализации.
·>У тебя опять память подводит. Есть final, record и даже sealed интерфейсы.

Ну и как с помощью этого всего сдалать из HashMap неизменяемый HashMap? Ну вот был HashMap, требуется сделать так, чтобы его модифицировать нельзя было.

·>Как и const. Всё верно.

Для клинических идиотов повторю еще раз:

void mutate(std::vector<std::string> & v);

const std::vector<std::string> immutable_value{...};
mutate(immutable_value);

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

·>И что? У тебя проблемы с логикой. Достаточно одного опровергающего примера и похрен на миллион подтверждающих.

Хде, хде, блин, этот опровергающий пример. Пока ни одного не было. Были примеры с наличием const-ссылок, но отсутствием const-объектов.

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

Еще раз для клинических идиотов: дополнительные сущности, которые программист должен делать вручную (хоть и посредством IDE) без какого-либо контроля со стороны компилятора.

s>> ·>Ты так и не рассказал, как же она там _гарантированно_ появится?
s>> Примеры были показаны. Штудируйте матчасть.
·>Ты врёшь опять.

Вы не сможете подтвердить это цитатами.

·>В твоём примере показано

Да, было показано:

int main() {
    const vector_of_string immutable_data{ "Hello"s, "World"s }; // Все, гарантии появились.

[/ccode]

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

s>> Да. Желание разработчика получить профит от наличия const в языке. Если разработчик умеет это делать.
s>> Да. Опыт и здравый смысл.
·>Т.е. "мамой клянус". Я знаю. Возражение-то в чём?

В том, что в C++ есть возможность написать const для объекта. В Java нет.

s>> ·>Потому что ты понял, что сел в лужу с ссылками и указателями, которые вообще никаких полезных гарантий не дают.
s>> Звиздеть изволите. Ну или покажите хотя бы одно мое утверждение о том, что const ссылки/указатели дают гарантии.
·>Ок.

Ок что? Где цитата, которая подтверждает, что я что-то утверждал или "что сел в лужу с ссылками и указателями"?

·>То есть нет никаких гарантий, всё мамой клянус.

Дяденька, вы реально настолько поехавший?

[[nodiscard]]
std::thread
launch_thread(const vector_of_string & v, int iterations) {
    // Здесь компилятор запрещает модифицировать v.
    return std::thread{ [&v, iterations] {
        // Здесь компилятор запрещает модифицировать v.
        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;
    }};
}

Попробуйте в этом коде просто так модифицировать v.

·>Но тогда не требуй каких-то гарантий от других ЯП.

Схерали?

·>А то, видите ли, ява ничего не гарантирует

Не гарантирует.

·>зато в c++ молитва const позволяет писать правильный код.

Да.

s>> ·>зато иммутабельные объекты — нужны и полезны, и тащатся и используются повсюду.
s>> Только вот в Java у вас нет никакой помощи от компилятора в их реализации.
·>У тебя опять память подводит. Есть final, record и даже sealed интерфейсы.

Ну и как с помощью этого всего сделать из HashMap неизменяемый HashMap? Ну вот был HashMap, требуется сделать так, чтобы его модифицировать нельзя было.

·>Как и const. Всё верно.

Для клинических идиотов повторю еще раз:

void mutate(std::vector<std::string> & v);

const std::vector<std::string> immutable_value{...};
mutate(immutable_value);

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

·>И что? У тебя проблемы с логикой. Достаточно одного опровергающего примера и похрен на миллион подтверждающих.

Хде, хде, блин, этот опровергающий пример? Пока ни одного не было. Были примеры с наличием const-ссылок, но отсутствием const-объектов.

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

Еще раз для клинических идиотов: дополнительные сущности, которые программист должен делать вручную (хоть и посредством IDE) без какого-либо контроля со стороны компилятора.

s>> ·>Ты так и не рассказал, как же она там _гарантированно_ появится?
s>> Примеры были показаны. Штудируйте матчасть.
·>Ты врёшь опять.

Вы не сможете подтвердить это цитатами.

·>В твоём примере показано

Да, было показано:

int main() {
    const vector_of_string immutable_data{ "Hello"s, "World"s }; // Все, гарантии появились.