Текущий Стандарт С++ и перспективы его развития

D_KEY, тебе знакомо понятие DSL?
Если например в моем DSL || обозначает параллельные прямые - о какой последовательности речь??

Цитата GoldFinch @ 17.12.09, 14:14

D_KEY, тебе знакомо понятие DSL?
Если например в моем DSL || обозначает параллельные прямые - о какой последовательности речь??

Знакомо. Только в С++ нереально сделать нормальный DSL. "Внешний" DSL, в любом случае, лучше.

Цитата D_KEY @ 17.12.09, 12:28

И ничего страшного в … Я не вижу. А код гораздо читабельнее(ибо семантика не меняется).

Спорно. Как раз возможность использования разных сущностей в одном выражении очень удобна и читабельнее, чем написанная "в столбик", sqlite++ тому примером. Да и потоки тоже из той же серии, с ними тоже в строчку удобнее выводить, чем "cout.write("hello, "); cout.write(name);"

ЗЫ а вообще, это всё оффтоп и его, наверное, надо вынести из данной темы.

Цитата olias @ 17.12.09, 14:18

Цитата D_KEY @ 17.12.09, 12:28

И ничего страшного в … Я не вижу. А код гораздо читабельнее(ибо семантика не меняется).

Спорно. Как раз возможность использования разных сущностей в одном выражении очень удобна и читабельнее, чем написанная "в столбик"

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

Цитата

sqlite++ тому примером. Да и потоки тоже из той же серии, с ними тоже в строчку удобнее выводить, чем "cout.write("hello, "); cout.write(name);"

Здесь с порядком вычислений все в порядке. Он соответствует неперегруженному варианту.

D_KEY, верно, что перегруженные operator||(), operator&&() и operator,() имеют иную семантику. Потому их и не рекомендуется перегружать. Но это не достаточно сильное обоснование для полного запрета. Тот же ?: запрещён к перегрузке по иным соображиям.

Цитата Qraizer @ 17.12.09, 14:58

Но это не достаточно сильное обоснование для полного запрета.

Да я и не говорю, что следует запретить. Раз есть - пусть будет. Просто непонятно, для чего нужно было такую перегрузку разрешать изначально.

Цитата

Тот же ?: запрещён к перегрузке по иным соображиям.

По каким?

D_KEY
http://www.research.att.com/~bs/bs_faq2.html#overload-dot

Цитата

There is no fundamental reason to disallow overloading of ?:. I just didn't see the need to introduce the special case of overloading a ternary operator. Note that a function overloading expr1?expr2:expr3 would not be able to guarantee that only one of expr2 and expr3 was executed.

Добавлено 17.12.09, 16:00
и да, действительно сложно представить зачем перегружать ?:

Сообщение отредактировано: GoldFinch - 17.12.09, 16:00

Цитата GoldFinch @ 17.12.09, 15:58

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

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

GoldFinch, в том-то и дело, что к трём остальным операторам это относится в той же мере. Все эти (неперегруженные) операторы вносят точку следования наравне с ;, чего не делают перегруженные, что и есть иной семантический смысл.
Не знаю точно. Могу догадываться, что возникают сложности с его интерпретацией в роли метода класса. Где там this-у место?

Тут скорее причина в другом, оператор ?: стоит несколько особняком от остальных операторов. Это скорее даже не оператор, а особая синтаксическая конструкция, вроде сокращенной записи для if…else.

В том же Algol W в этом качестве можно использовать if…fi. Там в этом смысле вообще хорошо, любая конструкция является выражением, возвращающим значение.

Цитата amk @ 17.12.09, 16:43

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

Также, как и ||, && и, тем более, запятая.

Цитата

Это скорее даже не оператор, а особая синтаксическая конструкция, вроде сокращенной записи для if…else.

Ну не совсем. Это именно выражение, в отличие от.

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

Хотя на мой взгляд лучше для первых двух операторов просто задать преобразователь в bool (вроде стандартный ), а для запятой, во избежание ненужных сюрпризов, пользоваться встроенным оператором.

Цитата amk @ 17.12.09, 23:33

Просто для ||, && и , нет такого устойчивого стереотипа, что они означают

Дело не только в значении, дело в поведении и порядке вычислений.
Так, например, встроенный || не вычисляет второй аргумент, если первый - true, кроме того, первый аргумент всегда вычисляется до второго. А если мы перегружаем ||, то вычислены будут оба аргумента, причем в неизвестном порядке.

Сообщение отредактировано: D_KEY - 17.12.09, 23:39

Да, это проблема. Если бы можно было отложить вычисление параметров до того момента, когда они действительно понадобятся. Но в C++ такой возможности нет - это не Алгол.

Цитата amk @ 18.12.09, 01:35

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

ленивые вычисления вполне реализуемы, правда вместо foo(x) будет чтото вроде bind(foo,x)