[Prev][Next][Index]

Re: C++ unparser does not do XOR correctly

Thank you very much for a whole sequence of bug reports
yesterday. I'll try to address all four in this message.

1. The xor problem seems like a simple unparser bug - I'll look into  
it immediately.

2.The empty class behavior (that is building a CONTROL_END node) is  
intentional. It is used to distinguish between statements like

class A;
and
class A{};

If you see any potential problems with the current behavior and/or  
can think of better ways to distinguish the two statements above  
please let me know. I've added the CONTROL_END "fix" to the parser  
recently because before it was unparsing 

class A{}; 

to 

class A;

3. about subscripting operator (and all other overloaded operators  
for that matter) - our current parser does not do the type analysis  
required to resolve overloaded operators; the operators in the Sage  
tree always refer to built-in versions. (BTW, the current parser is  
also unable to resolve overloaded functions correctly). I am working  
on a new C++ parser that will do all the necessary type analysis.  I  
can't tell you when the new parser is going to be ready (but  
definitely not any time soon). Please also note that the current  
structure of the Sage tree will have to change somewhat in order to  
accommodate information about overloaded operators. 

For example, we currently have no good way to represent
		x[5];
from your example:
	main()
	{
		X x;
		x[5];
	}
Yes, I know that it is semantically equivalent to:
                x.operator[](5);
but we would like to have a different representation for the two, so  
that when unparsed they would look as in the original source code. 


                             --Beata