Re: Intrinsics for N2965: Type traits and base classes
OK. Here are some simple benchmarks. I simulated heavy use of reflection
with 1000 classes that each had about a thousand base classes. I also
created a super-simple typelist class
template struct typelist {}; // Variadic templates rock
If bases returns a typelist, the program takes about 4 sec.
If bases returns a tuple, the program takes about 4 min.
If I make the program any bigger, the tuple case fails to compile with
spurious error messages, while the typelist version stays quick.
Given that metaprograms typically create large class hierarchies (look
at Alexandrescu's CreateScatterHierarchy that he uses to implement
factory in the Modern C++ design book) and that compile times are an
enormous obstacle to metaprogramming, I don't think these tests are at
all ridiculous.
I think this shows we need to return a typelist instead of a tuple.
As I mentioned earlier, I could just return the typelist, or hide it by
returning an unspecified type (which would actually be a typelist) that
you would apply a first<> and a rest<> template to walk through. This
would give us more flexibility for the future (e.g., if a standard
typelist type is adopted. Likewise, we would be covered if wanted to
change bases implementation in the future to return an associative
container. For example, if using size::type>>::value to
count the number of occurrences of A as a base class of E turns out to
be useful).
Thanks,
Mike
On 9/28/2011 6:54 AM, Mike Spertus wrote:
Don't worry, I'm not suggesting including boost::mpl at all, just
leaving the return type of the bases trait unspecified. IMO, your
example illustrates my point that without performance tuning,
compiling metaprograms can be prohibitively expensive, so I want to
avoid running the tuple metaprogram that creates the fields when we
never need to instantiate the type. Benchmarks soon.
Mike
On 9/28/2011 2:53 AM, Jonathan Wakely wrote:
On 28 September 2011 04:22, Michael Spertus wrote:
Benjamin,
I think tuple is wrong both for performance reasons (I believe these
are likely to be serious enough to depress use due to inordinately
long compiles) and because it prematurely locks us into a rigid
choice of how our typelists are implemented.
My inclination is to make it type-independent by returning an
unspecified type that can have a sequence of types extracted from it
(this is the approach taken by boost::mpl and has loads of
experience that shows it is a good approach to metaprogramming). In
other words, first>::type would be the first base of A, etc.
Citing Boost MPL as a good way to avoid inordinately long compiles ...
interesting! Have you ever tried to reduce a GCC bug report from 20k
lines to 20, because most Boost libs include every MPL header?!
I hope we can get a simple typelist _without_ needing everything else
in MPL, such as the apply and lambda metafunctions (and maybe a lot of
that could be massively simplified using variadic templates anyway.)
.
Re: Intrinsics for N2965: Type traits and base classes
Don't worry, I'm not suggesting including boost::mpl at all, just leaving the return type of the bases trait unspecified. IMO, your example illustrates my point that without performance tuning, compiling metaprograms can be prohibitively expensive, so I want to avoid running the tuple metaprogram that creates the fields when we never need to instantiate the type. Benchmarks soon. Mike On 9/28/2011 2:53 AM, Jonathan Wakely wrote: On 28 September 2011 04:22, Michael Spertus wrote: Benjamin, I think tuple is wrong both for performance reasons (I believe these are likely to be serious enough to depress use due to inordinately long compiles) and because it prematurely locks us into a rigid choice of how our typelists are implemented. My inclination is to make it type-independent by returning an unspecified type that can have a sequence of types extracted from it (this is the approach taken by boost::mpl and has loads of experience that shows it is a good approach to metaprogramming). In other words, first>::type would be the first base of A, etc. Citing Boost MPL as a good way to avoid inordinately long compiles ... interesting! Have you ever tried to reduce a GCC bug report from 20k lines to 20, because most Boost libs include every MPL header?! I hope we can get a simple typelist _without_ needing everything else in MPL, such as the apply and lambda metafunctions (and maybe a lot of that could be massively simplified using variadic templates anyway.) .
Intrinsics for N2965: Type traits and base classes
This patch consists intrinsics to properly create the bases and
direct_bases of a class in the correct order (including multiple nested
ambiguous virtual and non-virtual classes) for N2965
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2965.html).
This allows you to create type traits for giving the base classes of the
class:
template
struct bases
{
typedef tuple<__bases(_Tp)...> type;
};
I didn't modify the standard library to include the above type trait in
the patch because it is not yet clear what type it should return (e.g.,
a tuple, a "typelist," something satisfying the requirements of a
boost::mpl sequence, or a generalization of parameter packs). I have
(cursorily) tested it with the above type trait and the corresponding
direct_bases trait.
Thanks to Jason Merrill and Benjamin Kosnik for all their help,
Mike
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c(revision 178892)
+++ gcc/c-family/c-common.c(working copy)
@@ -423,6 +423,7 @@
{ "__asm__",RID_ASM,0 },
{ "__attribute",RID_ATTRIBUTE,0 },
{ "__attribute__",RID_ATTRIBUTE,0 },
+ { "__bases", RID_BASES, D_CXXONLY },
{ "__builtin_choose_expr", RID_CHOOSE_EXPR, D_CONLY },
{ "__builtin_complex", RID_BUILTIN_COMPLEX, D_CONLY },
{ "__builtin_offsetof", RID_OFFSETOF, 0 },
@@ -433,6 +434,7 @@
{ "__const",RID_CONST,0 },
{ "__const__",RID_CONST,0 },
{ "__decltype", RID_DECLTYPE, D_CXXONLY },
+ { "__direct_bases", RID_DIRECT_BASES, D_CXXONLY },
{ "__extension__",RID_EXTENSION,0 },
{ "__func__",RID_C99_FUNCTION_NAME, 0 },
{ "__has_nothrow_assign", RID_HAS_NOTHROW_ASSIGN, D_CXXONLY },
Index: gcc/c-family/c-common.h
===
--- gcc/c-family/c-common.h(revision 178892)
+++ gcc/c-family/c-common.h(working copy)
@@ -139,7 +139,8 @@
RID_IS_LITERAL_TYPE, RID_IS_POD,
RID_IS_POLYMORPHIC, RID_IS_STD_LAYOUT,
RID_IS_TRIVIAL, RID_IS_UNION,
- RID_UNDERLYING_TYPE,
+ RID_UNDERLYING_TYPE, RID_BASES,
+ RID_DIRECT_BASES,
/* C++0x */
RID_CONSTEXPR, RID_DECLTYPE, RID_NOEXCEPT, RID_NULLPTR,
RID_STATIC_ASSERT,
Index: gcc/tree.h
===
--- gcc/tree.h(revision 178892)
+++ gcc/tree.h(working copy)
@@ -21,7 +21,6 @@
#ifndef GCC_TREE_H
#define GCC_TREE_H
-
#include "hashtab.h"
#include "machmode.h"
#include "input.h"
Index: gcc/cp/pt.c
===
--- gcc/cp/pt.c(revision 178892)
+++ gcc/cp/pt.c(working copy)
@@ -2976,6 +2976,10 @@
}
break;
+case BASES:
+case DIRECT_BASES:
+ parameter_pack_p = true;
+ break;
default:
/* Not a parameter pack. */
break;
@@ -9123,6 +9127,16 @@
tree arg_pack = NULL_TREE;
tree orig_arg = NULL_TREE;
+ if (TREE_CODE (parm_pack) == BASES)
+{
+ return calculate_bases(tsubst_expr(BASES_TYPE(parm_pack),
+ args, complain, in_decl, false));
+}
+ if (TREE_CODE (parm_pack) == DIRECT_BASES)
+{
+ return
calculate_direct_bases(tsubst_expr(DIRECT_BASES_TYPE(parm_pack),
+args, complain, in_decl, false));
+}
if (TREE_CODE (parm_pack) == PARM_DECL)
{
if (!cp_unevaluated_operand)
Index: gcc/cp/semantics.c
===
--- gcc/cp/semantics.c(revision 178892)
+++ gcc/cp/semantics.c(working copy)
@@ -3407,6 +3407,155 @@
return underlying_type;
}
+/* Implement the __direct_bases keyword: Return the direct base classes
+ of type */
+tree
+calculate_direct_bases (tree type)
+{
+ VEC(tree, gc) *vector;
+ tree bases_vec = NULL_TREE;
+ VEC(tree, none) *base_binfos;
+ tree binfo;
+ unsigned i;
+
+ complete_type (type);
+
+ if (!NON_UNION_CLASS_TYPE_P (type))
+{
+ return bases_vec;
+}
+ /* Virtual bases are initialized first */
+ vector = VEC_copy (tree, gc, CLASSTYPE_VBASECLASSES (type));
+
+ base_binfos = BINFO_BASE_BINFOS(TYPE_BINFO (complete_type
(TYPE_MAIN_VARIANT (type;
+ for (i = 0; VEC_iterate (tree, base_binfos, i, binfo); i++)
+{
+ /* Now the non-virtual bases */
+ if (!BINFO_VIRTUAL_P (binfo))
+{
+ VEC_safe_push (tree, gc, vector, binfo);
+}
+}
+
+ bases_vec = make_tree_vec (VEC_length (tree, vector));
+
+ for (i = 0; i < VEC_length (tree, vector); ++i)
+{
+ TREE_VEC_ELT (bases_vec, i) = BINFO_TYPE (VEC_index (tree,
vector, i));
+}
+ return bases_vec;
+}
+
+tree
+finish_direct_bases (tree type)
+{
+ tree direct_bases = NULL_TREE;
+
+ if (!processing_template_decl)
+{
+ /* Parameter packs can only be used
