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

E>Влад, ты что, сейчас ответил, чтобы ответить?

Я ответил, что думал.

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

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

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

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

Причем тут перегрузка?

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

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

Вообще то для строк сложение заменяется на вызов string.Concat() и string.Concat() эффективнее StringBuilder-а. Другое дело, что это все правильно для фиксированного количества строк. А вот если нужно в цикле по одной строчке канкотинировать, то StringBuilder рулит адназначна.

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

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

Сборку? Может конкатинацию? Ну, и как ее отложиет не заводя промежуточное хранилище?
А с промежуточным хранилицем будет не быстрее StringBuilder-а.

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

И какая разница со StringBuilder-ом?

ЗЫ

Шутку про "перенести в compile time" не понял.

Ну, аргументировать минус тоже не буду.

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

ГВ>Как минимум, она позволяет писать обобщённые конструкции, которые оперируют семантикой перекрываемых операторов. Нпаример, в STL часто пользуются перекрытием operator() для подмены функции функтором. Другой пример, перекрытие operator->() для smart-указателей.

Отличные примеры!... того как проблемы языка вынуждают делать совершенно казалось бы бесполезные вещи. А ведь казалось бы ЖЦ и делегаты решили бы все проблемы.

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

Q>Идеологически правильный вариант — выбрать другое обозначение для операции конкатенации. Ибо конкатенация по сути — это слияние списков, а не сложение.

Просто не нужно смотреть на строки как на списки. Строка — это объект. Для объектов этого класса логично воспринимать сложение как канкатинацию. Остальное от лукавого.

В общем, пусть любой кинет в меня камень если он способен не понять кострукцию "строка 1 " + "строка 2".

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

C> Ну это совсем идеалистический вариант — представление строки списком, всё-таки нечто с рандомным доступом подошло бы лучше.

Эээ... Quintanar почитатель функциональных языков. А там массивы — это мовитон.

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

Q>Это не совсем идеалистический вариант, кое-где так и сделано. Кроме того, никто не говорит о том, что обязательно нужно представлять строку списком, речь идет о том, что конкатенация по сути — это слияние списков, а не арифметическре сложение, и логично для этого использовать другое обозначение.

А в чем, в конце концов, проблема если для конкатинации массивов (списков и т.п.) будет тоже применяться "+"? Не уж то кто-то не поймет суть происходящего?

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

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

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

О, блин, класс! С точки зрения логики "&" это операция "И" и стало быть разуный результат для "(1 2 3) & (3 4 5)" должен быть "()". Правда что для Ч(1 2 3) & (3 4 С++, что для Шарпа списки так не записывают. Да и логические операции над значением символов смысла не имеют. Это только для списков целых пригодно.

В общем, нужно хоть немножко отвлекаться от ФЯ и возвращаться к реалиям того что обсуждается. Строки есть строки. И для них использование "+" как оператора конкатинации совершенно нормально и общепринято. В том же SQL-е это сплошь и рядом.

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

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

При том, что если тип string встроенный и поддерживается только

string operator + (const string &, const string &)

То нужен StringBuilder но если можно перегрузить

MyType1 operator + (const MyType2 &, const string &)
MyType1 operator + (const string &, const MyType2 &)

то необходимости в StringBuilder'е как средстве повышения эффективности конкатекации строк нету. Доказано на практике

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

VD>Сборку? Может конкатинацию? Ну, и как ее отложиет не заводя промежуточное хранилище?
VD>А с промежуточным хранилицем будет не быстрее StringBuilder-а.

Да, только мы избавляемся от явного использования этого хранилища в большинстве случаев.

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

VD>И какая разница со StringBuilder-ом?

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

VD>Шутку про "перенести в compile time" не понял.

Это не шутка Просто такие оптимизации доступны только Си++ шаблонам.

Например есть выражение

string x = a + b + c + d.

при использовании StringBuilder или его аналога будет выделено место под два указателя (не будет уточнять smart/strong/weak это не важно) и туда запишутся &c и &d. Далее будет перераспределена память (массив из 2х элементов будет расширен до 3х) и туда допишется &b. И его ещё раз расширят для записи &a. Даже если перераспределения памяти не было (сразу выделили память под 10 указателе и хрен с ним) сдвиг элементов всё равно имел место быть.
Так вот, я думаю, что заполнение этой таблицы указателей вполне может быть выполнено в compile-time. Мелочь, а приятно. Хотя конечно вряд ли овчинка стоит выделки и на длинных строках разницы не будет заметно.

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

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

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

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

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

E>Влад, ты что, сейчас ответил, чтобы ответить?
E>Ведь если пытаться с помощь функций выражать операции помещения объекта в какой-то специфический поток, то желательно, чтобы функции имели осмысленные имена.
Обычно для этого достаточно иметь осмысленное имя первого аргумента. Т.е. там, где в С++ мы пишем

std::cout << "Hello" << " cruel " << "world";
asnSerializer << "Hello" << " cruel " << "world";
xml << "Hello" << " cruel " << "world";

в языке без перегрузки << мы напишем

Console.Write("Hello", " cruel ", "world");
asnSerializer.Write("Hello", " cruel ", "world");
xmlSerializer.Write("Hello", " cruel ", "world");

И понятности нисколько не убавится. Перегрузка операторов хороша там, где
а) применяются разнотипные параметры
б) инфиксная нотация+приоритеты позволяет обойтись несколько более компактной записью

Поясняю: Для Write мы сумели сделать функцию с произвольным количеством аргументов благодаря их однотипности.
Если мы попробуем преобразовать какое-нибудь выражение векторной алгебры, то получится совсем другая тема. Вот, например:

V1 = A*B*V;

Здесь A — это матрица 3*4, B — матрица 4*2, V — это 2d вектор, V1 — 3d вектор. Вряд ли нам удастся придумать подходящую версию функции Multiply с произвольным количеством аргументов.
Зато можно описать набор необходимых перегрузок двухаргументной функции Multiply. Но тогда придется выполнять преобразование в прямую польскую запись самостоятельно:
V1 = Multiply(Multiply(A, B), V);
Для более сложных выражений инфиксная нотация выиграет еще сильнее.

Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Как по мне, то есть более приемлемый вариант — введение нового оператора, a-la "&" в VB, "," в ST или упоминавшееся выше "~" в D.
Страуструп, имхо, предоставил достаточно понятное объяснение отсутствию механизма введения "новых" операторов в язык.
А использование "готового старого" оператора для конкатенации строк все равно требует наличия перегрузки операторов.

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

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

C>Интересный какой cons. А что это за язык? И возможна ли в нём не-двоичная нотация списков, типа такого: (1 2 3)?

Не помню, по-моему Erlang. А списки *теоретически* всегда представляются как пары (на самом деле они часто реализованы напрямую, тем не менее суть операций car и cdr — именно работа с парой).

Т.е. (1 2 3 4) это (cons 1 (cons 2 (cons 3 (cons 4 ())))), поэтому car — первый элемент пары будет 1, cdr — второй элемент, будет списком.

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

SK>>Для чисел — да, полность согласен и то это дело вкуса, метафоры тут не при чем.
E>Нет, не вкуса, а общепринятой нотации. Выражать математические концепции проще математическими символами.
Использование общепринятой нотации тоже дело вкуса
Но, повторюсь, с числами — абсолютно согласен, для них использование операторов лушче, чем функций.

SK>>Но все остальное более логично выглядит как раз с функциями, а не с операторами.
E>Так ведь здравого смысла еще никто не отменял. Если кто-то для класса Window определяет operator+=() для дополнения заголовка окна, то точно также он может объявить Window::add_string() для того же самого, хотя лучше было бы сделать caption() и set_caption().

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

E>Кроме того, операторы, которые являются свободными функциями, а не членами класса, позволяют делать расширения. Например, если я реализую собственный класс My_Data и объявляю:
E>

E>std::ostream & operator<<( std::ostream & o, const My_Data & o ) { ... }
E>

E>то это дает мне возможность писать:
E>

E>std::cout << "My data: " << my_data << ", your data: " << your_data << std::endl;
E>

E>Если бы перегрузок оператора сдвига не было, мне бы пришлось делать что-то вроде:
E>

E>print( std::cout, "My data: " );
E>print( std::cout, my_data );
E>print( std::cout, ", your data: " );
E>print( std::cout, your_data );
E>print( std::cout, "\n", std::flush );
E>

E>или
E>

E>print( print( print( print( print( std::cout, "My data: " ), my_data ), ", your_data: " ), your_data ), "\n", std::flush );
E>

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

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

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

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

SK>>Просвети, кстати, зачем, если не для этого?
A>Единообразием использования встроенного и пользовательского типов. Ты же пишешь (3+4)/5 а не 3.add(4).div(5).
Я и так это могу написать, без перегрузки операторов

A>Например если в шаблонный класс для подсчёта корней уравнения вместо double подставить какой-нибудь класс для вычислений с повышенной точностью вместо double, то код шаблонного класса не надо будет менять.
Согласен, для чисел это полезно, но в общем, не нужная фича.

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

A>>Например если в шаблонный класс для подсчёта корней уравнения вместо double подставить какой-нибудь класс для вычислений с повышенной точностью вместо double, то код шаблонного класса не надо будет менять.
SK>Согласен, для чисел это полезно, но в общем, не нужная фича.

Согласен, для ходьбы ноги полезны, но в общем ненужная фича