[boost] Fwd: Boost Digest, Vol 3137, Issue 2

Subject: [boost] Fwd: Boost Digest, Vol 3137, Issue 2
From: Brent Spillner (spillner_at_[hidden])
Date: 2011-01-03 23:57:10

> On 24/12/2010 18:14, Thomas Heller wrote:

(My apologies for the delay in responding; I've been travelling for
the holidays and had irregular access to email.)

>I think this comprehension syntax would be a wonderful addition to phoenix.
>In fact i was thinking of adding it to phoenix V3 myself.
>By basing your work on phoenix v3 you would introduce a kind of big
>dependency, true. However, that dependency is imho not a bad thing, it would
>provide you with a powerful basis for your work. The only thing that needed
>to be done is to code the logic for the list comprehension... everything
>else is already done for you.

I managed to make a little time to acquaint myself with Phoenix (v2)
and discovered that it wasn't that hard to add Phoenix support to the
comprehension library-- a couple of traits specializations to derive
the return types, a special case to treat void values as 'true' for
the purpose of continuing the comprehension (applies in all cases, not
just when using Phoenix expressions), and a mechanism to limit
ambiguous operator overloads.

I just uploaded a new version of the comprehension library (0.02) to
the Vault that includes all of the above, along with the ability to
nest comprehensions, support for increment/decrement and assignment
operators, general code cleanup, a couple of compiler workarounds,
reorganized example programs, and most importantly some preliminary
documentation in the README file.   As always, I'd appreciate reports
of any compilation environments or use cases that cause problems.

As far as integrating the comprehension syntax directly into Phoenix
goes, it certainly looks feasible but I wonder how much there really
is to be gained.  Since Phoenix already overloads the <<= (and every
other) operator, you'd either have to introduce a wordier
sequential-assignment syntax or a special sequentially-assignable
type, in which case the comprehension engine might as well be a
separate component.  One thing that would be handy in v3, though,
would be control flow operators that return a value type (e.g. the
value of the last expression in the statement list) rather than void.
Right now if you need a comprehension to depend on some value computed
within the body of a complex Phoenix statement, you have to assign
that value to a temporary variable and reference the variable later in
the comprehension.  I think that this capability would be more
generally useful outside the comprehension context, and it would
mirror the semantics of many functional languages.  I'm still not
familiar enough with the Phoenix internals to recognize whether
there's some other constraint that makes this impractical.

On a more technical note, does anyone know of a safe compile-time way
to detect whether the -std=c++0x (or /Qstd=c++0x) command-line option
has been passed to the Intel C++ compiler?
http://stackoverflow.com/questions/3744023/detecting-c0x-mode-on-intel-c
suggests that the the constant __GXX_EXPERIMENTAL_CXX0X__ will be
defined (as it is in g++), but that doesn't seem to be true, at least
in version 12 under Linux.  boost/config/compiler/intel.hpp doesn't
seem to have any tricks for this either, which is unfortunate because
it never enables BOOST_HAS_DECLTYPE, and the compiler chokes on parts
of Boost.Typeof when -std=c++0x is /not/ defined (i.e. when you
actually need it most.)

Brent