headers
Ion Gaztañaga | 29 Jan 21:56
Picon

[flyweight] Review period extended to February 3

Hi to all,

We've received 4 positive reviews and several comments, but we still 
want more ;-) Some people expressed interested in the pre-review period 
and I want to give some time (weekend is the right time to review a 
Boost library...) to those who are interested in the library and have 
not found time to review it. The last review day is February 3.

Common, the library is very lightweight ;-) to review, it's pretty well 
documented, it's certainly small and very general purpose. Here is the 
information. Last call to passengers!

*Description:*

Flyweights are small-sized handle classes granting constant access to
shared common data, thus allowing for the management of large amounts of
entities within reasonable memory limits. Boost.Flyweight makes it easy
to use this common programming idiom by providing the class template
flyweight<T>, which acts as a drop-in replacement for const T.

*Online docs:*

http://tinyurl.com/2sstyr
http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/index.html

*Download:*

http://tinyurl.com/hrdm6
http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directory=Patterns
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 31 Jan 23:46
Picon

Re: [flyweight] Review period extended to February 3

Hi Joaquin,

What is the magic number 16384 in the intermodule_holder intantiator
struct intermodule_holder_class contains the following initialization
    instantiator():
      mutex(interprocess::open_or_create,compute_mutex_name()),
      seg(interprocess::open_or_create,compute_segment_name(),16384),

Should this be configurable?

Are the compute_mutex_name and compute_segment_name friendly for debuging?
I think that we will need here some introspection in order obtain these 
values,
or better yet to be able to configure them.

Regards

---------------------------
Vicente Juan Botet Escriba 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Joaquín Mª López Muñoz | 1 Feb 15:22
Picon
Favicon
Gravatar

Re: [flyweight] Review period extended to February 3

"vicente.botet" ha escrito:

> Hi Joaquin,
>
> What is the magic number 16384 in the intermodule_holder intantiator
> struct intermodule_holder_class contains the following initialization
>     instantiator():
>       mutex(interprocess::open_or_create,compute_mutex_name()),
>       seg(interprocess::open_or_create,compute_segment_name(),16384),

intermodule_holder<T> creates a shared memory segment which is (intendedly)
unique to the combination (process,T), and it is used to share information on the
static data initialization process among the different dynamic modules in the
program.

16 KB is just a conventional size requested for the memory segment. Actually,
this segment only contains a pointer, but it's necessary that the segment be larger
than merely sizeof(void*) to accommodate object names and other
Boost.Interprocess internal information. Maybe 16KB is a little too much and
we could do with 2 or 4 KB, but I didn't think it was worth being avaricious here.

> Should this be configurable?

I don't think so, since the memory segment, as explained above, only holds data
of fixed size.

> Are the compute_mutex_name and compute_segment_name friendly for debuging?
> I think that we will need here some introspection in order obtain these
> values,or better yet to be able to configure them.
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 1 Feb 18:46
Picon

Re: [flyweight] Review period extended to February 3

"Joaquín Mª López Muñoz" wrotes

> "vicente.botet" ha escrito:
>
> > Hi Joaquin,
> >
> > What is the magic number 16384 in the intermodule_holder intantiator
> > struct intermodule_holder_class contains the following initialization
> >     instantiator():
> >       mutex(interprocess::open_or_create,compute_mutex_name()),
> >       seg(interprocess::open_or_create,compute_segment_name(),16384),
>
> intermodule_holder<T> creates a shared memory segment which is 
> (intendedly)
> unique to the combination (process,T), and it is used to share information 
> on the
> static data initialization process among the different dynamic modules in 
> the
> program.
>
> 16 KB is just a conventional size requested for the memory segment. 
> Actually,
> this segment only contains a pointer, but it's necessary that the segment 
> be larger
> than merely sizeof(void*) to accommodate object names and other
> Boost.Interprocess internal information. Maybe 16KB is a little too much 
> and
> we could do with 2 or 4 KB, but I didn't think it was worth being 
> avaricious here.
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 1 Feb 07:55
Picon

Re: [flyweight] Review period extended to February 3

Hi,

I was wondering if as the intermodule_holder is a kind of workaround for
platforms where dynamic loaded libraries can duplicate static libraries, we
can have a better performance on the others for free.

On platforms on which static variables are unique inter dynamic loaded
modules the intermodule_holder specifier can be a static_holder.
This could be controlled using conditional compilation.

struct intermodule_holder:holder_marker
{
  template<typename C>
  struct apply
  {
#ifdef BOOST_NO_DLL_UNIQUE_STATIC_VARIABLE
    typedef intermodule_holder_class<C> type;
#else
    typedef static_holder_class<C> type;
#endif
  };
};

Have this a sens or I'm missing something?
Could the documentation add a reference to the duplication problem?

In addition, I'd replace static_holder by intramodule_holder.
intramodule_holder reflects much more the accessibility intent for the
users, static_holder talks more about  the implementation.
(Continue reading)

Permalink | Reply |
headers
Joaquín Mª López Muñoz | 1 Feb 15:32
Picon
Favicon
Gravatar

Re: [flyweight] Review period extended to February 3


"vicente.botet" ha escrito:

> Hi,
>
> I was wondering if as the intermodule_holder is a kind of workaround for
> platforms where dynamic loaded libraries can duplicate static libraries, we
> can have a better performance on the others for free.
>
> On platforms on which static variables are unique inter dynamic loaded
> modules the intermodule_holder specifier can be a static_holder.
> This could be controlled using conditional compilation.
>
> struct intermodule_holder:holder_marker
> {
>   template<typename C>
>   struct apply
>   {
> #ifdef BOOST_NO_DLL_UNIQUE_STATIC_VARIABLE
>     typedef intermodule_holder_class<C> type;
> #else
>     typedef static_holder_class<C> type;
> #endif
>   };
> };
>
> Have this a sens or I'm missing something?
> Could the documentation add a reference to the duplication problem?

This makes sense, but I lack expertise on this area, and don't really
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 1 Feb 18:39
Picon

Re: [flyweight] Review period extended to February 3

"Joaquín Mª López Muñoz" wrotes
"vicente.botet" ha escrito:

[snip]

> > In addition, I'd replace static_holder by intramodule_holder.
> > intramodule_holder reflects much more the accessibility intent for the
> > users, static_holder talks more about  the implementation.
>
> Do you mean that intermodule_holder should be the default rather
> than static_holder? There are reasons not to do that, as I explained
> to John Reid at:
>
> http://lists.boost.org/Archives/boost/2008/01/132814.php

Non, this was only a renaming sugestion.
NOT INTERmodule_holder BUT  INTRAmodule_holder.

I'd RENAME static_holder by intramodule_holder.
intramodule_holder reflects much more the accessibility intent for the
users, static_holder talks more about  the implementation.

So at the end there will be two holders:
. intramodule_holder (renaming of static_holder) and
. intermodule_holder

Regards
---------------------------
Vicente Juan Botet Escriba
(Continue reading)

Permalink | Reply |
headers
Steven Watanabe | 1 Feb 20:33
Picon

Re: [flyweight] Review period extended to February 3

AMDG

vicente.botet wrote:
> So at the end there will be two holders:
> . intramodule_holder (renaming of static_holder) and
> . intermodule_holder

Those names are much too similar.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
vicente.botet | 2 Feb 00:23
Picon

Re: [flyweight] Review period extended to February 3

Hello Steven,
>"Steven Watanabe" wrotes
>> vicente.botet wrote:
>>> So at the end there will be two holders:
>>> . intramodule_holder (renaming of static_holder) and
>>> . intermodule_holder
>>
>> Those names are much too similar.

You are right.
Maybe module_holder and process_holder?

Regards

Vicente Botet
 _______________________________________________
 Unsubscribe & other changes: 
http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
JOAQUIN LOPEZ MU?Z | 2 Feb 11:07
Picon
Favicon
Gravatar

Re: [flyweight] Review period extended to February 3

----- Mensaje original -----
De: "vicente.botet" <vicente.botet <at> wanadoo.fr>
Fecha: Sábado, Febrero 2, 2008 0:24 am
Asunto: Re: [boost] [flyweight] Review period extended to February 3
Para: boost <at> lists.boost.org

> Hello Steven,
> >"Steven Watanabe" wrotes
> >> vicente.botet wrote:
> >>> So at the end there will be two holders:
> >>> . intramodule_holder (renaming of static_holder) and
> >>> . intermodule_holder
> >>
> >> Those names are much too similar.
> 
> You are right.
> Maybe module_holder and process_holder?

I don't see any problem with static_holder, but if we don't
want to stress the internal mechanism on which it is based
maybe we can name it simple_holder, so we'd have simple_holder
and intermodule_holder?

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Alberto Ganesh Barbati | 2 Feb 00:37
Picon
Favicon

Re: [flyweight] Review period extended to February 3

Ion Gaztañaga ha scritto:
> 
> * What is your evaluation of the design?

The overall design looks very good. However, IMHO it doesn't fully grasp 
the essence of the flyweight pattern because of a major flaw. The flaw 
is the fact that an object needs to be created in order to check whether 
an equivalent flyweight exists or not. Consider this code:

   typedef boost::flyweight<std::string> fw;

   fw s1("foo");
   fw s2("foo");

the creation of s1 requires one call to the string constructor, two 
calls to the string copy constructor and two calls to the string 
destructor. If we could use rvalue references and perfect forwarding, we 
could avoid one or maybe even two of the three temporaries. However 
insertion of a new flyweight should occur rarely in typical use cases, 
so it doesn't matter much. The problem is when constructing s2, a case 
which is going to occur much more often. To construct s2 the current 
implementation calls the string constructor once, the string copy 
constructor once and the string destructor twice. Even in this case, we 
may in the future avoid one temporary, but not the other. We are 
actually creating a full-blown object only to throw it away! That is a 
waste which can be get worse if instead of one std::string you had an 
UDT which is expensive to construct. Notice that the latter is precisely 
the scenario where the flyweight pattern is most useful!

The GoF book describes a flyweight pattern where each flyweight can be
(Continue reading)

Permalink | Reply |
headers
JOAQUIN LOPEZ MU?Z | 2 Feb 12:57
Picon
Favicon
Gravatar

Re: [flyweight] Review period extended to February 3

Hi Alberto, thank you for your review!

----- Mensaje original -----
De: Alberto Ganesh Barbati <AlbertoBarbati <at> libero.it>
Fecha: Sábado, Febrero 2, 2008 0:38 am
Asunto: Re: [boost] [flyweight] Review period extended to February 3
Para: boost <at> lists.boost.org

> Ion Gaztañaga ha scritto:
> > 
> > * What is your evaluation of the design?
> 
> The overall design looks very good. However, IMHO it doesn't fully 
> grasp the essence of the flyweight pattern because of a major
> flaw. The flaw is the fact that an object needs to be created in
> order to check whether an equivalent flyweight exists or not.
> Consider this code:
> 
>   typedef boost::flyweight<std::string> fw;
> 
>   fw s1("foo");
>   fw s2("foo");
> 
> the creation of s1 requires one call to the string constructor, 
> two calls to the string copy constructor and two calls to the
> string destructor. If we could use rvalue references and
> perfect forwarding, we could avoid one or maybe even two of
> the three temporaries. However insertion of a new flyweight
> should occur rarely in typical use cases, so it doesn't matter
> much. The problem is when constructing s2, a case which is
(Continue reading)

Permalink | Reply |
headers
Corrado Zoccolo | 2 Feb 13:51
Picon

Re: [flyweight] Review period extended to February 3

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
(Continue reading)

Permalink | Reply |
headers
Corrado Zoccolo | 2 Feb 14:04
Picon

Re: [flyweight] Review period extended to February 3

Sorry, I hit the send button before finishing.

On Feb 2, 2008 1:51 PM, Corrado Zoccolo <czoccolo <at> gmail.com> wrote:

> 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
(Continue reading)

Permalink | Reply |
headers
JOAQUIN LOPEZ MU?Z | 2 Feb 15:28
Picon
Favicon
Gravatar

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
(Continue reading)

Permalink | Reply |
headers
Alberto Ganesh Barbati | 3 Feb 12:38
Picon
Favicon

Re: [flyweight] Review period extended to February 3

JOAQUIN LOPEZ MU?Z ha scritto:
> 
> I'm glad you've raised an important issue here. As it happens,
> during the design of the library I devoted some thinking to the
> map-vs-set problem (if you allow me to call it that way) and I opted
> for the current design for the following reasons:
> 
>   <snip>
> 
>   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 :)
(Continue reading)

Permalink | Reply |
headers
JOAQUIN LOPEZ MU?Z | 4 Feb 00:20
Picon
Favicon
Gravatar

Re: [flyweight] Review period extended to February 3

----- Mensaje original -----
De: Alberto Ganesh Barbati <AlbertoBarbati <at> libero.it>
Fecha: Domingo, Febrero 3, 2008 12:39 pm
Asunto: Re: [boost] [flyweight] Review period extended to February 3
Para: boost <at> lists.boost.org

> JOAQUIN LOPEZ MU?Z ha scritto:
[...]
> >   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 such scenario is right there in the GoF book, the word-
> processing application that uses one flyweight object for each
> glyph in the document. I have another case in an project I am
> working on: in a 3D application, I have heavyweight 3D mesh
> objects that might be shared among several actors. The key of a
> 3D mesh is just its filename. I don't want to load 
> an entire mesh into memory just to find out that I have it 
> already. Yes, I could delay the actual loading of the mesh until
> the first time it is actually used, but that would be impractical
> for at least two reasons: 
> 1) any error encountered while loading the mesh would occur in the 
> wrong place and couldn't be handled properly, 2) the place where the 
> mesh is used is inside a tight rendering loop with strict real-time 
> requirements which can't be blocked by costly I/O operations.
(Continue reading)

Permalink | Reply |
headers
Michael Fawcett | 4 Feb 17:08
Picon

Re: [flyweight] Review period extended to February 3

On Feb 3, 2008 6:20 PM, "JOAQUIN LOPEZ MU?Z" <joaquin <at> tid.es> wrote:
> ----- Mensaje original -----
> De: Alberto Ganesh Barbati <AlbertoBarbati <at> libero.it>
> Fecha: Domingo, Febrero 3, 2008 12:39 pm
> Asunto: Re: [boost] [flyweight] Review period extended to February 3
> Para: boost <at> lists.boost.org
>
> > JOAQUIN LOPEZ MU?Z ha scritto:
> [...]
> > >   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 such scenario is right there in the GoF book, the word-
> > processing application that uses one flyweight object for each
> > glyph in the document. I have another case in an project I am
> > working on: in a 3D application, I have heavyweight 3D mesh
> > objects that might be shared among several actors. The key of a
> > 3D mesh is just its filename. I don't want to load
> > an entire mesh into memory just to find out that I have it
> > already. Yes, I could delay the actual loading of the mesh until
> > the first time it is actually used, but that would be impractical
> > for at least two reasons:
> > 1) any error encountered while loading the mesh would occur in the
> > wrong place and couldn't be handled properly, 2) the place where the
> > mesh is used is inside a tight rendering loop with strict real-time
(Continue reading)

Permalink | Reply |
headers
Joaquín Mª López Muñoz | 4 Feb 18:16
Picon
Favicon
Gravatar

Re: [flyweight] Review period extended to February 3

Michael Fawcett ha escrito:

> On Feb 3, 2008 6:20 PM, "JOAQUIN LOPEZ MU?Z" <joaquin <at> tid.es> wrote:
> > ----- Mensaje original -----
> > De: Alberto Ganesh Barbati <AlbertoBarbati <at> libero.it>
> > Fecha: Domingo, Febrero 3, 2008 12:39 pm
> > Asunto: Re: [boost] [flyweight] Review period extended to February 3
> > Para: boost <at> lists.boost.org
> >
> > > One such scenario is right there in the GoF book, the word-
> > > processing application that uses one flyweight object for each
> > > glyph in the document. I have another case in an project I am
> > > working on: in a 3D application, I have heavyweight 3D mesh
> > > objects that might be shared among several actors. The key of a
> > > 3D mesh is just its filename. I don't want to load
> > > an entire mesh into memory just to find out that I have it
> > > already. Yes, I could delay the actual loading of the mesh until
> > > the first time it is actually used, but that would be impractical
> > > for at least two reasons:
> > > 1) any error encountered while loading the mesh would occur in the
> > > wrong place and couldn't be handled properly, 2) the place where the
> > > mesh is used is inside a tight rendering loop with strict real-time
> > > requirements which can't be blocked by costly I/O operations.
> >
> > OK, I'd classify these two examples as scenarios where K and
> > T contain esentially the same info but the translation
> > function f() is computationally expensive. This is a valid
> > context, just not the one I deem the most common.
>
> Just to chime in here, that is also my use case, and I add textures
(Continue reading)

Permalink | Reply |
headers
Michael Fawcett | 4 Feb 18:40
Picon

Re: [flyweight] Review period extended to February 3

On Feb 4, 2008 12:16 PM, Joaquín Mª López Muñoz <joaquin <at> tid.es> wrote:
>
> Good to know there's a potential for the keyed variant. Would you support
> then the provision of regular flyweight and also keyed_flyweight as exposed
> in my prior post?

I support the notion of being able to lookup existing instances by
key.  However you implement it, I hope it will have an elegant syntax,
and an extremely efficient implementation.  Remember that this pattern
is used often in games and 3D graphics, where extra copies are not an
option, regardless of how pretty it makes the code look.

Alberto put it nicely when he wrote:

"I would keep the "factory" term if you are considering the find/insert
approach as an alternative to the current insert-only approach. With
that approach case, find() would be given a key, rather than an object.
If the object is not found, insert() would have to create an object out
of the information stored in the key and that would actually be what
factories are expected to do."

I intended on doing a review but regrettably don't have time to review
this library.  Good luck!  Your libraries are high quality and I enjoy
using them, so I hope Flyweight gets accepted.

--Michael Fawcett
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
Joaquín M LópezMuñoz | 4 Feb 21:44
Picon
Favicon
Gravatar

Re: [flyweight] Review period extended to February 3

Michael Fawcett <michael.fawcett <at> gmail.com> writes:

> 
> On Feb 4, 2008 12:16 PM, Joaquín Mª López Muñoz <joaquin <at> tid.es> wrote:
> >
> > Good to know there's a potential for the keyed variant. Would you support
> > then the provision of regular flyweight and also keyed_flyweight as exposed
> > in my prior post?
> 
> I support the notion of being able to lookup existing instances by
> key.  However you implement it, I hope it will have an elegant syntax,
> and an extremely efficient implementation.  Remember that this pattern
> is used often in games and 3D graphics, where extra copies are not an
> option, regardless of how pretty it makes the code look.

Besides regular flyweight and keyed_flyweight, there's a third
potential variant, namely tha in which the flyweight is
keyed but the key is not stored separately and can be obtained
from T. I'd like to ask you: in your particular use cases, do
your mesh classes store (apart from their data) the name of
the file the data was brought from, i.e. can you obtain
K from T? I wonder whether this third variant is worth implementing
after all, given ther difficulties STL containers have at
comparing elements with external keys.

> I intended on doing a review but regrettably don't have time to review
> this library.  Good luck!  Your libraries are high quality and I enjoy
> using them, so I hope Flyweight gets accepted.

Thanks for your compliments. The review has brought forward a
(Continue reading)

Permalink | Reply |
headers
Michael Fawcett | 4 Feb 22:15
Picon

Re: [flyweight] Review period extended to February 3

On Feb 4, 2008 3:44 PM, Joaquín M LópezMuñoz <joaquin <at> tid.es> wrote:
> Michael Fawcett <michael.fawcett <at> gmail.com> writes:
>
> >
> > On Feb 4, 2008 12:16 PM, Joaquín Mª López Muñoz <joaquin <at> tid.es> wrote:
> > >
> > > Good to know there's a potential for the keyed variant. Would you support
> > > then the provision of regular flyweight and also keyed_flyweight as exposed
> > > in my prior post?
> >
> > I support the notion of being able to lookup existing instances by
> > key.  However you implement it, I hope it will have an elegant syntax,
> > and an extremely efficient implementation.  Remember that this pattern
> > is used often in games and 3D graphics, where extra copies are not an
> > option, regardless of how pretty it makes the code look.
>
> Besides regular flyweight and keyed_flyweight, there's a third
> potential variant, namely tha in which the flyweight is
> keyed but the key is not stored separately and can be obtained
> from T. I'd like to ask you: in your particular use cases, do
> your mesh classes store (apart from their data) the name of
> the file the data was brought from, i.e. can you obtain
> K from T?

Almost never, and neither do the textures usually.  The textures in
particular are very lightweight - they only store a GLuint (OpenGL
typedef for unsigned int).  They also have a custom deleter that
deletes the texture from video memory by calling glDeleteTextures().

--Michael Fawcett
(Continue reading)

Permalink | Reply |
headers
Ion Gaztañaga | 5 Feb 17:44
Picon

Re: [flyweight] Review period extended to February 3

Joaquín M LópezMuñoz wrote:
> Besides regular flyweight and keyed_flyweight, there's a third
> potential variant, namely tha in which the flyweight is
> keyed but the key is not stored separately and can be obtained
> from T. I'd like to ask you: in your particular use cases, do
> your mesh classes store (apart from their data) the name of
> the file the data was brought from, i.e. can you obtain
> K from T? I wonder whether this third variant is worth implementing
> after all, given ther difficulties STL containers have at
> comparing elements with external keys.

This approach has been implemented in Boost.Intrusive. The user gives a 
key and a comparison functor compatible with the container Predicate and 
compares that key with stored values types. Basically this approach was 
provided to be able to efficiently implemented map-like containers over 
intrusive sets. This approach can be also used to search for prefix keys 
in ordered containers so that one can efficiently get the first element 
that begins with a certain key prefix. The approach is certainly 
efficient and I like it, but it can be a bit dangerous for the general case.

In intrusive "insert_check" compares the key and checks for duplicates. 
"insert_commit" uses information from the previous function and inserts 
a real value type. The key used in "insert_check" does not need to be 
enough to create a value type, just enough to find one element. 
Flyweight certainly does not need this flexibility and I don't think 
it's the place for such a general low level mechanism. But keys that are 
convertible to value types (const char * vs. std::string) might be 
interesting use cases to try to implement that third potential variant 
in a safe way.
(Continue reading)

Permalink | Reply |
headers
Joaquín Mª López Muñoz | 5 Feb 18:49
Picon
Favicon
Gravatar

Re: [flyweight] Review period extended to February 3


Ion Gaztañaga ha escrito:

> Joaquín M LópezMuñoz wrote:
> > Besides regular flyweight and keyed_flyweight, there's a third
> > potential variant, namely tha in which the flyweight is
> > keyed but the key is not stored separately and can be obtained
> > from T. I'd like to ask you: in your particular use cases, do
> > your mesh classes store (apart from their data) the name of
> > the file the data was brought from, i.e. can you obtain
> > K from T? I wonder whether this third variant is worth implementing
> > after all, given ther difficulties STL containers have at
> > comparing elements with external keys.
>
> This approach has been implemented in Boost.Intrusive. The user gives a
> key and a comparison functor compatible with the container Predicate and
> compares that key with stored values types. Basically this approach was
> provided to be able to efficiently implemented map-like containers over
> intrusive sets. This approach can be also used to search for prefix keys
> in ordered containers so that one can efficiently get the first element
> that begins with a certain key prefix. The approach is certainly
> efficient and I like it, but it can be a bit dangerous for the general case.
>
> In intrusive "insert_check" compares the key and checks for duplicates.
> "insert_commit" uses information from the previous function and inserts
> a real value type. The key used in "insert_check" does not need to be
> enough to create a value type, just enough to find one element.
> Flyweight certainly does not need this flexibility and I don't think
> it's the place for such a general low level mechanism. But keys that are
> convertible to value types (const char * vs. std::string) might be
(Continue reading)

Permalink | Reply |
headers
Ion Gaztañaga | 5 Feb 20:45
Picon

Re: [flyweight] Review period extended to February 3

Joaquín Mª López Muñoz wrote:

> As I explained in my previous post to Alberto, the problem is that variants
> 1 (classical) and 2 (external key) can be implemented with dumb factories,
> while 3 seems to demand more intelligent components based on B.MI,
> B.Intrusive or sometihng like that. Wouldn't users be satisfied with variant 2
> as a substitute?

Yes, I think variant 2 will be satisfactory.

> Joaquín M López Muñoz
> Telefónica, Investigación y Desarrollo

Regards,

Ion
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Alberto Ganesh Barbati | 5 Feb 00:18
Picon
Favicon

Re: [flyweight] Review period extended to February 3

JOAQUIN LOPEZ MU?Z ha scritto:
> 
> OK, I'd classify these two examples as scenarios where K and
> T contain esentially the same info but the translation
> function f() is computationally expensive. This is a valid
> context, just not the one I deem the most common. Maybe the
> particular case K!=T could be solved by a different class
> keyed_flyweight used like this (the example is similar to that
> of GoF you referred to):

> 
>   struct character
>   {
>     character(char c):c(c){}
>     char c;
>   };
> 
>   int main()
>   {
>     // fw_t objects are constructed from chars but are convertible
>     // to character.
>     typedef keyed_flyweight<char,character> fw_t;
> 
>     // creates an internal character('a')
>     fw_t x1('a');
> 
>     // same shared value as x1, zero temporary character's
>     fw_t x2('a');
> 
>     // creates an internal character('b')
(Continue reading)

Permalink | Reply |
headers
Joaquín Mª López Muñoz | 5 Feb 18:41
Picon
Favicon
Gravatar

Re: [flyweight] Review period extended to February 3

Alberto Ganesh Barbati ha escrito:

> JOAQUIN LOPEZ MU?Z ha scritto:
> > Well, if you think this line of research is interesting I can
> > pursue it.
>
> First of all, thanks for having considered my feedback.

This is what reviews are for :) Thanks for providing the feedback in the
first place.

> I was tempted to
> say that I liked the keyed_flyweight approach, but I preferred reading
> the rest of the thread before replying. When I reached the post of yours
> where you mention the "third" case where the keys are stored inside or
> can otherwise be computed from values, I realized that maybe we could
> not only get that case, but let it all happen (including the non-keyed
> case) with just one flyweight class template. Here's how I see it:
>
> 1) we have two types: key_type for keys and value_type for values. The
> two types can be coincident (as in your non-keyed proposal) or be
> different (keyed case)
>
> 2) the constructor of flyweight semantically takes keys, not values

OK so far.

> 3) keys (not values) are fed as-is to the factory insert() method:
> here's the key point, it's up to the factory to determine whether the
> key is already present and if it's not present to construct the
(Continue reading)

Permalink | Reply |
headers
Alberto Ganesh Barbati | 7 Feb 00:17
Picon
Favicon

Re: [flyweight] Review period extended to February 3

Joaquín Mª López Muñoz ha scritto:
> Alberto Ganesh Barbati ha escrito:
> 
>>
>> 1) we have two types: key_type for keys and value_type for values. The
>> two types can be coincident (as in your non-keyed proposal) or be
>> different (keyed case)
>>
>> 2) the constructor of flyweight semantically takes keys, not values
> 
> OK so far.
> 
> 
>> 3) keys (not values) are fed as-is to the factory insert() method:
>> here's the key point, it's up to the factory to determine whether the
>> key is already present and if it's not present to construct the
>> corresponding value. There's actually no need for a find() method.
> 
> find() would still be useful in combination with rw locks.
> 

If factories are kept "dumb" as they are, yes, it might be useful. See 
below for another possible approach.

> 
>> The flyweight template need not know how to compare keys with values,
>> actually it does not even need to know that it is happening.
> 
> How do I know if value_type is convertible to key_type? I need asistance
> from the user.
(Continue reading)

Permalink | Reply |
headers
Joaquín Mª López Muñoz | 7 Feb 19:07
Picon
Favicon
Gravatar

Re: [flyweight] Review period extended to February 3

Alberto Ganesh Barbati ha escrito:

> Joaquín Mª López Muñoz ha scritto:

[...]

> > How do I know if value_type is convertible to key_type? I need asistance
> > from the user.
> >
>
> The user might be allowed to provide that as an additional extension
> point. However, calling the value_type constructor with the key_type as
> parameter is a reasonable default behaviour.

I was referring to the reverse process, from value_type to key_type,
looks to me you're talking about key_type-->value_type here.

As for the construction key_type-->value_type, I agree with you calling
value_type ctor is a resonable default, but this should be replaceable
by the user (for instance, keyed_flyweight<K,T*> typically will need a
function calling new T rather than a pointer's ctor).

[...]

> > Well, this is a valid approach, but I'd rather factories remained dumber so
> > that all this intelligence is implemented in the core, because of the following
> > reason (among others): STL associative containers (which are the natural
> > components upon which to implement factories) are either set-like
> > (key_type=value_type) or map-like (key_type is a fixed part of value_type,
> > which does not coincide with user's provided T). To be able to accept both
(Continue reading)

Permalink | Reply |
headers
John Torjo | 3 Feb 22:48

Re: [flyweight] Review period extended to February 3


> Here are some questions you might want to answer in your review:
>
> * What is your evaluation of the design?
>   
Ok.
> * What is your evaluation of the implementation?
>   
I like it. Did not go into too much detail, but from what I've looked 
at, it's ok.

One thing I don't like is the initialization of boost::flyweight: 
http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/tutorial/technical.html
I think there could be a simpler way to do this: 
http://www.entropygames.net/globals.htm
> * What is your evaluation of the documentation?
>   
Very nice -  I had no problem reading through the basics.
Did not look much at extending the lib.

> * What is your evaluation of the potential usefulness of the library?
>   
Very useful.
> * Did you try to use the library? With what compiler?
>      Did you have any problems?
>   
No.
> * How much effort did you put into your evaluation?
>      A glance? A quick reading? In-depth study?
>
(Continue reading)

Permalink | Reply |
headers
Joaquín Mª López Muñoz | 4 Feb 09:01
Picon
Favicon
Gravatar

Re: [flyweight] Review period extended to February 3

Hello John, thanks for your review

John Torjo ha escrito:

> > * What is your evaluation of the implementation?
> >
> I like it. Did not go into too much detail, but from what I've looked
> at, it's ok.
>
> One thing I don't like is the initialization of boost::flyweight:
> http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/tutorial/technical.html
> I think there could be a simpler way to do this:
> http://www.entropygames.net/globals.htm

Well, static_holder (which is conceptually very similar to a singleton) does in fact
relies on Meyers' idiom, all the complications described at the referred section stems from
the fact that initialization is forced to happen in pre-main() time to avoid multi-threaded
clashes (which are deemed more unlikely before than after main() starts). Note that
the singletons described at your article can pose problems if first accessed
simultaneously from two different threads --this is what I tried to avoid in my lib.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
John Torjo | 4 Feb 17:43

Re: [flyweight] Review period extended to February 3


>> One thing I don't like is the initialization of boost::flyweight:
>> http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/tutorial/technical.html
>> I think there could be a simpler way to do this:
>> http://www.entropygames.net/globals.htm
>>     
>
> Well, static_holder (which is conceptually very similar to a singleton) does in fact
> relies on Meyers' idiom, all the complications described at the referred section stems from
> the fact that initialization is forced to happen in pre-main() time to avoid multi-threaded
> clashes (which are deemed more unlikely before than after main() starts). Note that
> the singletons described at your article can pose problems if first accessed
> simultaneously from two different threads --this is what I tried to avoid in my lib.
>   
I was talking about depends_on class

Best,
John

--

-- 
http://John.Torjo.com -- C++ expert
... call me only if you want things done right

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Joaquín Mª López Muñoz | 4 Feb 18:18
Picon
Favicon
Gravatar

Re: [flyweight] Review period extended to February 3


John Torjo ha escrito:

> >> One thing I don't like is the initialization of boost::flyweight:
> >> http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/tutorial/technical.html
> >> I think there could be a simpler way to do this:
> >> http://www.entropygames.net/globals.htm
> >>
> >
> > Well, static_holder (which is conceptually very similar to a singleton) does in fact
> > relies on Meyers' idiom, all the complications described at the referred section stems from
> > the fact that initialization is forced to happen in pre-main() time to avoid multi-threaded
> > clashes (which are deemed more unlikely before than after main() starts). Note that
> > the singletons described at your article can pose problems if first accessed
> > simultaneously from two different threads --this is what I tried to avoid in my lib.
> >
> I was talking about depends_on class

Oh, excuse my misunderstanding. In which way do you think that the depends_on
class can simplify the static initialization issues for the flyweight lib?

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Markus Werle | 3 Feb 23:13
Picon

Re: [flyweight] Review period extended to February 3

Thanks for extending this period!

Ion Gaztañaga <igaztanaga <at> gmail.com> writes:

> * What is your evaluation of the design?
> * What is your evaluation of the implementation?
> * What is your evaluation of the documentation?

I only took a short glance at the docs and at the issue page

> * What is your evaluation of the potential usefulness of the library?

I think this lib _could_ become useful for me some day.
No idea yet, but it is nice to know the solution to problems
that I do not have - yet. This is how I use boost all the time ...

> * Did you try to use the library? With what compiler?
>      Did you have any problems?

no try

> * How much effort did you put into your evaluation?

A quick reading

> * Are you knowledgeable about the problem domain?
no

> And finally, every review should answer this question:
>
(Continue reading)

Permalink | Reply |
headers
Joaquín Mª López Muñoz | 4 Feb 12:54
Picon
Favicon
Gravatar

Re: [flyweight] Review period extended to February 3

Hi Markus, thank you for submitting your review.

Markus Werle ha escrito:

> My remarks to the current discusion:
>
> Equality semantics:
> This is where I'd like to see the library changed.
> I did not think about this in depth, but it let me feel
> uncomfortable immediately after reading that passage in the docs.
>
> Flyweight is advertized as "drop-in replacement for const T."
> and can be used everywhere a "T const &" is expected
> and as such it should behave also for operator==.
> I found it odd, that something that is "not a pointer" must
> be dereferenced to be compared.

Sorry, I'm not getting this. Where is dereferencing needed?

> This breaks too much code for a true drop-in replacement.
> Also I think that intuitive behaviour is a GoodThing(TM) for a C++
> library. We get so used to all these little oddities that make
> you look into the book even after years in C++, but I think
> it's complicated enough now.
>
> The constant time comparison is nice, but it is due to the
> IMHO counter-intuitive basic interface (though I can see its advantages).
> In any case I'd prefer comparison of the underlying values,
> even for flyweights from different factories (!), just in order
> to keep the "drop-in replacement for const T." semantics everywhere
(Continue reading)

Permalink | Reply |
headers
Kevin Sopp | 3 Feb 23:42

Re: [flyweight] Review period extended to February 3

I vote for flyweight to be accepted into boost.

Earlier this week I have tried to plug a flyweight<string> type into
Boost.Wave but failed at doing so for reasons related to Boost.Wave or
my inexperience with Boost.Wave. So this review is based on a look at
its implementation and a longer look at its documentation. I am
knowledgable about the domain as I have implemented my own flyweight
type which was only customizable in respect to the parameters for the
hash container and which used a refcount tracking.

First of all I don't mind the name factory but I would prefer flyweight_pool.

I think the design is very good and the amount of work that Joaquin
has done for a seemingly simple library is amazing.

The documentation is very detailed minus some minor spelling errors.
It could use a better example in the Introduction with a custom object
and a custom hash function. Because 'how do I use boost.hash again'
was the question in my head.

As was already mentioned, a way to get usage statistics about the
flyweights would be nice.

Kevin
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Joaquín Mª López Muñoz | 4 Feb 12:58
Picon
Favicon
Gravatar

Re: [flyweight] Review period extended to February 3

Hello Kevin, thank you for your review.

Kevin Sopp ha escrito:

> First of all I don't mind the name factory but I would prefer flyweight_pool.

This name looks interesting to me. But I don't know how to arrange things so
as to reach a consensus on terminology among the reviewers. Maybe a separate
poll.

> The documentation is very detailed minus some minor spelling errors.

Could you please point me to those spelling errors? Thank you!

> It could use a better example in the Introduction with a custom object
> and a custom hash function. Because 'how do I use boost.hash again'
> was the question in my head.

I precisely chose a natively hashed type to not deviate the user's attention
from these details :) I can include a reference to the appropriate section at Boost.Hash
docs, though.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |

Gmane