Arash, Arash Partow wrote:
Vicente Botet wrote:
Could you give a concrete example of insertion of different types? any type?
A valid use-case could be that you have a struct called ipv4 and another called ipv6 which represent ip addresses (though not necessarily inheriting from a common base). Now it is true that they are nothing more than arrays of chars (or a string), but lets assume we'd like to treat them as the objects they are without knowing their underlying detail. Following on from this I'd like to be able to do something like the following:
bloom_filter<AHashFunc> bf(.....);
ipv4 i4(....); ipv6 i6(....);
bf.insert(i4); bf.insert(i6);
Where the only requirement is that the types ipv4 and ipv6 have the correct hash function specialization in the namespace std::tr1
I can see the convenience of this approach. Why would you prefer to use one Bloom filter to store two related types rather than two Bloom filters? For example: code wrote:
bloom_filter<ip4, 10000> ip4_bloom; bloom_filter<ip6, 10000> ip6_bloom;
ip4 x4(...); ip6 x6(...);
if ( // if is ip4, perhaps using type-traits or some form of polymorphism ) ip4_bloom.insert(x4); else if ( // if is ip6) ip6_bloom.insert(x6); else //error;
//...
if (!ip4_bloom.contains(...) ) // load resource from high latency storage else // fetch from cache
This is how I would typically expect the current Bloom filter to be used in multi-type scenarios. Arash Partow wrote:
Something to ponder over, when inserting a boost:any is it the any-type as a whole, the underlying type or the serialized type that will be inserted into the BF? What about a Person class? would it be the Person type as a whole, or the serialized form of every field in the Person type that will be inserted? - I supposed it all depends on the way the hash input is generated.
This really depends on the implementation of the Hasher (hash function callable). A Hasher could target a specific field of an object to generate its fingerprint. Alternatively, the Hasher could treat an object as an array of bytes and generate the fingerprint in that fashion. I've left this aspect of the design very open to customization. -Alej -- View this message in context: http://boost.2283326.n4.nabble.com/GSoC-Request-for-Feedback-on-Boost-Bloom-... Sent from the Boost - Dev mailing list archive at Nabble.com.