Re: Const constructor
Edward Rosten wrote:
On 26 June, 20:12, Dragan Milenkovic <dra...@plusplus.rs> wrote:
dumb and also const binds differently for *. I can not do the same for
user defined types without making a small hole in the type system.
Const binds always the same, and no need for drilling holes.
My point is:
const double* != const foo where foo==double*
which is mostly what one wants.
Did you read my other post? Because you still speak about
"custom pointers vs built-in pointers" when in fact it is
about "custom arrays vs built-in (evil) arrays"...
Anyway, access to an array is only one part of its interface.
The rest of it is element ownership, copy/assignment.
If you ignore these, there is no need to use anything beside
double * anyway.
Really? Because std::accumulate, std::sort and etc precisely ignore
all of these things. I am essentially talking about the same thing:
providing algorithms on one part of the interface while ignoring other
parts.
And the next design covers this. I learned it from Bjarne's book.
Your wish is for a single interface for both classes. This is
how it can be done (names suck though, and this is only
a non-template example)...
class ArrayAccessInterface {
public:
virtual ~ArrayAccessInterface();
virtual double operator[](int index) const = 0;
I didn't mention this before, but I can't afford virtual functions for
things like operator[]. They are much too slow.
And the next design covers this.
If you don't like this method, you can write template functions
that will take anything that has operator[] that returns double.
With incoming concepts it can be very clean:
template <typename A>
/* C++0x only */ requires MyCustomArrayOfDoubleConcept<A>
void func(A const & a) { /* bla a[0] bla */ }
Array<double> p; func(p);
ArraySlice<const double> q; func(q);
That would work for many situations, however IMO is is not quite
restrictive enough. In my library operator* on Vector does dot
products. On other libraries it does element by element multiplication
on Arrays. Both are reasonable choices, and both unfortunately have
the same interface. Accepting a generic type would cause problems. I
suppose one could add a specific tag to Vector to allow it to be
detected. This is so far the only sensible system that's been
suggested.
I fail to see the relevance of "operator*". The only thing that
concept MyCustomArrayOfDoubleConcept requires is operator[],
which is exactly the interface you would want. You can restrict
a concept any way you like.
But I still think it's a shame that one can make a foo behave like
double* but not make const foo behave like const double*.
We have irreconcilable differences, and I'm filing for a divorce.
Maybe in time you will come to your senses and we could remain friends.
:-D
--
Dragan
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]