Re: [boost] std::complex (Was: Re: multi_array management)

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-13 15:39:06

Here is the transcript of my discussion with John Spicer of EDG about the
restrictions on PODs, the rationale, and the reasons we need the
restrictions loosened.

-Dave

[Dave]
We have some bitter complaints about the liberal conditions which
cause a type to become non-POD, particularly the presence of any
constructor. We have some numerics experts preparing the specifics
(this came up because you can't convert a complex<double>* into a
double* portably), but I thought we should get your feedback about the
reasoning for the status quo...

[John]
PODs are supposed to be basically C structs, and can be manipulated
using mechanisms like memcpy.  If a class has a constructor, the
thought is that you should be using constructors for things like
copying.

I think we need PODs, but it would be possible to add another kind of
object type that had known layout properties (e.g., no virtual
functions, no base classes).

[ed. note: by this I think John means that we ought to leave the
  concept "POD" alone, but a new concept which captures the
  restrictions we need is possible]

[Dave]
What's so bad about base classes?

They could be extremely useful in the context of PODs. Just look at
how often 'C' programmers simulate base classes by
embedding-and-casting, or other equally odious approaches (macros). If
we allowed base classes, at least implicit conversions (upcasts) would
work properly.

[John]
Don't the existing C++ language facilities handle those cases
sufficiently?

[Dave]
Not when you need to make a POD. For example, the Python API does
everything in terms of PyObject*. Every object has to start with a
PyObject at its head. Now suppose I want, essentially, this:

    class Foo : non_pod
    {
        ...
    };

    struct MyPyObject : PyObject
    {
        Foo* my_data;
    };

    Now it's no longer a POD, so instead I need to write:

    struct MyPyObject
    {
        PyObject head;
        Foo* my_data;
    };

Now I can't pass MyPyObject*s directly to the Python API anymore.

[ed. note: I see the ability to use inheritance with PODs (or
something with some of the same properties) as an important part of
making C++ "a better 'C'", which is one of its goals]

[John]
The low-level stuff you do, the more you limit implementation choices.
   ^--- [ed.: "more"? ]
For example, if you have an empty base, is it given storage at the
start of the derived class or not?

[Dave]
Implementors don't need that freedom as much as I need power and
predictability ;-)

[John]
Plus, of course, you'd have to limit it to single inheritence.

[Dave]
Not neccessarily, but if you insist I can live with it.

You could just say that struct mypod : podA, podB {};
has the same layout as struct mypod { podA a; podB b; };

[John]
Thanks for the explanation.  Are you going to propose a change in this
area?

[Dave]
Yes, well, Ralf is going to write the proposal. He's an actual
numerics user with real concerns in this area. I think his
point-of-view will carry extra "street cred". I'm going to "sponsor"
his proposal as needed.