Re: connection points?

From: Phil Da Lick! (kjhgjhfgfdjgkjkhfdghhjfd_at_hkfhkgjfdhhfdg.spam)
Date: 02/24/04 

Date: Tue, 24 Feb 2004 22:22:35 -0000

"Igor Tandetnik" <itandetnik@mvps.org> wrote in message
news:OTPK0Nu%23DHA.3452@TK2MSFTNGP11.phx.gbl...
> "Phil Da Lick!" <phil_the_lick@nospam.hotmail.com> wrote in message
> news:1WF_b.9812$h44.1099836@stones.force9.net...
> > Thanks both, I think what I'll do is just pass a pointer to the
> required
> > interface into the children. They are defined entirely within the
> scope of
> > the parent. When the parent dies, the children die as well so this
> shouldn't
> > be a problem.
>
> What if the client still holds an interface pointer of the element? You
> can't have an element destroyed, or the client will crash the moment it
> calls anything through that pointer.

erm I think I'm getting confused about your terminology now, as I did when I
read up on connection points. Basically I have an object which holds a list
[collection] of other objects. The list is not incredibly dynamic, and all
add/remove functions will go through the parent object. When the parent
object dies, all children die. No child will die before the parent unless it
is the result of a proper delte operation within the parent's list
functions. No child object exists before the parent is created.

> > I just wondered whether the "correct" approach was to use a connection
> > point, that's all.
>
> Connection points are designed for loosely coupled components -
> components that have little or no a-priori knowledge of each other. You
> don't really need such a heavy-weight mechanism for tightly coupled
> components - components that are designed from the start to integrate
> with each other, often on the source code level. You don't even need COM
> for that - they can just hold straight C++ pointers to each other.

Sounds like the best way is as described in this thread. From what you've
said here CP's are overkill.

Relevant Pages

  • Re: AfxBeginThread question
    ... This comes as a serioius surprise to those of us who take AfxBeginThread for granted ... The last parameter, which is a pointer, would be written as NULL. ... On request to exit parent app, parent app notifies thread to close ... thread-shutdown object in as one of the fields of your parameter block. ...
    (microsoft.public.vc.mfc)
  • [PATCH 4/4] docbook: fix filesystems content
    ... Fix filesystems docbook warnings. ... a pointer to a string containing the name of the file to create. ... * @parent: a pointer to the parent dentry for this file. ...
    (Linux-Kernel)
  • [PATCH v4 7/8] debugfs: allow access to signed values
    ... debugfs: ... a pointer to a string containing the name of the file to create. ... * @parent: a pointer to the parent dentry for this file. ... * This function will return a pointer to a dentry if it succeeds. ...
    (Linux-Kernel)
  • [PATCH v5 7/8] debugfs: allow access to signed values
    ... debugfs: ... a pointer to a string containing the name of the file to create. ... * @parent: a pointer to the parent dentry for this file. ... * This function will return a pointer to a dentry if it succeeds. ...
    (Linux-Kernel)
  • Re: Stumped: returning a read pipe from a function
    ... use Socket; ... socketpair(my $child, my $parent, AF_UNIX, ... or die $!; ...
    (comp.lang.perl.misc)