Re: Containers that don't materialise the elements
On 09.11.2010 00:33, David Barrett-Lennard wrote:
On Nov 8, 8:26 pm, Daniel Kr?gler<daniel.krueg...@googlemail.com>
wrote:
From your description it is unclear to me what you specifically mean with "The
IntervalSet is implemented in terms of IntervalList". Is the reinterpret_cast
necessary, because of violations of access restrictions due to non-public
inheritance?
To implement IntervalSet in terms of IntervalList I would normally
compose using a private member, not a base class. I certainly
wouldn't use public inheritance.
I was thinking along these lines:
class IntervalSet
{
public:
IntervalList& AsList() { return list_; }
const IntervalList& AsList() const { return list_; }
...
private:
IntervalList list_;
};
It is easy to support reliable conversion from IntervalSet& to
IntervalList& using a member function. However I don't know how to
support the reverse in a way that's guaranteed by the standard.
If you don't use any form of inheritance, your design is very much limited by
layout constraints. You can legally cast one type S1 into another type S2, if
both are standard-layout types and both have the same number of non-static
member types that each are layout-compatible in a one-to-one correspondence in
the same order - in other words: both S1 and S2 are layout-compatible. For
standard-layout types it is also guaranteed that a pointer to such a structure
can be legally cast to a pointer to its first non-static data member.
As I think you're suggesting, private inheritance from IntervalList
doesn't help because static_cast for upcasting or downcasting
references or pointers is illegal when private inheritance is
involved.
It would, if both types would share the same common data structure and both
IntervalSet and IntervalList would derive from that or would use this as a data
member. In fact, your operations would only need to act on the underlying type
of these. Both IntervalSet and IntervalList would only be thin layers on top of
this underlying type. In fact, no casts would be necessary. This second design
form does not require standard-layout types, but requires that your actual
operations are defined in terms of the underlying type.
But hang on, I just had a thought... Do you know whether a static
member function of IntervalSet is allowed to perform the static_cast?
class IntervalSet : private IntervalList
{
public:
static IntervalList& AsList(IntervalSet& x)
{
return x;
}
static IntervalSet& AsSet(IntervalList& x)
{
// Is this legal?
return static_cast<IntervalSet&>(x);
}
...
};
Unless both IntervalSet and IntervalList are layout-compatible, this won't work.
Without further data available I would say that your example probably runs into
undefined behaviour because of the type aliasing. I don't think that it is
necessary to go this route of reinterpreting memory. You could make IntervalList
a friend of IntervalSet for example or you might just take advantage of the
fact, that they have a shared representation by performing all the work on the
shared representation,
I don't understand how making IntervalList a friend of IntervalSet
would help.
I was referring to the underlying type that both must share to guarantee what
you want. The friend was suggested to allow private inheritance. Other design
options (without friend) are possible, though.
As per a layered design I would expect IntervalList to be implemented
and tested independently of IntervalSet. It may exist in a third
party library and someone using the library decided it can be
exploited to represent sets of integers.
If both types are developed completely independent, not even guaranteeing that
they have the same underlying type, I don't see how you could satisfy the two
requirements of independent development *and* the layout-compatibility that
allows reinterpreting the different types.
I've seen a few examples where it's desirable to reinterpret an object
in a different way without the overhead of a copy. Apart from the
issue of the conversion I regard the technique as quite respectable
since it doesn't break encapsulation of the underlying type - i.e. the
wrapper class is supposed to utilise the public interface of the
underlying type it decorates.
Yes, this is OK, when both have the same underlying type. But then you actually
don't need the cast anyway, because the actual operation should work on the
underlying type. Id such underlying type exist, you have different options to
get access to it, either by explicit casts or by special member functions.
for example. "Programming of Elements" suggests a similar approach and refers to
an "underlying type".
I googled "Programming of Elements" and only obtained 101 results, the
first of which was some patent on quantum computing. Without the
quotes I get 53 million hits, the first of which is a book called
"Elements of Programming" by Stepanov and McJones. Is that what
you're referring to?
Yes.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]