Re: [boost] [flyweight] Review period extended to February 3

From: Corrado Zoccolo (czoccolo_at_[hidden])
Date: 2008-02-02 08:04:39

Sorry, I hit the send button before finishing.

On Feb 2, 2008 1:51 PM, Corrado Zoccolo <czoccolo_at_[hidden]> wrote:

> Hi Joaquin
>
>
> On Feb 2, 2008 12:57 PM, "JOAQUIN LOPEZ MU?Z" <joaquin_at_[hidden]> wrote:
>
> >
> >  2. Indeed GoF introduces a key type K into the pattern that
> >  is used to retrieve the actual values of T. So, we have
> >  a one-to-one relation K-->T, i.e. there exists a stateless
> >  function f of the form
> >
> >    T f(const K&);
> >
> >  that can be used to construct a T from a given K. And,
> >  additionally, K is cheaper to construct than T. This is
> >  the map approach, right? My question now is: is this a realistic
> >  scenario? If K is actually cheaper to construct than T and
> >  we can univocally get the associated T from any K, why work
> >  with Ts and not just use Ks in the first place? The only
> >  plaussible justifications I can think of is that f() is
> >  computationally expensive or that T is more convenient to
> >  work with than K, but these seem (to me) not so likely
> >  concerns --more on the second concern on point 3 below, though.
> >  Note that I explicitly observed that f must be *stateless*, i.e.
> >  a K object contains exactly the same information as its associated
> >  T value. This is not the case in most usages of std::map, which
> >  is a reason why std::maps are useful :)
> >  I am not plainly denying the existence of sensible K-->T
> >  scenarios, but I thought long and hard and couldn't find
> >  any. If you can come up with one I'll be happy to know.
> >  So, my analysis led me to conclude that the right approach
> >  is to assume that K==T, that is, the set approach, or at
> >  most than K and T are just different representations of the
> >  same information.
> >
>
> 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 have
something 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?

Corrado
>
> --
> __________________________________________________________________________
>
> dott. Corrado Zoccolo                          mailto:zoccolo_at_[hidden]
> PhD - Department of Computer Science - University of Pisa, Italy
> --------------------------------------------------------------------------
> The self-confidence of a warrior is not the self-confidence of the average
> man. The average man seeks certainty in the eyes of the onlooker and calls
> that self-confidence. The warrior seeks impeccability in his own eyes and
> calls that humbleness.
>                               Tales of Power - C. Castaneda
>
>

-- 
__________________________________________________________________________
dott. Corrado Zoccolo                          mailto:zoccolo_at_[hidden]
PhD - Department of Computer Science - University of Pisa, Italy
--------------------------------------------------------------------------
The self-confidence of a warrior is not the self-confidence of the average
man. The average man seeks certainty in the eyes of the onlooker and calls
that self-confidence. The warrior seeks impeccability in his own eyes and
calls that humbleness.
                              Tales of Power - C. Castaneda