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
> 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