|
From: | James Crotinger |
Subject: | RE: [pooma-dev] DynamicArray destroy methods |
Date: | Mon, 23 Apr 2001 14:20:36 -0700 |
Hi Jim,I'm pretty sure your performance concerns are unfounded.Accessing object methods via reference should never incura performance penalty, just as using the dot operator andthe arrow operator should be equivalent. If this were not thecase, almost all C++ code ever written would have problems.There is a performance penalty when you pass a heavyweightobject by value, of course.In any case, I did a quick test of your idea. It can be madeto work, but is slightly more annoying in actual use. In orderfor 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 anint*, once again triggers the ambiguity error. The compiler thinksyou have passed an int* & and an int*, and these two argumentsare not exactly the same. So you have to declare a secondint* 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 theIteratorPairDomain 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 wouldbe 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 methodsI 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.
> > >
> > >
> >
>
[Prev in Thread] | Current Thread | [Next in Thread] |