Re: [flyweight] Review period extended to February 3

----- Mensaje original -----
De: Corrado Zoccolo <czoccolo <at> gmail.com>
Fecha: Sábado, Febrero 2, 2008 2:05 pm
Asunto: Re: [boost] [flyweight] Review period extended to February 3
Para: boost <at> lists.boost.org
>
> One example for all:
> K = const char *
> T = std::string
>
> I have seen many of those examples in which an object is 
> actually built from something simpler (in all the cases f will be a
> one-argument,non-explicit constructor T(K) ).
>
> What about defining a trait, construction_arg<T>::type that can 
> give K in such cases, and T if not specified?
> It could be generally useful also in other cases, expecially in the
> transition phase, in which we still lack r-value references.
> 
> Clearly, you don't want to store the Ks in the container, exactly 
> for the same reason you want to use T in your code, so you should
> still havesomething like a set<T> as a container, and have some way
> to look for a K inside it without creating a T.
> 
> For example, for std::string we have overloaded  operator< that 
> also accept (const char *). Something equivalent could be obtained
> maybe with a custom comparator?

I'd need more time to articulate this into a coherent framewoek,
but at first blush the idea seems to get along with a potential
extension of the Factory concept, the LookupFactory, described at

  http://lists.boost.org/Archives/boost/2008/01/132798.php

LookupFactories are factories that, additionally to the
insert memfun, provide a find memfun. Looks like this
find could be overloaded so as to accept arguments of type K.
I'm putting this into the list of things to consider.
In any case, seems like the evolution of the library clearly
points towards supporting different factory concepts
providing extensions on the basic concept.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost