привет всем,
сегодня увидел такой код

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

С этим вопросом - к разработчикам стандарта Си++.


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

Запятые нужны в си, в первую очередь для форов (ну, не то, чтоб нужны - но удобно). В С++ - это, во-первых, наследие. Но кроме того есть перегрузка операторов, потому находятся и другие применения. Например, boost::asign.

Запятые также иногда удобны в условиях конструкций if и while.

А ещё запятые можно перегружать   

Специально для этого их и придумали   

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

совсем не для этого. Семантика оператора "," меняется при перегрузке и поэтому не рекомендуется его перегружать. Тудаже относится и перегрузка && и ||

да вроде-бы можно перегружать, но только для своих классов...

перегружать можно, но поведение его будет очень сильно отличаться. Реализовать его семантику при перегрузке невозможно, поэтому результат этого перегруженного оператора будет очень удивительным для пользователя класса. 
Вы ведь не будете перегружать "+" так чтобы он в итоге реализовывал "-"...

Добавлено через 9 минут и 15 секунд
вот подобный случай обсуждался

Fazil6, семантику менять - это нормально. Иногда Пример я уже привёл (boost::assign).

почему?

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

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

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

Во-первых, я что-то не слышал про стандартную семантику && и ||. А во-вторых, при перегрузке копирующего конструктора и оператора = тоже меняется семантика. Это значит, их не рекомендуется перегружать?

не совсем понимаю вопроса. В свою очередь встречный вопрос: как обеспечить чтобы левый операнд вычислялся всегда первым, а правый вторым?

ну и чем ты гордишься? Почитай топик по ссылке - там четко видно к чему приводит перегрузка ||

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

Интересная дискуссия. Много нового узнал...
Но правда, не вижу надобности перегружать "operator ,".

Это сообщение отредактировал(а) andrew_121 - 9.6.2008, 22:45

andrew_121, действительно, надобности это делать почти никогда нет. Но, иногда встречаются случаи, когда сделав это мы получим что-то, например, удобочитаемость кода. Пример, что лучше выглядит, это:или это

bsa: Да, беспорно, красивей, удобней, понятней! Респект!
Слышал про Boost, но некогда не юзал, поделитесь ссылками на оного. И на доки, и на форум об оном тожА. Плиз.

Это сообщение отредактировал(а) andrew_121 - 9.6.2008, 21:38

http://www.google.com/search?q=boost

Добавлено через 2 минуты и 6 секунд

Вся хитрость операторов && и || в том, что они не вычисляют второй свой аргумент, если уже по первому известен результат.

почитайте про точки следования
undefined behavior не страшен только тем, кто "намертво" прикреплен к одной версии определенного компилятора. В противном случае, может оказаться, что программа работает не так, как надо. Только потому,  что кто-то ради "удобочитаемости"(и то - спорно) вместо пяти точек следования(к примеру; т.е. 5 строк с ";" в конце) сделал одну(после выражения перед первой запятой в строке). 

skyboy:  То же вариант.

А что, есть смысл перегружать что-либо без изменения семантики? 



Перегрузка && и ||, как и перегрузка любых других операторов, приводит к изменению их семантики (вполне возможно, предыдущая семантика --- ошибка компиляци). Есть одна стандартная версия &&, || и т. п. для параметров (bool,bool) которую можно применять к указателям используя конвертацию указателей к bool. Что же может испортить перегрузка этих операторов для объектов и ссылок на объекты? Даже для указателей, мне кажется, гораздо опаснее использовать неявную конвертацию к bool, чем перегружать для них оператор && (тем более, что для (bool,bool) его нельзя перегрузить).

конечно. Именно так  и нужно перегружать. Что по твоему семантика? Семантика оператора - это его смысл. Смысл оператора "+" в сложении. Вот и перегружать его надо так, чтобы он по смыслу делал сложение. Где тут изменение семантики?
 правильная перегрузка не должна изменять семантику. Перегрузка стандартных "&&", "||" и "," всегда приводит к изменению семантики, ибо стандартная семантика этих операторов фиксирует порядок вычисления аргументов, и далеко не всегда эти операторы вычисляют оба аргумента, а перегрузка делает их совершенно обычными операторами. Такое поведение нестандартно для этих операторов. Ты в коде видишь a+b и совершенно справедливо ожидаешь от этого выражения сложения. Совершенно справедливо от выражения a||b ожидать того, что делает оператор || , а не обычная функция, аргументами, которой являются  a и b.


это поведение  не ошибка, а соответствие стандарту. 

Я имел ввиду вот что:

В этом случае --- семантика оператора a1||a2 --- ошибка компиляции.


Мы с вами по разному понимаем слово семантика. Я вкладываю в него не смысл, а то, что конкретно делает данная сущность (строгое определение во всех деталях), иными словами --- описание изменения состояния машины после выполнение данной сущности. А смысл я называю спецификацией (пример: +. Спецификация: сложить два числа. Семантика: записывает в стек сумму двух чисел без побочных эффектов). В этом случае, перегружать, не меняя семантики --- значит, писать тавтологичный код.

Не понимаю. В чем тогда по-твоему изменение семантики при перегрузке "+" для каких-нибудь объектов учитывая, что спецификация не изменилась(сложить два объекта)?

значит для тебя перегрузка оператора не должна менять его спецификацию
а для оператора "," это не возможно 

как это будет работать?
т.е сначала выполняется std::getline(std::cin, s), потом !std::cin.eof(), а что проверяется в while? возвращаемое значение std::getline(std::cin, s)?

последнее, т.е. !std::cin.eof()

В большинстве случаев это верно. Но иногда удобна перегрузка без следования этим правилам. boost::asign, boost::lambda, boost::optiona, etc. - в качестве примеров.

Это дискуссия, безконечна...
Спорить не буду, за - то же.
Как не крути, но в перегрузке "oprator ," больше негатива, чем позитива.
Так же, перегрузка "||" и "&&" вносит больше подозрений, непонятки, в код ее использующий. Зачем забивать себе голову еще и тем что, нужно помнить что эти операторы перегружены, когда и так у программера в голове, полно всякой полезной, и безполезной информации. Ведь проще написать пару лишних строк, чем забивать себе голову...(имхо)

оператор "запятая" возвращает значение последнего аргумента 

неперегруженый, а перегруженый, может вернуть что угодно 

Согласен. Но в большинстве случаев, программист знает, на что он идёт. И, скажем, если вы разрабатываете библиотеку, перегрузка оператора "," может испортить программу при подключении только в том случае, если:
1. Этот оператор объявлен все namespace, или используется using namespace (в противном случае, при уже существующей встроенной реализации "," будет выбираться пользовательская только в том случае, когда один из операндов имеет тип, находящийся в этом namespace, что не навредит. См. разрешение имён)
2. Этот оператор объявлен для типов, существующих вне библиотеки, например:
template<class T,class S>
T& operator , (const T&,const S&); //так делать не надо

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

Оператор "," полезно использовать вместо эллипса! Но надо быть осторожнsм, чтобы компилятор не воспринял , за знак отделения аргументов функции:


Т. о. Перегружать оператор , следует только в том случае, когда тип одного из операндов --- класс, к которому больше никак обращаться не следует.

помойму это совсем не обязательно, ведь сначала компилер "примеряет" юзерские переопределения, а только потом подставяляет стандартные

Нет, как раз в данном случае сработает вызов функции с двумя параметрами. Поэтому использование запятой как подмены функции с произвольным количеством параметров - не лучшее решение 

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


Это сообщение отредактировал(а) d06osipov - 10.6.2008, 16:53

оговорено. в аргументах без скобок запятая не оператор

ммм, всем спасибо за ответы. Спор помоему пошел ни о чем.
Подведу итог: использование запятой ухудшает читабельность кода, но в некоторых случаех запятая удобна(перегруженная) как в случае с boost.
Всем спасибо за ответы.