Re: dynamic axex [was Re: with parallelaxes dumps core]

[sfeam <sf...@us...>]

On Wednesday, 28 January 2015 10:55:40 PM Hans-Bernhard Bröker wrote:
> Am 27.01.2015 um 18:46 schrieb Ethan A Merritt:
> 
> > However, none of these are the reason for a cap on the number
> > of parallel axes. That comes instead from a poor design
> > decision now lost in the mists of program history.
> 
> I disagree about that decision having been a poor one. It was correct at 
> the time it was originally made, because it matched the capabilities and 
> of the program at the time.  There was really no way anyone could have 
> anticipated the amount of stuff that was later grafted onto the original 
> design.  A truly bad design would never have withstood 20+ years of add-ons.

Closer to 30 years now :-)

> > This is bad, because you can't just allocate a new
> > axis structure and pass it to any of the existing
> > subroutines or macros.
> 
> That wouldn't work anyway, and for rather more important reasons than 
> the implementation detail of whether axis methods' primary argument is 
> an index or a pointer.
> 
> The axes have to be in an array because the indices into that array have 
> more meaning than just as the indicator of one array entry to work with. 
>   The sequence of AXIS_INDEX enumeration values has been the same since 
> just about forever, and it has extra properties.  The entire first vs. 
> second axes mechanism is built on these properties.
> 
> IOW: as long as there remains
> 
> 	* any use of the macros FIRST_AXES and SECOND_AXES
> 	* any loop over a variable of type AXIS_INDEX
> 	* any inequality comparison among AXIS_INDEX values
> 
> you won't get rid of axis_array[].

I take your point, but that by itself isn't an argument against 
designing the various subroutines to accept pointers rather than
indices.  It is no harder to call sub(&array_axis[INDEX]) than
it is to call sub(INDEX).  All the FIRST and SECOND axes could
continue to live in an array just as they do now.  But unlike now
it would also be possible to dynamically allocate a temporary axis
structure, or a contiguous array of them if that makes sense.

As to manipulations using FIRST_AXES and SECOND_AXES,
there are not very many of these.  I suspect it would suffice to 
add a field or flag to the axis structure.

Instead of having code like axis.c:1381
    TBOOLEAN axis_is_second = ((axis / SECOND_AXES) == 1);
you would have
    TBOOLEAN axis_is_second = axis->is_second_axis;

> The best one could do before that would be to make axis_array[] itself 
> dynamically sized.  That, however, would mean that _all_ uses of 
> pointer-to-AXIS would have to be forbidden, because the array itself 
> could move when reallocated.  I.e. it would push things into the 
> opposite direction of your intention.

I agree that option is not very workable.

	Ethan