Chris Dearlove wrote:
>
> James Kuyper (kuyper@wizard.net) wrote:
>
> : The C standard doesn't specify the size or representation either. It
> : does specify that "double complex" is stored as if it were an array of 2
> : doubles, containing the real and complex parts, but it doesn't specify
> : the size or representation of double unless the implementation chooses
> : to define __STDC_IEC_559__.
>
> True, although it's a very perverse case where C and C++ make different
> decisions. Furthermore all cases are generally forced to be compatible
> with the hardware, hence with each other. (Yes, I know there are systems
> which support more than one floating type of the same size.)

That's precisely why the standard doesn't specify the representation. We
can count on QoI to handle the issue. One goal of C that has been at
least partly absorbed into C++ is to not make it unnecessarily difficult
to implement C on unusual platforms. The more specific the standard gets
about representation of floating point numbers, the smaller the number
of different platforms it would be easily implementable on. The
popularity of C/C++ is partly due to the large variety of platforms it
can be easily implemented on.

Only an idiotic vendor would produce an implementation of either
language that wasn't reasonably link-compatible with other popular
languages on the same platform, unless there were some very significant
disadvantages to doing so. Anyone care to nominate some vendors for
"idiot" status? :-)

> : The C standard says absolutely nothing about calling conventions; in
> : particular, it makes no guarantees of Fortran compatibility. Therefore,
> : C compatibility gives you no clue about (3).
>
> C compatibility gives you precisely that, compatibility with C, and

Yes - and item (3) was compatibility of calling conventions with
Fortran. I stand by my statement.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <newscache$k1ab2g$kke$1@firewall.thermoteknix.co.uk>,
Ken Hagan <K.Hagan@thermoteknix.co.uk> wrote:
>These may not be problems in practice, but as I've argued already,
>the layout probably won't be a problem in practice either.

Good point.  Since it's up to the implementor to make sure that all other
language interoperability requirements are met, he can easily extend that
to the design of the complex template.

The gist of the original poster's request could be the following though: If
we assume that the implementor has already done what's necessary to ensure
interoperability of calling sequences and the low-level types, couldn't we
specify the complex class in such a way that it will *automatically* take
advantage of that?  I.e. on any pair of C++ and Fortran/C implementations,
if you can successfully make calls that pass double[2] and have the
expected thing happen, then you can also pass complex<double>.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

James Kuyper (kuyper@wizard.net) wrote:

: The C standard doesn't specify the size or representation either. It
: does specify that "double complex" is stored as if it were an array of 2
: doubles, containing the real and complex parts, but it doesn't specify
: the size or representation of double unless the implementation chooses
: to define __STDC_IEC_559__.

True, although it's a very perverse case where C and C++ make different
decisions. Furthermore all cases are generally forced to be compatible
with the hardware, hence with each other. (Yes, I know there are systems
which support more than one floating type of the same size.)

: The C standard says absolutely nothing about calling conventions; in
: particular, it makes no guarantees of Fortran compatibility. Therefore,
: C compatibility gives you no clue about (3).

C compatibility gives you precisely that, compatibility with C, and
hence with numerical libraries written in C, of which I am using at
least one. It makes it more likely that you get Fortran compatibility,
although I agree it makes no guarantees.

Finally I don't buy the argument that says "you need (1), (2) and (3);
(2) and (3) are outside the scope of the standard [but often true]
so let's ignore (1)".

--
Christopher Dearlove

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <newscache$itk72g$ef3$1@firewall.thermoteknix.co.uk>,
  "Ken Hagan" <K.Hagan@thermoteknix.co.uk> wrote:
> <sirwillard@my-deja.com> wrote...
> > Where as it would be trivial to
> > create a conversion type to go from std::complex<double> to a
Fortran
> > compatible binary representation in a fast and exception safe
manner.
> >
> > In other words, there's a compelling reason to mandate the obvious
for
> > std::vector, but there isn't any for std::complex.
>
> Lets say I have an array of 50 million complex<float>. Lets
> also say there is a routine to solve my problem, written by
> some expert who has forgotten more about numerical coding than
> I'll ever know. Clearly I'd be stupid to write my own routine.
> (It could take me *years* to get it right.) So I'm going to
> pass this array to the Fortran code. Typically this step has
> to be done in the innermost loop. :-(

I agree that I might have gone to far in my post when I discussed the
conversion here.  Yes, in some cases the conversion will require mass
allocations and the performance will be lousy.  My point here was that
it could be trivially done, however, not that it would be ideally
efficient.

The main thrust isn't about efficiency (though it strongly applies to
why std::vector should be continguous), it's that the std::vector DR
applies to code entirely within the language, while your proposal deals
with interopability between langauges, which is outside of the scope of
the standard.  The standard should no more dictate the layout of
complex<double> than it should dictate the calling conventions of
functions, for instance.  What you want is a QOL issue, not a topic for
a DR, IMHO.

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Ross Smith (ross.s@ihug.co.nz) wrote:
: The point you seem to be missing is that merely specifying that complex
: contains the Cartesian representation in (Re,Im) order is _not_ enough
: to guarantee layout compatibility. There are at least three ways in
: which the C++ and Fortran complexes (complices?) can be incompatible:

: (2) The size and representation of the floating point types involved.
: Neither the C++ nor Fortran standards make any guarantees about this,
: beyond a few minimum precision requirements.

: (3) The calling convention of these functions you want to use. Nobody
: guarantees that a plain C++ or extern "C" function is call-compatible
: with a Fortran object module; nor does the C++ standard require the
: availability of an extern "Fortran" option.

As the originator of this thread I recognise I made a tactical error in
not pointing out from the start that compatibility between C++ and C
obvious complex values is also desirable. In this case you get (2) and (3)
automatically (with an extern "C"). The question then reduces to C and
Fortran compatibility, which is likely if the vendor used whichever format
he had first to define the other. This leaves the issue this thread is
about.

--
Christopher Dearlove BAE SYSTEMS Advanced Technology Centres

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Chris Dearlove <cmd@gmrc.gecm.com> wrote in message
news:8s27bc$768$1@miranda.gmrc.gecm.com...
> Ross Smith (ross.s@ihug.co.nz) wrote:

> In this case you get (2) and (3) automatically (with an extern "C").

You don't get (3) automatically. All you can guarantee is that it won't be
name-mangled. Does not guarantee that there is a C compiler out there that
has the same calling convention as your C++ compiler.

In practice compiler vendors arrange things nicely.

Stephen Howe


---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8s4t3k$iho$1@soap.pipex.net>,
Stephen Howe <SPAMGUARDstephen.howe@dial.pipex.co.uk> wrote:
>
>Chris Dearlove <cmd@gmrc.gecm.com> wrote in message
>news:8s27bc$768$1@miranda.gmrc.gecm.com...
>> Ross Smith (ross.s@ihug.co.nz) wrote:
>
>> In this case you get (2) and (3) automatically (with an extern "C").
>
>You don't get (3) automatically. All you can guarantee is that it won't be
>name-mangled. Does not guarantee that there is a C compiler out there that
>has the same calling convention as your C++ compiler.
>
>In practice compiler vendors arrange things nicely.

Well, even C doesn't guarantee that two different compilers use the same
calling convention.  But in practice, it's the OS vendor who specifies
calling conventions, and compilers normally comply.  I believe most C++
users expect that extern "C" does this as well.  Otherwise, of what use is
it?  What good is it to prevent name-mangling if you still can't call the
function?

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Chris Dearlove wrote:
>
> Ross Smith (ross.s@ihug.co.nz) wrote:
> : The point you seem to be missing is that merely specifying that complex
> : contains the Cartesian representation in (Re,Im) order is _not_ enough
> : to guarantee layout compatibility. There are at least three ways in
> : which the C++ and Fortran complexes (complices?) can be incompatible:
>
> : (2) The size and representation of the floating point types involved.
> : Neither the C++ nor Fortran standards make any guarantees about this,
> : beyond a few minimum precision requirements.
>
> : (3) The calling convention of these functions you want to use. Nobody
> : guarantees that a plain C++ or extern "C" function is call-compatible
> : with a Fortran object module; nor does the C++ standard require the
> : availability of an extern "Fortran" option.
>
> As the originator of this thread I recognise I made a tactical error in
> not pointing out from the start that compatibility between C++ and C
> obvious complex values is also desirable. In this case you get (2) and (3)
> automatically (with an extern "C"). The question then reduces to C and

The C standard doesn't specify the size or representation either. It
does specify that "double complex" is stored as if it were an array of 2
doubles, containing the real and complex parts, but it doesn't specify
the size or representation of double unless the implementation chooses
to define __STDC_IEC_559__.

The C standard says absolutely nothing about calling conventions; in
particular, it makes no guarantees of Fortran compatibility. Therefore,
C compatibility gives you no clue about (3).

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Ross Smith (ross.s@ihug.co.nz) wrote:
> (3) The calling convention of these functions you want to use.
> Nobody guarantees that a plain C++ or extern "C" function is
> call-compatible with a Fortran object module; nor does the C++
> standard require the availability of an extern "Fortran" option.

Does the standard require the availability of the "C" option, and
if so does it guarantee anything useful about interoperability with
code compiled by someone else's C compiler? (I think this came up
a month or so back and the answers were "yes" and "no".)

Barry Margolin () wrote...

> If the system already has interoperability between C and Fortran
> (which is likely -- often (2) is dictated by the hardware, and
> (3) is specified by the OS's ABI), and extern "C" guarantees C
> compatibilility, then it also guarantees Fortran compatibility as
> well.

This is true, but still not quite useful enough, because...

(2) I cannot *portably* know which of the floating point types
correspond in each language, or whether the language subsystems
will co-operate in their management of the floating point hardware.
(For an IEEE machine, there are exception handlers to install,
precision and rounding modes to set, etc.)

(3) The ABI may not supported by the compiler, but not as the
default. On Windows, the ABI is the "__stdcall" calling convention,
but you only get it if you use either the qualifier or select a
compiler option that forces its use, and it doesn't support variable
length argument lists.

These may not be problems in practice, but as I've argued already,
the layout probably won't be a problem in practice either. I remain
convinced by James' counter-arguments that fixing the layout (however
painless it may be) is insufficient to ensure *portable* usefulness.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8rk3am$mv0$1@miranda.gmrc.gecm.com>,
  chris.dearlove@baesystems.com wrote:
> Christopher Eltschka (celtschk@physik.tu-muenchen.de) wrote:
> : Barry Margolin wrote:
> : It could fail if a polar representation is used.
>
> Am I missing something? I can't see that code snippet failing because
it's
> purely using the standard complex member functions and nothing about
the
> storage. If real() could return something other than its mathematical
> meaning you can throw away that compiler.

Floating point errors, for one.

> In short I believe this and other alternative arrangements are not
realistic,
> but not prohibited by the standard as it currently stands. I agree
that it
> is a step away from a pure object oriented approach, and had it not
been
> for the vector DR I wouldn't even have raised it, but IMHO that is
equally
> non-object oriented, but a very good thing. Like much in C++ you are
free
> to ignore it of course and stick to pure OO. However interfacing to
libraries
> which don't use C++ complex numbers but use real numbers is a real
requirement
> and it would be desirable to be able to be able to be confident that
my
> interface will remain valid if I change compilers (something which I
may have
> insufficient control over, a point I failed to make in replying to a
> suggestion that this is a quality of implementation issue in another
posting).

I think there's a distinct difference between the two cases.
Conversion of std::vector to a type usable in legacy code (i.e. those
taking a pointer to an array) is both expensive and not exception safe
(with out effort and further bloat).  Where as it would be trivial to
create a conversion type to go from std::complex<double> to a Fortran
compatible binary representation in a fast and exception safe manner.

In other words, there's a compelling reason to mandate the obvious for
std::vector, but there isn't any for std::complex.

> Incidentally I think I made a tactical error in starting this thread
by
> quoting interfacing to Fortran (important though that may be). I
should have
> quoted interfacing C++ complex arrays with C real arrays with double
the
> length. It's the same issue, but compatibility with C might get more
sympathy
> than compatibility with Fortran.

I doubt it.  The std::vector DR is about compatibility with C++, not
with C, even though people often describe it as "interfacing with
legacy C code".  For instance, strcpy is a C++ method for which the DR
could be applied (yes, I know, there are better C++ solutions, this is
just a single example).

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Chris Dearlove" <cmd@gmrc.gecm.com> wrote...
>
> Consequently I think you can impose a realistic constraint
> on C++, that it does the obvious thing. I would still be
> interested to know if there is any compiler out there that
> doesn't.

Agreed. If complex arithmetic is done "in software" then I
can't see any reason to order the real and imaginary parts
in anything except the obvious fashion.

Furthermore, if Fortran requires a particular ordering,
then any CPU designer thinking about dedicated hardware
for complex arithmetic has a real incentive to use the
Fortran layout. If the C and C++ standards also demanded
the same layout then the incentive might be irresistible.

In summary, I think the proposed restriction is painless
and useful.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Barry Margolin" <barmar@genuity.net> wrote...
>
> I realize all this.  But many applications that use complex
> numbers make extensive use of polar representation, so if
> someone is coding such an application the costs of the extra
> members might be outweighed by all the trig functions that
> are saved.

I think the target audience for the complex template is people
doing scientific or engineering calculations. They want something
that can stuff their floating point pipelines until it hurts.

There *is* room for a polar complex class, but only if a cartesian
one is provided as well. Conversions between the two might even be
labelled "explicit", just so that no-one uses them by mistake.
(In passing, I think deriving one from the other, or even both
from a base class, will produce a performance hit that is not
acceptable to the number crunching community.)

However, the standard only provides one, and the only reasonable
choice for implementers is to use a cartesian representation,
since a cartesian multiply is sluggish, but a polar add is beyond
the pale. With that decision made, insisting on a particular
layout is not controversial, is it?
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

<sirwillard@my-deja.com> wrote...
>
> Where as it would be trivial to
> create a conversion type to go from std::complex<double> to a Fortran
> compatible binary representation in a fast and exception safe manner.
>
> In other words, there's a compelling reason to mandate the obvious for
> std::vector, but there isn't any for std::complex.

Lets say I have an array of 50 million complex<float>. Lets
also say there is a routine to solve my problem, written by
some expert who has forgotten more about numerical coding than
I'll ever know. Clearly I'd be stupid to write my own routine.
(It could take me *years* to get it right.) So I'm going to
pass this array to the Fortran code. Typically this step has
to be done in the innermost loop. :-(

If the types are layout-compatible, I can pass the address
and use the results with ZERO overhead. If I have to invoke
a conversion routine boing in and coming out, and especially
if that conversion isn't "in-place" (requiring that I allocate
memory and thrash my page file into the ground), then I'm
going to be mightily unimpressed with my library author.

I think that you (and Gabriel Dos Reis) are thinking of the
complex instantiations as some kind of abstract data type,
and trying to preserve lots of latitude for the implementor.
I really think this is dead wrong. Complex numbers are as
concrete as "int" and "float", and they are provided mainly
for the numerical community. If they aren't laid out in the
obvious manner (and therefore shareable with several billion
lines of Fortran) then as far as that community is concerned
C++ doesn't *have* a complex type, and they have two options
open to them...

1 Lobby for a complex type with the appropriate layout to be
  added at the next round of standardisation.
2 Until then, avoid using C++ since it is deliberately
  incompatible with numerical computing.

Harsh, but if you have a trillion calculations to perform, you
take a dim view of object oriented purists asking you to convert
between formats on each iteration.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ken Hagan wrote:
...
> the pale. With that decision made, insisting on a particular
> layout is not controversial, is it?

Yes it is. It's inconsistent with the rest of the standard. In most
(all?) of the other places where the standard defines a struct, the
layout is normally left up to the implementation.

The main argument for having the standard specify the order of the
components if Fortran compatibility. However, you don't have a ghost of
a chance of being compatible with Fortran unless the implementor goes
out of his way to make it possible. Do you think an implementor is going
to go to all the trouble (not required by the C++ standard) to make
their function call interfaces compatible with Fortran, and then mess up
by not making complex<> compatible just because the C++ standard doesn't
specify it?

I don't think there's sufficient need to justify having the standard
specify the layout.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Ken Hagan wrote:
>
> Lets say I have an array of 50 million complex<float>. Lets
> also say there is a routine to solve my problem, written by
> some expert who has forgotten more about numerical coding than
> I'll ever know. Clearly I'd be stupid to write my own routine.
> (It could take me *years* to get it right.) So I'm going to
> pass this array to the Fortran code. Typically this step has
> to be done in the innermost loop. :-(
>
> If the types are layout-compatible, I can pass the address
> and use the results with ZERO overhead. If I have to invoke
> a conversion routine boing in and coming out, and especially
> if that conversion isn't "in-place" (requiring that I allocate
> memory and thrash my page file into the ground), then I'm
> going to be mightily unimpressed with my library author.

The point you seem to be missing is that merely specifying that complex
contains the Cartesian representation in (Re,Im) order is _not_ enough
to guarantee layout compatibility. There are at least three ways in
which the C++ and Fortran complexes (complices?) can be incompatible:

(1) The representation and layout, the issue you seem to be fixated on.

(2) The size and representation of the floating point types involved.
Neither the C++ nor Fortran standards make any guarantees about this,
beyond a few minimum precision requirements.

(3) The calling convention of these functions you want to use. Nobody
guarantees that a plain C++ or extern "C" function is call-compatible
with a Fortran object module; nor does the C++ standard require the
availability of an extern "Fortran" option.

Your arguments seem to be based on the premise that fixing (1) will
somehow magically fix (2) and (3) as well (not to mention any other
considerations I may have forgotten here). In the real world, there's no
way of guaranteeing (2) and (3) short of explicitly requiring Fortran
compatibility in the C++ standard (which would open such an enormnous
can of worms that nobody sane would consider it for a moment), so why
waste effort guaranteeing (1) when it won't help anyway?

If your compiler and library vendors understand your desire to mix C++
and Fortran code, which I believe they generally do, they'll make an
effort to cooperate. If they don't, they won't, and you won't be able to
rely on them working together except by blind luck, _no matter what the
standard says_.

If you're prepared to trust your vendors to get (2) and (3) right in the
absence of a standard requiring it, why aren't you prepared to trust
them to get (1) right?

--
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
"C++ is to programming as sex is to reproduction. Better ways might
technically exist but they're not nearly as much fun." -- Nikolai Irgens

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"James Kuyper" <kuyper@wizard.net> wrote...
>
> The main argument for having the standard specify the order of the
> components if Fortran compatibility. However, you don't have a ghost of
> a chance of being compatible with Fortran unless the implementor goes
> out of his way to make it possible. Do you think an implementor is going
> to go to all the trouble (not required by the C++ standard) to make
> their function call interfaces compatible with Fortran, and then mess up
> by not making complex<> compatible just because the C++ standard doesn't
> specify it?

Hmm, since I've made several postings to the effect that you'd
have to be brain dead to use anything except the usual ordering,
I suppose I have to find this argument convincing. :-)
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <39E37A18.A6A8252A@ihug.co.nz>,
Ross Smith  <ross.s@ihug.co.nz> wrote:
>Ken Hagan wrote:
>>
>> Lets say I have an array of 50 million complex<float>. Lets
>> also say there is a routine to solve my problem, written by
>> some expert who has forgotten more about numerical coding than
>> I'll ever know. Clearly I'd be stupid to write my own routine.
>> (It could take me *years* to get it right.) So I'm going to
>> pass this array to the Fortran code. Typically this step has
>> to be done in the innermost loop. :-(
>>
>> If the types are layout-compatible, I can pass the address
>> and use the results with ZERO overhead. If I have to invoke
>> a conversion routine boing in and coming out, and especially
>> if that conversion isn't "in-place" (requiring that I allocate
>> memory and thrash my page file into the ground), then I'm
>> going to be mightily unimpressed with my library author.
>
>The point you seem to be missing is that merely specifying that complex
>contains the Cartesian representation in (Re,Im) order is _not_ enough
>to guarantee layout compatibility. There are at least three ways in
>which the C++ and Fortran complexes (complices?) can be incompatible:
>
>(1) The representation and layout, the issue you seem to be fixated on.
>
>(2) The size and representation of the floating point types involved.
>Neither the C++ nor Fortran standards make any guarantees about this,
>beyond a few minimum precision requirements.
>
>(3) The calling convention of these functions you want to use. Nobody
>guarantees that a plain C++ or extern "C" function is call-compatible
>with a Fortran object module; nor does the C++ standard require the
>availability of an extern "Fortran" option.
>
>Your arguments seem to be based on the premise that fixing (1) will
>somehow magically fix (2) and (3) as well (not to mention any other
>considerations I may have forgotten here). In the real world, there's no
>way of guaranteeing (2) and (3) short of explicitly requiring Fortran
>compatibility in the C++ standard (which would open such an enormnous
>can of worms that nobody sane would consider it for a moment), so why
>waste effort guaranteeing (1) when it won't help anyway?

If the system already has interoperability between C and Fortran (which is
likely -- often (2) is dictated by the hardware, and (3) is specified by
the OS's ABI), and extern "C" guarantees C compatibilility, then it also
guarantees Fortran compatibility as well.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8rk3am$mv0$1@miranda.gmrc.gecm.com>,
Chris Dearlove <chris.dearlove@baesystems.com> wrote:
>Christopher Eltschka (celtschk@physik.tu-muenchen.de) wrote:
>: Barry Margolin wrote:
>: >
>: > In article <8rf556$6nm$1@miranda.gmrc.gecm.com>,
>: > Chris Dearlove <chris.dearlove@baesystems.com> wrote:
>: > >(To be specific the "obvious thing" is that sizeof(complex<real>)
>: > >== 2 * sizeof(real) for appropriate real types and that storage is
>: > >of real and imaginary parts in that order. A precise statement could
>: > >use casts or a union.)
>: >
>: > Is this "obvious thing" really desirable, though?  While it might be useful
>: > when sharing data with Fortran, it's quite anti-Object Oriented, isn't it?
>: > One of the main features of OO programming is that representations are
>: > hidden, and only the interface matters.  An implementation should be
>: > permitted to store complexes using polar notation if it wishes;
>
>: Hmmm... is the following allowed to fail?
>
>:   double a = foo(), b = bar();
>:   assert(std::complex<double>(a, b).real() == a &&
>:          std::complex<double>(a, b).imag() == b);
>
>: It could fail if a polar representation is used.
>
>Am I missing something? I can't see that code snippet failing because it's
>purely using the standard complex member functions and nothing about the
>storage. If real() could return something other than its mathematical
>meaning you can throw away that compiler.

I think the issue he's raising is that storing the data in polar format
implies that asking for its real or imaginary component will involve a
conversion, which is almost certainly going to have a round-off error, so
the == test will fail.

>
>: > I can
>: > easily conceive of an implementation that uses a union of polar and
>: > rectangular coordinates, determining dynamically which one is most
>: > appropriate at the time, or one that has members for both, caching them as
>: > needed.
>
>: This is, of course, possible. If it's a good idea is another
>: question. After all, complex numbers will probably be used
>: mainly for numerics, where speed is one of the most important
>: considerations.
>
>(I'm replying to Mr. Margolin - whose posting hasn't reached me yet, as
>hasn't one of mine! - as well as Mr. Eltschka.)
>
>Yes a complex number could store polar coordinates. I considered mentioning
>such a possibility in one of my postings, but decided it was a red herring.
>Although superficially attractive I believe no one would actually code a
>complex number in that way. One reason is that anyone who uses complex
>numbers knows which operations are expensive and codes accordingly. In
>addition you would have to make a complex store cartesian and polar
>coordinates (polar only is a nightmare) and make the latter mutable
>(or else you've made a critical speed hit) with an indication of when
>valid. This now makes a complex number much bigger, with costs whenever
>copying complex numbers, and slower even when adding (you need to mark
>the polar coordinates no longer valid). In short any intelligent user
>of complex numbers who cared about processing load would find it got
>worse, not better. This of course isn't even considering the extra
>programming work.

I realize all this.  But many applications that use complex numbers make
extensive use of polar representation, so if someone is coding such an
application the costs of the extra members might be outweighed by all the
trig functions that are saved.

To do it right, you probably wouldn't make this a feature of the complex<T>
base class, but instead define a derived class polar_complex<T> that adds
the additional members and overrides the appropriate functions.  This way,
only applications that need this stuff would pay the performance penalty.
Although if the member functions of complex<T> aren't virtual, this
wouldn't work too well (I haven't checked the C++ standard's specification
of the complex<T> class).

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Barry Margolin <barmar@genuity.net> writes:

| In article <8rf556$6nm$1@miranda.gmrc.gecm.com>,
| Chris Dearlove <chris.dearlove@baesystems.com> wrote:
| >Consequently I think you can impose a realistic constraint on C++, that
| >it does the obvious thing. I would still be interested to know if there
| >is any compiler out there that doesn't.
| >
| >(To be specific the "obvious thing" is that sizeof(complex<real>)
| >== 2 * sizeof(real) for appropriate real types and that storage is
| >of real and imaginary parts in that order. A precise statement could
| >use casts or a union.)
|
| Is this "obvious thing" really desirable, though?  While it might be useful
| when sharing data with Fortran, it's quite anti-Object Oriented, isn't it?

Well, whatr does it really mean to be "Object Oriented" and
"anti-Object Oriented"?  (Yes, that is a rhetorical question bnut I
take it seriously).

The std::complex<> is meant to *store* the real and imaginary parts of
a complex number.  You might argue that that description isn't really
applying "information hiding" principle. Maybe; maybe not.  The most
important thing being that the actual layout is hidden.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <8rf556$6nm$1@miranda.gmrc.gecm.com>,
Chris Dearlove <chris.dearlove@baesystems.com> wrote:
>Consequently I think you can impose a realistic constraint on C++, that
>it does the obvious thing. I would still be interested to know if there
>is any compiler out there that doesn't.
>
>(To be specific the "obvious thing" is that sizeof(complex<real>)
>== 2 * sizeof(real) for appropriate real types and that storage is
>of real and imaginary parts in that order. A precise statement could
>use casts or a union.)

Is this "obvious thing" really desirable, though?  While it might be useful
when sharing data with Fortran, it's quite anti-Object Oriented, isn't it?
One of the main features of OO programming is that representations are
hidden, and only the interface matters.  An implementation should be
permitted to store complexes using polar notation if it wishes; I can
easily conceive of an implementation that uses a union of polar and
rectangular coordinates, determining dynamically which one is most
appropriate at the time, or one that has members for both, caching them as
needed.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Barry Margolin wrote:
>
> In article <8rf556$6nm$1@miranda.gmrc.gecm.com>,
> Chris Dearlove <chris.dearlove@baesystems.com> wrote:
> >Consequently I think you can impose a realistic constraint on C++, that
> >it does the obvious thing. I would still be interested to know if there
> >is any compiler out there that doesn't.
> >
> >(To be specific the "obvious thing" is that sizeof(complex<real>)
> >== 2 * sizeof(real) for appropriate real types and that storage is
> >of real and imaginary parts in that order. A precise statement could
> >use casts or a union.)
>
> Is this "obvious thing" really desirable, though?  While it might be useful
> when sharing data with Fortran, it's quite anti-Object Oriented, isn't it?
> One of the main features of OO programming is that representations are
> hidden, and only the interface matters.  An implementation should be
> permitted to store complexes using polar notation if it wishes;

Hmmm... is the following allowed to fail?

  double a = foo(), b = bar();
  assert(std::complex<double>(a, b).real() == a &&
         std::complex<double>(a, b).imag() == b);

It could fail if a polar representation is used.

> I can
> easily conceive of an implementation that uses a union of polar and
> rectangular coordinates, determining dynamically which one is most
> appropriate at the time, or one that has members for both, caching them as
> needed.

This is, of course, possible. If it's a good idea is another
question. After all, complex numbers will probably be used
mainly for numerics, where speed is one of the most important
considerations.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Christopher Eltschka (celtschk@physik.tu-muenchen.de) wrote:
: Barry Margolin wrote:
: >
: > In article <8rf556$6nm$1@miranda.gmrc.gecm.com>,
: > Chris Dearlove <chris.dearlove@baesystems.com> wrote:
: > >(To be specific the "obvious thing" is that sizeof(complex<real>)
: > >== 2 * sizeof(real) for appropriate real types and that storage is
: > >of real and imaginary parts in that order. A precise statement could
: > >use casts or a union.)
: >
: > Is this "obvious thing" really desirable, though?  While it might be useful
: > when sharing data with Fortran, it's quite anti-Object Oriented, isn't it?
: > One of the main features of OO programming is that representations are
: > hidden, and only the interface matters.  An implementation should be
: > permitted to store complexes using polar notation if it wishes;

: Hmmm... is the following allowed to fail?

:   double a = foo(), b = bar();
:   assert(std::complex<double>(a, b).real() == a &&
:          std::complex<double>(a, b).imag() == b);

: It could fail if a polar representation is used.

Am I missing something? I can't see that code snippet failing because it's
purely using the standard complex member functions and nothing about the
storage. If real() could return something other than its mathematical
meaning you can throw away that compiler.

: > I can
: > easily conceive of an implementation that uses a union of polar and
: > rectangular coordinates, determining dynamically which one is most
: > appropriate at the time, or one that has members for both, caching them as
: > needed.

: This is, of course, possible. If it's a good idea is another
: question. After all, complex numbers will probably be used
: mainly for numerics, where speed is one of the most important
: considerations.

(I'm replying to Mr. Margolin - whose posting hasn't reached me yet, as
hasn't one of mine! - as well as Mr. Eltschka.)

Yes a complex number could store polar coordinates. I considered mentioning
such a possibility in one of my postings, but decided it was a red herring.
Although superficially attractive I believe no one would actually code a
complex number in that way. One reason is that anyone who uses complex
numbers knows which operations are expensive and codes accordingly. In
addition you would have to make a complex store cartesian and polar
coordinates (polar only is a nightmare) and make the latter mutable
(or else you've made a critical speed hit) with an indication of when
valid. This now makes a complex number much bigger, with costs whenever
copying complex numbers, and slower even when adding (you need to mark
the polar coordinates no longer valid). In short any intelligent user
of complex numbers who cared about processing load would find it got
worse, not better. This of course isn't even considering the extra
programming work.

In short I believe this and other alternative arrangements are not realistic,
but not prohibited by the standard as it currently stands. I agree that it
is a step away from a pure object oriented approach, and had it not been
for the vector DR I wouldn't even have raised it, but IMHO that is equally
non-object oriented, but a very good thing. Like much in C++ you are free
to ignore it of course and stick to pure OO. However interfacing to libraries
which don't use C++ complex numbers but use real numbers is a real requirement
and it would be desirable to be able to be able to be confident that my
interface will remain valid if I change compilers (something which I may have
insufficient control over, a point I failed to make in replying to a
suggestion that this is a quality of implementation issue in another posting).

Incidentally I think I made a tactical error in starting this thread by
quoting interfacing to Fortran (important though that may be). I should have
quoted interfacing C++ complex arrays with C real arrays with double the
length. It's the same issue, but compatibility with C might get more sympathy
than compatibility with Fortran. I suspect this whole area is one where
there isn't the support, but I continue to think that (unless anyone has a
real example to the contrary) this would be painless, useful and analagous
to the vector case (although slightly weaker and of narrower application).

--
Christopher Dearlove, BAE SYSTEMS Advanced Technology Centres

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Chris Dearlove wrote:
>
> James Kuyper (kuyper@wizard.net) wrote:
> : Chris Dearlove wrote:
> : ...
> : > 26.2.2p1 notes that (I want cut and paste here!) "The class complex
> : > describes an object that can store the Cartesian components, real()
> : > and imag(), of a complex number." which suggests to me that this
> : > representation was what was assumed, if not specified.
>
> : It doesn't specify how they are to be stored. For generic T, the obvious
> : implementation of std::complex<T> is as two values of type T, but the
> : order is unspecified, and there could in principle be additional data
> : stored in the object as well. For the specializations for T==double, you
> : could have the real and imaginary parts stored in the even and odd bits
> : of a chunk of memory that's twice the size of a double.
>
> I may not have made myself clear. I know it isn't specified; I want to
> know if it could be. ...

No, I got that. However, you seemed to believe that some particular
representation might have been assumed; it wasn't. That's the part of
your question I was responding to. The writers of the standard
deliberately avoided assuming anything they didn't need to, so as to
give implementators as much freedom as they could safely be given.

...
> should) be so specified. My point in including the above quotation was
> to note that it appears to indicate thinking that assumed the obvious
> storage (otherwise why even mention the Cartesian components at all?)
> but, as you say, doesn't specify it.

Meantioning the cartesian components is not the same as making any
assumptions whatsoever as to how they're stored. In particular, putting
the imaginary part first would be perfectly legal, if unconventional.

> The key question remains, are there any implementations that don't do the
> obvious thing? If no, is this realistically ever going to change?

I've no idea, which is why I didn't answer that question. I'll leave it
to someone else.

Incidentally
> isn't generic T a red herring, only float, double and long double have to be
> supported, and it's only these cases that would drive the original requirement
> (interfacing to other languages, especially Fortran numerical libraries).

I just mentioned it for completeness. Personally, I'd prefer that
complex<T> have no restrictions on T that aren't derived from what
complex<> needs to do: T must support most of the standard numerical
operators. Several transcendental functions must be overloaded for T.
With the current rules, an implementation is free to use
std::atan2(t1,t2), but if arbitrary T were allowed, an implementation
should use atan2(t1,t2) instead, allowing a user-defined overload of
'atan2()' to be used.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Stephen Clamage (stephen.clamage@sun.com) wrote:

<snipped pointing out that I should have noticed my DR question in
the FAQ list>

: There is no requirement on the actual contents or layout of the C++
: complex number classes. A C++ implementation might match the layout of
: Fortan complex, but unless the vendor documents the compatibility, you
: cannot rely on it.

: >- If the answer to the first question is no then could this be
: >  considered as a requirement?

: It's a bit difficult to write such a requirement in the C++ standard.

I fail to see this, given what follows below.

: The Fortran standard, afaik, does not specify how type complex is
: implemented.

I believe this is incorrect, and that Fortran 77 at least does mandate
that complex values are stored as consecutive reals. (This was from memory,
but I have discovered that there is an HTML version of the Fortran standard
at http://www.fortran.com/fortran/F77_std/rjcnf0001.html. The final
sentence of section 4.6 is the relevant one.) I would be surprised if
this guarantee were removed in Fortran 90/95, but I have no access to
that standard.

: Existing Fortran implementations corresond to different
: versions (or to no version) of the various Fortran standards. Often,
: multiple incompatible Fortran implementations are available on a given
: platform, or no Fortran implementation at all. How do you make a
: meaningful, platform-independent, C++ requirement that C++ complex be
: implemented in a way compatible with Fortran complex?

Consequently I think you can impose a realistic constraint on C++, that
it does the obvious thing. I would still be interested to know if there
is any compiler out there that doesn't.

(To be specific the "obvious thing" is that sizeof(complex<real>)
== 2 * sizeof(real) for appropriate real types and that storage is
of real and imaginary parts in that order. A precise statement could
use casts or a union.)

: IMHO, this sort of thing is best left as a quality-of-implementation
: issue. A vendor who sees a market advantage in doing so could make
: object code from various language compilers compatible.

Here I disagree. As far as interfacing to Fortran libraries the issue
is, if there are no compilers not doing the obvious thing, directly
analagous to the vector issue. Yes, I realise there are issues within
C++ that make the vector issue desirable, and the complex case has
no equivalent there (well, probably not in "good" code anyway) but
there are in interfacing to C as well as to Fortran.

And yes, this would be useful since I could write my code in a way
which only required me to match Fortran and C++ real types - which
should be well documented in each case. For interfacing to C there
isn't even this issue - if C++'s complex gave the guarantee I'd like.

--
Christopher Dearlove

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

There has been some (helpful to me) discussion about vector here
recently asserting that all current compilers use continuous
vectors, and that this may become the subject of a Defect Report.
(As an aside how are C++ DRs made available?) This is useful
when considering interfacing to, for example, Fortran numerical
libraries. (A standardised matrix class would be handy too.)

In interfacing to such libraries (something I've been doing
recently) another similar subject which arises in that of
complex numbers. It is similarly convenient to be able to alias
C++ and Fortran complex types. I've been able to do this on the
system I've used, but obviously this is potentially dangerous,
and I would like to reduce the danger. Thus the questions

- Are there any existing systems on which it is not true that
  sizeof(complex<real>) == 2 * sizeof(real) for the appropriate
  real types, with the obvious layout (real then imag)?

- If the answer to the first question is no then could this be
  considered as a requirement?

Obviously this is slightly less obvious than for the vector class,
and it is possible to imagine alternatives (such as with additional
mutable members to avoid recalculations) but the fact that complex
numbers are often passed by value would make these probably less
efficient (and a lot more difficult to write). In addition I note
26.2.2p1 notes that (I want cut and paste here!) "The class complex
describes an object that can store the Cartesian components, real()
and imag(), of a complex number." which suggests to me that this
representation was what was assumed, if not specified.

--
Christopher Dearlove
BAE SYSTEMS Advanced Technology Centres - Great Baddow (Chelmsford UK)

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Chris Dearlove wrote:
...
> 26.2.2p1 notes that (I want cut and paste here!) "The class complex
> describes an object that can store the Cartesian components, real()
> and imag(), of a complex number." which suggests to me that this
> representation was what was assumed, if not specified.

It doesn't specify how they are to be stored. For generic T, the obvious
implementation of std::complex<T> is as two values of type T, but the
order is unspecified, and there could in principle be additional data
stored in the object as well. For the specializations for T==double, you
could have the real and imaginary parts stored in the even and odd bits
of a chunk of memory that's twice the size of a double.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Fri, 29 Sep 2000 12:40:45 CST, cmd@gmrc.gecm.com (Chris Dearlove)
wrote:

>There has been some (helpful to me) discussion about vector here
>recently asserting that all current compilers use continuous
>vectors, and that this may become the subject of a Defect Report.

It IS the subject of a DR, and sentiment within the C++ committee is
in favor of making it a requirement. The issue is not yet settled,
however.

>(As an aside how are C++ DRs made available?)

See the FAQ referenced at the end of every article in this newsgroup.

> This is useful
>when considering interfacing to, for example, Fortran numerical
>libraries. (A standardised matrix class would be handy too.)
>
>In interfacing to such libraries (something I've been doing
>recently) another similar subject which arises in that of
>complex numbers. It is similarly convenient to be able to alias
>C++ and Fortran complex types. I've been able to do this on the
>system I've used, but obviously this is potentially dangerous,
>and I would like to reduce the danger. Thus the questions
>
>- Are there any existing systems on which it is not true that
>  sizeof(complex<real>) == 2 * sizeof(real) for the appropriate
>  real types, with the obvious layout (real then imag)?

There is no requirement on the actual contents or layout of the C++
complex number classes. A C++ implementation might match the layout of
Fortan complex, but unless the vendor documents the compatibility, you
cannot rely on it.

>
>- If the answer to the first question is no then could this be
>  considered as a requirement?

It's a bit difficult to write such a requirement in the C++ standard.

The Fortran standard, afaik, does not specify how type complex is
implemented. Existing Fortran implementations corresond to different
versions (or to no version) of the various Fortran standards. Often,
multiple incompatible Fortran implementations are available on a given
platform, or no Fortran implementation at all. How do you make a
meaningful, platform-independent, C++ requirement that C++ complex be
implemented in a way compatible with Fortran complex?

IMHO, this sort of thing is best left as a quality-of-implementation
issue. A vendor who sees a market advantage in doing so could make
object code from various language compilers compatible.

---
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper (kuyper@wizard.net) wrote:
: Chris Dearlove wrote:
: ...
: > 26.2.2p1 notes that (I want cut and paste here!) "The class complex
: > describes an object that can store the Cartesian components, real()
: > and imag(), of a complex number." which suggests to me that this
: > representation was what was assumed, if not specified.

: It doesn't specify how they are to be stored. For generic T, the obvious
: implementation of std::complex<T> is as two values of type T, but the
: order is unspecified, and there could in principle be additional data
: stored in the object as well. For the specializations for T==double, you
: could have the real and imaginary parts stored in the even and odd bits
: of a chunk of memory that's twice the size of a double.

I may not have made myself clear. I know it isn't specified; I want to
know if it could be. This is (I believe) exactly analagous to vector which
isn't specified as contiguous, but it is now agreed that it could (and
should) be so specified. My point in including the above quotation was
to note that it appears to indicate thinking that assumed the obvious
storage (otherwise why even mention the Cartesian components at all?)
but, as you say, doesn't specify it.

The key question remains, are there any implementations that don't do the
obvious thing? If no, is this realistically ever going to change? Incidentally
isn't generic T a red herring, only float, double and long double have to be
supported, and it's only these cases that would drive the original requirement
(interfacing to other languages, especially Fortran numerical libraries).

--
Christopher Dearlove, chris.dearlove@baesystems.com
BAE SYSTEMS Advanced Technology Centres - Great Baddow, Chelmsford, UK

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]