[GiNaC-devel] Why does this program crash?

[Jan Rheinländer]

Hello,

thank you for your comments and explanations on C++ inheritance issues.
I was away for two weeks and apologize for the delay in answering.

I have a need to change the domain and the commutativity of a symbol
after creation. From what I gather, this is not possible with the
existing symbol class.

So what I would try next is to define a new symbol subclass which stores
domain and return_type in a member and has ::set operators to change them.

Jan

Am 15.05.2016 um 20:21 schrieb Alexey Sheplyakov:
> Hello,
>
>> I condensed my previous post on subclassing symbol into this little
>> program, which crashes at the last line. Any idea why? Is it a bug or do
>>      #include <iostream>
>>      #include <ginac/ginac.h>
>>      using namespace std;
>>      using namespace GiNaC;
>>
>>      int main()
>>      {
>>         symbol x("x");
>>         x = realsymbol("y");
> Assigning an instance of a subclass is in general a bad idea, see https://en.wikipedia.org/wiki/Object_slicing
> In this particular case GiNaC::basic assignment operator resets status_flags::evaluated
>
> Thus when an ex gets constructed from the symbol here
>
>>         cout << x << endl;
> ex::construct_from_basic enters an infinite recursion in
>
>  const ex tmpex & = other.eval();
>
> since symbol::eval() is essentially a nop. Sooner or later the program exhausts the stack and segfaults.
> So this is sort of GiNaC bug, but it's certainly useful for it lets you know that your code is wrong.
>
> #include <iostream>
> #include <ginac/ginac.h>
> using namespace std;
> using namespace GiNaC;
>
> int main() {
>       symbol x("x");
>       x.dbgprinttree();
>       x = realsymbol("y");
>       x.dbgprinttree();
>       return 0;
> }
>
> x (symbol) @0x7ffc08327bc0, serial=1, hash=0x1, flags=0x6, domain=0
> y (symbol) @0x7ffc08327bc0, serial=2, hash=0x1, flags=0x0, domain=0
>
> So x remains complex (domain == 0) after assigning y. This is natural from C++ point of the view,
> however this is most likely not what you mean. Without the bug which triggers an infinite recursion
> the original problem (assigning an instance of a subclass) will be more difficult to find.
>
>
> Hope this helps,
>        Alexey
> _______________________________________________
> GiNaC-devel mailing list
> GiNaC-devel at ginac.de
> https://www.cebix.net/mailman/listinfo/ginac-devel