[cfe-dev] LibC++ v3.8 - Problems with ISO C wrapper headers

[Richard Smith via cfe-dev]

On Jan 23, 2016 9:47 PM, "Howard Hinnant via cfe-dev" <
cfe-dev at lists.llvm.org> wrote:
>
> It was *never* intended to add the C++ overloads to the global namespace.
>
> I can now see how that is indeed what is written.  Believe me, it was the
farthest thought from *anyone’s* mind when these words were voted in.  This
is demonstrable by looking at the issue which introduced these words:
>
> http://cplusplus.github.io/LWG/lwg-defects.html#456
>
> The description includes:
>
> > The C headers are often beyond the direct control of C++ implementors.
In some organizations, it's all they can do to get a few #ifdef __cplusplus
tests added. Third-party library vendors can perhaps wrap the C headers.
But neither of these approaches supports the drastic restructuring required
by the C++ Standard. As a result, it is still widespread practice to ignore
this conformance requirement, nearly seven years after the committee last
debated this topic. Instead, what is often implemented is:
> >
> >       • Including the header <xxx.h> declares a C name in the global
namespace.
> >       • Including the header <cxxx> declares a C name in the global
namespace (effectively by including <xxx.h>), then imports it into
namespace std with an individual using declaration.
>
> This was the issue:  C++ lib vendors *not having control* over the C
headers.  The furthest thing from our mind was adding *more* stuff to the C
headers!
>
> Martin is 100% correct as far as historical intent goes.  The
mis-interpretation of these words by Richard and Eric is evidence that the
standard remains buggy in this area.

Thanks, Howard, it's useful to know how we got here.

For what it's worth, though, I think the words we have in the standard now
do say the best thing for users, striking a balance between C compatibility
and bug avoidance (even if they don't match the historical intent), and
would argue against changing them -- especially as we do now have an
implementation that follows them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160123/90159357/attachment.html>