nested stl containers - aliasing stl objects without invokingoperator=

A

Andrey Vul

I'm building a multi-dimensional array using std::vector and I want to
know there's a way (without using old-fashioned pointers) to alias
elements from one to another by reference rather than by value (and
invoking possibly significant overhead from operator=).

Using vector < vector< ... >& > invokes compiler errors.

Example:

vector< vector<unsigned> > foo;
/* ... initialize elements of foo */
vector< vector<unsigned> > bar;
bar[0] = foo[2]; // (*)
bar[3] = foo[1]; // (*)
/* ... continue initializing elements of bar */

Is there a way to do the operation in (*) by using pass-by-reference,
so that, e.g. &(bar[0]) == &(foo[2]) ?
 
J

James Kanze

I'm building a multi-dimensional array using std::vector and I
want to know there's a way (without using old-fashioned
pointers) to alias elements from one to another by reference
rather than by value (and invoking possibly significant
overhead from operator=).
Using vector < vector< ... >& > invokes compiler errors.

Correct, since references aren't assignable, and the type used
to instantiate a vector must be assignable.
vector< vector<unsigned> > foo;
/* ... initialize elements of foo */
vector< vector<unsigned> > bar;
bar[0] = foo[2]; // (*)
bar[3] = foo[1]; // (*)
/* ... continue initializing elements of bar */
Is there a way to do the operation in (*) by using
pass-by-reference, so that, e.g. &(bar[0]) == &(foo[2]) ?

No, since any changes in bar (e.g. bar[0]=...) are not allowed
to affect foo, and vice versa. It sounds like you need
pointers. (You can, of course, write a thin wrapper class which
uses pointers in the array, but dereferences them in
operator[].)
 
A

Andrey Vul


Because the size of the second dimension is not guaranteed.
boost::multiarry uses N*M[*L*K...] sizes, so the second dimension must
be a vector, whose elements refer to std::vector<...>, so that foo[x]
[y][z] can be used rather than foo[x]->at(y)->at(z) , which is why I'm
asking for reference copy assignment instead of value copy assignment,
because pointers will force usage of the latter, or even uglier, (*
(*foo[x])[y])[z] .
 
A

Andrey Vul

I'm building a multi-dimensional array using std::vector and I
want to know there's a way (without using old-fashioned
pointers) to alias elements from one to another by reference
rather than by value (and invoking possibly significant
overhead from operator=).
Using vector < vector< ... >& > invokes compiler errors.

Correct, since references aren't assignable, and the type used
to instantiate a vector must be assignable.
Example:
vector< vector<unsigned> > foo;
/* ... initialize elements of foo */
vector< vector<unsigned> > bar;
bar[0] = foo[2]; // (*)
bar[3] = foo[1]; // (*)
/* ... continue initializing elements of bar */
Is there a way to do the operation in (*) by using
pass-by-reference, so that, e.g. &(bar[0]) == &(foo[2]) ?

No, since any changes in bar (e.g. bar[0]=...) are not allowed
to affect foo, and vice versa. It sounds like you need
pointers.

Indeed, but foo[x]->at(y)->at(z) feels like a kludge, as does (*(*foo
[x])[y])[z] .
 
A

Andrey Vul

(You can, of course, write a thin wrapper class which
uses pointers in the array, but dereferences them in
operator[].)

Like this:

template <typename T>
class pvec {
private:
vector<T> *p;
public:
T& operator[](unsigned x) {
return p->at[x];
}
pvec& operator=(vector<T> *p2) {
p = p2;
return *this;
}
pvec& operator=(pvec<T>& pv) {
p = pv.p;
return *this;
}

unsigned size() const {
return p->size();
}
};

?

Also, would boost::shared_ptr<vector<T>> be better than vector<T> * ?
 
J

James Kanze

(You can, of course, write a thin wrapper class which
uses pointers in the array, but dereferences them in
operator[].)
Like this:
template <typename T>
class pvec {
private:
vector<T> *p;
public:
T& operator[](unsigned x) {
return p->at[x];
}
pvec& operator=(vector<T> *p2) {
p = p2;
return *this;
}
pvec& operator=(pvec<T>& pv) {
p = pv.p;
return *this;
}

unsigned size() const {
return p->size();
}
};

Also, would boost::shared_ptr<vector<T>> be better than vector<T> * ?

It depends on what you're doing, but probably not. At any
rate, you couldn't implement the above interface using it. (But
for the moment, I'm not really sure what you're trying to do. I
don't see any advantage in using the above rather than simply
having a reference to the vector.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,999
Messages
2,570,243
Members
46,836
Latest member
login dogas

Latest Threads

Top