[C++-sig] Re: C arrays mk 2

[Raoul Gough]

David Abrahams <dave at boost-consulting.com> writes:

> Raoul Gough wrote:
[snip]
>>>Right, and because it's not, fundamentally, a pair of iterators.  It's
>>>a facade for the Container concept.
>> OK, yes, it provides *part* of the container interface, since it has
>> the typedefs and begin() and end() and some syntactic niceities like
>> operator[]. However, there is an important distinction in terms of
>> storage management as I already mentioned. From the way you described
>> it, calling something std::list would be wrong, because that's an
>> implementation detail.
>
> No, it's not.  Its list-ness affects externally visible properties
> like complexity of insert, iterator invalidation, etc.  If you can
> build something with the same properties using a different data
> structure, by all means go ahead and call it "list".

OK, but apply the same reasoning to "iterator_pair" and there is no
problem with that name either. The iterator-pairness of my container
affects important semantic properties, mainly the fact that it
references external objects. e.g.

int a[10] = { 0 };
&iterator_pair<int *>(a, a + 10)[0] == a

This is an important property in terms of usefulness, but also in
terms of object lifetime management, unless you want to risk having
dangling references. For instance you need to consider what would
happen if you have an iterator_pair that references the contents of a
standard container - any operations on the container that invalidate
iterators within the range will affect the iterator_pair.

>
>> Anyway, paragraph one of the container requirements says:
>>   "Containers are objects that store other objects. They control
>>   allocation and deallocation of these objects through constructors,
>>   destructors, insert and erase operations."
>> There is also no way that ~iterator_pair is going to "apply the
>> destructor to every element", as is required of containers.
>
> OK, point taken.
>
>>>>Also, I'm also not sure that it could really be called immutable,
>>>>since you can replace elements (just not insert or delete them).
>>>>Anyway, can you suggest an alternative name?
>>>
>>>container ;->
>
> Well, I'm stumped for a name at the moment.  I think we need a new
> concept in the hierarchy, less-refined than Container.

How about "iterator_pair" :-)

Actually, I now think "iterator_range" might have been better, because
it hints that the two iterators must define a range. However, I can't
conceive of any sensible implementation with similar semantics that
*doesn't* store a pair of iterators, so I don't see anything to be
gained by trying to hide this behind a new abstraction.

[snip]
> Endline layout is what happens when you have an unmatched open
> delimiter in the middle of the line:
>
>      foo(bar
>
> What happens is that you're then compelled to line things up under
> bar. Not only does that make poor use of space, it means a whole lotta
> busywork indentation adjustment when someone changes the name of foo
> to "fu" or "foobarre".
>
> This isn't one of those things that kills a project, but you need to
> choose some style and I prefer to choose one that has a nice rationale
> so I can stop thinking about whether I chose right ;->
>
>  > I initially
>> thought you wanted to avoid columnar layouts entirely.
>
> No, you can see lots of examples of that in my code I'm sure.

OK, that makes a lot of sense to me know. I've added this to my (know
slowing shrinking) list.

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)