
Boost : 
From: Corrado Zoccolo (czoccolo_at_[hidden])
Date: 20080202 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 onetoone 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 oneargument,
> nonexplicit 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 rvalue 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 selfconfidence of a warrior is not the selfconfidence of the average
> man. The average man seeks certainty in the eyes of the onlooker and calls
> that selfconfidence. 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 selfconfidence of a warrior is not the selfconfidence of the average man. The average man seeks certainty in the eyes of the onlooker and calls that selfconfidence. The warrior seeks impeccability in his own eyes and calls that humbleness. Tales of Power  C. Castaneda
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk