Например, тут.

Ня!

И от меня спасибо

иу, лор читай, новое узнавай, спасибо :)

А про это знали: http://en.wikipedia.org/wiki/Comma_operator ?

Да, я его активно перегружаю иногда.

Compiler-specific вещи не нужны.

Это не С++ это Gnu C++

Да, я его активно перегружаю иногда.

И не было с этим проблем?

А про это знали: http://en.wikipedia.org/wiki/Comma_operator ?

У K&R описано.

+1. Некрасиво использовать расширения конкретного компилятора.

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

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

Такое нарушает «принцип наименьшего сюрприза», по крайней мере, для меня.

ну вот :(

У каждого додика своя методика (и свои принципы). Вообще очень удобно.

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

Я вообще то в курсе. Но бывают ситуации, когда такая перегрузка существенно упрощает жизнь (а с запятой так вообще позволяет делать вещи, которые на первый взгляд в С++ невозможны).

Кстати шаблонная перегрузка запятой для какого нить очень специального именно для этого сделанного класса вполне безопасна.

Можно пример?

class my_special_object{
...
   my_special_object( const char* S);
...
   template<typename T> my_special_object& operator , (const T& other){
    ...
    return *this;
  }
};
#define WOUT(args...){                                          \ 
   my_special_object _tmp_special_object( #args );  \
   _tmp_special_object,args;                                     \
}
...
int a = 2; const char*b = "qwerty";
WOUT( a*2, b+1 );

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

a*2=4; b="werty";

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

У меня к вам нескромный вопрос: а вы не пробовали хаскель?

В хаскель ему будет «тесно». Вон как извращается с указателями...

Не-а. Но при беглом просмотре мне не понравился синтаксис. Впрочем, возможно все впереди...

<? и >?

«может быть меньше» и «может быть больше» ?

Я поражаюсь людям, в головах которых пусть даже на мгновение мелькает мысль «о клевая фича, почему бы мне не начать использовать ее?».
Это касается например нижеследующих конструкций:

++i++;
i = (a, b);
call_me_maybe(i++, j++);
(i < j? init : deinit)(a);

Тернарный оператор-то тебе чем не угодил?

Синтаксис всегда штука очень субъективная. В хаскеле, например, на мой взгляд очень здорово описывают сигнатуры функций. А вот тот факт, что разобрать синтаксис хаскеля (в ast) значительно проще чем синтаксис плюсов — факт абсолютно объективный. А это создаёт определённый простор для всяких инструментов работающих с кодом.

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

Операция ПРОБЕЛ

это хорошо, что вы пока только запятую перегружаете.

вот тут пытаются перегружать «операцию пробел»

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

Compiler-specific вещи не нужны.

Плюсую!

А кто-то тут говорил, что Linux и всё такое прочее ОСС, следует стандартам, а сами гавна надобавляют, а потом мучайся с этим.

хаскиль, хаскиль...

для человека, испорченного нарзаном braces language, на D как-то намного лучше будет... намного лучше будет это всё

то получаем на выходе че нить вроде:
a*2=4; b=«werty»;

просто для рефлексии и описания полей каких-то?

а произвольный код времени компиляции нельзя? нужно в конструктор заворачивать?

вот в D например, можно со всякими static if, миксинами и проверкой, что код будет компилироваться, повозиться.

например, кроме того кода с функторами ещё pegged на гитхабе похоже сделан — целый парсер времени компиляции.

а в тему «операции пробел» и InteLib — был у меня компилятор схемы на D1, который по такому же принципу генерировал код на D1 во время компиляции, всё CTFE функциями сделано. автор даже где-то регистрантом на лоре был, правда, он кажется компилятор забросил - его до D2 совсем немного допилить нужно.

просто для рефлексии и описания полей каких-то?

Ну вообще то в плюсах это нетривиально делается. Интроспекции то нету... а тут она почти что есть;-)

Батенька, да я вообще не программист. У меня есть задачи, я их решаю. Хотите убедить меня, что есть инструменты более подходящие для моих задач чем С++ с питоном?;-)

Это и в C++ можно. Александреску показывал как ещё лет дохрена назад. В C++11 со static_assert'ами и constexpr'ами всё это делается совсем легко.

У D если мне память не изменяет такая же невыразительная система типов что и у плюсов. Так что если говорить об управляемом языке с brace'ами и компиляцией в нативный код, то Google Go смотрится как-то стройнее. А gdc, кстати, есть на шутауте?

Что только люди не придумают чтобы про монады не читать.

у вообще то в плюсах это нетривиально делается. Интроспекции то нету... а тут она почти что есть;-)

да не так уж она и сложно в С++ делается. вот, например, Константин Книжник со своей ООБД GOODS писал диссер ещё в мохнатых 90х (как бы не в 1994):

абстракт текст

там суть дисера в том, что он свою ОО СУБД писал на плюсах, реализуя рефлексию (в диссере описано, как). фактически переизобрёл что-то вроде MOP (метаобъектного протокола) на плюсах.

можно посмотреть его ООБД Goods , есть и другие его ООБД

Хотите убедить меня, что есть инструменты более подходящие для моих задач чем С++ с питоном?;-)

ага. есть ощущение, что язык D сюда лучше подойдёт. хотя, если Вас и плюсы вполне себе устраивают....

Не делай так! У Страуструпа из-за тебя брат умер!

Интроспекции то нету...

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

а в тему «операции пробел» и InteLib — был у меня компилятор схемы на D1, который по такому же принципу генерировал код на D1 во время компиляции, всё CTFE функциями сделано. автор даже где-то регистрантом на лоре был, правда, он кажется компилятор забросил - его до D2 совсем немного допилить нужно

автор кажется это он это он когда-то дописывал (видел его страничку с Scheme4D в LJ, правда сейчас он страничку удолил, а в LJ какой-то спам). у него есть LJ gmail jabber.ru, кажется он даже зареган на лоре.

правда он куда-то пропал.

А gdc, кстати, есть на шутауте?

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

вообще gdc неплохо должен оптимизировать.

У D если мне память не изменяет такая же невыразительная система типов что и у плюсов.

это да, но ситуацию несколько поправляют CTFE функции и возможность использования в них полноценного D, с проверкой скомпилируется ли этот код после подстановки. что-то на этом можно изобразить, как в примере с монадами.

Это касается например нижеследующих конструкций:

++i++;

:) Обфускаторов сорцов очень любят в «Ъ-ынтерпрайзе» на собеседованиях задрачивать вопросами, какой результат выдают подобные конструкции. Обычно самый правильный ответ им в голову не приходит.

ага. есть ощущение, что язык D сюда лучше подойдёт. хотя, если Вас и плюсы вполне себе устраивают....

Я плюсы временами НЕНАВИЖУ. Но ничего с такой же производительностью и выразительностью для НАШИХ задач пока на горизонте не наблюдается;-(

За ссылки спасибо, погляжу когда раскидаю текущий завал.

Я плюсы временами НЕНАВИЖУ.

а ЗА ЧТО ИМЕННО ненавидите? огласите весь список :-)

в смысле, записывайте куда-нибудь в бложик, проблемы, можно будет подумать, как их решить не на плюсах, и где-то там изобретут радио и наступит всеобщее счастье :-)

Но ничего с такой же производительностью и выразительностью

1. Производительность. Тут есть, вообще говоря, некоторые узкие места в D по сравнению с С++: сборщик мусора, реализация хеш-таблиц. Компиляторов есть три, официальный dmd с встроенным профилировщиком, gnu-подобный gdc, и llvm-подобный ldc-2. gdc неплохо оптимизирует, dmd самый быстрый.

Узкие места можно обойти — сборщик мусора в D можно отключить и пользоваться ручным выделением, как в С++; реализацию хеш-таблиц или чего из стандартной библиотеки заменить на другую. Конечно, до этого нужно проводить полноценный анализ производительности (или хотя бы грубо, приблизительно профилирование встроенным dmd -profile), чтобы определить, где именно её надо оптимизировать, и надо ли вообще.

2. Выразительность. Уверен, что тут ситуация будет получше, чем в С++. Например, есть статья Волтера Брайта про перенос алгоритма zlib с plain C на D, а это ещё не С++. Исходник сократился более чем на половину, сохранив функциональность и став более выразительным, легко читаемым. scope переменные. Плюс, элементы функционального программирования вроде std.ranges в стандартной библиотеке. Плюс, шаблоны, записанные по человечески. Плюс, возможность реализации встроенных DSL через string mixin. Плюс, доступность всего функционала языка в CTFE функциях времени компиляции. В общем, sky is the limit.

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

Например, есть статья Волтера Брайта про перенос алгоритма zlib с plain C на D, а это ещё не С++. Исходник сократился более чем на половину

а где можно посмотреть?

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

НО. КОмпиляторы - меня терроризируют коллеги, что мои библиотеки не собираются последней версией gcc, а она быстрее и дает более оптимальный код. Я не знаю D (и да, мне некогда его учить), но что то мне подсказывает, что евойные компиляторы сливают (просто не так много в них вкладываются). И я совершил акт саботажа - подарил шефу книгу про хаскель... судя по его восторженным высказываниям, нам светит в отдаленном будущем хаскель а не D;-)

Хотя я посмотрю на D, ну когда будет время, спасибо за наводку.