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
better.

`Allan

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 in handle_const_attribute).

Thanks,
Daniel

Reply via email to