[Opencxx-users] reproduce a template argument

[Julius G. <jgu...@ho...>]

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

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

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). 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). 3. Precludes the possibility of serializing and unserializing 
encoded type strings (which I don't attempt in my test case).

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). 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, the only potential problem I see is exceeding the 
256 byte encoding char limit.

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.

Thanks in advance,
JG

_________________________________________________________________
Shop online for kids’ toys by age group, price range, and toy category at 
MSN Shopping. No waiting for a clerk to help you! http://shopping.msn.com