Re: Const constructor
On 26 Jun., 00:38, Edward Rosten <Edward.Ros...@gmail.com> wrote:
On 23 June, 20:14, SG <s.gesem...@gmail.com> wrote:
Sorry, did you actually show the ArraySlice implementation somewhere?
What is it supposed to do? Is it supposed to act like a pointer?
Because that's what we're talking about, right?
It's some slice object. For instance it could hold a pointer and a
size. It would allow you to act on a chunk of an array just like an
array.
What does "It's some slice object" mean? It it supposed to have
reference semantics or pointer semantics? You can implement both with
a pointer but one propagates const and forwards assignments to the
slice and the other behaves like a pointer (not propagating const and
assignment doesn't change the current slice's elements but changes
what "slice" is being pointed to).
I really don't see the problem with user-defined pointer-like types
(or any inconsistency compared to builtin pointers). Can you
elaborate?
Yes:
double* // This type can be used as a slice of an array, or
// a whole array
No, it's always a pointer -- no value semantics w.r.t. the elements.
const double* // This type can be used as an immutable slice of
// an array or a whole immutable array.
Of course, those types require more by-hand book keeping but that's
what one gets for using C or C-like constructs.
Let us say that there are now some types which act like arrays.
How do "arrays" act in your world? Are they copiable (like
tr1::array<>)?
They
overload[] and have a .size() member:
Array<double>
ArraySlice<double>
Ok, so anything that has these member function "acts like an array". I
think this is a big part of your design problem. You're mixing
different concepts just because they have the same syntax.
one holds an array with copy semantics. The other holds a slice of an
array.
Yes. Whatever "slice" means. (pointer or reference semantics?)
A reasonable design might allow you to slice an array, so if
you have:
Array<double> a;
...
a.slice(0,5); //This returns an ArraySlice object, starting at a[0],
ending at a[4].
Let us say you have a function which operates on immutable data. To
take an array you would write:
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.
It's odd, though, that you pass a slice by reference to non-const.
Or maybe, if there is a ConstArraySlice class which holds a const
whatever*:
double sum(ConstArraySlice<double>& s);
Again, reference to non-const.... Hmmm....
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.
sum is quite
obvious and does no copying of the data. Yet despite these
similarities, const Array<> and const ArraySlice<> behave very
differently. This seems inconsistent.
By "differently" you mean one has value semantics and the other has
reference or pointer semantics? Well, that was intentional, wasn't it?
It's the point of having a class for slices, right?
Whereas, if you write it C-
style, you just need:
double sum(const double*, int size);
which is one function rather than two.
This function always takes a pointer. You could design ArraySlice to
behave like a pointer an add an implicit convertion from Array to
ArraySlice if you like. Then, you'd be really emulating the behaviour
of the built-in types (array, pointer) with additional benefit of
carrying "size" around. Though, you probably should not make this
conversion implicit. It could be error-prone. For an explicit
conversion you could use little helper functions like these:
template<typename T>
inline ArraySlice<T> slice(Array<T>&);
template<typename T>
inline ArraySlice<const T> cslice(const Array<T>&);
(assuming ArraySlice<T> behaves like a pointer)
To be able to write one
function in C++, consider you the following class:
template<class T, template<class> class Base> class Array: public
Base<T>;
Now, the behavior of Array depends on it's base. One can write a Base
(called eg called Alloc) which holds an array with copy semantics
(like std::vector) or one can write a Base (eg called Slice) which
holds a pointer and just copies the pointer. This way, the base class
can make Array behave like an Array or a slice.
Now, you can write a single function like this:
template<class T, template<class> class B> T sum(const Array<T, B>&);
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.
Array<T,B> will have value semantics for some templates B and poitner
or reference semantics for other templates B. This ought to confuse
people.
We're now rather closer to the nice properties of the C-style code.
Not really.
For instance, there is now one function where instead there were two.
You, you still have multiple functions because you declared a function
template. ;-)
You can write functions which take an Array to represent a chunk of
data either const or not const, and you don't have to care whether
you're operating on an array or a slice. That's good. It's like the C-
style function, except much nicer.
I don't agree. It's not "much nicer".
Except now I've made a nice little hole in the type system, since a
const double* is not the same as a double const* (ie an const
It is. const double* and double const* are the SAME types. As for
"little hole in the type system": Your design is to blame.
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
some inconsistency. But there is none. You just seem to confuse
concepts and don't like the pointer declaration syntax.
Cheers!
SG
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]