Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #122048 > unrolled thread
| Started by | Muttley@DastardlyHQ.org |
|---|---|
| First post | 2025-03-30 08:57 +0000 |
| Last post | 2025-04-02 10:29 +0200 |
| Articles | 20 on this page of 78 — 13 participants |
Back to article view | Back to comp.lang.c++
Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-03-30 08:57 +0000
Re: Pre-main construction order in modules Richard Damon <richard@damon-family.org> - 2025-03-30 07:21 -0400
Re: Pre-main construction order in modules Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-30 16:22 +0000
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-30 19:56 +0200
Re: Pre-main construction order in modules Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-30 18:00 +0000
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-30 10:38 -0400
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-03-30 15:30 +0000
Re: Pre-main construction order in modules Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-30 15:59 +0000
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-03-30 16:09 +0000
Re: Pre-main construction order in modules Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-30 16:17 +0000
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-03-30 16:23 +0000
Re: Pre-main construction order in modules Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-30 16:26 +0000
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-03-31 08:20 +0000
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-31 10:46 +0200
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-03-31 11:56 +0300
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-31 11:11 +0200
Re: Pre-main construction order in modules Richard Damon <richard@damon-family.org> - 2025-03-31 07:25 -0400
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-03-31 15:26 +0300
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-31 14:32 +0200
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-03-31 15:44 +0300
Re: Pre-main construction order in modules Jakob Bohm <egenagwemdimtapsar@jbohm.dk> - 2025-04-01 06:06 +0200
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-01 08:41 +0200
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-04-01 11:41 +0300
Re: Pre-main construction order in modules Richard Damon <richard@damon-family.org> - 2025-03-31 07:22 -0400
Re: Pre-main construction order in modules Richard Damon <richard@damon-family.org> - 2025-03-30 15:05 -0400
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-30 19:58 +0200
Re: Pre-main construction order in modules Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-30 18:02 +0000
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-30 20:05 +0200
Re: Pre-main construction order in modules Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-30 18:07 +0000
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-30 20:08 +0200
Re: Pre-main construction order in modules Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-30 18:11 +0000
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-30 20:17 +0200
Re: Pre-main construction order in modules Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-30 18:20 +0000
Re: Pre-main construction order in modules Richard Damon <richard@damon-family.org> - 2025-03-30 15:01 -0400
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-30 22:15 +0200
Re: Pre-main construction order in modules "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-30 13:57 -0700
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-31 07:37 +0200
Re: Pre-main construction order in modules "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-31 21:54 -0700
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-01 08:41 +0200
Re: Pre-main construction order in modules "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-01 00:00 -0700
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-01 11:42 +0200
Re: Pre-main construction order in modules "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-04-01 12:00 +0200
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-01 14:16 +0200
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-01 16:03 +0200
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-03-31 11:49 +0300
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-03-31 09:09 +0000
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-03-31 15:39 +0300
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-03-31 14:01 +0000
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-03-31 20:06 +0300
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-31 19:42 -0400
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-04-01 07:26 +0000
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-04-01 11:48 +0300
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-04-01 08:57 +0000
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-04-01 12:21 +0300
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-04-01 10:08 +0000
Re: Pre-main construction order in modules Michael S <already5chosen@yahoo.com> - 2025-04-01 13:12 +0300
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-04-01 10:23 +0000
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-04-01 10:27 +0000
Re: Pre-main construction order in modules Michael S <already5chosen@yahoo.com> - 2025-04-01 13:20 +0300
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-04-01 13:33 +0300
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-04-01 10:48 +0000
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-01 14:37 -0400
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-01 14:37 -0400
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-01 14:32 -0400
Re: Pre-main construction order in modules "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-01 12:39 -0700
Re: Pre-main construction order in modules Michael S <already5chosen@yahoo.com> - 2025-04-01 23:26 +0300
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-01 19:08 -0400
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-01 22:55 -0400
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-04-02 07:34 +0000
Re: Pre-main construction order in modules scott@slp53.sl.home (Scott Lurndal) - 2025-03-31 14:15 +0000
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-31 16:47 +0200
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-31 10:29 -0400
Re: Pre-main construction order in modules Jakob Bohm <egenagwemdimtapsar@jbohm.dk> - 2025-04-01 06:29 +0200
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-01 13:55 -0400
Re: Pre-main construction order in modules Michael S <already5chosen@yahoo.com> - 2025-04-01 23:10 +0300
Re: Pre-main construction order in modules Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-01 14:20 -0700
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-01 18:57 -0400
Re: Pre-main construction order in modules David Brown <david.brown@hesbynett.no> - 2025-04-02 10:29 +0200
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-04-01 11:42 +0200 |
| Message-ID | <vsgcdv$2pknn$1@raubtier-asyl.eternal-september.org> |
| In reply to | #122099 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-04-01 12:00 +0200 |
| Message-ID | <vsgdg8$2nddr$1@dont-email.me> |
| In reply to | #122105 |
Op 01.apr.2025 om 11:42 schreef Bonita Montero: > 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. > One may wonder why we still need a 'main'. Everything in main can be done in an static object.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-04-01 14:16 +0200 |
| Message-ID | <vsglej$32t2m$1@raubtier-asyl.eternal-september.org> |
| In reply to | #122106 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-04-01 16:03 +0200 |
| Message-ID | <vsgrn7$39544$1@raubtier-asyl.eternal-september.org> |
| In reply to | #122114 |
Am 01.04.2025 um 14:16 schrieb Bonita Montero: > 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. And more important: there might be other global objects which are initialized after this pseudo-"main()", but which are needed before.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2025-03-31 11:49 +0300 |
| Message-ID | <vsdkuj$3rhjh$1@dont-email.me> |
| In reply to | #122051 |
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. IIRC this clause in the standard (that it's implementation-defined which static initializations occur before the start of main()) was introduced in C++11 when they got around to recognize the existence of shared libraries. To make the global static variables usable there is now another clause ([basic.start.dynamic]): "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." In practice, it means it is a bad idea to expose global static variables directly from a TU or from a shared library, because it is tricky to tell when and if the exported address becomes safe to use, and this may change on a whim by the compiler version and optimization levels, etc. I think I have seen a compiler optimizing away the whole TU when it only contained static data and no functions with external linkage.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2025-03-31 09:09 +0000 |
| Message-ID | <vsdm3d$3srps$1@dont-email.me> |
| In reply to | #122077 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2025-03-31 15:39 +0300 |
| Message-ID | <vse2ep$8iai$2@dont-email.me> |
| In reply to | #122079 |
On 31.03.2025 12:09, Muttley@DastardlyHQ.org wrote: > 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? The standard does not talk specifically about dynamic libraries, so the same rules apply for the main program. This means the same quote you snipped is relevant to your myobj as well: "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.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2025-03-31 14:01 +0000 |
| Message-ID | <vse775$er2o$1@dont-email.me> |
| In reply to | #122085 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2025-03-31 20:06 +0300 |
| Message-ID | <vsei21$puh7$1@dont-email.me> |
| In reply to | #122087 |
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. > >> 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? The constructor of the object is not guaranteed to run if the object nor anything else in its TU is not accessed from outside. It means the socket might not be opened. And no, trying to access the object via a network socket does not qualify as "non-initialization odr-use" of the object, as far as the C++ standard is concerned ;-)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-03-31 19:42 -0400 |
| Message-ID | <vsf99o$1hbqv$1@dont-email.me> |
| In reply to | #122087 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2025-04-01 07:26 +0000 |
| Message-ID | <vsg4fq$2hn25$1@dont-email.me> |
| In reply to | #122092 |
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. I feel sorry for people who's native language is not english trying to understand this crap. Yes this sort of language is similar to legalese, but with law it usually only applies to a given country so will be in the language of that country.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2025-04-01 11:48 +0300 |
| Message-ID | <vsg98n$2m576$2@dont-email.me> |
| In reply to | #122100 |
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. >> "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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2025-04-01 08:57 +0000 |
| Message-ID | <vsg9pa$2n2oi$1@dont-email.me> |
| In reply to | #122102 |
On Tue, 1 Apr 2025 11:48:23 +0300 Paavo Helde <eesnimi@osa.pri.ee> wibbled: >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. Are you smoking something illegal? You're making less sense than that paragraph. >> 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.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2025-04-01 12:21 +0300 |
| Message-ID | <vsgb7k$2odd6$1@dont-email.me> |
| In reply to | #122103 |
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!
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2025-04-01 10:08 +0000 |
| Message-ID | <vsgduq$2r7hp$1@dont-email.me> |
| In reply to | #122104 |
On Tue, 1 Apr 2025 12:21:56 +0300 Paavo Helde <eesnimi@osa.pri.ee> wibbled: >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! > Oh well, I'm sure you can use google translate too.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-04-01 13:12 +0300 |
| Message-ID | <20250401131247.000068de@yahoo.com> |
| In reply to | #122104 |
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: > > > > Save your lame patronising for someone who cares and while you're > > at it mene vittuun itseäsi. > > Wrong language :-) Try again! > > 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.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2025-04-01 10:23 +0000 |
| Message-ID | <vsgeqs$2s79d$1@dont-email.me> |
| In reply to | #122108 |
On Tue, 1 Apr 2025 13:12:47 +0300 Michael S <already5chosen@yahoo.com> wibbled: >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 >> > Save your lame patronising for someone who cares and while you're >> > at it mene vittuun itse=C3=A4si. =20 >>=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.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2025-04-01 10:27 +0000 |
| Message-ID | <vsgf1p$2semn$1@dont-email.me> |
| In reply to | #122108 |
On Tue, 1 Apr 2025 13:12:47 +0300 Michael S <already5chosen@yahoo.com> wibbled: >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 >> > Save your lame patronising for someone who cares and while you're >> > at it mene vittuun itse=C3=A4si. =20 >>=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. Going by his name I assumed he was finnish but looking at his address now I suspect estonian. Right ballpark.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-04-01 13:20 +0300 |
| Message-ID | <20250401132044.00000e61@yahoo.com> |
| In reply to | #122102 |
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".
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2025-04-01 13:33 +0300 |
| Message-ID | <vsgfe7$2qk09$1@dont-email.me> |
| In reply to | #122109 |
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 phrases "strongly ordered" or "weakly ordered".
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.c++
csiph-web