[GiNaC-devel] New tinfo mechanism

[Alexei Sheplyakov]

Hello,

On Tue, Oct 21, 2008 at 09:43:02AM +0100, Vladimir V. Kisil wrote:

>	I wish to identify an object by the new tinfo mechanism.
> I used the naive expression
 
> ex_to<basic>(other).return_type_tinfo()

\begin{nitpick}
I don't quite understand what was wrong with other.return_type_tinfo()
\end{nitpick}

> However for ncmul, for example, it still returns the type of the first
> non-commutative factor,

Old RTTI did the same thing.

> not make_return_type_t<ncmul>() as may be expected from basic::return_type_info().

I'm very confused. Such a behaviour denies the whole point of RTTI. Why on Earth
one would expect it? Anyway, both C++ RTTI ("new tinfo system") and GiNaC's custom
RTTI follow the standard (see paragraph 5.2.8, "Type identification"):

"2. When typeid is applied to an lvalue expression whose type is a polymorphic
    class type (10.3), the result refers to a type_info object representing
		the type of the most derived object (1.8) (that is, the dynamic type) to
		which the lvalue refers."

So your expectation is plain wrong.

> What is most correct way to get the ncmul identified?

Could you please be more specific? What does 'identify ncmul' mean?

a. Check if the object is ncmul or its derived class.
b. Check what is exactly the type of ncmul object.
c. Something else.

Or even better -- post the fragment of a (pseudo)code, explain what you
expect, and what it actually does.

Best regards,
	Alexei

-- 
All science is either physics or stamp collecting.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
Url : http://www.cebix.net/pipermail/ginac-devel/attachments/20081021/86aee9ad/attachment.sig