Re: C23 thoughts and opinions

On Tue, 28 May 2024 13:21:26 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

David Brown <david.brown@hesbynett.no> writes:

On 28/05/2024 02:33, Keith Thompson wrote: 

[...]

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. 

>
They might, but I really do not think that is so important, since
they will not affect the generated results. 

 
Right, it won't affect the generated results (assuming I use it
correctly).  Unless I use `#embed optimize(true)` to initialize
a struct with varying member sizes, but that's my fault because I
asked for it.
 
The point is compile-timer performance, and perhaps even the ability
to compile at all.
 
I'm thinking about hypothetical cases where I want to embed a
*very* large file and parsing the comma-delimited sequence could
have unacceptable compile-time performance, perhaps even causing
a compile-time stack overflow depending on how the parser works.
Every time the compiler sees #embed, it has to decide whether to
optimize it or not, and the decision criteria are not specified
anywhere (not at all in the standard, perhaps not clearly in the
compiler's documentation).
 

What about suggestion of Scott Lurndal?
Preprocessor emits implementation defined directive as a prefix to CSV
table. The directive tells to compiler to temporarily switch itself
into specialized parsing mode, probably keeping all converted numbers
in a single node in parser's results tree.
As demonstrated in several posts below, parsing by itself as well as
text to number conversion by itself, are not too bad. It's tree
management that is problematic.