This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++ PATCH] Class template instantiation according to coreissue 287.

--On Saturday, October 26, 2002 09:13:31 PM +0700 Kriang Lerdsuwanakij <> wrote:


After some thought, I decide to implement the proposed resolution
for Core issue 287 (class template instantiation dependencies).  Although
the core issue is still under review, it is better than our current ad
hoc solution.  With the patch below, members and friends are processed
according to the order of declaration during class template instantiation.
This is the right approach.

A new field CLASSTYPE_DECL_LIST is added to the type lang_specific node
to hold all class declaration in the correct order.
Probably, we should just figure out a way to use TYPE_FIELDs; that's
already got stuff other than FIELD_DECLs on it.  And, in a template,
nothing in the middle end should see the TYPE_FIELDs list; those types
should not escape the front end.  We do not need to do that optimization
yet, though; correctness first.

Bootstrapped and tested on i686-pc-linux-gnu with no regression.
OK to commit to main trunk?
This is a regression, right?  If so, commit it to both the mainline
and the branch.

  + /* Add T to CLASSTYPE_DECL_LIST of TYPE which will be used
+    later during class template instantiation.
+    When FRIEND_P is zero, T can be member data, member
+    function, nested type, or member class template.
+    When FRIEND_P is nonzero, T is either friend class or
+    friend function.  */
Reword this to talk abut the kinds of tree nodes:

 T can be a non-static data member (FIELD_DECL), a member function
 (FUNCTION_DECL), a nested class (RECORD_TYPE), etc.

I want us to start thinking of the tree structure as strongly typed.

Also, what about non-static data members?

!      reverse order.  Put them in declaration order now.  */
Just say:

 /* The following lists are all in reverse order...

Then we do not have list each one explicitly, and keep updating them.

+    TREE_PURPOSE of each TREE_LIST provides the context of declaration
+    and TREE_VALUE is the actual declaration.  For friends, TREE_PURPOSE
+    is NULL_TREE.  Otherwise it is the class templates itself.  */
Just say:

 /* The TREE_PURPOSE of each TREE_LIST node is NULL_TREE for a friend,
    and the RECORD_TYPE/UNION_TYPE for the class template otherwise.  */


Mark Mitchell      
CodeSourcery, LLC  

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]