April 2007 - GiNaC-list

Some static functions
by Martin Sandve Alnæs 14 Apr '07

14 Apr '07

collect_symbols and get_symbol_stats are mentioned in the manual, but are defined as static functions in normal.cpp with no mention in normal.h. Does this mean they're meant to be internal and not part of the "official" API? I'd like to use them... -- --- Martin Sandve Alnæs PhD student, Cardiac Computations Simula Research Laboratory, Norway

3 3

Re: [GiNaC-list] Problem using a user-defined class on Mac OS X.
by Chris.Dams＠mi.infn.it 09 Apr '07

09 Apr '07

Dear David > This alone doesn't exhibit the issue in the original example. > What you've written above is just a plain partial specialization, no > violation at all. Now, suppose that the last definition above > (foo<T*>::data) was replaced in a *different* translation unit with: > > template <> void* foo<void*>::data = &something_else; > > which is similar to the original code in this thread. The instantiation > of foo<void*>::data can now be different-valued. (Is this analogous to > the GiNaC source or proposed patch in question?) No, there is only one instantiation in the GiNaC source. Both in the unmodified one and the one that I modified to work on Mac OS X. So it cannot have different values. The point is that in the original GiNaC code there would be two instances of, say, foo<void*>::data inside the executable. One comming from the shared library and the other one coming from the executable itself. Library code would modify the first one and code from the executable would modify the other one. To reproduce it in toy code, I think you would have to create a dynamic library on the Mac, but I havn't tried yet. I guess, it could have something to do with the so-called two-level namespaces that the man page of the linker talk about. I could test that. Best wishes, Chris

2 3

Problem using a user-defined class on Mac OS X.
by Chris.Dams＠mi.infn.it 05 Apr '07

05 Apr '07

Dear all, I seem to be having a problem with unarchiving a user-defined class on Mac OS X. The problem is that the static member class_info<registered_class_options>::first is (besides inside the GiNaC dynamic library) also created within my executable. This second version is then used when registering my own class, so that my own class does not appear in the linked list of which *(class_info<registered_class_options>::first) is the first element. I debugged this by printing both the address of first and the name of the class being registered from the constructor of class_info and the for my own class the address of first turned out to be different. The consequence of this is that members of my own class cannot be unarchived. The problem does not occur on Linux. Anyone any bright ideas? Should this be considered a bug GiNaC? Does anyone know a combination of linker flags that can prevent this? Best wishes, Chris

4 10