RE: [pooma-dev] DynamicArray destroy methods

[Julian C. Cummings]

Hi Jim,

 

I'm pretty sure your performance concerns are unfounded.

Accessing object methods via reference should never incur

a performance penalty, just as using the dot operator and

the arrow operator should be equivalent.  If this were not the

case, almost all C++ code ever written would have problems.

There is a performance penalty when you pass a heavyweight

object by value, of course.

 

In any case, I did a quick test of your idea.  It can be made

to work, but is slightly more annoying in actual use.  In order

for the pass-by-value to match when passing an iterator pair,

both of the arguments must be local objects that can be copied.

Thus, passing something like (dptr,dptr+3), where dptr is an

int*, once again triggers the ambiguity error.  The compiler thinks

you have passed an int* & and an int*, and these two arguments

are not exactly the same.  So you have to declare a second

int* object and set it equal to dptr+3.  With const references,

this little annoyance is gone.

 

Julian C.

 

P.S.  I stumbled over another potential bug, this time in the

IteratorPairDomain class.  The non-const version of operator()

returns an Element_t&.  This is incorrect when Iter is a const T*.

I think we need to add a typedef for ElementRef_t, which would

be set to std::iterator_traits<Iter>::reference, and return that here.

 

-----Original Message-----
From: James Crotinger [mailto:address@hidden
Sent: Monday, April 23, 2001 12:20 PM
To: 'address@hidden'; Pooma Developers
Subject: RE: [pooma-dev] DynamicArray destroy methods

I tend not to like this idea. Won't passing references result in dereferencing every time you use the object in question? With iterators and ints I would think this could potentially impact performance.

What about going the other way and passing the Destroy tag by value? We might need to write a dummy copy constructor for the tag, but that's not so hard.

        Jim

> -----Original Message-----
> From: Julian C. Cummings [mailto:address@hidden]
> Sent: Monday, April 23, 2001 12:59 PM
> To: Pooma Developers
> Subject: RE: [pooma-dev] DynamicArray destroy methods
>
>
> Never mind!  I just figured out the problem
> and the solution.  The reason for the overload
> ambiguities is that we were defining the
> destroy() functions to take domain and destroy
> method arguments by const reference but take
> iterators and patch IDs by value.  So the
> overloads did not match the function calls in
> exactly the same way, and I guess const int& is
> preferred to int when you pass a literal int
> like "6".  Also, you have to be careful about
> passing with an int array like killList because
> it is not treated quite the same as &killList[0]
> when it comes to argument matching.
>
> Anyhow, once I changed the iterator and patchID
> arguments to be passed by const reference, all
> the function overloads matched as expected.  I'd
> like to check in these fixes to DynamicArray.h
> along with the minor fixes I mentioned in my
> original e-mail on this, barring any objections.
> I am attaching the diff's for DynamicArray.h
> Sorry for the volley of e-mails on this.
>
> Julian C.
>
>
> > -----Original Message-----
> > From: Julian C. Cummings [mailto:address@hidden]
> > Sent: Monday, April 23, 2001 11:19 AM
> > To: Pooma Developers
> > Subject: RE: [pooma-dev] DynamicArray destroy methods
> >
> >
> > One way out of the function overloading
> > quandary I noted below would be to call
> > out versions of destroy() for each of the
> > two existing destroy methods, BackFill
> > and ShiftUp, rather than use a template
> > parameter.  We are unlikely to add more
> > of these, and if we do, they have to be
> > added to the list in DynamicEvents anyway.
> > Should we take this approach?
> >
> > Julian C.
> >
> >
> > > -----Original Message-----
> > > From: Julian C. Cummings [mailto:address@hidden]
> > > Sent: Monday, April 23, 2001 11:08 AM
> > > To: James Crotinger
> > > Cc: Pooma Developers
> > > Subject: [pooma-dev] DynamicArray destroy methods
> > >
> > >
> > > Jim,
> > >
> > > I was going to add new destroy() functions
> > > to Particles corresponding to the new
> > > IteratorPairDomain-based functions you
> > > added to DynamicArray.  I noticed three minor
> > > glitches in DynamicArray.h that I was going
> > > to fix, if you don't object.  One is on
> > > line 486.  We don't need to provide the
> > > BackFill() argument here because dynamic
> > > engines already provide a destroy() function
> > > that takes just a Domain argument.  (No harm
> > > done here though, and I think this glitch
> > > was here prior to your recent changes.)  The
> > > next item is on line 501.  You left out the
> > > Pooma:: qualifier on the IteratorPairDomain
> > > type.  It should be there for consistency,
> > > although there is probably a "using namespace
> > > Pooma;" statement somewhere that is making
> > > this work as written.  The last problem is on
> > > line 542.  I think you do have to provide the
> > > BackFill() argument here because MPEngine only
> > > provides three versions of destroy(): domain,
> > > domain and patchID, or domain, patchID and method.
> > >
> > > I was trying to check out this third item when
> > > I ran into another problem.  Perhaps others can
> > > chime in on this.  I modified dynamic_array_test5.cpp
> > > to call destroy() without specifying a method.  So
> > > I made calls with arguments (int*,int*) and with
> > > (vector<int>::iterator,vector<int>::iterator,int).
> > > The first call should invoke destroy() with Iter
> > > equal to int* (DynamicArray.h, line 498), but gcc
> > > says the overload is ambiguous with the version on
> > > line 477 also being plausible.  I thought matching
> > > one template parameter always beats matching two.
> > > With my second call, I was trying to invoke the
> > > destroy() function on line 538 of DynamicArray.h,
> > > but gcc thinks the version on line 491 is a good
> > > match also.  Again I am surprised because PatchID_t
> > > is defined as int, and that exactly matches the
> > > type of my third argument.  What's the deal?
> > >
> > > Julian C.
> > >
> > >
> >
>