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

Sat Jan 23 14:15:48 PST 2016

Sorry for being out of synch (its Saturday and after 10pm in Ireland), I was replying (verbosely) to an earlier message in this thread when these replies arrive (USA is awake and alive); but in response to the comment below, I agree 100% with Richard’s observation that this is a problem.  But what is really needed is that we need to teach programmers to use ‘<cmath>’ and not ‘<math.h>’ in their C++ programs, and the ‘std::’ names not the ‘::’ names, not that we make ‘<math.h>’ more cuddly - it’s the programmer’s problem if they are not writing their code properly, not the compiler or its libraries.

If anything, this is a programmer pattern aberration that the static analysers should look for and diagnose (perhaps they do already?).  And with this moving closer to becoming a standard part of the LLVM/CLang offering, I think that it would be a good place to put such precision and performances concerns. 

>From a performance perspective (which the Standard does not speak of), overloading means that the implementation can choose the most optimal algorithm suited to the data type - this is WHY I love C++ - and it also why the committee chose to overload the C Standard names, though within its own namespace so as not to interfere with the understood and expected semantics of C programmers.  Every time I have won-over a C programmer to doing things the C++ way, it is because I have been able to demonstrate a performance advantage to doing so.  Using ‘std::fabs’ etc. after including ‘<cmath>’ versus including ‘<math.h>’ proves this to them; but from the perspective of semantics, I do not think that it was ever the intent of the C++ Standards committee to alter the semantic meaning of naively using C headers in a C++ program, even if that meant they suffered silent problems such as precision.  It was intended that such programs would do exactly what they would have done in C.  If they adapt their program to use C++ properly, these things don’t’ happen and they can reap the advantages of adapting their code to being C++ and not C.  Bjarne Stroustrup famously stated a very long time ago “C++, as close to C as possible, but no closer”.

The headers ‘<iostream>’, ‘<cstdio>’ and ‘<stdio.h>’ really show how the committee tried very hard to maintain semantic compatibility between C and C++, right down to details such as “tied streams” and automatic flushing of ‘stdout’ (implied, not stated).  This was hard to word, but for the most part the committee got it right.

Another example is ‘isnan’.  It is not even semantically valid to attempt to convert a ‘float’ NaN to a ‘double’ NaN in order to call ‘bool isnan(double)’, hence the use of implementation defined MACROS (ugh) in C and overloaded functions in C++.

And Richard, you are absolutely right - that is “what the words” in the Standard say, but I genuinely believe that this is a bug in the Standard and not its intent.  We need to temper the implementations with the intent, and get the Standard (C++’17) to fix the words.

Please ignore ‘__fp16’, it is not really relevant since it is not a Standard data type, though I would love to see ‘short float’ someday, and have it incorporated as a first class citizen into the rules for “Usual Arithmetic Conversions”, “Standard Conversions” and “Overloading”.  It’s not there yet, but it’s importance is growing.  I would have liked to have used ‘int’ in my example, but the bug in the new headers did not make this ambiguous, it just quietly chose a different function.

            MartinO

From: metafoo at gmail.com [mailto:metafoo at gmail.com] On Behalf Of Richard Smith
Sent: 23 January 2016 21:23
To: Howard Hinnant <howard.hinnant at gmail.com>
Cc: Martin J. O'Riordan <Martin.ORiordan at movidius.com>; Marshall Clow <mclow.lists at gmail.com>; Clang Dev <cfe-dev at lists.llvm.org>; Eric Fiselier <eric at efcs.ca>
Subject: Re: [cfe-dev] LibC++ v3.8 - Problems with ISO C wrapper headers

We have evidence from the field that the lack of overloads of ::fabs causes (usually hard to detect precision loss) bugs. This thread concerns a nonstandard extension that I would imagine is only used by a small minority of libc++ users, and we can handle it by supporting that extension directly in libc++. (Doing so would fix a couple of other issues: wrong return type, no support for __fp16 in std::fabs.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160123/5b0c471e/attachment.html>