This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates
- From: Daniel Santos <daniel dot santos at pobox dot com>
- To: Allan Sandfeld Jensen <linux at carewolf dot com>, gcc at gcc dot gnu dot org
- Cc: Joseph Myers <joseph at codesourcery dot com>, Richard Henderson <rth at redhat dot com>
- Date: Wed, 10 May 2017 04:17:50 -0500
- Subject: Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <email@example.com>
Thanks for your feedback!
On 05/09/2017 08:29 AM, Allan Sandfeld Jensen wrote:
On Tuesday 09 May 2017, Daniel Santos wrote:
The primary aim is to facilitate high-performance generic C
libraries for software where C++ is not suitable, but the cost of
run-time abstraction is unacceptable. A good example is the Linux
kernel, where the source tree is littered with more than 100 hand-coded
or boiler-plate (copy, paste and edit) search cores required to use the
red-black tree library.
That is not a good excuse, they can just use a defined subset of C++. The cost
of C++ abstractions is zero if you don't use them.
Put simply, there are many projects who will not likely be converting to
C++ in the in our lifetimes. As far as abstractions, I meant the
abstraction penalty of static types which doesn't exist when using C++
templates (not at run-time anyway). In C, generic libraries typically
resolve abstract behavior with a callback function pointer. This costs
a function call in addition to the optimization barrier of the function
call (which is the worst part of it).
To further the usefulness of such techniques, I propose the addition of
a c-family attribute to declare a parameter, variable (and possibly
other declarations) as "constprop" or some similar word. The purpose of
the attribute is to:
1.) Emit a warning or error when the value is not optimized away, and
2.) Direct various optimization passes to prefer (or force) either
cloning or inlining of a function with such a parameter.
This I can get more behind, I have wanted a constexpr attribute for C for some
time. If not for anything else to be able to use it in shared/system headers
that can be used by both C and C++ and in C++ would be useful in constexpr
expressions. If you can find a use for it in pure C as well, so much the
Maybe "constexpr" would be a better name, as it mirrors the C++11
keyword. When I first read about C++ getting constexpr, my first
thought was, "Yeah, as if they needed yet another way to do
metaprogramming!" :) However, I hadn't gone so far as to investigate
using this new attribute on functions since we already have
__attribute__((const)). I haven't used this before so maybe I'm not
aware of something that makes it unusable for such cases? Which of
course raises the question if __attribute__((const)) would work out
since it's only currently used on function declarations (and pointers to
function declarations, but I don't fully understand what that is doing