Мммм и еще раз здравствуйте 

Друзья, из вашего сумбурного диалога я так и не поняла, поняли ли вы меня... Еще раз: функции OR и AND - не какие-то сферические штуковины со знакомыми названиями! Это аналогия обычных операторов && и ||, которые могут принимать  >=0 параметров (на практике сойдет >=2). Как работает обычный ||: он последовательно вычисляет аргументы и как как только наткнется на истинный результат, возвращает true, OR же вместо true возвращает само это вычисленное значение. Если все аргументы ложны, и ||, и OR возвращают 0.

Обычный &&: последовательно вычисляются аргументы, при встрече первого ложного результата возвращается 0, в AND - аналогично. Если результат вычисления всех аргументов истинен, && возвращает true, AND возвращает последний результат.

mes, у тебя функции неленивые (поправь, если я не права), для AND/OR это недопустимо... В лучшем случае это обернется легко обнаруживаемым сегфолтом, в худшем - сложно уловимыми побочными эффектами. По логике правильно.

volatile, Common Lisp. Не скриптовое, динамически типизированное.

math64, спасибо за помощь, сейчас буду разбираться...

boostcoder, тебе вообще огромное спасибо, сейчас тоже потыкаю твой последний вариант... Я вот сижу смотрю на раскрытие макроса и понимаю, что его аргументы (b1)(b2)(b3) будут вычисляться далеко не один раз... Значит нужно вначале раскрытия генерировать примерно следующее:


И потом внутри мега ?:-конструкции использовать __tmp_X вместо bX. Мне сложно судить наверняка, но при нынешнем однопроходном раскрытии макроса это нереально. И отчасти вдогонку к этому, не мог бы ты объяснить без привязки к BOOST_PP, каким образом препроцессор си раскрывает макрос macro((b1)(b2))? То есть получается, он не просто разбивает входные аргументы, а распарсивает выражение...

и выражения перестанут быть ленивыми.

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


в терминах boost.preprocessor - это последовательность. я же, итерируюсь по последовательности, и на каждой итерации раскрываю часть общего выражения.

Добавлено через 10 минут и 1 секунду

можно дважды пройтись по последовательности.

Ну да. динамически типизированное. там это имеет практический смысл.

В С++ даже если и получиться написать (кстати неплохие варианты тут предлагали, ребята постарались!)
но использовать это почти не получится.

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


Это сообщение отредактировал(а) volatile - 5.2.2012, 23:58

boostcoder, я поэксперементировала с твоими вариантами, с точки зрения логики раскрытия все правильно! Ты прав, сразу раскрывать все аргументы нельзя - привет, ленивость! Но нашлась мысля  Макросы можно разворачивать в ({})-форму, это расширение GCC, тогда на каждой итерации можно сначала вычислить результат, а потом его проверять!


Это я поняла по коду Мне любопытно, каким образом буст обманывает препроцессор и итерирует не по аргументам, а по свой скобочной коллекции. Интуиция подсказывает, что внутри это оборачивается в вызов другого макроса, очередной скобочный аргумент передается ему в качестве аргумента... Но как это происходит не пойму  Исходники буст-препроцессора я не осилила, поэтому и любопытствую, что за трюк такой... Если не сложно.

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

не знал. попробую.


именно так.

к примеру простой макрос BOOST_PP_SEQ_SIZE(): https://github.com/ryppl/boost-svn/blob/mas...or/seq/size.hpp

макрос:
var = BOOST_PP_SEQ_SIZE((a)(b)©)

развернется в:
var = BOOST_PP_SEQ_SIZE_BOOST_PP_SEQ_SIZE_3

который в свою очередь описан как:
# define BOOST_PP_SEQ_SIZE_BOOST_PP_SEQ_SIZE_3 3

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

Добавлено через 3 минуты и 58 секунд
или я не понял вопроса...

Добавлено через 8 минут и 57 секунд

хм..
http://liveworkspace.org/code/35bcbcc90f05...d71d9b551f41499

дай ссылку на описание расширения.

У тебя включен pedantic.

http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html

Компилируй с -std=gnu++98 или -std=gnu++0x

угу.

в общем работает.
попробую доделать..

Добавлено через 2 минуты и 31 секунду
mes, а Вы свой вариант будите доделывать? просто любопытно посмотреть на решение.
я тут еще подумал... для функционального программирования в с++, разработали boost.phoenix. еще попробую с его помощью решить задачу.

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


еще не приходилось сталкиваться 



Это сообщение отредактировал(а) mes - 6.2.2012, 10:13

  

newbee, итак.
давай посмотрим на препроцессированный вариант твоих тестов:

результат:

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

Добавлено @ 01:32
лишние скобки уберем..

Добавлено @ 01:36
вот что получилось:


Это сообщение отредактировал(а) boostcoder - 9.2.2012, 01:37

boostcoder, у тебя сложно раскрывается AND. Я для наглядности буду возвращать нули вместо самих вычисленных значений.



Теперь... Смотри, внутри OR и AND излишне следовать правилу раскрытия элемента последовательности x?x: Если x - вложенный AND или OR, его можно прямо встроить в выражение. Я не знаю, можно ли это сделать на дефайнах... Это необязательно. Таким образом твой пример принял бы форму


Теперь давай подумаем со скопами...



И аналогично должно быть с OR. Потом напишу, если надо. Я нигде не накосячила?

вроде въехал..


по моему - нет.

(не проверял)

newbee, смотри какое дело.
код:

как ты можешь видеть, тут вложенные скопы. но препроцессор не может рекурсию. он однопроходный.

идеи?

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

на примере Ext_OR((b1)(b2)(b3)):

вроде то, что надо.

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

идеи будут?

Добавлено через 2 минуты и 6 секунд
math64, не правильно. в твоем коде все равно выражения будут вычисляться не единожды.