[cfe-dev] deque<Incomplete Type> support

[Dimitry Andric]

On 12 Nov 2013, at 20:47, Zhihao Yuan <zy at miator.net> wrote:
> On Tue, Nov 12, 2013 at 2:22 PM, Dimitry Andric <dimitry at andric.com> wrote:
>> On 12 Nov 2013, at 18:35, Zhihao Yuan <zy at miator.net> wrote:
>>> is broken, while libstdc++ supports it.
>>> 
>>> struct A {
>>>   deque<A> q;
>>> };
>>> 
>>> I regard this as a QoI issue, and a somewhat important one.
>>> 1. vector, map support it; 2. no workaround unless discarding
>>> user's intended API.
>> 
>> This is not allowed by the standard, why would you want to promote using undefined features?  Better get libstdc++ to conform. :-)
> 
> AFAIK, the standard said nothing about whether and when to allow it,
> that does not mean the standard do not allow it.

The standard says it is undefined (ergo, don't rely on it).  Quoting the C++11 standard, part 17.6.4.8, paragraph 2:

2) In particular, the effects are undefined in the following cases:
   [ ... rest of list elided ...]
   —  if an incomplete type (3.9) is used as a template argument when instantiating a template component, unless specifically allowed for that component.

In previous standards, the "unless specifically allowed for that component" part was not even there.  But none of the components I could find for which it *is* specifically allowed in C++11 are containers:

20.2.4 Function template declval
20.7.1 Class template unique_ptr
20.7.1.1 Default deleters
20.7.2.2 Class template shared_ptr
20.7.2.3 Class template weak_ptr
20.7.2.4 Class template enable_shared_from_this

See also this Dr Dobbs article from 2002 (!) for some more in-depth information:

http://www.drdobbs.com/the-standard-librarian-containers-of-inc/184403814


> This is a difference:
> if an implementation allows it, it's not non-confirming, and user can
> benefit from it, and we already have those users, as reported to
> FreeBSD -- the "pan" news client.

The pan program is actually one of the first of many C++ programs in FreeBSD's ports collection that encountered this specific problem, so I don't think this is enough reason to change libc++'s internal implementation details just for it.  (Note that we can currently compile Qt, almost all of KDE and Libre/OpenOffice with clang and libc++, which are C++ codebases much more complicated and extensive than a news reader.)

My opinion is that the pan developers are using the C++ standard library incorrectly, and the argument "but it works with gcc" is simply rather weak. :)

That said, I see no reason that pan can't be fixed.  It should not need any dramatic changes.

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131112/0f149bc3/attachment.sig>