Topic: Defect Report: ambiguity of "after the first statement of main" (3.6.2/3)


Author: "Greg Herlihy" <greghe@pacbell.net>
Date: Sat, 4 Nov 2006 14:02:32 CST
Raw View
"Alf P. Steinbach" wrote:
>    3.6.2/3 [basic.start.init], about initialization of non-local objects:
>
>    "If the initialization is deferred to some point in time after the
>    first statement of main, it shall occur before the first use of any
>    function or object defined in the same translation unit as the object
>    to be initialized."
>
> Presumably the intent is to allow deferred initialization, such as with
> a dynamically loaded library, e.g. MSVC's "delay load" mechanism.

I'm not so sure. It seems more likely to me that the purpose is to
support "lazy" initialization of objects - that is, to defer
initialization of an object until the program needs the object.

> A literal reading says however that this support is limited to /after/
> the first statement of main, i.e., the initialization cannot occur
> /during/ the first statement of main, which seems to be meaningless.

The granularity of the paragraph here is definitely odd. It would seem
that a description at the function call level (such as "after main has
been entered") would be more appropriate here than the current,
statement-level description. Unless the intent is to make a (very)
oblique point. I'm thinking that the reference to the "first statement"
of main may be implying that a program whose main() has no first
statement (that is, an empty main) would be exempt from the
initialization requirement being described. In other words, it is legal
for certain objects in a program not to have been initialized at all by
the time the program terminates.

> To avoid that one must interpret, on the basis of presumed intent.
>
> Suggested rewording:
>
>    "... some point in time after /execution of/ the first statement of
>    main /has started/, ..."

I think that any statement-level description is likely to remain
somewhat confusing. The reader may well wonder what is the significance
of the first statement of main. It is exempt from this requirement? Or
is it prohibited from referring to uninitialized objects? What exactly
is the Standard getting at here?

So, if there is no sigificance to the statement-level description, then
replacing it with a higher level description would be my suggestion.
And even if that the Standard does want to single out an empty main()
as some kind of an exception, then a higher level description would
still be able to do so explicitly:

"If the initialization is deferred to some point in time after main has
been entered (and main is not empty), then the initialization shall
occur before the first use..."

Greg


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: alfps@start.no ("Alf P. Steinbach")
Date: Mon, 30 Oct 2006 17:51:53 GMT
Raw View
=A73.6.2/3 [basic.start.init], about initialization of non-local objects:

   "If the initialization is deferred to some point in time after the
   first statement of main, it shall occur before the first use of any
   function or object defined in the same translation unit as the object
   to be initialized."

Presumably the intent is to allow deferred initialization, such as with=20
a dynamically loaded library, e.g. MSVC's "delay load" mechanism.

A literal reading says however that this support is limited to /after/=20
the first statement of main, i.e., the initialization cannot occur=20
/during/ the first statement of main, which seems to be meaningless.

To avoid that one must interpret, on the basis of presumed intent.

Suggested rewording:

   "... some point in time after /execution of/ the first statement of
   main /has started/, ..."

--=20
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]