Re: [dbus-cplusplus-devel] Server's copy-constructor

[Ignacy G. <sf...@qu...>]

On Fri, Sep 05, 2008 at 05:39:57PM +0200, thus spake P. Durante:
> On Fri, Sep 5, 2008 at 1:29 PM, Ignacy Gawedzki <sf...@qu...> wrote:
> > Hi,
> >
> > A little question while I'm skimming the source code: what's the point with
> > the protected copy-constructor of Server?  I'm not asking why it is protected,
> > but why doesn't it do anything with the _pvt attribute, which remains 0.
> >
> it's just the C++ way of disallowing copies (but it should be private
> and not protected to make it clear, sorry)

Okay, then it should be private and should not have any body defined (just
declared).

> since there can't be copies around (they won't even work since their
> on_new_connection() would never be called, and honestly i can't see a
> use case where you'd need to do that anyway) the private smart pointer
> is useless, it could be a regular pointer

Or even a regular attribute, composited and not aggregated.  The only problem
would be that then it could not be hidden away in that _p.h file.  Quite
frankly, I don't really see the point in hiding these Private instances, but
nevermind. =)

> feel free to throw that class away and rewrite it :-)

I'm actually changing it in some ways to make it work.  There are few things
that need to be done in order to make writing an actual server possible.

First, oddly enough, I need to instantiate a dummy DBus object, so that
messages like Hello and AddWatch from clients (which are apparently sent
automatically by libdbus, regardless of whether the connection is to a
dbus-daemon or a private one) are successfully received.

Second, I need as many instances of exported objects as I have open
connections and I need to be able to destroy all the ones associated with a
connection that I'm closing.  For this purpose I need to be able to retrieve
all the instances that have been constructed with a given connection.

I could of course keep a container with my objects, but then I would have to
iterate through all its elements in search of the ones that have been
constructed with a given connection.  So here it would be helpful to keep a
collection of pointers to the objects in instances of Connection themselves.
Here arises the question of whether the objects should be composited (i.e.
owned by the connection) or simply aggregated.  Since each instance of Object
owns its instance of Connection, making the Connection own its objects doesn't
make much sense.

-- 
NO CARRIER