I was curious about the order in which objects get constructed in modules before main gets called. It seems with both Clang and gcc its the order in which the modules were linked together to form the runnable binary so if
the link order was m1.o m2.o then anything in m1 would get constructed first. Vice verca if you switch the order.
Is this codified in the standard or is it left up to compiler and linker writers to decide how they order this?
I was curious about the order in which objects get constructed in modules before main gets called. It seems with both Clang and gcc its the order in which the modules were linked together to form the runnable binary so if
the link order was m1.o m2.o then anything in m1 would get constructed first. Vice verca if you switch the order.
Is this codified in the standard or is it left up to compiler and linker writers to decide how they order this?
On 3/30/25 4:57 AM, Muttley@DastardlyHQ.org wrote:
I was curious about the order in which objects get constructed in modules
before main gets called. It seems with both Clang and gcc its the order in >> which the modules were linked together to form the runnable binary so if
the link order was m1.o m2.o then anything in m1 would get constructed first.
Vice verca if you switch the order.
Is this codified in the standard or is it left up to compiler and linker
writers to decide how they order this?
Section 6.9.3.3 does in fact impose many constraints on the sequence in
which non-local objects with static storage duration get initialized. >However, all of the sequence requirements are only between objects
defined in the same translation unit. Also, it's implementation-defined
which of those initializations occur before the start of main().
On Sun, 30 Mar 2025 10:38:57 -0400 James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On 3/30/25 4:57 AM, Muttley@DastardlyHQ.org wrote:
I was curious about the order in which objects get constructed in
modules before main gets called. It seems with both Clang and gcc its
the order in which the modules were linked together to form the
runnable binary so if the link order was m1.o m2.o then anything in m1
would get constructed first.
Vice verca if you switch the order.
Is this codified in the standard or is it left up to compiler and
linker writers to decide how they order this?
Section 6.9.3.3 does in fact impose many constraints on the sequence in >>which non-local objects with static storage duration get initialized. >>However, all of the sequence requirements are only between objects
defined in the same translation unit. Also, it's implementation-defined >>which of those initializations occur before the start of main().
Initialising global objects before main is an absolute must otherwise
how are you expected to use them safely? They're not in the code for decoration.
On Sun, 30 Mar 2025 15:30:34 +0000, Muttley wrote:
On Sun, 30 Mar 2025 10:38:57 -0400 James Kuyper
<jameskuyper@alumni.caltech.edu> wibbled:
On 3/30/25 4:57 AM, Muttley@DastardlyHQ.org wrote:
I was curious about the order in which objects get constructed in
modules before main gets called. It seems with both Clang and gcc its
the order in which the modules were linked together to form the
runnable binary so if the link order was m1.o m2.o then anything in m1 >>>> would get constructed first.
Vice verca if you switch the order.
Is this codified in the standard or is it left up to compiler and
linker writers to decide how they order this?
Section 6.9.3.3 does in fact impose many constraints on the sequence in >>>which non-local objects with static storage duration get initialized. >>>However, all of the sequence requirements are only between objects >>>defined in the same translation unit. Also, it's implementation-defined >>>which of those initializations occur before the start of main().
Initialising global objects before main is an absolute must otherwise
how are you expected to use them safely? They're not in the code for
decoration.
Global variables are really bad, you are wrong to think it is OK to use >them.
On Sun, 30 Mar 2025 15:59:05 GMT Mr Flibble <flibble@reddwarf.jmc.corp> wibbled:
On Sun, 30 Mar 2025 15:30:34 +0000, Muttley wrote:
On Sun, 30 Mar 2025 10:38:57 -0400 James Kuyper
<jameskuyper@alumni.caltech.edu> wibbled:
On 3/30/25 4:57 AM, Muttley@DastardlyHQ.org wrote:
I was curious about the order in which objects get constructed in
modules before main gets called. It seems with both Clang and gcc
its the order in which the modules were linked together to form the
runnable binary so if the link order was m1.o m2.o then anything in
m1 would get constructed first.
Vice verca if you switch the order.
Is this codified in the standard or is it left up to compiler and
linker writers to decide how they order this?
Section 6.9.3.3 does in fact impose many constraints on the sequence
in which non-local objects with static storage duration get >>>>initialized. However, all of the sequence requirements are only
between objects defined in the same translation unit. Also, it's >>>>implementation-defined which of those initializations occur before the >>>>start of main().
Initialising global objects before main is an absolute must otherwise
how are you expected to use them safely? They're not in the code for
decoration.
Global variables are really bad, you are wrong to think it is OK to use >>them.
You're entitled to your opinion. I tend to use a few global objects,
often singletons that contain most of the code. Having them global means
I don't have to pass a reference into every damn function in one object
that requires the other object.
On 3/30/25 4:57 AM, Muttley@DastardlyHQ.org wrote:
I was curious about the order in which objects get constructed inIt is left explicitly undefined in the Standard.
modules before main gets called. It seems with both Clang and gcc its
the order in which the modules were linked together to form the
runnable binary so if the link order was m1.o m2.o then anything in m1
would get constructed first.
Vice verca if you switch the order.
Is this codified in the standard or is it left up to compiler and
linker writers to decide how they order this?
On Sun, 30 Mar 2025 16:09:38 +0000, Muttley wrote:
You're entitled to your opinion. I tend to use a few global objects,
often singletons that contain most of the code. Having them global means
I don't have to pass a reference into every damn function in one object
that requires the other object.
Singletons don't have to be global objects if you use the Meyers Singleton >pattern.
On Sun, 30 Mar 2025 16:17:04 GMT Mr Flibble <flibble@reddwarf.jmc.corp> wibbled:
On Sun, 30 Mar 2025 16:09:38 +0000, Muttley wrote:
You're entitled to your opinion. I tend to use a few global objects,
often singletons that contain most of the code. Having them global
means I don't have to pass a reference into every damn function in one
object that requires the other object.
Singletons don't have to be global objects if you use the Meyers
Singleton pattern.
Never heard of it and don't particularly care. I write code to solve problems,
not to subscribe to whatever structural paradigm is flavour of the
month.
On Sun, 30 Mar 2025 07:21:14 -0400, Richard Damon wrote:
On 3/30/25 4:57 AM, Muttley@DastardlyHQ.org wrote:
I was curious about the order in which objects get constructed inIt is left explicitly undefined in the Standard.
modules before main gets called. It seems with both Clang and gcc its
the order in which the modules were linked together to form the
runnable binary so if the link order was m1.o m2.o then anything in m1
would get constructed first.
Vice verca if you switch the order.
Is this codified in the standard or is it left up to compiler and
linker writers to decide how they order this?
No, it is *unspecified* not *undefined*.
Singletons don't have to be global objects if you use the Meyers Singleton pattern.
Am 30.03.2025 um 18:22 schrieb Mr Flibble:
On Sun, 30 Mar 2025 07:21:14 -0400, Richard Damon wrote:
On 3/30/25 4:57 AM, Muttley@DastardlyHQ.org wrote:
I was curious about the order in which objects get constructed inIt is left explicitly undefined in the Standard.
modules before main gets called. It seems with both Clang and gcc its
the order in which the modules were linked together to form the
runnable binary so if the link order was m1.o m2.o then anything in
m1 would get constructed first.
Vice verca if you switch the order.
Is this codified in the standard or is it left up to compiler and
linker writers to decide how they order this?
No, it is *unspecified* not *undefined*.
LOL - idiot
Am 30.03.2025 um 18:17 schrieb Mr Flibble:
Singletons don't have to be global objects if you use the Meyers
Singleton pattern.
That nearly doesn't make a difference, everything is still in the BSS-segment.
It makes all the difference as it is the standard way to avoid the initialisation order fiasco (the subject of this thread) but I wouldn't expect an ignorant troll such as yourself to know this.
Am 30.03.2025 um 20:02 schrieb Mr Flibble:
It makes all the difference as it is the standard way to avoid the
initialisation order fiasco (the subject of this thread) but I wouldn't
expect an ignorant troll such as yourself to know this.
It doesn't help to prevent the static initialization order fiasco since
the initialization order of static members is also not guaranteed across translation units.
On Sun, 30 Mar 2025 20:05:51 +0200, Bonita Montero wrote:
Am 30.03.2025 um 20:02 schrieb Mr Flibble:
It makes all the difference as it is the standard way to avoid the
initialisation order fiasco (the subject of this thread) but I wouldn't
expect an ignorant troll such as yourself to know this.
It doesn't help to prevent the static initialization order fiasco since
the initialization order of static members is also not guaranteed across
translation units.
The Meyers Singleton does NOT involve static members; I suggest you go
read up on what it actually involves rather than continue to make a fool
of yourself.
/Flibble
Am 30.03.2025 um 20:07 schrieb Mr Flibble:meyers_singleton.html
On Sun, 30 Mar 2025 20:05:51 +0200, Bonita Montero wrote:
Am 30.03.2025 um 20:02 schrieb Mr Flibble:
It makes all the difference as it is the standard way to avoid the
initialisation order fiasco (the subject of this thread) but I
wouldn't expect an ignorant troll such as yourself to know this.
It doesn't help to prevent the static initialization order fiasco
since the initialization order of static members is also not
guaranteed across translation units.
The Meyers Singleton does NOT involve static members; I suggest you go
read up on what it actually involves rather than continue to make a
fool of yourself.
/Flibble
What you mean is right, but that's not Meyers singleton: https://laristra.github.io/flecsi/src/developer-guide/patterns/
No what I meant was the Meyers Singleton which involves static local variables NOT static member variables which is what YOU thought it meant.
Am 30.03.2025 um 20:11 schrieb Mr Flibble:
No what I meant was the Meyers Singleton which involves static local
variables NOT static member variables which is what YOU thought it
meant.
static local variables need double-checked locked initialization.
That's rather slow to just get a reference.
On Sun, 30 Mar 2025 20:17:23 +0200, Bonita Montero wrote:
Am 30.03.2025 um 20:11 schrieb Mr Flibble:
No what I meant was the Meyers Singleton which involves static local
variables NOT static member variables which is what YOU thought it
meant.
static local variables need double-checked locked initialization.
That's rather slow to just get a reference.
But that is nevertheless what the Meyers Singleton involves. Static local initialisation has been threadsafe since C++11 and if performance is a concern then you can always cache the result in a reference downstream in
any hot path that needs it.
/Flibble
On Sun, 30 Mar 2025 16:17:04 GMT
Mr Flibble <flibble@reddwarf.jmc.corp> wibbled:
On Sun, 30 Mar 2025 16:09:38 +0000, Muttley wrote:
You're entitled to your opinion. I tend to use a few global objects,
often singletons that contain most of the code. Having them global means >>> I don't have to pass a reference into every damn function in one object
that requires the other object.
Singletons don't have to be global objects if you use the Meyers Singleton >> pattern.
Never heard of it and don't particularly care. I write code to solve problems,
not to subscribe to whatever structural paradigm is flavour of the month.
But that is nevertheless what the Meyers Singleton involves. Static local initialisation has been threadsafe since C++11 and if performance is a concern then you can always cache the result in a reference downstream in
any hot path that needs it.
Am 30.03.2025 um 20:20 schrieb Mr Flibble:
But that is nevertheless what the Meyers Singleton involves. Static
local
initialisation has been threadsafe since C++11 and if performance is a
concern then you can always cache the result in a reference downstream in
any hot path that needs it.
With current implemention all C++ runtimes govern all station initia- lizations through a single mutex. That hurts if you have a constructor
that takes longer, maybe because of a socket-connection which the code
waits for.
Creating threads, socket-connections before main is a bad idea...? ;^o
On Sun, 30 Mar 2025 16:23:33 +0000, Muttley wrote:
On Sun, 30 Mar 2025 16:17:04 GMT Mr Flibble <flibble@reddwarf.jmc.corp>
wibbled:
On Sun, 30 Mar 2025 16:09:38 +0000, Muttley wrote:
You're entitled to your opinion. I tend to use a few global objects,
often singletons that contain most of the code. Having them global
means I don't have to pass a reference into every damn function in one >>>> object that requires the other object.
Singletons don't have to be global objects if you use the Meyers >>>Singleton pattern.
Never heard of it and don't particularly care. I write code to solve
problems,
not to subscribe to whatever structural paradigm is flavour of the
month.
The Meyers Singleton pattern has been around for decades, it certainly is >not "flavour of the month" and your ignorance of it is quite noobish - it
is the standard way of avoiding the global variable initialisation order >fiasco.
The Meyers Singleton pattern has been around for decades, ..
On Sun, 30 Mar 2025 10:38:57 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
Section 6.9.3.3 does in fact impose many constraints on the sequence in
which non-local objects with static storage duration get initialized.
However, all of the sequence requirements are only between objects
defined in the same translation unit. Also, it's implementation-defined
which of those initializations occur before the start of main().
Initialising global objects before main is an absolute must otherwise how
are you expected to use them safely? They're not in the code for decoration.
Am 30.03.2025 um 18:26 schrieb Mr Flibble:
The Meyers Singleton pattern has been around for decades, ..
Decades are multiples of a decade, i.e. >= 20 years. But Meyer's
singleton is possible since C++11, where static local initializations
are thread-safe, that's 14 years ago.
On 30.03.2025 18:30, Muttley@DastardlyHQ.org wrote:
On Sun, 30 Mar 2025 10:38:57 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
Section 6.9.3.3 does in fact impose many constraints on the sequence in
which non-local objects with static storage duration get initialized.
However, all of the sequence requirements are only between objects
defined in the same translation unit. Also, it's implementation-defined
which of those initializations occur before the start of main().
Initialising global objects before main is an absolute must otherwise how
are you expected to use them safely? They're not in the code for decoration.
Initializing global objects before main is not possible with
demand-loaded dynamically loaded libraries.
Before C++11 one had to just add their own synchronization for thread
safety (assuming multi-threaded access was needed, which was not so
often in the past).
C++11 just made coding of a Meyer's singleton easier, that's all.
Am 30.03.2025 um 18:26 schrieb Mr Flibble:
The Meyers Singleton pattern has been around for decades, ..
Decades are multiples of a decade, i.e. >= 20 years. But Meyer's
singleton is possible since C++11, where static local initializations
are thread-safe, that's 14 years ago.
Am 31.03.2025 um 10:56 schrieb Paavo Helde:
Before C++11 one had to just add their own synchronization for thread
safety (assuming multi-threaded access was needed, which was not so
often in the past).
C++11 just made coding of a Meyer's singleton easier, that's all.
That's not that easy since it is undefined when a static local variable
is initialized before C++11. You'd have to wrap it in a union and leave
only member which is the object uninitialized. That's possible, but
that's not Meyer's singleton.
Am 31.03.2025 um 10:56 schrieb Paavo Helde:
Before C++11 one had to just add their own synchronization for thread
safety (assuming multi-threaded access was needed, which was not so
often in the past).
C++11 just made coding of a Meyer's singleton easier, that's all.
That's not that easy since it is undefined when a static local variable
is initialized before C++11. You'd have to wrap it in a union and leave
only member which is the object uninitialized. That's possible, but
that's not Meyer's singleton.
An example of pre-C++11 thread-safe Meyer singleton:
std::map<std::string, std::string>& GetGlobalMap() {
// No dynamic initialization, so this is safe:
static std::map<std::string, std::string>* pGlobal = NULL;
// No dynamic initialization, so this is safe as well:
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
// Initialize the global static if not yet initialized.
pthread_mutex_lock(&mutex);
if (!pGlobal) {
pGlobal = new std::map<std::string, std::string>();
}
pthread_mutex_unlock(&mutex);
return *pGlobal;
}
On Mon, 31 Mar 2025 11:49:23 +0300
Paavo Helde <eesnimi@osa.pri.ee> wibbled:
On 30.03.2025 18:30, Muttley@DastardlyHQ.org wrote:
On Sun, 30 Mar 2025 10:38:57 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
Section 6.9.3.3 does in fact impose many constraints on the sequence in >>>> which non-local objects with static storage duration get initialized.
However, all of the sequence requirements are only between objects
defined in the same translation unit. Also, it's implementation-defined >>>> which of those initializations occur before the start of main().
Initialising global objects before main is an absolute must otherwise how >>> are you expected to use them safely? They're not in the code for decoration.
Initializing global objects before main is not possible with
demand-loaded dynamically loaded libraries.
Well obviously, but thats not what I'm talking about. If myobj() is constructed
in a linked .o file I expect it to be available and ready in main(). If not then when? Or are you just supposed to guess or hope for the best?
Am 31.03.2025 um 14:26 schrieb Paavo Helde:
An example of pre-C++11 thread-safe Meyer singleton:
std::map<std::string, std::string>& GetGlobalMap() {
// No dynamic initialization, so this is safe:
static std::map<std::string, std::string>* pGlobal = NULL;
// No dynamic initialization, so this is safe as well:
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
// Initialize the global static if not yet initialized.
pthread_mutex_lock(&mutex);
if (!pGlobal) {
pGlobal = new std::map<std::string, std::string>();
}
pthread_mutex_unlock(&mutex);
return *pGlobal;
}
That's rather slow. Double-checked locking as implemented for
all static locals with current runtimes is much more efficient.
On 31.03.2025 12:09, Muttley@DastardlyHQ.org wrote:
"If [initialization] is deferred, it strongly happens before any >non-initialization odr-use of any non-inline function or non-inline
variable defined in the same translation unit as the variable to be >initialized."
The keyword here is "non-initialization use". If you access your myobj
from main() it would be a non-initialization use, which is guaranteed to >trigger the needed initialization if needed, so everything will work fine.
On 30.03.2025 18:30, Muttley@DastardlyHQ.org wrote:
On Sun, 30 Mar 2025 10:38:57 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
Section 6.9.3.3 does in fact impose many constraints on the sequence in
which non-local objects with static storage duration get initialized.
However, all of the sequence requirements are only between objects
defined in the same translation unit. Also, it's implementation-defined
which of those initializations occur before the start of main().
Initialising global objects before main is an absolute must otherwise how
are you expected to use them safely? They're not in the code for decoration.
Initializing global objects before main is not possible with
demand-loaded dynamically loaded libraries.
On Sun, 30 Mar 2025 10:38:57 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
Section 6.9.3.3 does in fact impose many constraints on the sequence in
which non-local objects with static storage duration get initialized.
However, all of the sequence requirements are only between objects
defined in the same translation unit. Also, it's implementation-defined
which of those initializations occur before the start of main().
Initialising global objects before main is an absolute must otherwise how
are you expected to use them safely? They're not in the code for decoration.
Which are initialized as the library is loaded. Much the
same effect as implementing before main.
On Mon, 31 Mar 2025 15:39:53 +0300
Paavo Helde <eesnimi@osa.pri.ee> wibbled:
On 31.03.2025 12:09, Muttley@DastardlyHQ.org wrote:
"If [initialization] is deferred, it strongly happens before any
non-initialization odr-use of any non-inline function or non-inline
variable defined in the same translation unit as the variable to be
initialized."
Who writes this stuff? Its borderline gibberish.
The keyword here is "non-initialization use". If you access your myobj >>from main() it would be a non-initialization use, which is guaranteed to
trigger the needed initialization if needed, so everything will work fine.
Not necessarily. What it the constructor of one object opened a network socket but that object wasn't touched again until something else in the program tried to loop back to that socket?
On Mon, 31 Mar 2025 15:39:53 +0300
Paavo Helde <eesnimi@osa.pri.ee> wibbled:
On 31.03.2025 12:09, Muttley@DastardlyHQ.org wrote:
"If [initialization] is deferred, it strongly happens before any
non-initialization odr-use of any non-inline function or non-inline
variable defined in the same translation unit as the variable to be
initialized."
Who writes this stuff? Its borderline gibberish.
Am 31.03.2025 um 14:26 schrieb Paavo Helde:
An example of pre-C++11 thread-safe Meyer singleton:
std::map<std::string, std::string>& GetGlobalMap() {
// No dynamic initialization, so this is safe:
static std::map<std::string, std::string>* pGlobal = NULL;
// No dynamic initialization, so this is safe as well:
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
// Initialize the global static if not yet initialized.
pthread_mutex_lock(&mutex);
if (!pGlobal) {
pGlobal = new std::map<std::string, std::string>();
}
pthread_mutex_unlock(&mutex);
return *pGlobal;
}
That's rather slow. Double-checked locking as implemented for
all static locals with current runtimes is much more efficient.
On 30.03.2025 18:30, Muttley@DastardlyHQ.org wrote:
On Sun, 30 Mar 2025 10:38:57 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
Section 6.9.3.3 does in fact impose many constraints on the sequence in
which non-local objects with static storage duration get initialized.
However, all of the sequence requirements are only between objects
defined in the same translation unit. Also, it's implementation-defined
which of those initializations occur before the start of main().
Initialising global objects before main is an absolute must otherwise how
are you expected to use them safely? They're not in the code for decoration.
"If it [initialization] is deferred, it strongly happens before any non-initialization odr-use of any non-inline function or non-inline
variable defined in the same translation unit as the variable to be initialized.47 It is implementation-defined in which threads and at
which points in the program such deferred dynamic initialization
occurs." (6.9.3.3p5).
Therefore, what you need to do is make sure that the object has been initialized is to access it from a function defined in the same
translation unit.
Am 30.03.2025 um 22:57 schrieb Chris M. Thomasson:
Creating threads, socket-connections before main is a bad idea...? ;^o
Why ?
Artificial locking around ALL static locals as implemented by some
modern compilers is highly wasteful as in most code, the code
structure already ensures a single thread will be the first to
execute that initialization/construction, often one of the threads
in the compiler itself.
That locking by compilers seem to be the result of someone in the C++
ctte wanting to take over every OS feature that used to be out of
scope for system programming languages like C/C++ . It also makes it unnecessarily harder to use the system compiler to implement the lower
level code that exists at a more fundamental / portable level than
silly textbook examples .
Is main all setup pre main?
Am 01.04.2025 um 06:54 schrieb Chris M. Thomasson:
Is main all setup pre main?
Pre-main.
On 31.03.2025 17:01, Muttley@DastardlyHQ.org wrote:
On Mon, 31 Mar 2025 15:39:53 +0300
Paavo Helde <eesnimi@osa.pri.ee> wibbled:
On 31.03.2025 12:09, Muttley@DastardlyHQ.org wrote:
"If [initialization] is deferred, it strongly happens before any
non-initialization odr-use of any non-inline function or non-inline
variable defined in the same translation unit as the variable to be
initialized."
Who writes this stuff? Its borderline gibberish.
Keep in mind that the key thing that makes this seem like gibberish is
the use of precisely defined technical jargon, which is used for the
same reason that jargon is used in many other contexts: it has a more >precisely specified meaning than more informal wording would have had.
Key pieces of jargon: "strongly happens before", "non-initialization",
"odr-use", "translation unit". If there's anything you don't understand
about that clause, it's probably based in unfamiliarity with such phrases.
On 2025-03-31 14:32, Bonita Montero wrote:
Am 31.03.2025 um 14:26 schrieb Paavo Helde:
An example of pre-C++11 thread-safe Meyer singleton:
std::map<std::string, std::string>& GetGlobalMap() {
// No dynamic initialization, so this is safe:
static std::map<std::string, std::string>* pGlobal = NULL;
// No dynamic initialization, so this is safe as well:
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
// Initialize the global static if not yet initialized.
pthread_mutex_lock(&mutex);
if (!pGlobal) {
pGlobal = new std::map<std::string, std::string>();
}
pthread_mutex_unlock(&mutex);
return *pGlobal;
}
That's rather slow. Double-checked locking as implemented for
all static locals with current runtimes is much more efficient.
Artificial locking around ALL static locals as implemented by some
modern compilers is highly wasteful as in most code, the code
structure already ensures a single thread will be the first to
execute that initialization/construction,
often one of the threads in the compiler itself.
That locking by compilers seem to be the result of someone in the C++
ctte wanting to take over every OS feature that used to be out of
scope for system programming languages like C/C++.
It also makes it
unnecessarily harder to use the system compiler to implement the lower
level code that exists at a more fundamental / portable level than
silly textbook examples .
On Mon, 31 Mar 2025 19:42:48 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On 31.03.2025 17:01, Muttley@DastardlyHQ.org wrote:
On Mon, 31 Mar 2025 15:39:53 +0300
Paavo Helde <eesnimi@osa.pri.ee> wibbled:
On 31.03.2025 12:09, Muttley@DastardlyHQ.org wrote:
"If [initialization] is deferred, it strongly happens before any
non-initialization odr-use of any non-inline function or non-inline
variable defined in the same translation unit as the variable to be
initialized."
Who writes this stuff? Its borderline gibberish.
Keep in mind that the key thing that makes this seem like gibberish is
the use of precisely defined technical jargon, which is used for the
same reason that jargon is used in many other contexts: it has a more
precisely specified meaning than more informal wording would have had.
Key pieces of jargon: "strongly happens before", "non-initialization",
"strongly happens before" is genuine gibberish. Either something happens before
or it doesn't, the adverb is entirely superfluous.
"odr-use", "translation unit". If there's anything you don't understand
about that clause, it's probably based in unfamiliarity with such phrases.
I'm a native english speaker and had to read it more than once to understand it.
On 01.04.2025 10:26, Muttley@DastardlyHQ.org wrote:
On Mon, 31 Mar 2025 19:42:48 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On 31.03.2025 17:01, Muttley@DastardlyHQ.org wrote:
On Mon, 31 Mar 2025 15:39:53 +0300
Paavo Helde <eesnimi@osa.pri.ee> wibbled:
On 31.03.2025 12:09, Muttley@DastardlyHQ.org wrote:
"If [initialization] is deferred, it strongly happens before any
non-initialization odr-use of any non-inline function or non-inline
variable defined in the same translation unit as the variable to be
initialized."
Who writes this stuff? Its borderline gibberish.
Keep in mind that the key thing that makes this seem like gibberish is
the use of precisely defined technical jargon, which is used for the
same reason that jargon is used in many other contexts: it has a more
precisely specified meaning than more informal wording would have had.
Key pieces of jargon: "strongly happens before", "non-initialization",
"strongly happens before" is genuine gibberish. Either something happens >before
or it doesn't, the adverb is entirely superfluous.
Welcome to the 21-st century where out-of-sync CPU caches and pipelines
are the norm.
I'm a native english speaker and had to read it more than once to understand >> it.
Somehow I suspect you have not understood much. For understanding the >technical terms you need to read their definitions in the standard, not
try to guess their meaning by an isolated usage example.
Save your lame patronising for someone who cares and while you're at it
mene vittuun itseäsi.
Setting a lot of things up pre-main can lead to some issues... Waiting
on a connection before main is called seems rather odd to me, ect...
Am 01.04.2025 um 09:00 schrieb Chris M. Thomasson:
Setting a lot of things up pre-main can lead to some issues... Waiting
on a connection before main is called seems rather odd to me, ect...
If it does happen anyway it doesn't matter when it happens.
On 01.04.2025 11:57, Muttley@DastardlyHQ.org wrote:
Save your lame patronising for someone who cares and while you're at it
mene vittuun itseäsi.
Wrong language :-) Try again!
On 01.04.2025 11:57, Muttley@DastardlyHQ.org wrote:
Save your lame patronising for someone who cares and while you're
at it mene vittuun itseäsi.
Wrong language :-) Try again!
Welcome to the 21-st century where out-of-sync CPU caches and
pipelines are the norm.
On Tue, 1 Apr 2025 12:21:56 +0300
Paavo Helde <eesnimi@osa.pri.ee> wrote:
On 01.04.2025 11:57, Muttley@DastardlyHQ.org wrote:
=20=20
Save your lame patronising for someone who cares and while you're
at it mene vittuun itse=C3=A4si. =20
Wrong language :-) Try again!
=20
=20
He is probably using Google Translate. Google Translate does not know
how to say it in right language. So Muttley, being Muttley, had no
choice but to select a closest language in which Google translate does
know a translation.
On Tue, 1 Apr 2025 12:21:56 +0300
Paavo Helde <eesnimi@osa.pri.ee> wrote:
On 01.04.2025 11:57, Muttley@DastardlyHQ.org wrote:
=20=20
Save your lame patronising for someone who cares and while you're
at it mene vittuun itse=C3=A4si. =20
Wrong language :-) Try again!
=20
=20
He is probably using Google Translate. Google Translate does not know
how to say it in right language. So Muttley, being Muttley, had no
choice but to select a closest language in which Google translate does
know a translation.
On Tue, 1 Apr 2025 11:48:23 +0300
Paavo Helde <eesnimi@osa.pri.ee> wrote:
Welcome to the 21-st century where out-of-sync CPU caches and
pipelines are the norm.
It seems to me that saying that events are "strongly ordered" makes
sense only when "weakly ordered" and "unordered" are not the same.
In this particular case I don't see how exactly "weakly ordered"
differs from "unordered".
On 01.04.2025 13:20, Michael S wrote:
On Tue, 1 Apr 2025 11:48:23 +0300
Paavo Helde <eesnimi@osa.pri.ee> wrote:
Welcome to the 21-st century where out-of-sync CPU caches and
pipelines are the norm.
It seems to me that saying that events are "strongly ordered" makes
sense only when "weakly ordered" and "unordered" are not the same.
In this particular case I don't see how exactly "weakly ordered"
differs from "unordered".
The standard defines the terms "happens before", "simply happens
before", and "strongly happens before". The standard does not contain
One may wonder why we still need a 'main'. Everything in main can be
done in an static object.
Am 01.04.2025 um 12:00 schrieb Fred. Zwarts:
One may wonder why we still need a 'main'. Everything in main can be
done in an static object.
It's easier to define a main() since it needs less syntax than a class.
On 2025-03-31 16:29, James Kuyper wrote:...
"If it [initialization] is deferred, it strongly happens before any
non-initialization odr-use of any non-inline function or non-inline
variable defined in the same translation unit as the variable to be
initialized.47 It is implementation-defined in which threads and at
which points in the program such deferred dynamic initialization
occurs." (6.9.3.3p5).
Therefore, what you need to do is make sure that the object has been
initialized is to access it from a function defined in the same
translation unit.
The literalist reading of that wording fails miserably if a real world program uses a global constructor/initializer to cause some desired imperative effect outside the C++ runtime state. Examples include
setting the CPU clock frequency of a small system, outputting some kind
of welcome message to the human user etc. etc.
However treating the standard text as an imperfect description of traditional compiler techniques used for 2nd. Edition compilers makes
much more sense .
On Mon, 31 Mar 2025 19:42:48 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On 31.03.2025 17:01, Muttley@DastardlyHQ.org wrote:
On Mon, 31 Mar 2025 15:39:53 +0300
Paavo Helde <eesnimi@osa.pri.ee> wibbled:
On 31.03.2025 12:09, Muttley@DastardlyHQ.org wrote:
"If [initialization] is deferred, it strongly happens before any
non-initialization odr-use of any non-inline function or non-inline
variable defined in the same translation unit as the variable to be
initialized."
Who writes this stuff? Its borderline gibberish.
Keep in mind that the key thing that makes this seem like gibberish is
the use of precisely defined technical jargon, which is used for the
same reason that jargon is used in many other contexts: it has a more
precisely specified meaning than more informal wording would have had.
Key pieces of jargon: "strongly happens before", "non-initialization",
"strongly happens before" is genuine gibberish. Either something happens before
or it doesn't, the adverb is entirely superfluous.
It seems to me that saying that events are "strongly ordered" makes
sense only when "weakly ordered" and "unordered" are not the same.
In this particular case I don't see how exactly "weakly ordered"
differs from "unordered".
On 01.04.2025 10:26, Muttley@DastardlyHQ.org wrote:
On Mon, 31 Mar 2025 19:42:48 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On 31.03.2025 17:01, Muttley@DastardlyHQ.org wrote:
On Mon, 31 Mar 2025 15:39:53 +0300
Paavo Helde <eesnimi@osa.pri.ee> wibbled:
On 31.03.2025 12:09, Muttley@DastardlyHQ.org wrote:
"If [initialization] is deferred, it strongly happens before any
non-initialization odr-use of any non-inline function or non-inline
variable defined in the same translation unit as the variable to be
initialized."
Who writes this stuff? Its borderline gibberish.
Keep in mind that the key thing that makes this seem like gibberish is
the use of precisely defined technical jargon, which is used for the
same reason that jargon is used in many other contexts: it has a more
precisely specified meaning than more informal wording would have had.
Key pieces of jargon: "strongly happens before", "non-initialization",
"strongly happens before" is genuine gibberish. Either something happens before
or it doesn't, the adverb is entirely superfluous.
Terms are explicitly defined by the C++ standard precisely because their meaning cannot be inferred by using ordinary English to interpret the
words that make them up. Both "happens before" and "strongly happens
before" are separate pieces of C++ jargon, and the requirements for qualifying as "strongly happens before" are in fact stronger than those
for "happens before".
"An evaluation A happens before an evaluation B (or, equivalently, B
happens after A) if:
(10.1)— A is sequenced before B, or
(10.2)— A inter-thread happens before B.
The implementation shall ensure that no program execution demonstrates a cycle in the “happens before” relation. [Note: This cycle would
otherwise be possible only through the use of consume operations. — end note]" (6.9.2.1p10).
the first occurrence of "happens before" in that clause is in italics,
an ISO convention indicating that it is a piece of specialized jargon
whose definition is provided by the sentence in which it occurs. Note
that "sequenced before" and "inter-thread happens before" are two other pieces of standard-defined jargon.
"An evaluation A strongly happens before an evaluation D if, either
(12.1)— A is sequenced before D, or
(12.2)— A synchronizes with D, and both A and D are sequentially
consistent atomic operations (31.4), or
(12.3)— there are evaluations B and C such that A is sequenced before B,
B simply happens before C, and C is sequenced before D, or
(12.4)— there is an evaluation B such that A strongly happens before B,
and B strongly happens before D.
[Note: Informally, if A strongly happens before B, then A appears to be evaluated before B in all contexts. Strongly happens before excludes
consume operations. — end note]"
The first occurrence of "strongly happens before" in that clause is also italicized.
Note that "A is sequenced before D" would be sufficient to ensure that
both "A happens before D" and "A strongly happens before D" are true.
The difference between the two terms only shows up if A is not sequenced before D. In that case, at a minimum you must have "A inter-thread
happens before D", but is not synchronized with D.
For instance A inter-thread happens before D if it is dependency-ordered before D. (6.9.2.1p9). This could happen if A performs a release
operation on an atomic object M , and, in another thread, D performs a consume operation on M and reads the value written by A (6.9.2.1p8).
In that case, the requirements associated with "A happens before D" must
be met, but those associated with "A strongly happens before D" need not be.
Do you need an explanation of the parts of the above explanation that
use the terms "release" and "consume"? I have little experience with multi-threaded code - someone else might be able to explain those better
than I can.
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.
On 01.04.2025 10:26, Muttley@DastardlyHQ.org wrote:
On Mon, 31 Mar 2025 19:42:48 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On 31.03.2025 17:01, Muttley@DastardlyHQ.org wrote:
On Mon, 31 Mar 2025 15:39:53 +0300
Paavo Helde <eesnimi@osa.pri.ee> wibbled:
On 31.03.2025 12:09, Muttley@DastardlyHQ.org wrote:
"If [initialization] is deferred, it strongly happens before any
non-initialization odr-use of any non-inline function or
non-inline variable defined in the same translation unit as the
variable to be initialized."
Who writes this stuff? Its borderline gibberish.
Keep in mind that the key thing that makes this seem like
gibberish is the use of precisely defined technical jargon, which
is used for the same reason that jargon is used in many other
contexts: it has a more precisely specified meaning than more
informal wording would have had.
Key pieces of jargon: "strongly happens before",
"non-initialization",
"strongly happens before" is genuine gibberish. Either something
happens before or it doesn't, the adverb is entirely superfluous.
Terms are explicitly defined by the C++ standard precisely because
their meaning cannot be inferred by using ordinary English to
interpret the words that make them up. Both "happens before" and
"strongly happens before" are separate pieces of C++ jargon, and the requirements for qualifying as "strongly happens before" are in fact
stronger than those for "happens before".
"An evaluation A happens before an evaluation B (or, equivalently, B
happens after A) if:
(10.1)— A is sequenced before B, or
(10.2)— A inter-thread happens before B.
The implementation shall ensure that no program execution
demonstrates a cycle in the “happens before” relation. [Note: This
cycle would otherwise be possible only through the use of consume
operations. — end note]" (6.9.2.1p10).
the first occurrence of "happens before" in that clause is in italics,
an ISO convention indicating that it is a piece of specialized jargon
whose definition is provided by the sentence in which it occurs. Note
that "sequenced before" and "inter-thread happens before" are two
other pieces of standard-defined jargon.
"An evaluation A strongly happens before an evaluation D if, either
(12.1)— A is sequenced before D, or
(12.2)— A synchronizes with D, and both A and D are sequentially
consistent atomic operations (31.4), or
(12.3)— there are evaluations B and C such that A is sequenced before
B, B simply happens before C, and C is sequenced before D, or
(12.4)— there is an evaluation B such that A strongly happens before
B, and B strongly happens before D.
[Note: Informally, if A strongly happens before B, then A appears to
be evaluated before B in all contexts. Strongly happens before
excludes consume operations. — end note]"
The first occurrence of "strongly happens before" in that clause is
also italicized.
Note that "A is sequenced before D" would be sufficient to ensure that
both "A happens before D" and "A strongly happens before D" are true.
The difference between the two terms only shows up if A is not
sequenced before D. In that case, at a minimum you must have "A
inter-thread happens before D", but is not synchronized with D.
For instance A inter-thread happens before D if it is
dependency-ordered before D. (6.9.2.1p9). This could happen if A
performs a release operation on an atomic object M , and, in another
thread, D performs a consume operation on M and reads the value
written by A (6.9.2.1p8).
In that case, the requirements associated with "A happens before D"
must be met, but those associated with "A strongly happens before D"
need not be.
Do you need an explanation of the parts of the above explanation that
use the terms "release" and "consume"? I have little experience with multi-threaded code - someone else might be able to explain those
better than I can.
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.
On Tue, 1 Apr 2025 13:55:43 -0400...
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
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.
You probably paid attentions that the text is not crystal clear.
It looks like authors of the Standard invent their own terminology not
only when absolutely necessary but sometimes even when there exist established terms for the same things. To their defense, I could say
that in the branch of CS that is related to concurrency and parallelism
very few terms are 100% consensus.
I suspected that the difference between "strong happens before" and
"happens before" is somehow related to implied ordering due to
causality. After reading the text above my feeling changed from
suspicion to strong suspicion. But it is not yet a certainty.
Note that "A is sequenced before D" would be sufficient to ensure that
both "A happens before D" and "A strongly happens before D" are true.
The difference between the two terms only shows up if A is not sequenced before D. In that case, at a minimum you must have "A inter-thread
happens before D", but is not synchronized with D.
For instance A inter-thread happens before D if it is dependency-ordered before D. (6.9.2.1p9). This could happen if A performs a release
operation on an atomic object M , and, in another thread, D performs a consume operation on M and reads the value written by A (6.9.2.1p8).
"An evaluation A strongly happens before an evaluation D if, either:
(12.4)— there is an evaluation B such that A strongly happens before B,
and B strongly happens before D.
Do you need an explanation of the parts of the above explanation that
use the terms "release" and "consume"? I have little experience with >multi-threaded code - someone else might be able to explain those better
than I can.
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.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,029 |
| Nodes: | 10 (2 / 8) |
| Uptime: | 181:25:00 |
| Calls: | 13,337 |
| Calls today: | 4 |
| Files: | 186,574 |
| D/L today: |
5,241 files (1,443M bytes) |
| Messages: | 3,356,580 |