Re: [Opencxx-users] understanding TypeInfo

[Stefan S. <se...@sy...>]

Grzegorz Jakacki wrote:


> Encoding no longer depends on TypeInfo, offending methods have been 
> promoted to EncodingUtil.

yeah, I noticed. But is that really a solution ? The Encoding
class should encapsulate the representation of declarator type/names,
and moving half of it out into 'EncodingUtil' breaks that encapsulation,
i.e. even though EncodingUtil is now a separate piece of code, it
very much depends on the intrinsics of the Encoding class. In fact
even the TypeInfo class depends on a large degree on Encoding, so I
wonder whether we shouldn't try to refactor these classes. Another
issue is that of TypeInfo's expanded vs. non-expanded form...

>>> Typeinfo --- this class is intended to represent types, however the
>>
>>
>> representation is not unique, because:
>>
>>>  - typedefs are expanded lazily (thus many operations need
>>>    an environment, to be able to look up typedefs definitions),
>>>  - dereferences ('*') are applied lazily.
>>
>>
>>
>> yeah. Is this lazyness really necessary ? Does it gain performance ?
>> I'm just wondering because without it (i.e. putting 'Normalize' into
>> the constructor), most methods could become 'const'...
>> Or alternatively the inner representation (encoding) could become 
>> 'mutable',
>> such that normalizing a TypeInfo keeps the invariants intact and thus can
>> semantically be considered a no-op.
> 
> 
> This is a profound question.
> 
> In theory this laziness is not necessary. However in practice it may be 
> very useful (for the users, not implementors). 'gcc' is very much 
> praised for expanding typedefs lazily, which results in much more 
> readable error messages (especially if one uses lots of templates). My 
> suggestion is not to remove it unless it is really really really 
> troublesome to maintain it.
 >
 > The solution with 'mutable' has a drawback: the const operations will
 > actually change the observable state of the object, because
 > 'FullTypeName()' and 'MakePtree()' will not necesarily return the same
 > result after normalization.

Speaking of which, what does 'MakePtree' actually generate ? Or, to
push the question further, what do the two encodings of a declarator
contain ? What is a 'type encoding', and what is a 'name encoding' ?
Why isn't one enough ? A declarator either declares a type or an instance
(let's count function as an instance for now), and in the first case
I need the type encoding, in the second the name encoding, no ?
What am I missing ?

Thanks for any clarifications,
		Stefan