Re: Baby X is bor nagain

On 12/06/2024 13:27, bart wrote:

On 12/06/2024 08:01, David Brown wrote:

On 12/06/2024 07:40, Bonita Montero wrote:

 

I converted my code into sth. that produces a C-string as an output.
Printing that is still very fast, i.e. the files produced are written
with about 2.6GiB/s. But the problem is still that all compilers don't
parse large files but quit with an out of memory error. So having a
.obj output along with a small header file would be the best.
>

>
How big files are you talking about?  In an earlier thread (which I thought had beaten this topic to death), "xxd -i" include files were fine to at least a few tens of megabytes with gcc.

 What was never discussed is why xxd  (and the faster alternates that some posted to do that task more quickly), produces lists of numbers anyway.
 Why not strings containing the embedded binary data?
 

There are some cases where lists of numbers would be useable while strings would not be.  But I suppose the opposite will apply too.
While string literals can contain embedded null characters (a string literal in C does not have to be a string), I don't feel as comfortable using a messy string literal full of escape codes for binary data.  A list of hex numbers, with appropriate line lengths, is also vastly neater if you need to look at the data (or accidentally open it in a text editor).
I also don't imagine that string literals would be much faster for compilation, at least for file sizes that I think make sense.  And I have heard (it could be wrong) that MSVC has severe limits on the size of string literals, though it is not a compiler I ever use myself.
But of course, if you prefer string literals, use them.  I don't think xxd can generate them, but it should not be hard to write a program that does.

 

  And it would be, IMHO, absurd to have much bigger files than that embedded with your executable in this manner.

  BM complained that some files expressed as xxd-like output were causing problems with compilers.
 I suggested using a string representation. While the generated text file is not much smaller, it is seen by the compiler as one string expression, instead of millions of small expressions. Or at least, 1/20th the number if you split the strings across lines.
 It's a no-brainer. Why spend 10 times as long on processing such data?
 

10 times negligible is still negligible.
But to be clear, I'd still rate a string literal like this as vastly nicer than some XML monstrosity!