Boost logo

Boost :

From: Eric Niebler (eric_at_[hidden])
Date: 2006-07-11 00:06:00

Gennaro Prota wrote:
> On Mon, 10 Jul 2006 10:24:29 -0700, "Eric Niebler"
> <eric_at_[hidden]> wrote:
>> [...]
>> Last week, at Scott's prodding, I took the issue up again and finally
>> resolved the lvalue/rvalue problem. The result is a macro MAX(a,b) that
>> behaves *exactly* like ((a)<(b)?(b):(a)), except that it does not
>> reevaluate its arguments.
> Hi Eric,
> I thought I could throw an idea even if I had no time to examine your
> code. Generally speaking I find it grotesque that one has to go
> through contortions for such simple "primitives" (gcc has had builtin
> operators for min and max for years now). My question is: is your
> solution extendible to different operations, such that one could write
> (not necessarily with that syntax):
> f(x, y) = v
> rather then
> max(x, y) = v
> ?
> In this case you would have a little "framework" to build modifiable
> lvalues upon binary functions or function objects.

I don't see why not. The techniques used are fairly general. If you have
a macro that expands to an expression, and you don't want it to
reevaluate its arguments, and you want to preserve const-correctness and
lvalue/rvalue-ness, this approach should work.

This is probably a lack of imagination on my part, but I can't think of
another use besides min/max. What do you have in mind?

Eric Niebler
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at