JOAQUIN LOPEZ MU?Z said: (by the date of Thu, 05 Oct 2006 22:53:10 +0200)

After uploading the version of the lib you can find at the vault. I'd say the stuff could be ready for presentation around Dec 06 or Jan 07.

thanks for your answer. I'll get it from the vault and examine it carefully, while trying to use it. I see a possibility to save a lot of memory :) If I decide to depend on it, I hope that it will make its way into boost 1.35 :) -- Janek Kozicki |

Joaquín M_ López Mu_oz said: (by the date of Fri, 06 Oct 2006 07:48:22 +0200)

Janek Kozicki ha escrito:

What is your intended usage scenario? It might help me add more diversity to the examples section of the lib.

1. I want to try to use it together with boost::serialization when converting between archive formats. Think about xml format - it has to remember variable name (as a string) for each variable. But with large collections, those strings are higly duplicated. Like - a container with 1000 similar objects that have just 8 variables. And of course those variables have long names, because the names should be descriptive :) 2. a Typo in libs/flyweight/doc/tutorial/holders.html: "For instance, flyweight<T> is equivalent to" ^^^ 3. am I right to think that: flyweight<std::string,hashed_factory<>,global_holder<unsigned char> > will allow me to have 255 different strings, while flyweight<std::string,hashed_factory<>,global_holder<unsigned short> > will allow me to have 65535 ? 4. have you ever thought about sample usage of flywieght to create a new boost library: boost::flyweight_shared_ptr<T> ? The problem it tries to solve is that on amd64 each pointer consumes 64 bits (8 bytes!), when people make a switch from 32bits to 64bits, this hurts badly. In my calculations memory usage grew from 700MB to 1.3GB, and that actually makes a difference. (it's not possible to run calculations if some of the data must swap to disc...) hmm... maybe this will actually work: boost::flyweight<boost::shared_ptr<T> > will it? -- Janek Kozicki |

JOAQUIN LOPEZ MU?Z said: (by the date of Sun, 08 Oct 2006 13:21:04 +0200)

Well, the short answer is that flyweight won't gain you nothing wrt to shared_ptr, since flyweight objects contain a pointer (much like shared_ptr's) which is 8 bytes in 64bit architectures. The long answer is, given the flexibility that the componentized nature of flyweight allows, it is possible to devise a factory adaptor that limits the capacity of the factory *and* let the flyweight object use internally a handle value smaller in size than a pointer (an index of size unsigned short, for instance). I will try to write something along this line, I'll keep you informed.

many thanks. This is the feature I'm looking for. Consider my first example about serialization. The variable names in classess have names with various length, eg: "foo", "bar", "my_cool_foo_bar_controller", etc. Their length varies, but in some cases average length is shorter than 8 characters (64 bits), therefore only this size reduction (8 bytes -> 1 byte) gives an improvement. In the case of std::string("foo"); we actually lose 5 bytes of memory on amd64 with flyweight (minus some additional storage data that std::string might use..) ;) -- Janek Kozicki |