Greg Herlihy wrote:
> Nicola Musatti wrote:
> > Clause 20.6.6.2(2) of N2134 states:
> > Specializations of shared_ptr shall be convertible to bool, allowing
> > their use in boolean expressions and declarations in conditions. The
> > template parameter T of shared_ptr may be an incomplete type."
> >
> > The last sentence contradicts the last bullet of clause 17.4.3.6:
> > 2 In particular, the effects are undefined in the following cases:
> > [...]
> > - if an incomplete type (3.9) is used as a template argument when
> > instantiating a template component."
> >
> > Shouldn't the last sentence I quoted be changed to allow for
> > exceptions?
>
> As exceptions to what exactly?    17.4.3.6 essentially states that the
> Standard Library imposes no requirement on its template components
> vis-   -vis incomplete template type arguments - so how can an exception
> be needed where no rule exists in the first place?

Because later 20.6.6.2(2) expresses the contradicting requirement that
the specified semantics for shared_ptr be respected even if its
argument is an incomplete type.

"There are no requirements" contradicts "there is a requirement".

> Likewise, there can be no contradiction between a requirement for a
> specific case, and a nonexistent requirement for the general case. In
> particular, simply because the library defines no behavior for its
> template components when it comes to instantiating them with incomplete
> types - does nothing to prevent a template component from filling the
> void, and defining a behavior for itself - on its own.

The contradiction exists because    17.4.3.6 is expressed in an
universal way. The leeway allowed by the term "undefined behaviour" is
directed towards implementors, not other clauses of the standard. The
body expressing requirements or their absence is one and the same.

Cheers,
Nicola Musatti


---
[ 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                      ]

Nicola Musatti wrote:
> Hallo,
> Clause 20.6.6.2(2) of N2134 states:
> "Specializations of shared_ptr shall be CopyConstructible, Assignable,
> and LessThanComparable, allowing their use in standard containers.
> Specializations of shared_ptr shall be convertible to bool, allowing
> their use in boolean expressions and declarations in conditions. The
> template parameter T of shared_ptr may be an incomplete type."
>
> The last sentence contradicts the last bullet of clause 17.4.3.6:
> "1 In certain cases (replacement functions, handler functions,
> operations on types used to instantiate standard library template
> components), the C++ Standard Library depends on components supplied by
> a C++ program. If these components do not meet their requirements, the
> Standard places no requirements on the implementation.
> 2 In particular, the effects are undefined in the following cases:
> [...]
> - if an incomplete type (3.9) is used as a template argument when
> instantiating a template component."
>
> Shouldn't the last sentence I quoted be changed to allow for
> exceptions?

It probably should; or maybe 17.4.3.6/1 needs to have "unless
explicitly stated otherwise" at the end, consistent with 17.4.3.7/1.
You might want to submit a formal defect report for this.

---
[ 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                      ]

On Fri, 10 Nov 2006 11:14:25 CST, Nicola Musatti wrote:

>Because later 20.6.6.2(2) expresses the contradicting requirement that
>the specified semantics for shared_ptr be respected even if its
>argument is an incomplete type.
>
>"There are no requirements" contradicts "there is a requirement".

Without even looking at the standard, what would you expect from
similar text arrangements? Whoever writes such statements so far from
the points they apply to is looking for trouble. Sad to note that the
authors of this are exactly the persons that should be most aware of
the resulting issues: software engineers.

Oh, and I'm in a bad day, so I'll not comment about the conversion to
bool :-)

--
Gennaro Prota
[To mail me, remove any 'u' from the provided address]

---
[ 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                      ]

Gennaro Prota wrote:
> On Fri, 10 Nov 2006 11:14:25 CST, Nicola Musatti wrote:
>
> >Because later 20.6.6.2(2) expresses the contradicting requirement that
> >the specified semantics for shared_ptr be respected even if its
> >argument is an incomplete type.
> >
> >"There are no requirements" contradicts "there is a requirement".
>
> Without even looking at the standard, what would you expect from
> similar text arrangements? Whoever writes such statements so far from
> the points they apply to is looking for trouble. Sad to note that the
> authors of this are exactly the persons that should be most aware of
> the resulting issues: software engineers.

It is not clear which statement do you have in mind, 17.4.3.6 or
20.6.6.2. 17.4.3.6 has been carried over from C++98; at the time it was
written, no standard library component handled incomplete types, so a
blanket prohibition made sense. The alternative was to repeat it for
every standard template.

20.6.6.2 has been introduced when TR1 was integrated into the working
paper. Since it specifically refers to shared_ptr, it isn't clear where
else it should have gone.

---
[ 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                      ]

On Sun, 12 Nov 2006 10:23:38 CST, Peter Dimov wrote:

>20.6.6.2 has been introduced when TR1 was integrated into the working
>paper. Since it specifically refers to shared_ptr, it isn't clear where
>else it should have gone.

Yup. Then good luck with that statement and all the ones assuming that
a container is fixed-size.

--
Gennaro Prota
[To mail me, remove any 'u' from the provided address]

---
[ 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                      ]

Nicola Musatti wrote:
> Greg Herlihy wrote:
> > Nicola Musatti wrote:
> > > Clause 20.6.6.2(2) of N2134 states:
> > > Specializations of shared_ptr shall be convertible to bool, allowing
> > > their use in boolean expressions and declarations in conditions. The
> > > template parameter T of shared_ptr may be an incomplete type."

> > > The last sentence contradicts the last bullet of clause 17.4.3.6:
> > > 2 In particular, the effects are undefined in the following cases:
> > > [...]
> > > - if an incomplete type (3.9) is used as a template argument when
> > > instantiating a template component."

> > > Shouldn't the last sentence I quoted be changed to allow for
> > > exceptions?

> > As exceptions to what exactly?    17.4.3.6 essentially states that the
> > Standard Library imposes no requirement on its template components
> > vis-   -vis incomplete template type arguments - so how can an exception
> > be needed where no rule exists in the first place?

> Because later 20.6.6.2(2) expresses the contradicting requirement that
> the specified semantics for shared_ptr be respected even if its
> argument is an incomplete type.

> "There are no requirements" contradicts "there is a requirement".

> > Likewise, there can be no contradiction between a requirement for a
> > specific case, and a nonexistent requirement for the general case. In
> > particular, simply because the library defines no behavior for its
> > template components when it comes to instantiating them with incomplete
> > types - does nothing to prevent a template component from filling the
> > void, and defining a behavior for itself - on its own.

> The contradiction exists because    17.4.3.6 is expressed in an
> universal way. The leeway allowed by the term "undefined behaviour" is
> directed towards implementors, not other clauses of the standard. The
> body expressing requirements or their absence is one and the same.

Give them time.  The statement in    17.4.3.6 is basically
unchanged from the C++98 standard, where it was true.  The
exceptions have only been recently introduced, and I suspect
that impact simply hasn't propagated back to all of the places
it should.  (On the other hand, of course, it's good to mention
it, since without a written note, it's the sort of thing which
can easily slide through the cracks.)

--
James Kanze (Gabi Software)            email: james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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                      ]

Hallo,
Clause 20.6.6.2(2) of N2134 states:
"Specializations of shared_ptr shall be CopyConstructible, Assignable,
and LessThanComparable, allowing their use in standard containers.
Specializations of shared_ptr shall be convertible to bool, allowing
their use in boolean expressions and declarations in conditions. The
template parameter T of shared_ptr may be an incomplete type."

The last sentence contradicts the last bullet of clause 17.4.3.6:
"1 In certain cases (replacement functions, handler functions,
operations on types used to instantiate standard library template
components), the C++ Standard Library depends on components supplied by
a C++ program. If these components do not meet their requirements, the
Standard places no requirements on the implementation.
2 In particular, the effects are undefined in the following cases:
[...]
- if an incomplete type (3.9) is used as a template argument when
instantiating a template component."

Shouldn't the last sentence I quoted be changed to allow for
exceptions?

Cheers,
Nicola Musatti

---
[ 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                      ]

Nicola Musatti wrote:
> Clause 20.6.6.2(2) of N2134 states:
> Specializations of shared_ptr shall be convertible to bool, allowing
> their use in boolean expressions and declarations in conditions. The
> template parameter T of shared_ptr may be an incomplete type."
>
> The last sentence contradicts the last bullet of clause 17.4.3.6:
> 2 In particular, the effects are undefined in the following cases:
> [...]
> - if an incomplete type (3.9) is used as a template argument when
> instantiating a template component."
>
> Shouldn't the last sentence I quoted be changed to allow for
> exceptions?

As exceptions to what exactly?    17.4.3.6 essentially states that the
Standard Library imposes no requirement on its template components
vis-   -vis incomplete template type arguments - so how can an exception
be needed where no rule exists in the first place?

Likewise, there can be no contradiction between a requirement for a
specific case, and a nonexistent requirement for the general case. In
particular, simply because the library defines no behavior for its
template components when it comes to instantiating them with incomplete
types - does nothing to prevent a template component from filling the
void, and defining a behavior for itself - on its own.

After all, undefined behavior can obtain only in the absence of defined
behavior. So once std::tr1::shared_ptr defines what happens when it is
instantiated with an incomplete type (which turns out to be the same as
when instantiated with a complete type), then the behavior presumed
undefined becomes - on account of shared_ptr's own requirements -
undefined no more.

It may be interesting to note that a shared_ptr - just like any class
template - when instantiated with an incomplete type is nonetheless
itself a complete type. So it is in fact possble to instantiate a
Standard Library template component with an incomplete type -
indirectly - through a shared_ptr instantiation serving as the
intermediate type.

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                      ]

* Greg Herlihy:
> Nicola Musatti wrote:
>> Clause 20.6.6.2(2) of N2134 states:
>> Specializations of shared_ptr shall be convertible to bool, allowing
>> their use in boolean expressions and declarations in conditions. The
>> template parameter T of shared_ptr may be an incomplete type."
>>
>> The last sentence contradicts the last bullet of clause 17.4.3.6:
>> 2 In particular, the effects are undefined in the following cases:
>> [...]
>> - if an incomplete type (3.9) is used as a template argument when
>> instantiating a template component."
>>
>> Shouldn't the last sentence I quoted be changed to allow for
>> exceptions?
>=20
> As exceptions to what exactly? =A717.4.3.6 essentially states that the
> Standard Library imposes no requirement on its template components
> vis-=E0-vis incomplete template type arguments - so how can an exceptio=
n
> be needed where no rule exists in the first place?
>=20
> Likewise, there can be no contradiction between a requirement for a
> specific case, and a nonexistent requirement for the general case. In
> particular, simply because the library defines no behavior for its
> template components when it comes to instantiating them with incomplete
> types - does nothing to prevent a template component from filling the
> void, and defining a behavior for itself - on its own.

If that is the case then =A717.4.3.6/2 is 100% completely superflous (and=
=20
therefore misleading) and should be removed or replaced.

On the other hand, if it isn't superflous then it's incorrect wrt.=20
shared_ptr, possibly also wrt. auto_ptr, and should be removed or replace=
d.

So, in any case, superflous or incorrect, it should be removed or replace=
d.

--=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                      ]