Joel de Guzman wrote:

David Abrahams wrote:

...

Joel de Guzman <joel@boost-consulting.com> writes:

...

...

In the extension example, I see repeatedly the same patter transferring the cv-ref qualification from one type to another. Can't that be made simpler for extenders?

typedef typename mpl::if_< is_const<Sequence>, std::string const&, std::string&>::type type; Can you point me to an example in the library, please?

This isn't from the library code. I copied it directly from the docs at libs/fusion/doc/html/fusion/extension.html

Ah, ok. I'll let Dan reply then. He wrote that part of the docs.

There is a common theme here when you need to return refs into the container (from deref, at, at_key etc.) you need to const qualify the result if the container is const. There is similiar logic in the library proper, for example in the vector deref_impl we have: typedef typename mpl::eval_if< is_const<vector> , fusion::detail::cref_result<element> , fusion::detail::ref_result<element> >::type type; The ref/cref generation is currently in detail, so library private implementation, and the is_const switch is repeated as with my example. So yes this is a recurring theme, we could provide a utility to do the necessary, but that does not seem to be a feature specific to fusion (as opposed to any other lib that needs to make similar decisions, I believe there is similar code in phoenix for example). Possibly we could make this decision at a higher level, in deref proper for example, but I'm not sure the logic is appropriate in all cases, such as transform views, were it may be appropriate to return non-const refs from a deref of a const container. Cheers Dan

dan marsden <danmarsden@yahoo.co.uk> writes:

The ref/cref generation is currently in detail, so library private implementation, and the is_const switch is repeated as with my example. So yes this is a recurring theme, we could provide a utility to do the necessary, but that does not seem to be a feature specific to fusion (as opposed to any other lib that needs to make similar decisions, I believe there is similar code in phoenix for example).

Possibly we could make this decision at a higher level, in deref proper for example, but I'm not sure the logic is appropriate in all cases, such as transform views, were it may be appropriate to return non-const refs from a deref of a const container.

IMO you can do better. -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

David Abrahams wrote:

dan marsden <danmarsden@yahoo.co.uk> writes:

...

The ref/cref generation is currently in detail, so library private implementation, and the is_const switch is repeated as with my example. So yes this is a recurring theme, we could provide a utility to do the necessary, but that does not seem to be a feature specific to fusion (as opposed to any other lib that needs to make similar decisions, I believe there is similar code in phoenix for example).

Possibly we could make this decision at a higher level, in deref proper for example, but I'm not sure the logic is appropriate in all cases, such as transform views, were it may be appropriate to return non-const refs from a deref of a const container.

IMO you can do better.

We're considering a utility metafunction that can be used to generate the return type for the various places where element access is required: element_ref<Seq, Element>::type It will then do the add_reference and add_const if needed based on the Seq the element is from. It can then be used to avoid the fiddling above in what I suspect is the common case. Is this sufficient improvement, or did you have something grander in mind? Cheers Dan