Development list for the standard C++ library

Mark Mitchell | 1 Jun 2005 05:09

Re: Problems with PR 21210

Nathan (Jasper) Myers wrote:
> On Tue, May 31, 2005 at 03:20:29PM -0700, Mark Mitchell wrote:
> 
>>I'm not sure what other areas of concern arise, with respect to this PR, 
>>which is just about the core language.
>>
>>There are indeed other questions, though, like:
>>
>>1. Overload resolution
>>
>>  void f(std::complex<double>);
>>  void f(__complex__ double);
>>
>>2. Should we have overloads of "sin" (and so forth) for "__complex__" 
>>   types?
> 
> 
> The Intent of the Committee was that compilers would open-code complex 
> and val_array objects if there was anything to be gained by it.   
> That is, std::complex<> and __complex__ ought to one and the same 
> type.   I hope the C committee has not given them such different 
> semantics that it's impossible.

(From now on, I'm going to call __complex__ by its official C99 name, 
which is _Complex.)

Every libstdc++ std::complex<> presently contains a _Complex, so making 
them the same type would break that.  But, yes, it would be cool if they 
were magically the same type.

(Continue reading)

headers

Nathan (Jasper) Myers | 1 Jun 2005 05:40

Re: Problems with PR 21210

On Tue, May 31, 2005 at 08:09:37PM -0700, Mark Mitchell wrote:
> Nathan (Jasper) Myers wrote:
> >On Tue, May 31, 2005 at 03:20:29PM -0700, Mark Mitchell wrote:
> >
> >The Intent of the Committee was that compilers would open-code complex 
> >and val_array objects if there was anything to be gained by it.   
> >That is, std::complex<> and __complex__ ought to one and the same 
> >type.   I hope the C committee has not given them such different 
> >semantics that it's impossible.
> 
> (From now on, I'm going to call __complex__ by its official C99 name, 
> which is _Complex.)
> 
> Every libstdc++ std::complex<> presently contains a _Complex, so making 
> them the same type would break that.  But, yes, it would be cool if they 
> were magically the same type.
> 
> Under this interpretation, would you have to #include <complex> before 
> you got to use _Complex?  (That's not true in C99.)

Of course not.

>  But, if _Complex in 
> C++ is going to be the same type as std::complex, then it seems like 
> you'd have to have the header to make everything make sense.

The header just exposes the alternative name, std::complex<float>
(or std::complex<double>) for the same type, which is implicitly fully
defined.  The syntax that establishes the identity must be a local 
extension, but that's OK: the headers already contain plenty of that.

(Continue reading)

headers

Mark Mitchell | 1 Jun 2005 07:51

Re: Problems with PR 21210

Nathan (Jasper) Myers wrote:
> On Tue, May 31, 2005 at 08:09:37PM -0700, Mark Mitchell wrote:
> 
>>Nathan (Jasper) Myers wrote:

>>Under this interpretation, would you have to #include <complex> before 
>>you got to use _Complex?  (That's not true in C99.)
>  
> Of course not.

Well, I asked, because you have to #include <typeinfo> before you can 
use std::type_info, which is rather more built-in than std::complex in 
most compilers.

However, I've always thought that restriction somewhat lame. 

> This also depends on somebody not myself doing a not-insubstantial
> amount of core compiler work to make it happen; and somebody else
> jimmying the libstdc++ headers to match, presumably a lesser task.

I agree that this could be made to work, by essentially hard-wiring 
std::complex/_Complex into the compiler, rather than defining it in the 
library.

That would be a considerably more radical change, though; historically, 
G++ has indeed treated the types as separate.

--

-- 
Mark Mitchell
CodeSourcery, LLC

(Continue reading)

headers

Nathan (Jasper) Myers | 1 Jun 2005 16:04

Re: Problems with PR 21210

On Tue, May 31, 2005 at 10:51:48PM -0700, Mark Mitchell wrote:
> Nathan (Jasper) Myers wrote:
> >On Tue, May 31, 2005 at 08:09:37PM -0700, Mark Mitchell wrote:
> >>Nathan (Jasper) Myers wrote:
> 
> >>Under this interpretation, would you have to #include <complex> before 
> >>you got to use _Complex?  (That's not true in C99.)
> > 
> >Of course not.
> 
> Well, I asked, because you have to #include <typeinfo> before you can 
> use std::type_info, which is rather more built-in than std::complex in 
> most compilers.

C++ programs can't mention std::complex without the header, and making 
_Complex a keyword need not change that.  Of course no C99 program can
mention std::complex, header or no.

> >This also depends on somebody not myself doing a not-insubstantial
> >amount of core compiler work to make it happen; and somebody else
> >jimmying the libstdc++ headers to match, presumably a lesser task.
> 
> I agree that this could be made to work, by essentially hard-wiring 
> std::complex/_Complex into the compiler, rather than defining it in
> the  library.
> 
> That would be a considerably more radical change, though; historically, 
> G++ has indeed treated the types as separate.

... albeit with results that are extremely unlikely to be compatible

(Continue reading)

headers

Zack Weinberg | 1 Jun 2005 06:11

Re: Problems with PR 21210


> This also depends on somebody not myself doing a not-insubstantial
> amount of core compiler work to make it happen; and somebody else
> jimmying the libstdc++ headers to match, presumably a lesser task.

I gotta wonder how much of the way there it would get us if we could
write

  template <typename T> class complex;
  template <>
  typedef _Complex double complex<double>;

(yes, that's a typedef partially specializing a class template.)

zw

headers

Gabriel Dos Reis | 1 Jun 2005 08:24

Re: Problems with PR 21210

Zack Weinberg <zack <at> codesourcery.com> writes:

| > This also depends on somebody not myself doing a not-insubstantial
| > amount of core compiler work to make it happen; and somebody else
| > jimmying the libstdc++ headers to match, presumably a lesser task.
| 
| I gotta wonder how much of the way there it would get us if we could
| write
| 
|   template <typename T> class complex;
|   template <>
|   typedef _Complex double complex<double>;

If we do that, we mutate C++ because we would have now introduced an
implicit conversion of a std:complex<double> to its real part, where
it did not exist before.

-- Gaby

headers

Zack Weinberg | 1 Jun 2005 07:46

Re: Problems with PR 21210

Gabriel Dos Reis <gdr <at> integrable-solutions.net> writes:

> Zack Weinberg <zack <at> codesourcery.com> writes:
>
> | > This also depends on somebody not myself doing a not-insubstantial
> | > amount of core compiler work to make it happen; and somebody else
> | > jimmying the libstdc++ headers to match, presumably a lesser task.
> | 
> | I gotta wonder how much of the way there it would get us if we could
> | write
> | 
> |   template <typename T> class complex;
> |   template <>
> |   typedef _Complex double complex<double>;
>
> If we do that, we mutate C++ because we would have now introduced an
> implicit conversion of a std:complex<double> to its real part, where
> it did not exist before.

Bother.

That exhausts my store of helpful suggestions; I leave further
discussion to people who know this part of both standards.

zw

headers

Gabriel Dos Reis | 1 Jun 2005 09:37

Re: Problems with PR 21210

Zack Weinberg <zack <at> codesourcery.com> writes:

| Gabriel Dos Reis <gdr <at> integrable-solutions.net> writes:
| 
| > Zack Weinberg <zack <at> codesourcery.com> writes:
| >
| > | > This also depends on somebody not myself doing a not-insubstantial
| > | > amount of core compiler work to make it happen; and somebody else
| > | > jimmying the libstdc++ headers to match, presumably a lesser task.
| > | 
| > | I gotta wonder how much of the way there it would get us if we could
| > | write
| > | 
| > |   template <typename T> class complex;
| > |   template <>
| > |   typedef _Complex double complex<double>;
| >
| > If we do that, we mutate C++ because we would have now introduced an
| > implicit conversion of a std:complex<double> to its real part, where
| > it did not exist before.
| 
| Bother.

My earlier comment did not provide an example:

    void f(const complex<long double>&);  // #1
    void f(double);                       // #2

    int main() {
      std::complex<double> z;

(Continue reading)

headers

Nathan (Jasper) Myers | 1 Jun 2005 15:56

Re: Problems with PR 21210

On Wed, Jun 01, 2005 at 09:37:38AM +0200, Gabriel Dos Reis wrote:
> 
> My earlier comment did not provide an example:
>     void f(const complex<long double>&);  // #1
>     void f(double);                       // #2
>     int main() {
>       std::complex<double> z;
>       f(z);
>     }
> 
> Currently, this will pick #1.  If we make _Complex double and
> std::complex<double> identical, we silently break the program because 
> now we would call #2 (for a standard conversion is better than
> user-defined conversion). 

We don't have any choice but to do something that most people would
consider broken, one way or another.  The best we can do is to choose
something nobody would consider crazy (e.g. discarding imaginary part 
in _Complex -> std::complex<> copies.)  Since we're outside the realm 
of the standard, anything is allowed; within certain limits we can do 
whatever makes sense.  If what we do works out, it could be adopted 
into C++0x.

What limits?  Our goal must have every program that compiles in both 
C99 and C++ mean the same thing.  Not every C99 program need compile 
in C++, but for any given program in C99 that does not compile in C++, 
it should be obvious how to change it to a C99 program that does, and 
means the same thing.  (This is similar to C++ requiring a cast in 
malloc expressions.)  For a trivial example, we need not provide an 
implicit conversion from _Complex to scalar; it's not safe anyway,

(Continue reading)

headers

Gabriel Dos Reis | 1 Jun 2005 19:26

Re: Problems with PR 21210

"Nathan (Jasper) Myers" <ncm <at> codesourcery.com> writes:

| On Wed, Jun 01, 2005 at 09:37:38AM +0200, Gabriel Dos Reis wrote:
| > 
| > My earlier comment did not provide an example:
| >     void f(const complex<long double>&);  // #1
| >     void f(double);                       // #2
| >     int main() {
| >       std::complex<double> z;
| >       f(z);
| >     }
| > 
| > Currently, this will pick #1.  If we make _Complex double and
| > std::complex<double> identical, we silently break the program because 
| > now we would call #2 (for a standard conversion is better than
| > user-defined conversion). 
| 
| We don't have any choice but to do something that most people would
| consider broken, one way or another.

Yet, a change that silently breaks the above does not read sensible to me.

| The best we can do is to choose
| something nobody would consider crazy (e.g. discarding imaginary part 
| in _Complex -> std::complex<> copies.)  Since we're outside the realm 
| of the standard, anything is allowed; within certain limits we can do 
| whatever makes sense.  If what we do works out, it could be adopted 
| into C++0x.

We're considering extensions here that shold help us implement the

(Continue reading)

headers

Nathan (Jasper) Myers | 1 Jun 2005 19:23

Re: Problems with PR 21210

On Wed, Jun 01, 2005 at 07:26:28PM +0200, Gabriel Dos Reis wrote:
> "Nathan (Jasper) Myers" <ncm <at> codesourcery.com> writes:
> 
> | >     void f(const complex<long double>&);  // #1
> | >     void f(double);                       // #2
> | >     int main() { std::complex<double> z; f(z); }
> | > 
> | > Currently, this will pick #1.  
> | 
> | We don't have any choice but to do something that most people would
> | consider broken, one way or another.
> 
> Yet, a change that silently breaks the above does not read sensible 
> to me.

Not to me, either.  I would not suggest any change that could break 
existing, conforming C++ programs.  

> | The best we can do is to choose | something nobody would consider
> crazy (e.g. discarding imaginary part | in _Complex -> std::complex<>
> copies.)  Since we're outside the realm | of the standard, anything is
> allowed; within certain limits we can do | whatever makes sense.  If
> what we do works out, it could be adopted | into C++0x.
> 
> We're considering extensions here that shold help us implement the
> library efficiently.  I do not consider breaking existing programs
> with well-defined semantics, because of clear semantics, something
> that  we should seriously contemplate.  The chances that such a
> change would get into C++0x appear very low to me.

(Continue reading)