Re: [Opencxx-users] understanding TypeInfo

[Grzegorz J. <ja...@ac...>]

Stefan Seefeld wrote:
> 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 ? 

Strictly speaking not. However the details of encoding were not 
encapsulated even before EncodingUtil, since e.g. TypeInfo knew about it.

> 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. 

Yes.

> Another
> issue is that of TypeInfo's expanded vs. non-expanded form...

What's unclear about it?

Best regards
Grzegorz

>>>> 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
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users