On 05/10/2017 04:14 PM, Daniel Santos wrote:
On 05/10/2017 04:24 AM, Jonathan Wakely wrote:
Just because there's already one way to do something doesn't mean
better ways to do it are bad.
I'm only speaking out of jealousy being that most of my recent work has
been in C.
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).
__attribute__((const)) is not a substitute for constexpr, it's not
even in the same ballpark. It says the function doesn't touch global
memory, it doesn't mean its return value is a constant expression, so
you can't do:
int f() __attribute__((const));
int f() { return 1; }
int i[f()];
I don't think __attribute__((const)) is useful for your goal.
Well my primary goal is programming with values that are constant in the
compiler. There is no language in any C specification (that I'm aware
of) for a "compile-time constant", but the concept is very important.
So just because some expression is a compile-time constant doesn't mean
we morph into a "constant expression" (as per the spec), even with
__attribute__((const)).
The C committee has discussed extending the set of expressions
that are considered constant in C2X. A proposal was submitted
last year that, at least in spirit, gained pretty broad support
(the finer details, including the syntax, especially the reuse
of the register keyword, are likely to evolve):
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2067.pdf
The C committee's charter for C2X is to increase compatibility
with C++, so new language features with that effect have a good
chance of being considered.
I don't expect C2X to go as far as to add something as complex
as templates but some on the committee are working on enhancing
support for generic programming (via _Generic). Interestingly,
C11 (by accident) introduced a requirement for implementations
to support true type genericity in the form of the C11 atomic
APIs. It may not be too far out there to propose to generalize
the underlying machinery and make it available to programs (as
opposed to just the standard library alone).
Martin
