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

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

VD>>Вот если "Hello " + "world" будет заниматься побайтным сложением строк, или еще какую фигню делать, то это уже будет уродство.

Т>А каково "правильное" значение выражения
Т>

Т>(1 2 3) + (4 5 6)
Т>

Т>?
Т>Есть по крайней мере 2 варианта
Т>

Т>a) (1 2 3 4 5 6)
Т>b) (5 7 9)
Т>

А (4 5 6) это на каком языке, и что означет?

Мы вроде про строки говорили. У тебя есть сомнения по поводу того что делает приведенная тобой конструкция? Нет, ну, и не нужно высасывать проблему из пальца.

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

Т>Но есть не менее общепринятая интерпретация для сложения двух векторов.

А причем тут векторы?

У тебя часм проблем с пониманием принципов ООП нет?

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

Т>Соглашусь. Но лично я предпочел бы вместо "+", нечто более оригинальное.

Не вижу чем здесь "+" хуже. Ну, в некоторых языках вообще "&" используют. Тоже особых проблем не возникает.

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

E>Справедливости ради можно добавить, что в зависимости от левого операнда оператора сдвига выполняемое действие может очень сильно меняться

О, да. От смены функции тоже.

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

O>Обычно я не оверквочу, но мне пришлось оставить самую первую фразу:

Так и нужно было сделать вот так:
>>>>>>Overloading function names saves time during writing by saving keystrokes and, more significantly, saves the mental effort of thinking up unique names...
ANS>В критикуемой цитате об этом и говорится.

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

Уговорил

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

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

E>>Справедливости ради можно добавить, что в зависимости от левого операнда оператора сдвига выполняемое действие может очень сильно меняться

VD>О, да. От смены функции тоже.

Влад, ты что, сейчас ответил, чтобы ответить?
Ведь если пытаться с помощь функций выражать операции помещения объекта в какой-то специфический поток, то желательно, чтобы функции имели осмысленные имена:

print( std::cout, my_data );
serialize( xml, my_data );
serialize( asn1, my_data );
calculate( hash, my_data );

а не:

shift( std::cout, my_data );
shift( xml, my_data );
shift( asn1, my_data );
shift( hash, my_data );

А если функции помещения объекта куда-то именются по разному, то писать обобщенный код становится сложнее.

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

ANS>>Как по мне, то есть более приемлемый вариант — введение нового оператора, a-la "&" в VB, "," в ST или упоминавшееся выше "~" в D.
ANS>>Кстати, в развитие темы, зачем ограничиваться строками? В ST "," применим ко всем упорядоченным коллекциям. Типа:
ANS>>#(1 2 3) , #(4 5 6)
ANS>>Результат #(1 2 3 4 5 6)

O>Согласен, но такая фича должна быть встроена в язык. Т.е. из тех операторов, что есть в C++ (C#), наилучший кандидат — именно +. И использовать его для конкатенации строк не есть зло.

Я потому своё несогласие в виде минуса расписывать не стал, что это во многом не формализуемую ощущение правильности. Тебе кажется это правильно, мне — нет. А аргументов типа "вон там ракета бабахнула из-за исспользования + для конкатенации" у меня нет.
И вообще, нечего тут сокращать, ибо для конкатенации множества строк всё равно прийдётся StringBuilder создавать.

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

SK>Просвети, кстати, зачем, если не для этого?

Единообразием использования встроенного и пользовательского типов. Ты же пишешь (3+4)/5 а не 3.add(4).div(5).
Например если в шаблонный класс для подсчёта корней уравнения вместо double подставить какой-нибудь класс для вычислений с повышенной точностью вместо double, то код шаблонного класса не надо будет менять.

Здравствуйте, Кодёнок, Вы писали:

Кё>Конкатенация и сложение два разных оператора. Другие языки специально для конкатенации используют не +.

Кё>Возможно, для конкатенации лучше использовать & (and). Тогда (1 2 3) & (3 4 5) -> (1 2 3 3 4 5), а (1 2) + (3 3) -> (4 5).

Побитовое И?

В ПХП, например, — это точка. Но точка там, насколько я помню, не используется для доступа к членам класса, поэтому вполне допустима с этой точки зрения. В Си++ я не вижу символа более подходящего, чем +.

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

E>А если функции помещения объекта куда-то именются по разному, то писать обобщенный код становится сложнее.

По сути, все сводится к вопросу как лучше называть функции: print/serialize/calculate или do_something/do_something/do_something

Здравствуйте, Andrei N.Sobchuck, Вы писали:

O>>Согласен, но такая фича должна быть встроена в язык. Т.е. из тех операторов, что есть в C++ (C#), наилучший кандидат — именно +. И использовать его для конкатенации строк не есть зло.

ANS>Я потому своё несогласие в виде минуса расписывать не стал, что это во многом не формализуемую ощущение правильности. Тебе кажется это правильно, мне — нет. А аргументов типа "вон там ракета бабахнула из-за исспользования + для конкатенации" у меня нет.

Где-то так. Ветку можно закрыть

ANS>И вообще, нечего тут сокращать, ибо для конкатенации множества строк всё равно прийдётся StringBuilder создавать.

Это если у тебя есть StringBuilder (возвращаясь к C++)... Правда, и в C++ никто не будет делать тысячу конкатенаций (ибо опять же тормоза)...

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

ANS>>И вообще, нечего тут сокращать, ибо для конкатенации множества строк всё равно прийдётся StringBuilder создавать.

O>Это если у тебя есть StringBuilder (возвращаясь к C++)...

std::ostringstream?

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

O>>Это если у тебя есть StringBuilder (возвращаясь к C++)...

E>std::ostringstream?

М.б. Позабывал всё напрочь

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

Кё>>Конкатенация и сложение два разных оператора. Другие языки специально для конкатенации используют не +.
Кё>>Возможно, для конкатенации лучше использовать & (and). Тогда (1 2 3) & (3 4 5) -> (1 2 3 3 4 5), а (1 2) + (3 3) -> (4 5).
A>Побитовое И?

Просто "И". Это у тебя привычка так о нем думать, потому что для целых оно побитовое.

A>В ПХП, например, — это точка. Но точка там, насколько я помню, не используется для доступа к членам класса, поэтому вполне допустима с этой точки зрения. В Си++ я не вижу символа более подходящего, чем +.

Это для строки. А для последовательности или матрицы появляется упомянутый Трурлем конфликт.

Вообще давайте отличать значение символа от своих привычек Амперсанд, обозначает союз "и" (et), который почти всегда (кроме битовых и логических операций, которые суть одно и то же) обозначает соединение оригинальных объектов вместо, а вот за плюсом стоит создание нового объекта.

Маша и Вася и Клава и Марина и Петя = (Маша Вася Клава Марина Петя)
Маша + Вася + Клава + Марина + Петя = /* групповуха? */
(1 2) & (3 4 5 6) = (1 2 3 4 5 6) // соединение
(1 2) + (3 4 5) = ошибка
(1 2) + (3 4) = (4 6) // векторная операция, сложение векторов. Есть еще матрицы. Символ "+" это математическое сложение, и применять его для конкатенации имхо плохая идея.

Есть еще cons. Это почти то же, но образуется всегда список-пара:
1 :: 2 = (1 2)
(1 2) :: 3 = ((1 2) 3)
(1 2) :: (3 4) = ((1 2) (3 4))

Чем больше в языке операторов, которые можно перегрузить, тем он потенциально более выразителен. Понятие последовательности есть в любом языке (в С++ его ввели в STL, например), логично было бы ввести базовые операторы над списками. В современных программах побитовое "И" встречается редко, и вполне могло решаться функцией. Упомянутый Трурлем конфликт заключается всего лишь в недостатке выразительных средств языка, но никак не сойдет за аргумент против перегрузки "+".

Возможность вводить новые типы (ПОЛНОПРАВНЫЕ с встроенными) тоже увеличивает выразительность, и перегрузка операций просто обязана сопутствовать этой возможности. Иначе они не будут полноправными Автор стати выдумал какие-то мифические проблемы.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>И вообще, нечего тут сокращать, ибо для конкатенации множества строк всё равно прийдётся StringBuilder создавать.

Для того чтобы конкатекация была эффективной? Вовсе нет StringBuilder это излишество вызванное как раз неиспользованием перегрузки операторов.

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

ANS>>И вообще, нечего тут сокращать, ибо для конкатенации множества строк всё равно прийдётся StringBuilder создавать.

A>Для того чтобы конкатекация была эффективной? Вовсе нет StringBuilder это излишество вызванное как раз неиспользованием перегрузки операторов.

Вы про C# StringBuilder? Это ж как надо перегружать, чтобы конкатенация через + была столь же эффективной (например, сборка строки в цикле)?

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

O>Вы про C# StringBuilder? Это ж как надо перегружать, чтобы конкатенация через + была столь же эффективной (например, сборка строки в цикле)?

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

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

O>>Вы про C# StringBuilder? Это ж как надо перегружать, чтобы конкатенация через + была столь же эффективной (например, сборка строки в цикле)?

A>Надо просто отложить сборку до первого чтения строки

Как вариант... но StringBuilder всё равно выходит функциональнее и [немного] эффективнее (надо же в таком случае внутри хранить некий список конкатенируемых строк, даже скорее дерево, — накладные расходы на это).

А вообще идея хорошая

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

O>>Вы про C# StringBuilder? Это ж как надо перегружать, чтобы конкатенация через + была столь же эффективной (например, сборка строки в цикле)?
A>Надо просто отложить сборку до первого чтения строки

А может вообще возвращать ленивую строку, которая будет имитировать обычную?