Re: [Opencxx-users] reproduce a template argument

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

Hi,

On Thu, 11 Dec 2003, Julius Gunthorp wrote:

> Hi, first I'd like to quickly congratulate and thank everyone who's
> contributed to OpenC++, what a genuinely useful and cool project!

Wow!

> Previously Yang Qu sent an email to the list asking about generating Ptree's
> (via TypeInfo::MakePtree) for encodings of templated types that have value
> parameters (e.g. template_arg<16>, the "16" might be any non-type
> epxression, so e.g. template_arg<(myconst + 7) / 8> is possible). Currently
> OpenC++ is unable to generate a Ptree from an encoding for such a template
> type. I took a quick look at the templates branch and it also doesn't appear
> to handle this.
>
> I'm new to OpenC++ so don't understand its intricacies, but I'm fairly sure
> my quick personal hack of this feature is the wrong way of doing it and
> wanted to ask what a correct way would be. All I did was store the value of
> the pointer to the template argument's Ptree (generated in
> Parser::rTemplateArgs) in the encoded type string after the '*', then
> changed Encoding::MakePtree to retrieve the pointer from the string when it
> reads a '*'.

Sounds good, but unfortunately I don't think it is *that* easy. With your
approach 'templ<5>' and 'templ<1+4>' are not the same type, because they
have different encodings. Also 'templ<5>' from one place in the code is
not the same type as 'templ<5>' from another place in the code, because
most likely both '5's are represented by individual ptrees (and
consequently they yield different pointer value in the encoding).

> Although it appears to work in my test case there's some obvious potential
> issues with it:

> 1. Might be unsafe with the garbage collector (which I've turned off
> in my test case).

I think so. I don't remember the details of how GC scans memory for
pointers, but I would expect GC will ignore the pointer at least on
platforms where you cannot store integers (pointers) at, say, odd
addresses (AFAIK sun-sparc is such a platform).

> 2. Might insert bytes equalling zero in the
> middle of the encoded string (although I did a quick unthorough search for
> string operations on encodings where zero bytes would matter and couldn't
> find any).

Perhaps this is not a huge issue.

> 3. Precludes the possibility of serializing and unserializing
> encoded type strings (which I don't attempt in my test case).

Type encoding is an implementation detail and is not published in any
interface, so I don't think this is a big issue either.

The design problem I can see is mixing two approaches, namely tree-based
type representation and serialized type representation. I think it is
better to stick to one of them.

> Instead of inserting the value of the pointer to the template paramater's
> Ptree, it could be changed to insert the string from ptree->ToString() (with
> the length of that string prepended).

There is an issue here again. ToString() returns text as it appears in the
source file, so in this case types "templ<5>" and "templ< 5 >" will not be
recognized equal.

> Then Encoding::MakePtree could call
> Ptree::Make with the template parameter's string as the pattern. Would that
> be the functionally correct? Unless there's issues with converting Ptree's
> to strings and back again,

To recap, the problem is not with converting Ptree to string, but rather
with converting Ptree to *canonical* string (so that equality of strings
implies equality of expressions (or types) represented by respective
Ptrees). Neither pointer trick, nor ToString() provide canonical
representation.

Also I don't think Yang Qu's problem can be easily solved that way,
because it is not enough to store just the expression used at template
instantiation site, e.g. "templ<n>". Here you would also have to store
the value of static constant n (which perhaps will not be visible in
the scope where Yang Qu wants to create a variable of type "templ<n>")
or preferably just an encoding of "templ<...>" with appropriate numeric
value in place of '...'.

> the only potential problem I see is exceeding the
> 256 byte encoding char limit.

This is an issue. Most likely before any serious work on templates we
should remove this limitation (preferably by the means of string or
vector<char>).

> Alternatively, any object that stores an encoding string could be changed to
> also store the Ptree that represents the type (from the parser). That seems
> like a more drastic change, and I don't think it would handle substituting
> typedefs with their original type the same way that the current encoding
> system does.

I am a little bit confused here, can you elaborate what would it break?

Cheers
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2003 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################