From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25136 invoked by alias); 16 Mar 2012 13:04:58 -0000 Received: (qmail 25126 invoked by uid 22791); 16 Mar 2012 13:04:57 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail1-relais-roc.national.inria.fr (HELO mail1-relais-roc.national.inria.fr) (192.134.164.82) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Mar 2012 13:04:42 +0000 Received: from unknown (HELO pluto) ([193.50.110.167]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 16 Mar 2012 14:04:39 +0100 From: ludovic.courtes@inria.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) To: Richard Guenther Cc: Ian Lance Taylor , Andrew Pinski , gcc@gcc.gnu.org Subject: Re: GCC 4.7.0RC: Mangled names in cc1 References: <877gyu85mc.fsf@inria.fr> <87ty1y6oq2.fsf@inria.fr> <877gytvl0o.fsf@inria.fr> <87r4x1r9re.fsf@inria.fr> <87pqciurih.fsf@inria.fr> <87obrwyfhg.fsf@inria.fr> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 27 =?iso-8859-1?Q?Vent=F4se?= an 220 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu Date: Fri, 16 Mar 2012 13:04:00 -0000 In-Reply-To: (Richard Guenther's message of "Fri, 16 Mar 2012 12:05:01 +0100") Message-ID: <87ty1ou26x.fsf@inria.fr> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2012-03/txt/msg00243.txt.bz2 Hi, Richard Guenther skribis: > 2012/3/16 Ludovic Court=C3=A8s : >> Hi, >> >> After writing an Autoconf macro that determines whether to build >> plug-ins with gcc or g++ [0], I realized that nested functions, which my >> plug-in uses extensively, are not supported in C++. >> >> Any suggestions on how to address this? > > Don't use nested functions ;) GCC is supposed to be buildable with an IS= O C99 > compiler which does not support nested functions either. Right, but the nice thing with GCC plug-ins is they can be implemented using all GNU extensions. Nested functions can serve as the basis for some form of functional programming, which some of the APIs lend themselves to very well. For instance, the plug-in at [0] contains things like: tree task =3D task_implementation_task (fn); tree build_parameter (const_tree lst) { tree param, type; type =3D TREE_VALUE (lst); param =3D build_decl (DECL_SOURCE_LOCATION (task), PARM_DECL, create_tmp_var_name ("parameter"), type); DECL_ARG_TYPE (param) =3D type; DECL_CONTEXT (param) =3D task; /* =E2=86=90 closed over variable */ return param; } DECL_ARGUMENTS (task) =3D map (build_parameter, list_remove (void_type_p, TYPE_ARG_TYPES (TREE_TYPE (task)))); What if this snippet were to be written in ANSI C99? The whole =E2=80=98ma= p=E2=80=99 paradigm couldn=E2=80=99t be used, because there=E2=80=99d be no way to clo= se over a local variable. What about writing it in C++? Function objects could be passed around to achieve a similar result, at the expense of conciseness and interoperability with C. This is an unfortunate collateral damage, IMO. Thanks, Ludo=E2=80=99. [0] https://gforge.inria.fr/scm/viewvc.php/trunk/gcc-plugin/src/starpu.c?vi= ew=3Dmarkup&root=3Dstarpu