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

BFE>Не, согласно пропазлу, это должен быть именно шаблон:
BFE>

BFE>struct B
BFE>{
BFE>    template<class T> void vfun(T t) { std::cout << t << '\n'; }
BFE>    template <typename Self, class T> void f1(this Self&& self, T t) { self.vfun(t); }
BFE>};

BFE>struct D: B 
BFE>{
BFE>    template<class T> void vfun(T t) { std::cout << "D:t=" << t << '\n'; }
BFE>};

BFE>struct C: B 
BFE>{
BFE>    template<class T> void vfun(T t) { std::cout << "C:t=" << t << '\n'; }
BFE>};

BFE>int main()
BFE>{
BFE>    D d{};
BFE>    C c{};
BFE>    B* pb = &d;
BFE>    d.f1(1);        // обязан вывести D:t=1 
    pb->>f1(1);      // output: 1 :(
BFE>    pb = &c;
    pb->>f1("asdf"); // output: asdf  :(
BFE>    c.f1("asdf");   // обязан вывести C:t=asdf
BFE>    return 0;
BFE>}
BFE>

BFE>я пока проверить не могу.

VC++ версия 19.36.32532 (сегодня обновил VS2022):

D:t=1
1
asdf
C:t=asdf

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

NB>иными словами, основная мысль, "выкиньте c++ и используйте dsl"?
Вы давно писали свою реализацию C++? А DSL?
NB>мысль не новая, но пока какого-то массированного применения дсл для решения общих задач почему-то не наблюдается
Нет мысль не в этом. Мысль в том что в рамках c++ что-то новое не появится (кроме более затейлевых UB).

NB>не совсем понял, это написано "си и луа", или "экспериментирую с" +lua
NB>если первое то тоже довольно старая комбинация, но на замену c++ никак не тянет
Я где-то написал что это замена? Я к тому что эта связка позволяет её применять к любым задачам довольно не ожиданными способами. При этом весь набор инструментов максимально ни от чего не зависит и ни чем не ограничивает поле для экспериментов.

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

NB>>иными словами, основная мысль, "выкиньте c++ и используйте dsl"?
_>Вы давно писали свою реализацию C++? А DSL?

не писал. а надо?

NB>>мысль не новая, но пока какого-то массированного применения дсл для решения общих задач почему-то не наблюдается
_>Нет мысль не в этом. Мысль в том что в рамках c++ что-то новое не появится (кроме более затейлевых UB).

а, понятно
мне просто показалось что предлагается что-то более конструктивное

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

_>>Вы давно писали свою реализацию C++? А DSL?
NB>не писал. а надо?
У всех разные интересы. Если вам удобнее пользоваться готовым нет проблем.

NB>мне просто показалось что предлагается что-то более конструктивное
Ничего нового я не предлагаю, просто отделить разные понятия что бы было проще ими оперировать и структурировать их. А не смешивать всё в кучу, делая оптимизации на основании заведомо не верных рассуждений. И не вводить наркоманские понятия не связанные с реальностью для оправдания подобных оптимизаций.

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

NB>>мне просто показалось что предлагается что-то более конструктивное
_>Ничего нового я не предлагаю, просто отделить разные понятия что бы было проще ими оперировать и структурировать их. А не смешивать всё в кучу, делая оптимизации на основании заведомо не верных рассуждений. И не вводить наркоманские понятия не связанные с реальностью для оправдания подобных оптимизаций.

дык я не возражаю
просто покажи где это уже сделано и работает

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

BFE>Почему функциональность std::start_lifetime_as<T> и std::launder нельзя было бы повесить на reinterpret_cast<T> ?

reinterpret_cast обычно обслуживает уже имеющийся живой объект.
Если не брать приведение целочисленных типов по-значению, он приводит в других случаях указатели и ссылки.
Причём, требуется, чтобы было приведение к правильному типу, иначе UB.
Одновременно с этим оно означает, что экземпляр типа был уже создан ранее и его жизненный цикл "кем-то" отслеживается.

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

S>>- есть final и records.
·>Верно. И они относятся к более полезной идее — иммутабельность, а не константность.

Дык, мало того, что через константность в С++ легко получить иммутабельность (если требуется именно она), но еще эта иммутабельность может начинаться с некоторой нужной точки в коде.
И это натуральная киллер-фича! ))

Например:

std::map<int, int> buildMap() {
    std::map<int, int> result;

    result.insert(42, 43); // мутабельность
    ...
    return result;
}

const std::map<int, int> someDictionary = buildMap(); // сохранили в иммутабельный объект

В шарпе для такого сценария есть отдельно иммутабельный аналог map, и отдельно мутабельный builder для него.
В С++ не потребовалось создавать две сущности.

Этот сценарий может возникнуть не только вокруг иммутабельного map, где в шарпе постелили соломку, а вообще везде.

Собсно, только об этом и говорится в обсуждении (многократно по кругу) — что практически любой мутабельный тип можно использовать в т.ч. в иммутабельных сценариях.

Остальные сценарии, когда мутабельный объект подаётся по константной ссылке — это просто удобные гарантии, т.к. после вызова метода с таким аргументом ты можешь в коде рассуждать о том, что целевой объект в результате вызова некоей ф-ии с им-аргументом, не изменился.

V>Например:
V>

std::map<int, int> buildMap() {
    std::map<int, int> result;

    result.insert(42, 43); // мутабельность
}

const std::map<int, int> xxx = buildMap(); // сохранили в иммутабельный объект

Вопрос с подвохом: что если происходит NRVO и result с xxx обозначают один и тот же объект. Он будет константным?

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

σ>Вопрос с подвохом: что если происходит NRVO и result с xxx обозначают один и тот же объект.

Ничего особенного.
Результат начинает свой лайфтайм после возврата из хелпера-инициализатора.

σ>>Вопрос с подвохом: что если происходит NRVO и result с xxx обозначают один и тот же объект.

V>Ничего особенного.



V>Результат начинает свой лайфтайм после возврата из хелпера-инициализатора.

Т.е. внутри buildMap result обозначает объект вне лайфтайма? Значит на нём нельзя вызывать методы.

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

σ>Т.е. внутри buildMap result обозначает объект вне лайфтайма? Значит на нём нельзя вызывать методы.

Не понял проблемы. Да, адрес у объектов один и тот же, но в одном контексте считается, что по этому адресу объект менять нельзя, а в другом — что можно.
А вот определить константность объекта в С++ невозможно.

σ>>Т.е. внутри buildMap result обозначает объект вне лайфтайма? Значит на нём нельзя вызывать методы.

TB>Не понял проблемы. Да, адрес у объектов один и тот же

У объектов? При NRVO это один объект.

TB>но в одном контексте считается, что по этому адресу объект менять нельзя, а в другом — что можно.

Что значит «считается»?

TB>А вот определить константность объекта в С++ невозможно.

NRVO поймать-то можно.

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

σ>>>Т.е. внутри buildMap result обозначает объект вне лайфтайма? Значит на нём нельзя вызывать методы.

TB>>Не понял проблемы. Да, адрес у объектов один и тот же

σ>У объектов? При NRVO это один объект.

TB>>но в одном контексте считается, что по этому адресу объект менять нельзя, а в другом — что можно.

σ>Что значит «считается»?

Не очень понятна суть вопросов. В С++ даже у константных объектов есть период времени, когда они константами не считаются:

#include <iostream>

class demo {
public:
    demo() {
        f();
    }

    void f() { std::cout << "I'm not const!" << std::endl; }
    void f() const { std::cout << "I'm const..." << std::endl; }
};

int main() {
    const demo d; // d.f() will be called in the constructor.
    d.f();
}

цинк: https://wandbox.org/permlink/ssqBdbzjjTmb9YoI

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

V>>Результат начинает свой лайфтайм после возврата из хелпера-инициализатора.
σ>Т.е. внутри buildMap result обозначает объект вне лайфтайма? Значит на нём нельзя вызывать методы.

Забавные рассуждения, однако. ))
(у меня там были описки, исправил исходный пример http://www.rsdn.org/forum/cpp/8581544.1)

Переменная result внутри метода имеет свой лайфтайм, не связанный с оным у переменной someDictionary.
Что касается оптимизации возвращаемого значения — это низкоуровневая механика компилятора, ничего не меняющая в семантике исходного кода (если конструктор/деструктор без побочных эффектов).

На проблемы тут можно нарваться только в динамической фазе инициализации глобальных переменных, если переменная someDictionary глобальная и кто-то её юзает до инициализации или умудрился создать в коде динамической инициализации еще один поток и оттуда юзает эту переменную одновременно с наполнением её данными из основного потока.
(после инициализации иммутабельного someDictionary к нему безопасно обращаться из разных потоков без блокировки)

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

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

TB>>Не понял проблемы. Да, адрес у объектов один и тот же
σ>У объектов? При NRVO это один объект.

Дудки! ))
Это одна область памяти, в которой по очереди живут два объекта.

А что для трансформации первого объекта во второй не потребовалось никаких телодвижений — не ваше дело, как грится, тут компилятору виднее. ))


TB>>но в одном контексте считается, что по этому адресу объект менять нельзя, а в другом — что можно.
σ>Что значит «считается»?

Есть такое слово "семантика".


TB>>А вот определить константность объекта в С++ невозможно.
σ>NRVO поймать-то можно.

Но проблем там никаких (при условии, повторюсь, отсутствия побочных эффектов в конструкторе и деструкторе).

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


V>В шарпе для такого сценария есть отдельно иммутабельный аналог map, и отдельно мутабельный builder для него.
V>В С++ не потребовалось создавать две сущности.
Именно, то же самое на шарпах делается с помощью интерфейса. А две сущности в C++ тоже есть, просто неявно. Вместо явного интерфейса делается пара const- и просто-методов. Константные объекты появляются не магически, а в определениях соответствующих полей и методов.

V>Этот сценарий может возникнуть не только вокруг иммутабельного map, где в шарпе постелили соломку, а вообще везде.
И там и там надо вводить два типа. Ведь T и const T это тоже разные типы.

V>Собсно, только об этом и говорится в обсуждении (многократно по кругу) — что практически любой мутабельный тип можно использовать в т.ч. в иммутабельных сценариях.
"Практически" в том смысле если для типа правильно спроектирован const подтип. Ровно та же петрушка, что и с интерфейсом.

V>Остальные сценарии, когда мутабельный объект подаётся по константной ссылке — это просто удобные гарантии, т.к. после вызова метода с таким аргументом ты можешь в коде рассуждать о том, что целевой объект в результате вызова некоей ф-ии с им-аргументом, не изменился.
Аналог final.

Суть моего тезиса в том, что семантика const в других ЯП выражается тоже, просто через другие механизмы языка.

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

TB>> ·>Не понял, ты же в мапу ключ кладёшь снаружи. Или мапа копию делает?
TB>> Копию, конечно.
·>А если указатель?

Тогда ключом является адрес. ))


TB>> ·>Скажем, ключом в мапе может быть массив из миллиона элементов... Дальше продолжать?
TB>> Мув-копию.
·>А если массив является ключом в двух разных мапах?

Встроенный массив не имеет операции сравнения, поэтому не может быть ключом.
Речь может идти о некоем типе-обертке над массивом, в котором ты уже сам разбираешь с принципом владения — static-immutable, unique или shared.


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

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

template<typename T>
class Pointer {
    T * ptr_;

public:
    Pointer(T * ptr = nullptr) : ptr_(ptr) {}

    T * operator->() { return ptr_; }

    const T * operator->() const { return ptr_; }
};

TB>> а вот итерация по мапе делается регулярно и там проследить за кривыми руками кодера сложнее.
·>Короче, может и есть какие-то средства, работающие в каких-то сценариях, никакой гарантии нет.

Гарантии создаёт программист согласно требуемой семантике, разумеется.
Разумеется, и в джаве и в плюсах можно обеспечить все требуемые гарантии.

Здесь сравнивается цена телодвижений в различных сценариях. ))
Абсолютно все подходы джавы по обеспечению гарантий иммутабельности или константности в плюсах есть, что уже не может дать джаве никакого преимущества в этом вопросе. ))
Но сверху этого в плюсах есть в разы более выразительные механизмы, позволяющие не писать лишний код (не засорять им бинарник).

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

·>

·>std::map<std::reference_wrapper<const int>, std::string> map;
·>int key = 42;
·>map[key]= "hi";
·>key++; //упс! Мапа сломана.
·>

reference_wrapper хранит ссылку как значение, т.е. придаёт ссылке св-ва указателя.
Соотв, когда будешь описывать операторы сравнения для reference_wrapper, сравнивать надо identity ссылаемых объектов, а не содержимое.

Если же охота рассматривать указатели не как identity, а как агрегаторы, "превращающие" ссылочное владение по семантике к владению по значению, то надо соотв. распространять константность:
http://www.rsdn.org/forum/cpp/8582434.1

В любом случае, пример твой некорректен согласно логике спора, бо ты пытаешься рассуждать об потенциальных ошибках обеспечения константности-иммутабельности, где ошибки можно допустить и в джаве (и где угодно) в попытках обеспечения этой иммутабельности.

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

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

R>>Потому что константность ссылки/указателя не гарантируют неизменности адресуемых данных. И тем не менее, программист МОЖЕТ обеспечить реальную константность адресуемых данных. И в этом случае их неизменность будет гарантирована в well-defined программе. Короче говоря, да, в этой области больше возможностей выстрелить себе в ногу. Но и возможность писать добротные надежные программы тоже есть.
·>Я это прекрасно знаю. Ровно то же и в java. Просто T4r4sB заявил

Автор: T4r4sB
Дата: 12.05.23

, что в C++ есть какая-то защита в виде const. Да не даёт const ровным счётом ничего.

Даёт экономию труда примерно вдвое в обсуждаемых сценариях.


·>Только если либо копия передаётся, либо передача ownership, и это немного помогает в некоторых случаях, но возможностей стрельнуть в ногу всё равно дофига.

Возможностей стрельнуть себе в ногу дофига где угодно.
Тут рассуждения такие: меньше кода — меньше ошибок.

TB>>>Не понял проблемы. Да, адрес у объектов один и тот же
σ>>У объектов? При NRVO это один объект.

V>Дудки! ))
V>Это одна область памяти, в которой по очереди живут два объекта.



[class.copy.elision]/1: When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the constructor selected for the copy/move operation and/or the destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy/move operation as simply two different ways of referring to the same object.

В общем, уровень (не)компетентности понятен. Оттуда и ощущения/заявления, что «всё просто».

	Скрытый текст
	— Да что тут предлагать?.. А то пишут, пишут… Конгресс, немцы какие-то… Голова пухнет. Взять все, да и поделить… … — Да какой тут способ, дело не хитрое.