Re: Deprecating --enable-bounds-check?

[Rik]

On 05/11/2017 11:49 AM, John W. Eaton wrote:
> On 05/11/2017 01:16 PM, Rik wrote: > >>> It seems reasonable to me.  We could make xelem, elem, and () all do the >>> same thing, and deprecate xelem (and possibly elem, or is there an >>> advantage to having both operator and member function forms?). > > Oops, I started looking at this and realized that I completely forgot about the other difference between xelem and elem:  elem checks the reference count. > > We could still eliminate bounds checking by doing the following: > >     deprecating checkelem >     removing the conditional call to it in () >     replacing the elem method with () everywhere > > Then, separately, we could decide to eliminate xelem.  If we eliminate it, then all uses can be replaced by using the data method to get a pointer to the underlying data vector then and indexing that directly with "[]".  Doing that is probably better than using xelem anyway, because it forces you to think about whether the object is const and/or whether you want to make the representation unique instead of just ignoring the reference count completely.

A long time back I did some benchmarking on using fortran_vec and then indexing directly on the data.  The performance boost was about 10% which is enough to be noticeable and worth it for things like mapper functions.  For files outside the core, say a user's .oct file, I think the reduction in the clarity of the code probably isn't worth the 10%.

What is the 2x2 decision diagram for this?

          const    non-const
        |        |           |
 unique |        |           |
        |--------|-----------|
 same   |        |           |
        |        |           |


I can see that predicate test functions might be const, same.  And I could see mapper functions as being non-const, same.  When and how would the programmer decide on unique/same?


> > What do you think? > > Either way, I can go ahead and do the first part now.

That's better for the philosophy of one change / one changeset as well.

--Rik