[cfe-dev] deque<Incomplete Type> support

[Zhihao Yuan]

On Tue, Nov 12, 2013 at 3:14 PM, Dimitry Andric <dimitry at andric.com> wrote:
> 2) In particular, the effects are undefined in the following cases:

Of course it's undefined, but implement something in a defined way
does not make an implementation non-confirming.  Otherwise, all
compilers with well-defined signed overflow behavior are non-confirming.

> 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.

Two months ago one of my crappy program ran into a linker issue with
libstdc++'s __normal_iterator's operator+.  Of course standard says nothing
about whether implementation defined iterator types' operator+ can or can not
odr-use its argument, but they still fixed this.  What does that mean?
Improving QoI is nothing shame.  No matter how many user can benefit from
it, placing unneeded barrier on harmless issue should not be recommended.

> 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. :)

libstdc++ regards failing to support such use as *regressions* -- this
is a feature, and can be safely addressed without people propose it.

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

No matter you see an reason or not, an issue like this has been
identified as bug and being *fixed* before:

  http://llvm.org/bugs/show_bug.cgi?id=9351


-- 
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/