Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Thu, 13 Jun 2024 17:43:54 +0300
Organization: A noiseless patient Spider
Lines: 119
Message-ID: <20240613174354.00005498@yahoo.com>
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>
	<v4c8s4$1lki1$4@dont-email.me>
	<20240613002933.000075c5@yahoo.com>
	<v4emki$28d1b$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 13 Jun 2024 16:43:39 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="385665b774ea20863bf51bd6cc97bd68";
	logging-data="2400322"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+kJOD3Ds92MCennjMJ7+7DWjZUN4PT1K4="
Cancel-Lock: sha1:7yzFZgTgCPZWsDobaJtalW3C7dE=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 5697

On Thu, 13 Jun 2024 13:53:54 +0200
David Brown <david.brown@hesbynett.no> wrote:

> 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.
>

Since he do compilers himself, he has much better feeling [that you
or me] of what is hard and what is easy, what is small and what is big,
what is fast and what is slow. That applies to all compilers except
those that are very unusual. "Major" compiler are not unusual at all.

> Testing a 1 MB file of random data, gcc -O2 took less than a second
> to compile it.

Somewhat more than a second on less modern hardware. Enough for me to
feel that compilation is not instant.
But 1 MB is just an arbitrary number. For 20 MB everybody would feel
the difference. And for 50 MB few people would not want it to be much
faster.

>  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

And that is sort of the thing that bart knows immediately. Unlike you
and me.

>  (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.)
> 

I didn't know it, thanks.
It means that string method can't be used universally.

Still, for C (as opposed to C++), limitation of compiler can be tricked
around by declaring container as a struct. E.g. for array of length
1234567

struct {
  char bulk[123][10000];
  char tail[4567];
} bar = {
 {
  "init0-to-99999" ,
  "init10000-to-199999" ,
  ....
 },
 "init123400-to1234566"
};

For that I'd expecte compilation speed almost as fast as of one string.