JTC1/SC22/WG21
N0761
Title: Open Issues for Numeric Libraries (Chapter 26)
Revision 3
Author: Judy Ward
Document Number: X3J16/95-0161
WG21/N0761
*****
Note: This revision includes the resolutions of Clause 26 issues
closed at the Monterey meeting in July 1995 (issues 001
through 006).
*****
-------------------------------------------------------------------------
Work Group: Library
Issue Number: 26/001
Title: operator conversions in complex
Section: 26.1 New
Status: closed
Description:
To: C++ libraries mailing list
Message c++std-lib-3382
/*
There seems to be a problem with the current interface
of the complex library. At Valley Forge
complex was changed to a templatized library. This
is an example of code that would have worked with
the non-templatized float_complex class but will no
longer work with the templatized complex<float> class.
Shouldn't this code still be valid?
Judy Ward
ward@roguewave.com
*/
class float_complex {}; // old non-templatized float complex class
float_complex operator/(float,float_complex);
template <class T>
class complex {}; // new templatized complex class
template <class T>
complex<T> operator/(const T&,const complex<T>&);
void main() {
float_complex fcf;
complex<float> cf;
fcf=1/fcf; // ok
cf=1/cf; // can't match
}
From John Spicer at EDG:
>The complex template should work okay if the operator functions are
>declared as friends inside the class definition. These friend
>functions participate in overloading as normal functions do.
>Consequently, the normal conversions can be performed on their
>arguments.
>
>The example below should do what you want it to.
>
>John.
>
>template <class T> struct complex {
> friend complex operator/(const T&, const complex);
>};
>
>int main()
>{
> complex<float> cf;
> cf = 1 / cf;
>}
If we use this approach, we would have to specify that all the
operator declarations listed in Section 26.2 must be friends.
Resolution:
Discussed by the LWG at Monterey. Recommend making the
following changes to the WP:
Add friend declarations to the declaration of complex<T>
in 26.2 [lib.complex.numbers] for each of the 12 operator
functions that take both T and complex<T> arguments:
operator+(const complex<T>&, T)
operator+(T, const complex<T>&)
operator-(const complex<T>&, T)
operator-(T, const complex<T>&)
operator*(const complex<T>&, T)
operator*(T, const complex<T>&)
operator/(const complex<T>&, const T>&)
operator/(T, const complex<T>&)
operator==(const complex<T>&, T)
operator==(T, const complex<T>&)
operator!=(const complex<T>&, T)
operator!=(T, const complex<T>&)
Requestor: Judy Ward
Owner: Judy Ward
Emails: (email reflector messages that discuss this issue)
c++std-lib-3385
c++std-ext-2832
c++std-lib-3386
c++std-lib-3382
c++std-lib-3387
c++std-ext-2833 (same as above)
c++std-lib-3771
Papers: (committee documents that discuss this issue)
-------------------------------------------------------------------------
Work Group: Library
Issue Number: 26/002
Title: complex needs to be updated for new iostreams
Section: 26 New
Status: closed
Description:
The complex library's insertion/extraction operators need to
be updated for the new iostreams, i.e. from:
istream& operator>>(istream&,complex<T>&);
ostream& operator<<(ostream&,const complex<T>&);
to:
template<class T, class charT, class traits>
basic_istream<charT, traits>&
operator>>(basic_istream<charT, traits>&, complex<T>&);
template<class T, class charT, class traits>
basic_ostream<charT, traits>&
operator<<(basic_ostream<charT, traits>&, const complex<T>&);
Resolution:
Discussed by the LWG at Monterey. Recommend making the
changes proposed above to the WP.
Requestor: Judy Ward
Owner: Judy Ward
Emails: (email reflector messages that discuss this issue)
Papers: (committee documents that discuss this issue)
-------------------------------------------------------------------------
Work Group: Library
Issue Number: 26/003
Title: complex library operator << needs to be refined
Section: 26 New
Status: closed
Description:
To: C++ libraries mailing list
Message c++std-lib-3659
26.2.1.3.8 says operator<<(ostream &os, complex x) returns
os << '(' << x.real() << ',' << x.imag() << ')'
I take it the output from:
complex x(4.5,2.2) ;
cout << ':' << setiosflags(ios::left)
<< setw(12) << x ;
would be
:( 4.5,2.2)
It seems to me that complexes will behave more like the builtin types
if operator<< did something like this:
ostream & operator<<(ostream &o, complex x) {
ostrstream ost; // should be stringstream
ost.precision(o.precision()); // and other flags too
ost << '(' << x.real() << ',' << x.imag() << ')' << ends ;
o << ost.str() ;
ost.rdbuf()->freeze(0) ;
return o;
}
If this has been discussed and rejected as too busy by the library
group, please forgive my intrusion.
Resolution:
Discussed by the LWG at Monterey. Recommend making the
following changes to the WP:
Modify the description of operator<<() in section 26.2.5
[lib.complex.ops] to read as follows:
template <class charT, class traits, class T>
basic_ostream<charT, traits>&
operator<<(basic_ostream<charT, traits>& o, const complex<T>& x);
Effects: inserts the complex number x onto the stream o as if
it were implemented as follows:
template <class charT, class traits, class T>
basic_ostream<charT, traits>&
operator<<(basic_ostream<charT, traits>& o, const complex<T>& x)
{
basic_ostringstream<charT, traits> s;
s.flags(o.flags());
s.imbue(o.getloc());
s.precision(o.precision());
s << ( << x.real() << , << x.imag() << ) << ends;
return o << s.str();
}
[See also issue 26/006, which discusses the updating of
the inserter/extractor functions for templates.]
Requestor: Thomas Holday, JP Morgan
Owner: Judy Ward
Emails: (email reflector messages that discuss this issue)
c++std-lib-3662
c++std-lib-3665
c++std-lib-3676
c++std-lib-3678
c++std-lib-3681
c++std-lib-3682
Papers: (committee documents that discuss this issue)
-------------------------------------------------------------------------
Work Group: Library
Issue Number: 26/004
Title: cleanup of Chapter 26
Section: 26 New
Status: closed
Description:
Hopefully these are all editorial changes. I noticed
the following typos and mistakes.
Section 26.2.5
1. There is an extra "P" after lhs in ther Returns for operator==
2. The "Returns" for operator!= should be:
rhs.real() != lhs.real() || rhs.imag() != lhs.imag()
Section 26.2.6
1. In the "Returns" for arg and conj, what is TBS (To be specified?)?
I would make them:
for arg, Returns the phase angle of x.
for conj, Returns the complex conjugate of x.
2. The polar function
change t to T in the second arg
the second argument should default to 0.
Section 26.2.7
In the description, I don't think the "F" means anything, I'd remove it.
Section 26.3
In paragraph 3, the "an" should be "a"
Section 26.5
The added signatures list at the end is incomplete.
It only includes the the float ones, not the long
double functions mentioned in the previous sentence.
Why does the double abs(double) have a comment that says fabs?
I'm not sure what this comment or the labs() or ldiv() comments
mean.
Shouldn't the last two prototypes be:
float abs(float);
float pow(float, int);
Section 26.3.1.2
the argument to operator= should be:
const valarray<T>& (not: const valarra<T>y&)
Resolution:
Discussed by the LWG at Monterey. Recommend making all
the changes outlined above except for the changes to 26.5.
[Note: to allow this issue to be closed, a separate issue
(26/007) is being created for the changes suggested for
26.5.]
Requestor: Judy Ward
Owner: Judy Ward
Emails: (email reflector messages that discuss this issue)
Papers: (committee documents that discuss this issue)
-------------------------------------------------------------------------
Work Group: Library
Issue Number: 26/005
Title: exceptions in valarray classes
Section: 26 New
Status: closed
Description:
Box 125 says the description of valarray and its classes
lack any discussion of possible exceptions. There is a paragraph
above this issue which says bad_allocs are allowed. Is there
anything else that people want to add or should we close this
issue?
Resolution:
Discussed by the LWG at Monterey. Recommend that this
issue be closed with no changes to the WP. There is a
global Library issue to specify what exceptions may be
thrown from template containers.
Requestor: Judy Ward
Owner: Judy Ward
Emails: (email reflector messages that discuss this issue)
Papers: (committee documents that discuss this issue)
-------------------------------------------------------------------------
Work Group: Library
Issue Number: 26/006
Title: update iostream inserters/extractors for templates
Section: 26 New
Status: closed
Description:
The declarations for operator<<() and operator>>() in Clauses
26.2 [lib.complex.numbers] and 26.2.5 [lib.complex.ops] are out
of date. They must be corrected to correspond to the current
use of templates in the iostream classes.
Resolution:
Discussed by the LWG at Monterey. Recommend making the
following changes to the WP:
Change the declarations of operator<<() and operator>>()
in 26.2 and 26.2.5 to read as follows:
template <class charT, class traits, class T>
basic_istream<charT, traits>&
operator>>(basic_istream<charT, traits>& is, complex<T>& x);
template <class charT, class traits, class T>
basic_ostream<charT, traits>&
operator<<(basic_ostream<charT, traits>& os, const complex<T>& x);
Requestor: Judy Ward
Owner: Judy Ward
Emails: (email reflector messages that discuss this issue)
Papers: (committee documents that discuss this issue)
-------------------------------------------------------------------------
Work Group: Library
Issue Number: 26/007
Title: cleanup of Chapter 26
Section: 26 New
Status: active
Description:
Editorial changes:
Section 26.5
The added signatures list at the end is incomplete.
It only includes the the float ones, not the long
double functions mentioned in the previous sentence.
Why does the double abs(double) have a comment that says fabs?
I'm not sure what this comment or the labs() or ldiv() comments
mean.
Shouldn't the last two prototypes be:
float abs(float);
float pow(float, int);
Resolution:
Requestor: Judy Ward
Owner: Judy Ward
Emails: (email reflector messages that discuss this issue)
Papers: (committee documents that discuss this issue)
-------------------------------------------------------------------------