RE: [pooma-dev] domain architecture diagram

[Julian C. Cummings]

Hi Allan,

I really enjoyed reading through your analysis of
the relationships between the Domain classes.  You
did a great job of unentangling it all.  By the way,
is that UML tool available free-of-charge?  I will
check out the URL you gave for it.  Just a few brief
comments and replies...

>
> The key to understanding the structure is the declaration for the class
> state.
>
> template <> struct DomainTraits< Interval<1> >::Storage_t;
>
> This type encapsulates the runtime state of any Interval<1> object.  The
> N-dimensional case looks like this (paraphrased):
>
> template <int Dim> struct DomainTraits< Interval<Dim> > {
>   typedef UninitializedVector<Interval<1>,Dim,Element_t> Storage_t;
> };
>
> OK, that's interesting.  Interval<N> defines its state in terms of its own
> specialization Interval<1>.

This is why I added a bunch of forward declarations
of the 1D specializations of the Domain classes all
over the place.  Bad things happen if the compiler
is not told in advance that specializations will be
forthcoming.  But the storage scheme does make sense.

>
> The only object with state is DomainBase which contains a member of this
> type Storage_t.  All Interval<> objects inherit their state from this base
> class via this idiom:
>
> struct foo : public base<foo>;
>
> It's important to note that polymorphism does not exist in this construct.
> A unique downcast is always implied.  If the derived class contains no
> state, the downcast becomes a change of interface and nothing more.
>
> template <class DT>
> class DomainBase {
>   // unwrap this object back to its derived-class type
>   inline
>   Domain_t &unwrap() { return *static_cast<Domain_t *>(this); }
>
>   // a const version of unwrap
>   const Domain_t &unwrap() const {
>     return *static_cast<Domain_t *>(const_cast<DomainBase<DT> *>(this));
>   }
> };
>
> I'm curious why the second version is not written:
>
>   static_cast<const Domain_t *>(this);
>
> Is the two-step conversion required by the language, or was this shaped by
> one of the compilers being used at the time?  I don't know the exact rules
> of casting.  Is static_cast defined to leave constness unchanged?

I think this is simply a mistake.  Your version (with
a * in front of it to dereference the result) is
correct.  There is no reason to cast away const here.

> One of the questions I'll be asking myself of the next couple of
> days (as I
> flesh out the formal documentation) is whether placing the
> Storage_t member
> variable at the bottom of the structure (DomainBase) is a vital aspect of
> the unwrap() magic, or is entirely independent as an optimization to avoid
> empty-base-class size penalities, and to what extent it
> complicates the code
> to preserve this as such.

I'm pretty sure this was originally designed to avoid the
empty-base-class size penalties.  The unwrap magic is used
in many other instances, such as the Barton-Nachman trick,
in which the base class is indeed empty.  I don't know if
this issue of the empty base class is important anymore
with current C++ compilers.  If not, then the DomainBase
layer could probably go away, and the actual data storage
could be relocated to the derived classes.

-- Julian C.


Dr. Julian C. Cummings
Staff Scientist, CACR/Caltech
(626) 395-2543
address@hidden