Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c++
Subject: Re: Pre-main construction order in modules
Date: Wed, 2 Apr 2025 10:29:17 +0200
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <vsisgt$1bk1v$1@dont-email.me>
References: <vsb12i$2mv42$1@dont-email.me> <vsbl21$1jsvi$1@dont-email.me>
 <vsbo2p$1p5ov$1@dont-email.me> <vse8sj$f9o2$1@dont-email.me>
 <vsfq2q$26s1t$1@dont-email.me> <vsh9av$362k4$1@dont-email.me>
 <20250401231040.00007eeb@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 02 Apr 2025 10:29:18 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="74a97941b726b117bb180f881e003081";
	logging-data="1429567"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/QoYMZaEcz4GXMTj0wjOYE0/247YmqnsY="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:qo5WcG7MnTCSZ8U+y9szbqXrx/Y=
In-Reply-To: <20250401231040.00007eeb@yahoo.com>
Content-Language: en-GB
Bytes: 3633

On 01/04/2025 22:10, Michael S wrote:
> On Tue, 1 Apr 2025 13:55:43 -0400
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> 
>> On 4/1/25 00:29, Jakob Bohm wrote:
> 
>>
>>> However treating the standard text as an imperfect description of
>>> traditional compiler techniques used for 2nd. Edition compilers
>>> makes much more sense .
>>
>> No, that does not. The standard was never intended as a description of
>> how compilers actually work, it was always intended to be a
>> description of requirements on how they should work.
> 
> 
> It sounds to me like a revisionisms.
> Most language standards are intended to codify commonalities of work of
> existing compilers. That applies to C++98 and mostly, although not
> completely, to the following C++ standards.
> There exist exceptions, for example, Ada83. But they are exceptions.
> 

Most language standards /started/ with a codification of existing tools. 
  Making a language standard is a lot of effort, and is rarely done 
until there is at least one implementation and it has been used for a 
while - there's little point spending a lot of time defining a language 
that might never be used, or might turn out to be impractical or 
inefficient to implement.  Initial standards are often books - K&R "The 
C Programming Language" and Stroustrup "The C++ Programming Language" 
being fine examples.  More official standards can come later.

Sometimes there is a "reference implementation" and the documentation 
for that becomes, in effect, the standard.

But once the process is in place, it is now the standard that defines 
the language, and future implementations are intended to conform to the 
standard.  Implementations can have extensions and extra features, and 
those can strongly influence future versions of the standard, but the 
standard defines how the language works.

Thus many features that were added to C and C++ after their initial 
standardisation began as extensions in compilers - especially gcc.  But 
the standardised features were what the language committees felt were 
best for the language going forward - /not/ a codification of existing 
practice.  There are countless examples of new features in language 
standards that are clearly inspired by, but noticeably different from, 
extensions in compilers.