segmented_array question
 

Shalom

My marshalling deques adventure has been stymied by the C++
standards morass.... Now I'm focusing on segmented_arrays.
Would the author of segmented_array comment on adding the
following to the segmented_array file?

template <typename T, std::size_t N = 64, typename A =
std::allocator<T> >
class segmented_iterator : public ::neolib::segmented_array<T, N,
A>::iterator
{
typedef typename ::neolib::segmented_array<T, N, A>::iterator
base;
public:
segmented_iterator(base const& x) : base(x) {}
typename base::segment_type& segment() { return base::seg(); }
};


That's a slightly modified version of something from the
segmented_array web pages. Tia.


Brian Wood
Ebenezer Enterprises
http://webEbenezer.net

Re: segmented_array question
 

On Sep 29, 8:07*am, Leigh Johnston <le...@i42.co.uk> wrote:
> On 29/09/2011 02:35, Ebenezer wrote:
>
>
>
>
>
>
>
>
>
> > Shalom
>
> > My marshalling deques adventure has been stymied by the C++
> > standards morass.... *Now I'm focusing on segmented_arrays.
> > Would the author of segmented_array comment on adding the
> > following to the segmented_array file?
>
> > template<typename T, std::size_t N = 64, typename A =
> > std::allocator<T> *>
> > class segmented_iterator : public ::neolib::segmented_array<T, N,
> > A>::iterator
> > {
> > * * *typedef typename ::neolib::segmented_array<T, N, A>::iterator
> > base;
> > public:
> > * * *segmented_iterator(base const& *x) : base(x) {}
> > * * *typename base::segment_type& *segment() { return base::seg(); }
> > };
>
> > That's a slightly modified version of something from the
> > segmented_array web pages. *Tia.
>
> Hi,
>
> I don't think it would be within the spirit of the standard C++
> container library to formally provide a mechanism to access the internal
> data structures of a container; the provided public interface should be
> as similar to what the standard C++ library provides.
>

What this means to me is having to:

1. maintain my own copy of segmented_array.h and update it
when a new version of the code is adopted or

2. put the code in a separate file and include it when
needed including code generation contexts.

I hope you will reconsider. It could be under an ifdef if
that would help.

> I prefer to keep
> accessing segmented_array's segments an esoteric feature. :)

Accessing vector's segment is an esoteric feature?

If others want to comment on this, please do.


Brian Wood
http://wnd.com

Re: segmented_array question
 

On Sep 29, 8:25*pm, Leigh Johnston <le...@i42.co.uk> wrote:
> On 30/09/2011 01:43, Ebenezer wrote:
>
>
>
>
>
>
>
>
>
> > On Sep 29, 8:07 am, Leigh Johnston<le...@i42.co.uk> *wrote:
> >> On 29/09/2011 02:35, Ebenezer wrote:
>
> >>> Shalom
>
> >>> My marshalling deques adventure has been stymied by the C++
> >>> standards morass.... *Now I'm focusing on segmented_arrays.
> >>> Would the author of segmented_array comment on adding the
> >>> following to the segmented_array file?
>
> >>> template<typename T, std::size_t N = 64, typename A =
> >>> std::allocator<T> * *>
> >>> class segmented_iterator : public ::neolib::segmented_array<T, N,
> >>> A>::iterator
> >>> {
> >>> * * * typedef typename ::neolib::segmented_array<T, N, A>::iterator
> >>> base;
> >>> public:
> >>> * * * segmented_iterator(base const& * *x) : base(x) {}
> >>> * * * typename base::segment_type& * *segment() { return base::seg(); }
> >>> };
>
> >>> That's a slightly modified version of something from the
> >>> segmented_array web pages. *Tia.
>
> >> Hi,
>
> >> I don't think it would be within the spirit of the standard C++
> >> container library to formally provide a mechanism to access the internal
> >> data structures of a container; the provided public interface should be
> >> as similar to what the standard C++ library provides.
>
> > What this means to me is having to:
>
> > 1. maintain my own copy of segmented_array.h and update it
> > when a new version of the code is adopted or
>
> Feel free to do this; my license permits it.

Thanks, I've already concluded that was fine and am including
copies of several of your files in my archive.

>
>
>
> > 2. put the code in a separate file and include it when
> > needed including code generation contexts.
>
> Sounds like a better idea.

Agreed, but not as good as what I suggested at first.

>
>
>
> > I hope you will reconsider. *It could be under an ifdef if
> > that would help.
>
> Sorry but no; exposing the internal data structures of a container is
> Doing It Wrong Thing (tm) as it:
>
> 1) Allows the user to break the container class invariant.
> 2) Is not in the spirit of the STL.
> 3) Is not "clean".
>
>
>
> >> I prefer to keep
> >> accessing segmented_array's segments an esoteric feature. :)
>
> > Accessing vector's segment is an esoteric feature?
>
> Yes; the segmented_array container is designed like any STL container in
> that it provides a public interface to access the controlled sequence in
> a standard way. *Accessing the segments is not accessing the controlled
> sequence in a standard way just as trying to access the chunks of a
> std::deque's controlled sequence isn't.
>

I don't think there's a problem with being able to access a
vector's segment. If you do that you take responsibility
upon yourself for making sure everything is kosher.