Товарищи, а что комитет думает по поводу нечленовых operator += например?

И нечленовых operator=

извини, каких?

это что за звери такие?

ну non-member перегрузки операторов

например, чтобы можно было делать так: string& operator=(string &, const MyClass &); string str; str = MyClass();

это что за звери такие?

он например про переопределение operator<< для cout (который можно объявить только в виде свободной функции)

ну non-member перегрузки операторов

юзкейс?

юзкейс?

+ выстрел в ногу?

юзкейс?

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

Чтобы стреляли исключительно в свою ногу, сделать правило. что это работает только в неймспейсе, где оператор объявлен, как в Rust. А когда это в C++ оберегали от прострела своей ноги?

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

так это разве не разрешено?

так это разве не разрешено?

Ну operator= нет. operator+= тоже

operator<< для всяких потоков точно разрешён

operator<< для всяких потоков точно разрешён

Так вот и я о том, что-то дали, что-то - нет. В чём причина диссонанса?

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

https://godbolt.org/g/jjsyHA

но лучше так не делать очевидно

Там же временная строка создаётся. А если есть возможность не делать временной строки?

Чтобы стреляли исключительно в свою ногу, сделать правило. что это работает только в неймспейсе, где оператор объявлен, как в Rust. А когда это в C++ оберегали от прострела своей ноги?

Это потому, что эти операторы подразумевают то, что ты знаешь кишки класса. Для операторов << >> это не обязательно в контексте ввода-вывода в поток.

Строка это просто самый понятный пример, оно более пригодно, если у нас будет какой-нибудь std::variant, и не хочется плодить к нему ещё один вариант, проще свести к имеющемуся.

Это потому, что эти операторы подразумевают то, что ты знаешь кишки класса. Для операторов << >> это не обязательно в контексте ввода-вывода в поток.

Но ведь кишки класса, в принципе, и так скрыты, в чём проблема разрешить операторы то?

Но ведь кишки класса, в принципе, и так скрыты, в чём проблема разрешить операторы то?

Эм, а как ты собираешься реализовать, например, operator=, не зная реализации класса?

Эм, а как ты собираешься реализовать, например, operator=, не зная реализации класса?

А почему нет? Если у нас есть способ преобразования, который мы можем реализовать функцией или оператором каста - эту же логику и в operator= вписать. Это позволит избежать временных объектов. А они бывают массивными.

Здравствуйте

Там же временная строка создаётся. А если есть возможность не делать временной строки?

Нет возможности, у тебя нет доступа к кишкам стд стринг

Можете подсказать

Нет возможности, у тебя нет доступа к кишкам стд стринг

А зачем они мне, если мне нужно сделать clear(); reserve(); append() ?

А почему нет? Если у нас есть способ преобразования, который мы можем реализовать функцией или оператором каста - эту же логику и в operator= вписать. Это позволит избежать временных объектов. А они бывают массивными.

яннп

Почему если я написал алгоритм в dev cpp ide и все корректно работает

Почему если я написал алгоритм в dev cpp ide и все корректно работает

@supapro

Если пишу алгоритм в visual c++

То не работает?

А зачем они мне, если мне нужно сделать clear(); reserve(); append() ?

Лол тогда это вывод в поток

А зачем они мне, если мне нужно сделать clear(); reserve(); append() ?

Это неэффективно для начала

Не компилируется

Не компилируется

какой компилятор использовался в dev cpp?

Лол тогда это вывод в поток

Товарищ, я же пример привожу, там может быть не строка, а сложный variant

Console application

Товарищ, я же пример привожу, там может быть не строка, а сложный variant

Я к тому что семантически это вывод в поток

Console application

это тип конечного приложения, а не компилятор

А не += к строке

Ммм

Я начинающий программист

Компилятор дев с++

Компилятор дев с++

@supapro

Спс

А не += к строке

Да я же не принципиально об этом примере. Я вообще о концепции. Для других типов это может быть не семантически вывод в поток если у меня std::variant<Type1, Type2>, а я хочу туда зафигачить Type3, котрый может быть оптимально приведён к Type1 без временного объекта

Да я же не принципиально об этом примере. Я вообще о концепции. Для других типов это может быть не семантически вывод в поток если у меня std::variant<Type1, Type2>, а я хочу туда зафигачить Type3, котрый может быть оптимально приведён к Type1 без временного объекта

Короче это в 50% вывод в поток в 50% это .str()

Явное лучше неявного

Да я же не принципиально об этом примере. Я вообще о концепции. Для других типов это может быть не семантически вывод в поток если у меня std::variant<Type1, Type2>, а я хочу туда зафигачить Type3, котрый может быть оптимально приведён к Type1 без временного объекта

Ключевое слово приведен

Ключевое слово приведен

тут и оно, оператор каста порождает временный объект=)

ERROR: S client not available

Я примерно понял что вы хотите

Вам короче лень оборачивать в свой класс

Вам короче лень оборачивать в свой класс

Так точно. Особенно, если это ради полторы строчки кода.

Ну потенциально это может развиться в больше чем полторы

Это всегда баланс и рефакторинг, так и работаем. Невозможно же всё запланировать.

А можно было сразу написать нормально

Обернуть вариант в класс

Обернуть вариант в класс

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

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

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

Тогда это проблема того кто писал такой интерфейс

Но присваивание перегружать вне класса это дичь

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

Потомучто этим операторам не нужно участвовать в ADL

Я бы сказал противопоказано

Так я и предлагаю разрешить их, но не доаавлять к ADL. Только свой неймспейс.

Так я и предлагаю разрешить их, но не доаавлять к ADL. Только свой неймспейс.

а это уже какието ифы в стандарте

не надо так

какието эвристики для частных случаев

А сейчас для них не иф чтоль?

нет

я конечно понимаю что раст построен на эвристиках

То есть, это всё должно работать на весь массив присваиваний, новых ифов это не создаст

Кто то писал алгоритм ,обойти конем шахматную доску ?

То есть, это всё должно работать на весь массив присваиваний, новых ифов это не создаст

>но не доаавлять к ADL

вангую что это выльется в квалификатор недобавлятькadl аkа explicit на все функции

Кстати, было же какое-то предложение к стандарту, которое позволяло вызывать size(const T &t) как t.size(), или я путаю?