Boost logo

Boost :

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2006-03-06 20:15:12


Daniel Wallin wrote:
> I don't think the rationale for this is completely expressed in the
> docs. The reason binding<> works like this is because of dangling
> references to defaults. Consider from your example above:
>
> something_t const & q = args[something | 0];
>
> When binding<> returns the default type here you will get a dangling
> reference here:
>
> int const& = args[something | 0]
>
> Our design handles this by letting binding<> return a reference type
> when an argument is bound to the keyword, and otherwise return the
> default type unchanged.

OK I understand what you are saying, but I don't see it :-) As far as I
understand from the docs the binding<>::type has nothing to do with the
default value as above as it happens before one gets to extracting the
value. I wasn't talking about changing the types that the operator[]
return. And also from the docs, the binding<> function has it's own way
of declaring what the default type should be, which could be different
than the default value AFAICT.

Are you saying that operator[] uses the binding<>::type, instead of
using the internal "reference" type. Looking at code again... Ah yes it
does, but not for all compilers, in some it returns the reference type.
I think I would consider that a bug ;-)

But given that, would not what I suggested of having
binding<>::value_type, binding<>::const_reference, binding<>::reference,
etc. And then either having the operator[] use the binding<>::reference.
  Or another less incompatible change would be to just make those extra
binding types available. And the users could use the value_type in most
cases.

> I would consider adding a binding_value<> metafunction though.

Adding types to the binding<> function seems easier to me. But then I
didn't write the code :-)

--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk