Deutsch English Français Italiano |
<v4c8s4$1lki1$4@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: David Brown <david.brown@hesbynett.no> Newsgroups: comp.lang.c Subject: Re: Baby X is bor nagain Date: Wed, 12 Jun 2024 15:46:44 +0200 Organization: A noiseless patient Spider Lines: 62 Message-ID: <v4c8s4$1lki1$4@dont-email.me> References: <v494f9$von8$1@dont-email.me> <v49seg$14cva$1@raubtier-asyl.eternal-september.org> <v49t6f$14i1o$1@dont-email.me> <v4bcbj$1gqlo$1@raubtier-asyl.eternal-september.org> <v4bh56$1hibd$1@dont-email.me> <v4c0mg$1kjmk$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 12 Jun 2024 15:46:44 +0200 (CEST) Injection-Info: dont-email.me; posting-host="56b4a0ed48525cf719a93689486bb34c"; logging-data="1757761"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX190LNnf8cvCeeuxgI8ucMW1rjBlj9y8J08=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Cancel-Lock: sha1:574CizSsiLmXsu0ALDEtmzQ6LXg= In-Reply-To: <v4c0mg$1kjmk$1@dont-email.me> Content-Language: en-GB Bytes: 3918 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!