[cfe-dev] LibC++ v3.8 - Problems with ISO C wrapper headers
Martin J. O'Riordan via cfe-dev
cfe-dev at lists.llvm.org
Tue Jan 26 12:09:11 PST 2016
And C++ also requires that some parts of the interfaces from C are presented to C++ as functions - examples being ‘fpclassify’, ‘signbit’ etc. These have to be handled differently, and I think that the current LibC++ approach to these is good and maintains semantic compatibility with C.
I had intended to build a patch file of my changes today in case anyone is interested, but other things got me busy. I’ll do that tomorrow and attach it to this thread.
I think that it is a good idea to have LibC++ provide its own wrapper headers for the C headers. It is a logical place to deal with portability issues that arise when referring to C headers provided by newlib, uclibc or glibc (and other less well known implementations). The handling of these portability issues will mean that the ‘c’ prefixed C++ headers will need little or no alteration and just maintain the ‘std’ namespace.
MartinO
From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Craig, Ben via cfe-dev
Sent: 26 January 2016 19:42
To: cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] LibC++ v3.8 - Problems with ISO C wrapper headers
With regards to "where do we want to be", we shouldn't take the complete opposite approach and have the libcxx provide none of the C headers. At a minimum, we need a libcxx version of tgmath.h that hides the C version of tgmath.h. The generic macros from tgmath.h would play havoc with the overloaded functions in cmath.
Maybe all the other libcxx C headers could forward to the underlying C headers (or maybe not), but tgmath.h (and maybe others I'm forgetting) are special, and should not forward to the underlying C header.
On 1/25/2016 4:30 PM, Marshall Clow via cfe-dev wrote:
On Sat, Jan 23, 2016 at 12:46 PM, Howard Hinnant <howard.hinnant at gmail.com <mailto:howard.hinnant at gmail.com> > wrote:
[snip]
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.
While I bow to Howard's experience and to his recollection, I have to disagree with his characterization of Richard and Eric's posts as "mis-interpretation".
I believe that they have accurately reflected what is written in the standard.
But that's just a nit.
The real questions are - where do we want to be, and how can we get there?
(and let's not forget http://cplusplus.github.io/LWG/lwg-defects.html#2086) as well, which implies that there is no support for user-defined types in <cmath>.
-- Marhsall
_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160126/908840f8/attachment.html>
More information about the cfe-dev
mailing list