Topic: Small problem with Draft TR1 (N1660=04-0100)
Author: technews@kangaroologic.com ("Jonathan Turkanis")
Date: Wed, 15 Sep 2004 17:36:01 GMT Raw View
Dear all,
Section 1.1 of the Draft TR states: "Unless otherwise specified, the whole
of the ISO C++ Standard Library introduction (clause 17) is included into this
Technical Report by reference." This would include 17.4.3.6/2 item 5, which
makes it undefined behavior to instantiate a library template with an incomplete
type.
However, one of the virtues of shared_ptr is supposed to be that it can be
instantiated with incomplete types.(See "A Proposal to Add General Purpose Smart
Pointers to the Library Technical Report", N1431=03-0013 at
http://tinyurl.com/2zp83).
Furthermore, some of the statements of preconditions in the type traits
proposal (Clause 4) require that the template arguments be complete (e.g., is
pod, 4.3.4/5) while others don't (e.g, is_const, 4.3.4/2). (See also 4.6/10).
I don't see any indication that 17.4.3.6/2 item 5 of the standard has not
been
included by reference. I think TR1, perhaps in section 1.1, should state that
clause 17 of the standard is included with the following modification to
17.4.3.6/2.
"- if an incomplete type (3.9) is used as a template argument when
instantiating a template component."
should be replaced by
"- if an incomplete type (3.9) is used as a template argument when
instantiating a template component, unless otherwise specified"
Alternatively,
"In particular, the effects are undefined in the following cases"
could be replaced by
"In particular, the effects are undefined in the following cases, unless
otherwise specified"
Best Regards,
Jonathan
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: petebecker@acm.org (Pete Becker)
Date: Thu, 16 Sep 2004 22:19:51 GMT Raw View
Jonathan Turkanis wrote:
>
> Section 1.1 of the Draft TR states: "Unless otherwise specified, the whole
> of the ISO C++ Standard Library introduction (clause 17) is included into this
> Technical Report by reference." This would include 17.4.3.6/2 item 5, which
> makes it undefined behavior to instantiate a library template with an incomplete
> type.
>
> However, one of the virtues of shared_ptr is supposed to be that it can be
> instantiated with incomplete types.
Already covered in a defect report.
>
> Furthermore, some of the statements of preconditions in the type traits
> proposal (Clause 4) require that the template arguments be complete (e.g., is
> pod, 4.3.4/5) while others don't (e.g, is_const, 4.3.4/2). (See also 4.6/10).
>
> I don't see any indication that 17.4.3.6/2 item 5 of the standard has not
> been
> included by reference. I think TR1, perhaps in section 1.1, should state that
> clause 17 of the standard is included with the following modification to
> 17.4.3.6/2.
>
> "- if an incomplete type (3.9) is used as a template argument when
> instantiating a template component."
>
> should be replaced by
>
> "- if an incomplete type (3.9) is used as a template argument when
> instantiating a template component, unless otherwise specified"
Unnecessary. The specific controls over the general.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: technews@kangaroologic.com ("Jonathan Turkanis")
Date: Fri, 17 Sep 2004 00:20:05 GMT Raw View
"Pete Becker" <petebecker@acm.org> wrote in message
news:4148E2D6.51FAB23C@acm.org...
> Jonathan Turkanis wrote:
> >
> > Section 1.1 of the Draft TR states: "Unless otherwise specified, the
whole
> > of the ISO C++ Standard Library introduction (clause 17) is included into
this
> > Technical Report by reference." This would include 17.4.3.6/2 item 5, which
> > makes it undefined behavior to instantiate a library template with an
incomplete
> > type.
> >
> > However, one of the virtues of shared_ptr is supposed to be that it can
be
> > instantiated with incomplete types.
>
> Already covered in a defect report.
Good.
> > Furthermore, some of the statements of preconditions in the type traits
> > proposal (Clause 4) require that the template arguments be complete (e.g.,
is
> > pod, 4.3.4/5) while others don't (e.g, is_const, 4.3.4/2). (See also
4.6/10).
> >
> > I don't see any indication that 17.4.3.6/2 item 5 of the standard has
not
> > been
> > included by reference. I think TR1, perhaps in section 1.1, should state
that
> > clause 17 of the standard is included with the following modification to
> > 17.4.3.6/2.
> >
> > "- if an incomplete type (3.9) is used as a template argument when
> > instantiating a template component."
> >
> > should be replaced by
> >
> > "- if an incomplete type (3.9) is used as a template argument when
> > instantiating a template component, unless otherwise specified"
>
> Unnecessary. The specific controls over the general.
You mean it's unnecessary in light of the defect report? I understand that
adding language explicitly permitting shared_ptr's template argument to be
incomplete at the point of instantiation would fall under the "unless otherwise
specified" exception I cited from TR1.
But this won't hold if parts or all of TR1 -- in one form or other -- are
incorporated into a future version of the standard. Shouldn't it be noted that
the fifth item of 17.4.3.6/2 will need to be modified?
Best Regards,
Jonathan
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: petebecker@acm.org (Pete Becker)
Date: Fri, 17 Sep 2004 13:58:38 GMT Raw View
Jonathan Turkanis wrote:
>
> > > "- if an incomplete type (3.9) is used as a template argument when
> > > instantiating a template component, unless otherwise specified"
> >
> > Unnecessary. The specific controls over the general.
>
> You mean it's unnecessary in light of the defect report?
No, I mean only that the phrase "unless otherwise specified" is rarely,
if ever, needed. It merely states the obvious.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: technews@kangaroologic.com ("Jonathan Turkanis")
Date: Sat, 18 Sep 2004 00:04:44 GMT Raw View
"Pete Becker" <petebecker@acm.org> wrote in message
news:414AD5B6.4F4C5659@acm.org...
> Jonathan Turkanis wrote:
> >
> > > > "- if an incomplete type (3.9) is used as a template argument when
> > > > instantiating a template component, unless otherwise specified"
> > >
> > > Unnecessary. The specific controls over the general.
> >
> > You mean it's unnecessary in light of the defect report?
>
> No, I mean only that the phrase "unless otherwise specified" is rarely,
> if ever, needed. It merely states the obvious.
I understand. What is your view, then, on library issue 397, also relating to
17.4? (I'm looking at revision 31.) Basically,
- 17.4.4.8/5 says that the destructors of standard library components don't
throw exceptions, while
- 27.6.2.3/4 and 27.6.2.6/7, taken together, imply that basic_ostream::senty's
destructor can throw in certain circumstances
The bracketed notes under "Proposed resolution" say "... We're leaning toward
changing clause 17: putting in an "unless otherwise specified" clause...."
In your view, that change would be unnecessary?
Best Regards,
Jonathan
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: petebecker@acm.org (Pete Becker)
Date: Sat, 18 Sep 2004 08:13:10 GMT Raw View
Jonathan Turkanis wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:414AD5B6.4F4C5659@acm.org...
> > No, I mean only that the phrase "unless otherwise specified" is rarely,
> > if ever, needed. It merely states the obvious.
>
> I understand. What is your view, then, on library issue 397, also relating to
> 17.4? (I'm looking at revision 31.) Basically,
>
> - 17.4.4.8/5 says that the destructors of standard library components don't
> throw exceptions, while
> - 27.6.2.3/4 and 27.6.2.6/7, taken together, imply that basic_ostream::senty's
> destructor can throw in certain circumstances
>
> The bracketed notes under "Proposed resolution" say "... We're leaning toward
> changing clause 17: putting in an "unless otherwise specified" clause...."
>
> In your view, that change would be unnecessary?
>
Good example. I overstated my point. I was giving generic advice about
technical writing. Too many technical writers write like what they've
read, with the result that cliches proliferate. "unless otherwise
specified" alerts you that there are situations where a requirement
doesn't apply. For statements like the one about destructors, knowing
that there are exceptions is critical to correct program design. For
statements like the one about incomplete types knowing that there are
exceptions is far less important; using something that doesn't follow
the rule doesn't affect other code.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]