Sujet : Re: Baby X is bor nagain
De : david.brown (at) *nospam* hesbynett.no (David Brown)
Groupes : comp.lang.cDate : 13. Jun 2024, 12:53:54
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v4emki$28d1b$1@dont-email.me>
References : 1 2 3 4 5 6 7 8
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
On 12/06/2024 23:29, Michael S wrote:
On Wed, 12 Jun 2024 15:46:44 +0200
David Brown <david.brown@hesbynett.no> wrote:
>
I also don't imagine that string literals would be much faster for
compilation, at least for file sizes that I think make sense.
Just shows how little do you know about internals of typical compiler.
Which, by itself, is o.k. What is not o.k. is that with your level of
knowledge you have a nerve to argue vs bart that obviously knows a lot
more.
I know more than most C programmers about how certain C compilers work, and what works well with them, and what is relevant for them - though I certainly don't claim to know everything. Obviously Bart knows vastly more about how /his/ compiler works. He also tends to do testing with several small and odd C compilers, which can give interesting results even though they are of little practical relevance for real-world C development work.
Testing a 1 MB file of random data, gcc -O2 took less than a second to compile it. One megabyte is about the biggest size I would think makes sense to embed directly in C code unless you are doing something very niche - usually if you need that much data, you'd be better off with separate files and standardised packaging systems like zip files, installer setup.exe builds, or that kind of thing.
Using string literals, the compile time was shorter, but when you are already below a second, it's all just irrelevant noise.
For much bigger files, string literals are likely to be faster for compilation for gcc because the compiler does not track as much information (for use in diagnostic messages). But it makes no difference to real world development.
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.
>
Citation, please..
<
https://letmegooglethat.com/?q=msvc+string+literal+length+limit>
Actually, I think it was from Bart that I first heard that MSVC has limitations on its string literal lengths, but I could well be misremembering that. I am confident, however, that it was here in c.l.c., as MSVC is not a tool I have used myself.
<
https://learn.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp>
It seems that version 17.0 has removed the arbitrary limits, while before that it was limited to 65K in their C++ compiler.
For the MSVC C compiler, I see this:
<
https://learn.microsoft.com/en-us/cpp/c-language/maximum-string-length>
Each individual string is up to 2048 bytes, which can be concatenated to a maximum of 65K in total.
I see other links giving different values, but I expect the MS ones to be authoritative. It is possible that newer versions of their C compiler have removed the limit, just as for their C++ compiler, but it was missing from that webpage.
(And I noticed also someone saying that MSVC is 70x faster at using string literals compared to lists of integers for array initialisation.)