Re: [Boost-users] [ptr_container] Const & non-const ptr_map iteration over mapped values

Hi Thorsten, Thanks a lot for your reply.
I would just implement this as (abbreviated)
template< class R > struct X { template< class Pair > R operator()( const Pair& p ) const { return *p.second; } };
umm ... yep, you're right: the T1 and T2 types weren't used in my original alternative. Your struct X needs, tough, the result_type nested typedef (maybe that's why you said "abbreviated").
Well, why do you want to define that typedef, when it is easier to infer the type automatically?
Yep, it's easier and shorter; but this came so as to to fulfill C++ standard requirements over an "unary function" (as of my understanding). Nevertheless, it seems that (at least in this case) Boost's requirements are weaker, without requiring this other nested typedef.
Why? Dont map::value_type v = *m.find(x) work?
Well, yes: at first, this came as a result of the last point: it the arg_type has to be provided (if it has...), then a function template is a no-go alternative. So, an specifically typed function has to be defined: what's the arg_type? The "detail" type shouldn't be used one, and a std::pair didn't work due to the lack of implicit conversion. Then I saw the other nested template typedefs (const_reference and reference). But the question of the to std::pair remainded: does it help with interoperability with code that worked on maps that used the standard std::pair? Is it free to provide it, or there's some impossibility?
Again, why do you want to do this?
For the aforementioned reasons, but as you pointed that template parameter wasn't actually needed. Anyway, seemed reasonable to have it provided by ptr_map. Thanks a lot again. Cheers. Rodolfo.
participants (1)
-
Rodolfo Federico Gamarra