Boost logo

Boost :

From: Jeremy Pack (rostovpack_at_[hidden])
Date: 2008-07-15 15:25:20


Looking back at my code, I realized that I had provided similar
functionality, but never tested it. I had a bug in the logic, which I have
fixed. You can actually write the following:

factory_map fm;
std::map<int, factory<word> >& factory_list(fm);

It's similar to Steven's suggestion, though it doesn't use a separate class
for the map type.

An alternative would be something like this:

factory_map fm;
std::map<int, factory<word> >* factory_list_ptr;
std::map<int, factory<word> > factory_list_copy;
fm.get(factory_list_ptr); // now factory_list_ptr points to the internal
map.
fm.get(factory_list_copy); // now factory_list_copy has a copy of the
internal map.

Any preferences?

Jeremy

On Fri, Jul 4, 2008 at 1:50 PM, vicente.botet <vicente.botet_at_[hidden]>
wrote:

> ----- Original Message ----- From: "Robert Dailey" <rcdailey_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Friday, July 04, 2008 2:49 AM
> Subject: Re: [boost] [extension] factory_map::get() suggestion
>
>
>
>
>> On Thu, Jul 3, 2008 at 7:36 PM, Jeremy Pack <rostovpack_at_[hidden]> wrote:
>>
>>> Steven,
>>>
>>> Yeah, it isn't quite that simple. I read the original post too quickly
>>> and
>>> thought he was referring to a different function.
>>>
>>> I originally had a type for that std::map<int, factory<word> >, so it
>>> would
>>> be something like type_factory_map<int, word>, which isn't much terser.
>>> (thus, I removed it)
>>>
>>> I think the best solution here is to make your own typedefs for your
>>> specific case.
>>>
>>> There are a couple of other places in the library though where I intend
>>> to
>>> add the type of typedefs suggested.
>>>
>>> Jeremy
>>>
>>> On Thu, Jul 3, 2008 at 5:26 PM, Steven Watanabe <watanabesj_at_[hidden]>
>>> wrote:
>>>
>>> AMDG
>>>>
>>>> Jeremy Pack wrote:
>>>>
>>>> Yep! Good idea. I'll take care of it.
>>>>>
>>>>>
>>>>> For example, right now I have to do this:
>>>>>>
>>>>>> factory_map fm;
>>>>>> std::map<int, factory<word> > & factory_list = fm.get<word, int>();
>>>>>>
>>>>>> It would be ideal to do this instead:
>>>>>>
>>>>>> factory_map fm;
>>>>>> factory_map::type& factory_list = fm.get<word, int>();
>>>>>>
>>>>>>
>>>>>>
>>>>> Is it really that easy? Doesn't the result of get
>>>> depend on the particular template arguments?
>>>> I don't quite see how you can get away with a
>>>> single typedef.
>>>>
>>>> In Christ,
>>>> Steven Watanabe
>>>>
>>>>
>>>> _______________________________________________
>>>> Unsubscribe & other changes:
>>>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>>>
>>>> _______________________________________________
>>> Unsubscribe & other changes:
>>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>>
>>>
>> Why not turn factory_map::get() into a template utility class of some
>> sort instead of a function? That would give you the ability to typedef
>> the std::map. Perhaps another option is to do the following:
>>
>> factory_map<word, int>::get()
>>
>> I don't have time right now to give any reasonable ideas, but those
>> are just some thoughts off the top of my head. Later on I may try to
>> help find an alternative to this. All I know for sure is that exposing
>> std::map seems like an implementation detail, and specifying the same
>> template parameters more than once also bothers me slightly.
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>>
> Hello,
>
> Maybe you are thinking on something like:
>
> struct factory_map {
> template <typename A, typename B>
> struct getter {
> typedef std::map<A, factory<B> > type;
> static type& apply(factory_map&fm){return fm.get<A,B>();}
> };
> };
> factory_map fm;
> typedef factory_map::getter<word, int> factory_map_getter;
> factory_map_getter::type& factory_list = factory_map_getter::apply(fm);
>
> Vicente
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


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