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

Subject: Re: [Boost-users] [ptr_container] Const & non-const ptr_map iteration over mapped values
From: Rodolfo Federico Gamarra (rgamarra_at_[hidden])
Date: 2009-06-15 11:45:46

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.