Boost logo

Boost :

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2002-12-11 11:02:15


"Eric Woodruff" <Eric.Woodruff_at_[hidden]> wrote in message
news:at7kru$5v7$1_at_main.gmane.org...
>
> "Johan Nilsson" <johan.nilsson_at_[hidden]> wrote in message
> news:at76e1$2ro$1_at_main.gmane.org...
> >
> > "Eric Woodruff" <Eric.Woodruff_at_[hidden]> wrote in message
> > news:at542o$2hq$1_at_main.gmane.org...
> > >
> > > "Johan Nilsson" <johan.nilsson_at_[hidden]> wrote in message
> > > news:at52vi$si6$1_at_main.gmane.org...
> > > [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.

?????


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk