2012/3/16 Ludovic Courtès <ludovic.cour...@inria.fr>:
> Hi,
>
> Richard Guenther <richard.guent...@gmail.com> skribis:
>
>> 2012/3/16 Ludovic Courtès <ludovic.cour...@inria.fr>:
>>> 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 ISO
>> 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 = task_implementation_task (fn);
>
> tree build_parameter (const_tree lst)
> {
> tree param, type;
>
> type = TREE_VALUE (lst);
> param = build_decl (DECL_SOURCE_LOCATION (task), PARM_DECL,
> create_tmp_var_name ("parameter"),
> type);
> DECL_ARG_TYPE (param) = type;
> DECL_CONTEXT (param) = task; /* ← closed over variable */
>
> return param;
> }
>
> DECL_ARGUMENTS (task) =
> 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 ‘map’
> paradigm couldn’t be used, because there’d be no way to close 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.
Well, if you invent new paradigms in your plugin that are not used by GCC
itself but use GCC internals (which all plugins have to do ...) then I know
where the problem lies ;) I suppose you would be better served by
some of the more high-level plugin packages that let you write GCC plugins
in python or lisp?
Or wait until GCC has fully transitioned to C++ (at least I expect we won't
ever relax the rule that GCC can be built with a C++ compiler) and use
C++0x lambdas.
Richard.
> Thanks,
> Ludo’.
>
> [0]
> https://gforge.inria.fr/scm/viewvc.php/trunk/gcc-plugin/src/starpu.c?view=markup&root=starpu
