Re: [boost] LWG reaction: Header <cstdint>

From: Kevin Lynch (krlynch_at_[hidden])
Date: 2001-11-05 16:06:26

Howard Hinnant wrote:
> 
> On Monday, November 5, 2001, at 11:53  AM, Kevin Lynch wrote:
> 
> > I'm certainly willing to post something to the newsgroup along the lines
> > of what I posted to the boost list; Are there any other thoughts (particularly
> > about math related issues) about migrating features from C99 into C++
> > that people haven't posted yet?  
> 
> Both C90 and C99 handle integral types passed to math functions more
> gracefully than does C++98.  For example:
> 
>         double x = cos(1);  // ambiguous error in C++
>                          // legal C90 and C99
>
> Without at this time proposing a C++ solution, it would be nice if C++
> also gracefully handled integral arguments to the math functions.
> 
> -Howard
> 

I have to apologize, but I'm not quite sure if you are advocating a
change that I put something into a post or not; regardless of your
answer, it's probably that I'm misreading something that you said in
your mail.

Certainly, I agree with you that C99 in particular provides a more
"graceful" handling of integral arguments to the math functions than
does C++ (particularly through tgmath.h as you mentioned, and which I
cut out above); however, I would argue that, in almost all cases, the
C++ method is the "correct" method, whereas the C method is incorrect,
and perhaps even dangerous (I can't actually think of any benefits of
the C approach over the C++ approach in regards to numerics).  While
there are perhaps a few isolated exceptions, it has been my experience
that calling one of the standard math functions with integral arguments
is almost always an error on the part of the programmer, and in C at
least, it is the type of error that can be very very difficult to track
down, because the compiler doesn't have to tell you that you "might" be
doing something wrong.  I can't think of any case where something like

int i = 1;
double d = sin(i);

would be anything but an error in coding, and if you are doing it with a
literal, it doesn't take any real additional effort to write

sin(1.);  than to write  sin(1);

(OK, I'll grant that something like double d = sqrt(2); is occassionally
useful, and certainly true that pow(int,int) can be very useful for
smaller arguments at times, but it isn't that much harder to write

double d = sqrt(2.);  or even

int i;
// intervening code which sets i ...
double d = sqrt(static_cast<double>(i));

since this is a fairly unusual usage; also, the pow situation could (and
probably should) be solved by an overload)

So, unless I'm misunderstanding something, I really don't see that it is
useful to make any changes to the library or language that would loosen
the type system in this way to solve what I see as a nonexistent issue. 
But again, I could easily be missing something, and might well be
convinced otherwise.

-- 
-------------------------------------------------------------------------------
Kevin Lynch				voice:	 [phone]
Physics Department			Fax: [phone]
Boston University			office:	 PRB-565
590 Commonwealth Ave.			e-mail:	 krlynch_at_[hidden]
Boston, MA 02215 USA			http://physics.bu.edu/~krlynch
-------------------------------------------------------------------------------