2 Feb 13:51
Re: [flyweight] Review period extended to February 3
From: Corrado Zoccolo <czoccolo <at> gmail.com>
Subject: Re: [flyweight] Review period extended to February 3
Newsgroups: gmane.comp.lib.boost.devel
Date: 2008-02-02 12:51:55 GMT
Subject: Re: [flyweight] Review period extended to February 3
Newsgroups: gmane.comp.lib.boost.devel
Date: 2008-02-02 12:51:55 GMT
Hi Joaquin On Feb 2, 2008 12:57 PM, "JOAQUIN LOPEZ MU?Z" <joaquin <at> tid.es> 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. Corrado -- -- __________________________________________________________________________ dott. Corrado Zoccolo mailto:zoccolo <at> di.unipi.it 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RSS Feed