From: Nikolay Ivchenkov on
On 17 May, 22:22, Scott Meyers <NeverR...(a)aristeia.com> wrote:
> 15.2/2 cannot stand on its own. The first sentence
> makes no sense without some kind of context that indicates when it applies.

I don't understand what do you mean.

> The
> obvious place to look for that context is 15.2/1, and 15.2/1 applies only to
> automatic objects. The fact that 15.2/3 explicitly mentions automatic objects
> reinforces the idea that 15.2 applies only to automatic objects, except where
> otherwise explicitly mentioned (e.g., the final sentence of 15.2/2).

15.2/2 begins with "An object", not with "An automatic object" nor
with "The object". So, I don't understand your reading.

> > Did you mean the sentence "Should a constructor for an element of an
> > automatic array throw an exception, only the constructed elements of
> > that array will be destroyed"? This is just redundant sentence, it was
> > removed as the resolution of the defect report 592:
> >http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#592
>
> There are two issues here. First, this issue doesn't change C++03, which is
> what we are discussing,

Redundant sentences do not cancel any other requirements.

> More
> interestingly, the resolution to DR592 removes the text that states that
> new-expression-based array elements are destroyed

I don't see this.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Kenneth 'Bessarion' Boyd on
On May 17, 1:22 pm, Scott Meyers <NeverR...(a)aristeia.com> wrote:

> There are two issues here. First, this issue doesn't change C++03, which is
> what we are discussing, although of course it can clarify its intent. More
> interestingly, the resolution to DR592 removes the text that states that
> new-expression-based array elements are destroyed, which makes the draft C++0x's
> 15.2/2 even weaker as regards the topic we are discussing. In draft C++0x (the
> FCD), 5.3.5/7 says that the deallocation function is called even if an exception
> is thrown,

In a note (e.g., this detail is intended to be derivable anyway even
if 5.3.5/7 is deleted from the FCD). I can't quickly derive this note
in terms of a "explicit requirements" reading of the standard, as
opposed to my preferred "maximal compliance" reading.

> something that is reiterated in 15.2/2. However, 5.3.5/6 is where
> the implicit loop destructing array elements is specified, yet this behavior is
> *not* reiterated in 15.2/2. This suggests to me that 5.3.5/6 is supposed to be
> abandoned in the event of an exception.

Yet abandoning the destructor calls for the remaining objects is
equivalent to their lifetime *not* ending, which contraindicates
calling the deallocation function.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Kenneth 'Bessarion' Boyd on
On May 18, 10:55 am, "Kenneth 'Bessarion' Boyd" <zaim...(a)zaimoni.com>
wrote:
> On May 17, 1:22 pm, Scott Meyers <NeverR...(a)aristeia.com> wrote:
>
> > There are two issues here. First, this issue doesn't change C++03, which is
> > what we are discussing, although of course it can clarify its intent. More
> > interestingly, the resolution to DR592 removes the text that states that
> > new-expression-based array elements are destroyed, which makes the draft C++0x's
> > 15.2/2 even weaker as regards the topic we are discussing. In draft C++0x (the
> > FCD), 5.3.5/7 says that the deallocation function is called even if an exception
> > is thrown,
>
> In a note (e.g., this detail is intended to be derivable anyway even
> if 5.3.5/7 is deleted from the FCD). I can't quickly derive this note
> in terms of a "explicit requirements" reading of the standard, as
> opposed to my preferred "maximal compliance" reading.

Insufficient proofreading: 15.2 is what allows 5.3.5/7 to exist as a
note.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]