Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-06 16:39:39

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk_at_[hidden]>

> IMO complex<double>() should behave like double().


> OK, I happily go with your bet. Here is the new plan:
> 0. You do (have done already?) the Enhanced POD proposal (could I see

No, I don't.

Err, looking back at what I had, it appears I volunteered you for that
one (see below) ;^S.

I think mostly, the discussion below covers it, but let me know if you
think anything is missing.

> 1. complex<T> proposal:
> a. predictable layout to facilitate use of existing code
> b. members should be directly accessible (T& real() { return
re; })

Yes, though you only really need part a. to get part b.

> 2. propose additional constructors for containers (vector<T> and
> vector(size_t n, no_initialization_flag);
> valarray(size_t n, no_initialization_flag);
> - with compile time assertion that T has a trivial destructor.

I like this idea better:

First, we need a way to construct complex<> without initializing the
members, so we add a constructor


Then we need a way to construct a vector of n uninitialized complexes:

    template <class U>
    vector(size_t n, U const& u)
        // initializes each of n T objects with u.

This is analogous to the existing constructor:

    template <class Iterator>
    vector(Iterator i1, Iterator i2) {}

In fact, there may be some problems with my suggestion; resolving all of
vector's constructor overloads is already tricky. If it's problematic we
can always fall back to using the above constructor with a special
iterator whose value type is "uninitialized". I like this in part
because it only requires changes to complex<> and not to the containers.


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


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...

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

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]

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.

Don't the existing C++ language facilities handle those cases

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]

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?

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

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

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; };

Thanks for the explanation. Are you going to propose a change in this

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at