 |
C++Talk.NET C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Stefan Große Pawig Guest
|
Posted: Sun Sep 24, 2006 10:55 pm Post subject: Defect Report: TR1/C++0x: fabs(complex<T>) redundant / wrong |
|
|
Hello all,
TR1 introduced, in the C compatibility chapter, the function
fabs(complex<T>):
----- SNIP -----
8.1.1 Synopsis [tr.c99.cmplx.syn]
namespace std {
namespace tr1 {
[...]
template<class T> complex<T> fabs(const complex<T>& x);
} // namespace tr1
} // namespace std
[...]
8.1.8 Function fabs [tr.c99.cmplx.fabs]
1 Effects: Behaves the same as C99 function cabs, defined in
subclause 7.3.8.1.
----- SNIP -----
The current C++0X draft document (n2009.pdf) adopted this
definition in chapter 26.3.1 (under the comment // 26.3.7 values)
and 26.3.7/7.
But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document
n1124), the referenced subclause reads
----- SNIP -----
7.3.8.1 The cabs functions
Synopsis
1 #include <complex.h>
double cabs(double complex z);
float cabsf(float complex z);
long double cabsl(long double z);
Description
2 The cabs functions compute the complex absolute value (also called
norm, modulus, or magnitude) of z.
Returns
3 The cabs functions return the complex absolute value.
----- SNIP -----
Note that the return type of the cabs*() functions is not a complex
type. Thus, they are equivalent to the already well established
template<class T> T abs(const complex<T>& x);
(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft
document n2009.pdf).
So either the return value of fabs() is specified wrongly, or fabs()
does not behave the same as C99's cabs*().
Proposed resolution:
This depends on the intention behind the introduction of fabs().
If the intention was to provide a /complex/ valued function that
calculates the magnitude of its argument, this should be
explicitly specified. In TR1, the categorization under "C
compatibility" is definitely wrong, since C99 does not provide
such a complex valued function.
Also, it remains questionable if such a complex valued function
is really needed, since complex<T> supports construction and
assignment from real valued arguments. There is no difference
in observable behaviour between
complex<double> x, y;
y = fabs(x);
complex<double> z(fabs(x));
and
complex<double> x, y;
y = abs(x);
complex<double> z(abs(x));
If on the other hand the intention was to provide the intended
functionality of C99, fabs() should be either declared deprecated
or (for C++0X) removed from the standard, since the functionality
is already provided by the corresponding overloads of abs().
Regards,
Stefan
--
Veni, vidi, VISA: I came, I saw, I did a little shopping
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
 |
Pete Becker Guest
|
Posted: Mon Sep 25, 2006 9:43 pm Post subject: Re: Defect Report: TR1/C++0x: fabs(complex<T>) redundant / w |
|
|
Stefan Große Pawig wrote:
| Quote: |
If on the other hand the intention was to provide the intended
functionality of C99,
|
That was the intention. Code written for C99 should be easily portable
to C++. So I think you're right: the return type of fabs(const
complex<T>&) for C++ should be T.
| Quote: | fabs() should be either declared deprecated
or (for C++0X) removed from the standard, since the functionality
is already provided by the corresponding overloads of abs().
|
That's a bit too drastic, since it would mean that C code using fabs
would have to be modified.
--
-- Pete
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
 |
Stefan Große Pawig Guest
|
Posted: Tue Sep 26, 2006 1:42 am Post subject: Re: Defect Report: TR1/C++0x: fabs(complex<T>) redundant / w |
|
|
petebecker (AT) acm (DOT) org (Pete Becker) wrote:
| Quote: | Stefan Große Pawig wrote:
fabs() should be either declared deprecated
or (for C++0X) removed from the standard, since the functionality
is already provided by the corresponding overloads of abs().
That's a bit too drastic, since it would mean that C code using fabs
would have to be modified.
|
Oh, sorry for being unclear. I did not mean to deprecate or remove
fabs() as a whole, but only the fabs(const complex<T>&) overload
introduced in TR1. This should not effect any C code at all.
(Or am I missing something?)
But of course there may also be C++ code out there that uses
fabs(const complex<T>&), which would have to be modified.
Nevertheless, if the return type of fabs(const complex<T>&) is
changed from complex<T> to T, this leaves us with two functions
that do exactly the same:
T abs(const complex<T>&) and
T fabs(const complex<T>&).
If deprecation or removal are still too drastic, I think at least
a clarifying note in the standard would be in order. ;-)
Regards,
Stefan
--
NOTICE: Due to budgetary constraints the light at the end of the
tunnel will be turned off until further notice
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
 |
Pete Becker Guest
|
Posted: Tue Sep 26, 2006 7:30 am Post subject: Re: Defect Report: TR1/C++0x: fabs(complex<T>) redundant / w |
|
|
Stefan Große Pawig wrote:
| Quote: | petebecker (AT) acm (DOT) org (Pete Becker) wrote:
Nevertheless, if the return type of fabs(const complex<T>&) is
changed from complex<T> to T, this leaves us with two functions
that do exactly the same:
T abs(const complex<T>&) and
T fabs(const complex<T>&).
|
Yes, but that's already the case for most of the math functions. The one
that takes double is overloaded to take float, double, and long double,
and we provide the C-compatible ones whose names end with f and l. For
example, in C++ we have:
float cosf(float)
float cos(float)
double cos(double)
long double cos(long double)
long double cosl(long double)
The ones that take the same argument types do exactly the same thing.
That's so that C code will be easier to port to C++, and so that C++
code can take advantage of function overloading.
--
-- Pete
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|