Path: ...!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: question about linker
Date: Wed, 4 Dec 2024 11:26:42 +0100
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <vipap2$po6v$3@dont-email.me>
References: <vi54e9$3ie0o$1@dont-email.me> <20241129142810.00007920@yahoo.com>
 <vicfra$13nl4$1@dont-email.me> <20241129161517.000010b8@yahoo.com>
 <vicque$15ium$2@dont-email.me> <vid110$16hte$1@dont-email.me>
 <87mshhsrr0.fsf@nosuchdomain.example.com> <vidd2a$18k9j$1@dont-email.me>
 <8734j9sj0f.fsf@nosuchdomain.example.com> <vihhkj$2er60$1@dont-email.me>
 <vihjaj$2f79m$2@dont-email.me> <vihs4s$2hgg1$2@dont-email.me>
 <20241201185740.00004c30@yahoo.com> <viia55$2mrc9$1@dont-email.me>
 <vinftq$2sv5n$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 04 Dec 2024 11:26:42 +0100 (CET)
Injection-Info: dont-email.me; posting-host="3d4736a0b9182c19006430c54e7a5ec1";
	logging-data="843999"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19UvIUWdUqCK9rg1F0I1hC243RnNCHWsI4="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:ej4uRz/jC12sP1y1Ingv3ityLQE=
In-Reply-To: <vinftq$2sv5n$1@paganini.bofh.team>
Content-Language: en-GB
Bytes: 4314

On 03/12/2024 18:42, Waldek Hebisch wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 01/12/2024 17:57, Michael S wrote:
>>> On Sun, 1 Dec 2024 15:34:04 +0100
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>
>>>> I can see some advantages in a language being happy with any order of
>>>> function definition, without requiring forward declarations to use a
>>>> function before it is defined.  But C is not like that, and I cannot
>>>> honestly say it bothers me one way or the other.  And apparently, it
>>>> does not particularly bother many people - there is, I think, no
>>>> serious impediment or backwards compatibility issue that would
>>>> prevent C being changed in this way.  Yet no one has felt the need
>>>> for it - at least not strongly enough to fight for it going in the
>>>> standard or being a common compiler extension.
>>>>
>>>>
>>>>
>>>
>>> I think, arguing in favor of such change would be easier on top of
>>> the changes made in C23.
>>> Before C23 there were, as you put it "no serious impediment or
>>> backwards compatibility issue". After C23 we could more categorical
>>> claim that there are no new issues.
>>>
>>
>> Does that mean there was something that you think was allowed in C
>> before C23, but not after C23, that would potentially be a problem here?
>>
>> What, specifically, are you thinking of?
> 
> Michael probably meant 'constexpr'.  AFAICS the are on troubles with
> automatic reordering of "pure" declarations.  But variable declarations
> may have initialization and 'constexpr' allows not entirely trivial
> expressions for initialization.  And C wants to be compatible with
> C++, where even now initialization is much more "interesting".
> 
> So, reordering variable declarations is problematic due to
> initalization and it would be ugly to have special case for
> function declarations.
>    

Prior to C23 you could have non-trivial expressions for initialisations 
that depend on the order of the declarations in the code:

	enum { a = 1, b = 10, c = 100 };
	const int y = (a * b) - (c / 10);

constexpr in C23 gives you a lot of flexibility to do more here, using 
different types (not just "int").  Prior to C23, people would use 
#define'd macros:

	#define pi 3.14159265359
	const double zeta_2 = (pi * pi) / 6;

constexpr does not actually change the principles here, it just makes 
them clearer and neater.


Since macros are not scoped, and can be undefined and redefined, they 
will always be an issue for any re-ordering of code.  Replacing such 
"literal" macros with constexpr declarations would make it a lot easier 
to support a single wide file-level scope where declaration order does 
not matter, rather than making it harder.