From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29072 invoked by alias); 28 Sep 2011 07:53:33 -0000 Received: (qmail 29055 invoked by uid 22791); 28 Sep 2011 07:53:31 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-pz0-f47.google.com (HELO mail-pz0-f47.google.com) (209.85.210.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 28 Sep 2011 07:53:15 +0000 Received: by pzk4 with SMTP id 4so21254347pzk.6 for ; Wed, 28 Sep 2011 00:53:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.16.166 with SMTP id h6mr1547859pbd.103.1317196395132; Wed, 28 Sep 2011 00:53:15 -0700 (PDT) Received: by 10.143.30.6 with HTTP; Wed, 28 Sep 2011 00:53:15 -0700 (PDT) In-Reply-To: References: <20110913154324.4be22faf@shotwell> <4E809F45.2010908@symantec.com> <20110927195930.54e0d0df@shotwell> Date: Wed, 28 Sep 2011 09:33:00 -0000 Message-ID: Subject: Re: Intrinsics for N2965: Type traits and base classes From: Jonathan Wakely To: Michael Spertus Cc: Benjamin Kosnik , "gcc-patches@gcc.gnu.org" , Jason Merrill , "libstdc++@gcc.gnu.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg01804.txt.bz2 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 compile= s) and because it prematurely locks us into a rigid choice of how our typel= ists 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 appr= oach taken by boost::mpl and has loads of experience that shows it is a goo= d 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.)