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

[Hans-Bernhard B. <HBB...@t-...>]

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.

> 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[].

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.