"kanze" <kanze@gabi-soft.fr> wrote in message
news:1155826517.807685.44550@p79g2000cwp.googlegroups.com...

> "P.J. Plauger" wrote:
>> "skaller" <skaller@users.sourceforge.net> wrote in message
>> news:pan.2006.08.11.01.33.34.253488@users.sf.net...
>
>> > Can someone explain the current and proposed relationship
>> > between C++ complex library type and C99 complex types?
>
>> > Its very unsatisfactory to have two distinct types for
>> > complex numbers. C++ complex is a template, and thus a class
>> > type. C99 complex may be a primitive type.
>
>> It may be unsatisfactory, but that's the way the two languages
>> evolved.
>
>> > If we wanted to make complex<double> the same type as C99
>> > double _Complex, it would seem we'd need to allow a typedef
>> > as a specialisation, eg:
>
>> > typedef double _Complex
>> > template<> complex<double>;
>
>> > [unreadable .. I would write:
>
>> > typedef template<> complex<double> =
>> > double _Complex;
>
>> > if I could.] Is there another way? Is this possible?
>
>> > Any help here appreciated, including suggestions how to
>> > handle the dichotomy (apart from the obvious: convert one to
>> > the other as required)
>
>> We ensure that the two types have the same representation and are
>> freely interchangeable in C++.
>
> When you say we, do you mean, "we, the members of the
> standardization committee", or "we, the implementors at
> Dinkumware"?  (I know at one point there was a suggestion to
> constraint the implementation of complex<T>, so that it would be
> required to be physically equivalent of T[2].  I don't know what
> became of it, though.)

IIRC, that has passed, ensuring that Fortran, C, and C++ all
represent complex the same as an array of its two floating-point
Cartesian coordinates. So the "we" above is certainly Dinkumware,
encouraged by TR1, approved for the next C++ Standard, and de
facto true of the existing implementations I know (if only by
accident).

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ 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                      ]

"P.J. Plauger" wrote:
> "skaller" <skaller@users.sourceforge.net> wrote in message
> news:pan.2006.08.11.01.33.34.253488@users.sf.net...

> > Can someone explain the current and proposed relationship
> > between C++ complex library type and C99 complex types?

> > Its very unsatisfactory to have two distinct types for
> > complex numbers. C++ complex is a template, and thus a class
> > type. C99 complex may be a primitive type.

> It may be unsatisfactory, but that's the way the two languages
> evolved.

> > If we wanted to make complex<double> the same type as C99
> > double _Complex, it would seem we'd need to allow a typedef
> > as a specialisation, eg:

> > typedef double _Complex
> > template<> complex<double>;

> > [unreadable .. I would write:

> > typedef template<> complex<double> =
> > double _Complex;

> > if I could.] Is there another way? Is this possible?

> > Any help here appreciated, including suggestions how to
> > handle the dichotomy (apart from the obvious: convert one to
> > the other as required)

> We ensure that the two types have the same representation and are
> freely interchangeable in C++.

When you say we, do you mean, "we, the members of the
standardization committee", or "we, the implementors at
Dinkumware"?  (I know at one point there was a suggestion to
constraint the implementation of complex<T>, so that it would be
required to be physically equivalent of T[2].  I don't know what
became of it, though.)

> That seems to solve most problems that occur when people call
> C99 complex functions with C++ complex objects.

I presume that it does mean that you'd need something like:

    #ifdef __cplusplus
    extern "C" void f( std::complex< double > ) ;
    #else
    extern void f( double _Complex ) ;
    #endif

in your header files, or... ?

And of course, it would be preferable if said header file didn't
include the C header <complex.h>, although that would be the
natural thing for it to do if it were written by the developers
of f() (who are working in C).

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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                      ]

Can someone explain the current and proposed relationship between
C++ complex library type and C99 complex types?

Its very unsatisfactory to have two distinct types for
complex numbers. C++ complex is a template, and thus
a class type. C99 complex may be a primitive type.

If we wanted to make complex<double> the same type
as C99 double _Complex, it would seem we'd need to
allow a typedef as a specialisation, eg:

 typedef double _Complex
  template<> complex<double>;

[unreadable .. I would write:

 typedef template<> complex<double> =
  double _Complex;

if I could.] Is there another way? Is this possible?

Any help here appreciated, including suggestions how
to handle the dichotomy (apart from the obvious:
convert one to the other as required)

--
John Skaller <skaller at users dot sf dot net>
Try Felix, the successor to C++ http://felix.sf.net


---
[ 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                      ]

"skaller" <skaller@users.sourceforge.net> wrote in message
news:pan.2006.08.11.01.33.34.253488@users.sf.net...

> Can someone explain the current and proposed relationship between
> C++ complex library type and C99 complex types?
>
> Its very unsatisfactory to have two distinct types for
> complex numbers. C++ complex is a template, and thus
> a class type. C99 complex may be a primitive type.

It may be unsatisfactory, but that's the way the two languages evolved.

> If we wanted to make complex<double> the same type
> as C99 double _Complex, it would seem we'd need to
> allow a typedef as a specialisation, eg:
>
> typedef double _Complex
> template<> complex<double>;
>
> [unreadable .. I would write:
>
> typedef template<> complex<double> =
> double _Complex;
>
> if I could.] Is there another way? Is this possible?
>
> Any help here appreciated, including suggestions how
> to handle the dichotomy (apart from the obvious:
> convert one to the other as required)

We ensure that the two types have the same representation and are
freely interchangeable in C++. That seems to solve most problems
that occur when people call C99 complex functions with C++
complex objects.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ 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                      ]

On Sat, 12 Aug 2006 20:37:52 +0000, P.J. Plauger wrote:

> "skaller" <skaller@users.sourceforge.net> wrote in message
> news:pan.2006.08.11.01.33.34.253488@users.sf.net...

>> Its very unsatisfactory to have two distinct types for
>> complex numbers. C++ complex is a template, and thus
>> a class type. C99 complex may be a primitive type.
>
> It may be unsatisfactory, but that's the way the two languages evolved.

Well yes, I know that: different timing of the Standards
and perhaps a failure of liaison.

> We ensure that the two types have the same representation and are
> freely interchangeable in C++. That seems to solve most problems
> that occur when people call C99 complex functions with C++
> complex objects.

I presume by 'we' you mean Dinkumware .. I guess I'm really
asking if there is any proposal to do anything about it
in the Standards committee .. (er.. used to call that the
ANSI/ISO committee but it isn't ANSI anymore .. whats
the right name for the 'committee as a whole' now?]

My vague proposal for allowing a 'typedef to be a specialisation'
was a suggestion that it might be possible to provide
proper machinery to actually identify the types (in the
case of a C++ library that actually does so). I admit I
haven't thought much about whether the idea would actually work:
but there is a motivation to think about it.

Also, whether or not one library provides the same
representation .. there is a question of which one to
use, given one has an eye for the future: we're
going to have 6 variants of, for example:

 sin z

instead of just 3. Given that, suppose you wished
to write some new functions .. what would you do?
Use the C version? The C++ version? Both?

Note that my typedef solution *precludes* doing both.
If a typedef is used as a specialisation, then

 complex<float>

and

 float _Complex

will actually be the same type, which has implications
for overloading.

MAYBE the only thing that can be done is provide
a macro which tells if these two types are representation
compatible.. but this may still cause aliasing problems
(see previous discussion where my assumptions aliasing
pointers were quashed by aliasing rules).

It's going to be a real pain if one has C libraries
for complex arithmetic and also some C++ libraries:
if the objects are matricies .. conversions would be
too slow to contemplate.

--
John Skaller <skaller at users dot sf dot net>
Try Felix, the successor to C++ http://felix.sf.net


---
[ 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                      ]