[ZOOM] Re: Ouch

Mike Taylor mike at tecc.co.uk
Thu Nov 1 11:59:53 CET 2001


Adam (and others),

Now that we have the ZOOM list, could we please make an effort to
remember that replies need go _only_ to the list, not also to the
originator.  Otherwise, the originator gets two copies.  Not the end
of the world, but worth avoiding if/when you remember.

> Date: Thu, 1 Nov 2001 11:38:53 +0100
> From: Adam Dickmeiss <adam at indexdata.dk>
> 
> > What's the point?  If we added this, wouldn't the following two lines
> > be _exactly_ equivalent?
> > 
> > 	resultSet rs = c->search(q);
> > 	resultSet rs = new resultSet(c, q);
>
> Well if you add a pointer, then the code compiles. Result is:
>        resultSet *rs = c->search(q);
>        resultSet *rs = new resultSet(c, q);

Sure, I'm blurring the pointer issue at the moment because I don't
think we've resolved it one way or the other yet.  BUT I think I'm
beginning to understand what your point is (FX: Adam sighs with
relief.)

> > > record *give_me_targetinfo (connection *c)
> > > {
> > >     prefixQuery q("@attr exp1 1=1 targetinfo");
> > >     resultSet s(c, &q);
> > ***or  resultSet s = c->search(q);
> > >     return s.getRecord(0);
> > > }
> > >
> > > record *give_me_targetinfo2 (connection *c)
> > > {
> > >     prefixQuery q("@attr exp1 1=1 targetinfo");
> > >     resultSet *s = new resultSet(c, &q);
> > >     record *rec = s->getRecord(0);
> > >     delete s;
> > >     return rec;
> > > }
> 
> There are two ways and it makes sense. Why? The pointer version is
> used when you have an object and you don't want it to be destructed
> within the function (control of lifetime). You have local objects
> (first version) when you wan't them to be automatically destrcuted.
> That's the C++ style, AFAIK. 

Right.  I agree that this is a valuable thing to aim for.

So are you saying (you seem to be) that the reason you want an
explicit constructor is because you can then use it to allocate
resultSet objects _either_ on the stack or on the heap?  Whereas
ZOOM:connection::search() always returns a pointer?

If so, then, your legitimate requirement would also be met by:

	class connection {
	 public:
	   resultSet *search (query *q);
	   resultSet searchStack (query *q);
	};

(Not that I am necessarily claiming that this is a better way to do
it: just making sure I understand what the issues are.)

BTW., and this sort of related, it may be that the search method (or
methods) (or the equivalent resultSet constructors) should take a
query (not a query*) as their argument.  Then you can say:

	resultSet *s = c->search(prefixQuery("@attr exp1 1=1 targetinfo");

Instead of having to mess about like this:

	prefixQuery q("@attr exp1 1=1 targetinfo");
	resultSet *s = c->search(&q);

The more I look at this interface, the more I think that I was overly
seduced by the C mindset in putting together the initial version (and
to be fair to myself, I do admit that in the introductory prose!) with
the result that pointers predominate in a way that is not idiomatic
C++.

Thanks for battling on until you finally managed to get me to see
this.  You've been very gracious about it :-)

> Furthermore when resultSets create resultSets you have a way to use
> a different (your own) new operator. That doesn't work when
> connections create result sets.

Once again, I'm afraid I don't understand what point you're making.
Is it a duplicate of the above?  If not, you'll have to explain it.

> If we force pointers, then one of the major points of doing C++
> implementations is sort of, well gone. Since you ALWAYS have to do
> manual destruction (delete) - you know like C.

Yuh.

> > I think we're confusing two issues here: one is the issue of
> > whether the C++ binding should be passing actual objects rather
> > than pointers, and the other is whether we want an explicit
> > resultSet constructor.
> 
> True. But if you force pointers on people that affects the
> way objects are used in subsequent methods.

So am I right in thinking that the reason these two issues are getting
confused is that you see explicit constructurs as The Right Way of
getting hold of non-pointer resultSet objects?

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor   <mike at miketaylor.org.uk>   www.miketaylor.org.uk
)_v__/\  "Sitting on the sofa with all our classified information ..."
	 -- Monty Python.




More information about the ZOOM mailing list