From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23809 invoked by alias); 29 Sep 2011 17:22:33 -0000 Received: (qmail 23750 invoked by uid 22791); 29 Sep 2011 17:22:31 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Sep 2011 17:22:17 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8THMGZB008377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 13:22:16 -0400 Received: from shotwell ([10.3.113.13]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8THMFXc022551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 29 Sep 2011 13:22:15 -0400 Date: Thu, 29 Sep 2011 19:42:00 -0000 From: Benjamin Kosnik To: Mike Spertus Cc: Jonathan Wakely , "gcc-patches@gcc.gnu.org" , Jason Merrill , "libstdc++@gcc.gnu.org" Subject: Re: Intrinsics for N2965: Type traits and base classes Message-ID: <20110929102215.33af0ba9@shotwell> In-Reply-To: <4E831DF8.9080700@symantec.com> References: <20110913154324.4be22faf@shotwell> <4E809F45.2010908@symantec.com> <20110927195930.54e0d0df@shotwell> <4E830B10.8020802@symantec.com> <4E831DF8.9080700@symantec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-09/txt/msg01962.txt.bz2 > 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. Yes, compelling. > 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. The interface is still simple, I like it. > 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 bases::type>>::value to count the number of occurrences of A as a > base class of E turns out to be useful). This plan sounds excellent to me. -benjamin