Sujet : Re: C23 thoughts and opinions
De : Keith.S.Thompson+u (at) *nospam* gmail.com (Keith Thompson)
Groupes : comp.lang.cDate : 28. May 2024, 01:33:52
Autres entêtes
Organisation : None to speak of
Message-ID : <87cyp6zsen.fsf@nosuchdomain.example.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14
User-Agent : Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
David Brown <
david.brown@hesbynett.no> writes:
On 27/05/2024 01:17, Keith Thompson wrote:
[...]
Here's how I personally would have preferred for #embed to be
specified:
- As in current C23 drafts, #embed with no parameters must operate
*as
if* it expanded to a comma-delimited list of integer constant
expressions.
- With no parameters, both the common cases (initializing an array of
characters) and odd cases (e.g., initializing a struct object with
varying types and sizes of members) must work as specified.
- A standard-defined parameter allows control over optimization.
The parameter can be "optimize(true)" or "optimize(false)".
"optimize(false)" has no formal effect, but the compiler *should*
generate the canonical sequence of constants.
"optimize(true)" causes undefined behavior if #embed is used in a
context other than the initialization of an array of character type.
>
I disagree here. I want the compiler to generate the "as if" results
regardless of any optimisation, working as currently specified. And
/if/ the compiler is able to optimise the #embed, then I want it to do
so automatically - I see no situation in which I would ever want
"optimize(false)".
The issue I'm trying to address (very prematurely, no doubt) is
that the decision of whether to optimize #embed vs. generating the
naive comma-separated sequence is difficult to formalize, and easy
to get wrong in corner cases. "restrict" is another performance
hint whose only formal effect is to introduce undefined behavior
if you use it incorrectly.
Let's say I define an array of a 1-byte enumeration type, initialized
with #embed for a very large binary file. Maybe one compiler recognizes
this as a case where it can perform the optimization, and another
doesn't. If I can tell the compiler "trust me, I'm using this to
initialize raw byte data, and I'll take responsibility if I get it
wrong", I can see that being useful.
And maybe "optimize" isn't the best name. Perhaps "raw_bytes"?
Without some kind of programmer control, I'm concerned that the rules
for defining an array so #embed will be correctly optimized will be
spread as lore rather than being specified anywhere.
[...]
-- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.comvoid Void(void) { Void(); } /* The recursive call of the void */