"Eric Woodruff" <[EMAIL PROTECTED]> wrote in message at7kru$5v7$[EMAIL PROTECTED]">news:at7kru$5v7$[EMAIL PROTECTED]... > > "Johan Nilsson" <[EMAIL PROTECTED]> wrote in message > at76e1$2ro$[EMAIL PROTECTED]">news:at76e1$2ro$[EMAIL PROTECTED]... > > > > "Eric Woodruff" <[EMAIL PROTECTED]> wrote in message > > at542o$2hq$[EMAIL PROTECTED]">news:at542o$2hq$[EMAIL PROTECTED]... > > > > > > "Johan Nilsson" <[EMAIL PROTECTED]> wrote in message > > > at52vi$si6$[EMAIL PROTECTED]">news:at52vi$si6$[EMAIL PROTECTED]... > > > [snip] > > > > > > > I'd like to be able to store references to objects of arbitrary types > in > > a > > > > homogenous collection, not requiring them to be derived from a common > > base > > > > class. For COM users, that would be something like an "IUnknown in the > > > > context of standard C++". I suspect that boost::any might be something > > > > similar to what I need, but I just got that idea using void pointers. > > > > > > > > > > What's the point of that? I mean, with no interface to the types, you > > can't > > > do anything with these objects you're storing, not even delete them. > > > > > > > If I can dynamically cast a void pointer to a polymorphic type, I can do > > whatever I want to do. > > > > > You could also do: > > > > > > struct IHolder { > > > virtual ~IHolder () {} > > > }; > > > > > > template <typename Object> > > > class holder : public IHolder{ > > > public: > > > holder (Object* const object); > > > ~holder (); > > > }; > > > > > > It's always better to try and look for a real (type safe) solution than > > > playing around with type casting. It still depends on what you want to > > _do_ > > > with theses objects behind this common, empty interface. I suspect > > problems > > > with your design if you have been led down this path. > > > > > > > I _am_ looking for a type safe solution, I was simply playing around > trying > > to find one that would fit my needs. > > > > I'm actually experimenting with a kind of 'generic' object factory with > the > > following characteristics: > > > > Well then void* is not what you need. Especially in your design, you may > later decide that need to not only delete these objects in the factory, but > do other things with them as well. >
I thought that was what I said, or, at least what I was trying to say? > I think you need to reanalyze what your needs are and the important roles in > this system. It seems to be that there is more than one class necessary > here. I have not suggested otherwise. I simplified for the sake of illustration (which obviously failed), and the domain-specific part has not even been mentioned here. Anyway, I think this is definitely going out of scope for this mailing list, so I suggest leaving the discussion. > > Anyhow, in my opinion, dynamic_void_cast is completely unnecessary and takes > casts away the intent that it is _supposed_ to be a two step and very ugly > process--the signifier that you have a not-so-good design on your hands. I'd rather have the possibility in the language to dynamic_cast all data types (including built-ins). > Stop trying to code a new messenger. ????? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
