|
Boost Users : |
Subject: Re: [Boost-users] 'Hashable' concept for type erasure
From: Samuel Christie (schrist_at_[hidden])
Date: 2014-03-24 14:46:02
Interesting. That looks useful, but at the same time I think I can actually
get away without erasing _value. The actual type would be the erased type
we were working on earlier, so I should be able to just stick it in
explicitly.
How would you erase insert() though? Its return type seems fairly
complicated. I tried using std::pair<te::any<te::forward_iterator<> >,
bool>, but I get "invalid initialization of reference of type 'int&' from
expression of type 'const int'" for the simple test case.
Thanks again,
-sc
On Sat, Mar 22, 2014 at 8:47 PM, Steven Watanabe <watanabesj_at_[hidden]>wrote:
> AMDG
>
> On 03/22/2014 05:13 PM, Samuel Christie wrote:
> > Hmm. Maybe it would be best if I make a custom wrapper class anyway,
> then.
> > All I really need is the ability to 1) record 'seen' objects in the
> > history, and 2) be able to tell whether one of the same objects is in the
> > history or not. Up until this point, I've been using unordered_sets, but
> I
> > was hoping to support more sophisticated memory models that would only
> > remember recent history, for instance.
> >
> > Of those choices, I think (b) makes the most sense for my purposes,
> though
> > a or c would also be acceptable. I can't really see how I would achieve
> > that with just type erasure though. This could easily be a case of an
> > over-used hammer.
> >
>
> Do you actually need to erase the value_type?
> If you can use has_count<size_t(int)>, then
> everything will just work.
>
> > If you don't mind my asking, which of them would you recommend, which do
> > you think is achievable with type-erasure, and what other alternatives do
> > you think I should be considering?
> >
>
> If it were just count, I would go for (b). However,
> that isn't an option for insert, since it's impossible
> to insert something that isn't an int into a container
> that stores ints. Whether consistency between the
> functions is more important than the extra convenience,
> only you can decide. Now that I think about it, all these
> options can all be implemented in basically the same way
> (you will need typeid_<_value> for this to work):
>
> template<class T>
> std::size_t generic_count(const any_set& c, const T& t)
> {
> typedef any<requirements, const _value&> val_ref;
> // check that the type of t matches the value_type
> // of the container.
> if(typeid_of<_value>(binding_of(c)) == typeid(t)) {
> // capture the value in a way that's compatible
> // with the container.
> val_ref v(t, binding_of(c));
> return c.count(v);
> } else {
> return 0; // or throw or whatever
> }
> }
>
> You can put this directly in the concept_interface,
> if you define it manually instead of using
> BOOST_TYPE_ERASURE_MEMBER.
>
> In Christ,
> Steven Watanabe
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net