[GiNaC-list] Re: GiNaC 1.3.1

[Chris Dams]

Dear Jens,

On Tue, 28 Jun 2005, Jens Vollinga wrote:

> why did the references have to go? I don't understand this, yet. In the
> Jan 20th mail you say it crashes otherwise. Do you have an explanation?

The point is that the library_init class should make sure that when the
very first compilation module (corresponding to some arbitrary *.cpp file)
is initialized all static variables are initialized. However, this very
first compilation module does not set the references. This is because as
the situation is in GiNaC 1.3.1 only the _num_whatever_p pointers get a
value when this first module is initialized. Note also that these
references cannot be set by linker because at that time the pointers do
not yet point anywhere. Hence these references must get their value at the
point when utils.cpp is initialized. It can be that some of GiNaCs
functions are called before that time and these may attempt to use the
references and then it crashes.

The conclusion from the previous paragraph is that the references should
be intialized in library_init::library_init. However, how does one
initialize references? Things like
(numeric*)(some_ref)=the_thing_the_ref_should_point_to of course do not
work because it is not the reference that is casted to a numeric* but the
numeric object itself and that does not make sense. One could wrap the
reference in some class and use that as a handle to initialize the
reference, but that will certainly (?) break binary compatibility and
could theoretically not work the same way for all compilers. Therefore, I
thought that throwing away the references was the best option.

> Did it also crash with references when the line
>   const ex _ex30 = _num30;
> had been changed to
>   const ex _ex30 = _ex30;
> (i.e. your Jan 8th patch with that additional change) ??

I do not remember the results of all the debugging that I did back in
January, but it should also crash since the initialization of the
refrences is not changed in any way. Note however that the removal of the
destructor of library_init that occurs in the patch of Jan 8th would
certainly break binary compatibility. Therefore, the patch of Jan 20th
should be used and the one of Jan 8th should be forgotten. Also, after
ititializing the exes with the numerics instead of with themselves their
refcount would be 2 and I think that is strange, even if it does not cause
trouble.

Best wishes,
Chris