Re: [Opencxx-users] understanding TypeInfo

[Stefan S. <sse...@ar...>]

Hi Grzegorz,

thanks for taking this up :-)

I'll try to rephrase the documentation. Let's
iterate over it until it is correct.

Once everything is covered and correct, it should
be put into the code, so synopsis can extract it
into a reference manual :-)

Grzegorz Jakacki wrote:

>> * Encoding::GetBaseName()
>
>
> This is now EncodingUtil::GetBaseName(). Comment says:
>
> // GetBaseName() returns "Foo" if ENCODE is "Q[2][1]X[3]Foo", for
> // example.
> // If an error occurs, the function returns 0.
>
> Let me know what is unclear.

Here is my rephrased doc:

The result of GetBaseName is a substring of the 'encoding' argument.
[but what is 'base' ?]
The Environment will point to the scope containing the declaration.

>> * Encoding::ResolveTypedefName()
>
>
> Also has been moved to EncodingUntil::ResolveTypedefName().
>
> Takes environment 'env' and typedef encoding ('name' & 'len'), returns
environment in which the given typedef is defined.

so the precondition is that 'name' is a typedef ?

By the way, I wonder whether this method can be reimplemented without
TypeInfo.
AFAICS it's the only place where Encoding depends on TypeInfo, thus
introducing
a circular dependency.

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

>> * TypeInfo::Reference()
>
>
> Precondition: *this represents some type T
> Postcondition: *this represents type T*

fine

>> * TypeInfo::Dereference(t)
>
>
> Precondition: *this represents some type equivalent to T*
> Postcondition: *this represents type T

fine

>> * TypeInfo::Normalize()
>
>
> [I fail to understand this function clearly; my findings:]
> - strips top-level cv-qualifiers
> - if *this represents dereferenced function pointer changes *this
>   so that it represents function return type,
> - if *this represents dereferenced typedef, expands typedef and
>   tries to proceed with dereferencing
>
> Name suggests that the actual represented type should not change, although
its representation may (e.g. typedefs are expanded if necessary). However
some details are misterious (member function pointers for instance).
>

This method is indeed the most puzzling: it only operates
on temporary variables, so what does it *really* do ?
It looks like the lazy evaluation of (de)reference and typedefs,
but the result is never used, as the member variables aren't reset
to the values of the local variables...?!?

>> * TypeInfo::SkipCv()
>
>
> Strips all top-level cv-qualifiers from type represented by *this; if
after stripping *this represents a typedef, expands typdef and proceeds.

good. (though here again: all the complexity stems from the fact that refs
and typedefs
are handled lazily. If it wouldn't, the implementation would become *much*
simpler !)

>> * TypeInfo::SkipName(encode, e)
>
>
> Preconditions:
>   - encode points into cstring which encodes a typeinfo.
>   - encode points to the beginning of class or template name withing
>     the encoded typeinfo cstring
> Postcondition:
>   - return value points immediately after the class or template name
>     in the encoded typeinfo cstring; if cstring contains typedef names,
>     they are expanded in environment e
>
>> * TypeInfo::ResolveTypedef(e, ptr, resolvable)
>
>
> Preconditions:
>   - ptr points to the beginning of a typedef name in an encoding
>   - e is an environment, in which the typedef occures (lookup begins
>     in this environment)
> Postconditions:
>   - if typedef can be correctly looked up, *this represents the same
>     type, but with the typedef name expanded.
>   - otherwise *this is unchanged if 'resolvable == false' or
>     becomes unknown (special state) otherwise.

nice explanation !

> Hope this helps.

It does quite a lot. Thanks !

Best regards,
		Stefan