Re: Const constructor
On 28 Jun., 22:34, Edward Rosten <Edward.Ros...@gmail.com> wrote:
http://en.wikipedia.org/wiki/Array_slicing
"Depending on the programming language and context, the elements
of the new array may be aliased to (i.e., share memory with)
those of the original array."
Essentially a slice of an array refers to sum subset of the array.
This is not very specific w.r.t. copy/assignment semantics and how
const-qualification affects the result of operator[].
You're mixing
different concepts just because they have the same syntax.
[...]
That's half the point of C++ and templates, and ideed duck typing in
general. A lot of the STL works this way: if you can provide
iterators, it does not matter what the underlying concept is.
The concept is always the same: It's an iterator. An iterator behaves
like a pointer. You can safely copy an iterator without the need to
worry about what's gonna happen to the elements it refers to. If I
have a const reference to an iterator I know I may be able to modify
the object it points to because it's just a top-level const. You're
forgetting that iterators are an additional abstraction layer between
containers and algorithms.
You want algorithms to run on anything that has .operator[]() and .size
(), containers and (shallow) container views. For this you write a
funtion to take an "array-like" object by reference. It's all fine and
dandy as long as you don't accitentally try to copy such an object
while having kind of copy semantics in mind that doesn't match the
object's.
double sum(const Array<double>& s); //Sum up the contents
whereas to take a slice you have to write:
double sum(ArraySlice<const double>& s);
I would not know because I don't know how "slice" is going to behave.
Well, slicing is not an uncommon concept in computer science.
But you left out the details of concepts. I can think of at least two
"slice" classes which I referred to by "pointer semantics" and
"reference semantics". For the first version I would declare the sum
function like this:
double sum(ArraySlice<const double> s); //<-- pass by value
In this case ArraySlice models a "view" into an array. A copy of
ArraySlice will refer to the same elements. Assignment of ArraySlice
objects doesn't change the elements but changes what elements the
slice object refers to (like a pointer). By creating ArraySlice
objects that refer to all elements of an array you can reuse this
function. This is what happens with the array-to-pointer decay in C
and C++. You can't get any closer semantically to that than this. In C+
+0x you could add an implicit conversion from Array<T> to
ArraySlice<T> and ArraySlice<const T> in case the Array<T> object was
an lvalue (your own "array-to-slice" decay if you will).
The second slice class version acts like a reference. Once initialized
it cannot be reseated. It refers to a subrange of an array and
propagates const to its elements. It would allow you to write a single
function template that can be used with a slice object as well as an
array object in case NO copying is done:
template<typename NonCopiableArrayLike>
double sum(NonCopiableArrayLike const& s);
NonCopiableArrayLike can be an Array<double>, or an ArraySlice<double>
or an ArraySlice<const double>. Either way, s is const-qualified and
since ArraySlice<double> propagates const to its elements you get a
consistent behaviour compared to with Array<double>. This is NOT what
a pointer would do. I used the name "NonCopiableArrayLike"
deliberately because as long as this "thing" is not copied we wouldn't
know the difference between an array with value semantics and a slice
with reference semantics. But they ARE models of different concepts if
you also count copy semantics.
So, Array<double> and ArraySlice<double> look pretty much the same
from the outside. They both have operator[] and .size().
same syntax, yes, but /different/ concept.
Really? The concept is the same. Both provide array-like access to a
bunch of data.
So, your "ArrayLike"-concept doesn't say anything about copy/
assignment semantics.
How else do you do slices?
I generally prefer to distinguish between a container ("store" with
value semantics) and something that only refers to elements (like a
pointer) because I prefer to know what happens if I copy such an
object and how a const qualification affects the result of operator[].
For me, this is part of the concept (C++0x terminology "concept").
[on an ArraySlice<T> version behaving like a pointer to T with
known size]
One could but one then has the rather nasty thing that 1. you
instantiate Array objects yet write functions to accept ArraySlice
objecgts
But that would be equivalent to taking a T* and an int for the size as
parameters. If I remember correctly, you mentioned that it's
impossible to write user-defined types that emulate this behaviour.
Well, you're wrong, obviously.
I think this is a bad design idea. You should not let the behaviour of
an class instantiation depend on a template parameter like this.
Why not?
I think it's error-prone to let the copy/assignement semantics of a
class be determined by a template parameter while declaring functions
like these:
template<typename T, typename B>
void do_something(Array<T,B> const& x)
{
// can I copy x? What will happen? Well, it
// depends on B, doesn't it?
}
Except now I've made a nice little hole in the type system, since
[...]
Typo. const double * != double * const.
Or, more to the point:
const foo != const double* where foo==double*
It's not obvious to me how this is a bad thing. On the contrary, it's
consistent. I really have trouble figuring out whether you just don't
like the pointer declaration syntax or you don't like the fact that
top-level const for builtin pointers (intentionally) doesn't propagate
down to pointees. It's certainly not a hole in the type system. If
anything, your design is broken. If you want double const* then simply
use double const* and not double*const.
So, in a nutshell, here's my complaint. I can write a single C-style
function which operates on immutable data, regardless of whether it's
an array or merely a slice of an array, because pointers are rather
dumb and also const binds differently for *.
How can you say you're not confused and yet say something like "const
binds differently for *"? It sounds like you're implying that there is
because const foo != const double* where foo = double*
We've established that already. It still isn't a coherent argument for
your claim/complaint. All you do is giving the impression that you're
confusing something (pointer declaration syntax and/or the difference
between arrays and pointers and/or the implicit array-to-pointer decay
and/or how a const qualified pointer behaves).
Cheers!
SG
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]