[boost] Re: 98% portable ptr<>

From: David B. Held (dheld_at_[hidden])
Date: 2002-08-20 15:57:33

"Philippe A. Bouchard" <philippeb_at_[hidden]> wrote in message
news:aju40j$qt4$1_at_main.gmane.org...
> "David B. Held" <dheld_at_[hidden]> wrote:
> >
> > Not sure what this means.
>
> - operator +/- is less error-prone because reinterpret_cast<>s would have
to
> be explicit, therefore the pointers will follow rules and regulations of
> alignments.

I got this.

> - element_type not aligned to its type is not specified in the standard
even
> though it is not dereferenced.

Not sure where this fits in either.  What I was really asking about was
this:

> > "Philippe A. Bouchard" <philippeb_at_[hidden]> wrote:
> > > [...]
> > > - ptr_base<T, __false_type>::m_ptr is of type void * to allow perfect
> > > copies;

> > [...]
> > They need to be *tested* to assure that they work properly on
> > all intended platforms
> > [...]
>
> I follow the already tested *rules*.

The "rule" is that reinterpret_cast<> is implementation-dependent.  And
your justification for the various casts is not as straightforward and
obvious as you like to believe.  All the standard guarantees is that
casting from a pointer type to an integer and back will give the same
pointer.  It makes no guarantees about what happens when you start
adding values to the integer.  To show that reinterpret_cast<> does
what you expect, you should write more tests, like Larry has.  The fact
that Larry has already made several tests that expose flaws in the design
does not give me much confidence that everything works as you expect
(or that you didn't expect enough ;).

> [...]
> Yeah I know, I've just noticed it also.  I've noticed also that the
> implementation is the same with gcc's.

Yes, I just verified that both gcc and Rogue Wave have basically the
same implementation.  I was under the impression that the preferred
implementation involved sizeof().  What do I know?

> [...]
> Because convertions from char * to U * is unspecified.  I simply forgot
> to mention it.  Sorry.

Is that so?  That seems like it would make the STL impossible, as it
regularly allocates raw memory as char*, and casts it to the appropriate
T* after construction.  You're going to have to quote chapter and verse
on this one.

Dave