vector of const references. Is it possible?

[ragged_hippy]

Hi,

I wanted to create a vector of const references. Something like this:

vector<const x&> y;

where x is a class name.

Is this a valid statement? Will this work if I use a reference of 'y'
somewhere else?

PJ.

 

[Noah Roberts]

Hi,

I wanted to create a vector of const references. Something like this:

vector<const x&> y;

where x is a class name.

Is this a valid statement? Will this work if I use a reference of 'y'
somewhere else?

It is not portable. const& is not assignable and therefore not a valid
container element.

 

[mlimber]

I wanted to create a vector of const references. Something like this:

vector<const x&> y;

where x is a class name.

Is this a valid statement? Will this work if I use a reference of 'y'
somewhere else?

Did you try it? Any compiler will instantly tell you whether pointers
to references are allowed. (Hint: they're not, but vector requires
pointers to its containees.)

Cheers! --M

 

[Mike Wahler]

Hi,

I wanted to create a vector of const references.
Why?

Something like this:

vector<const x&> y;

where x is a class name.

Not valid.

Is this a valid statement?
No.

Will this work if I use a reference of 'y'

No.

Standard library containers store objects. References
are not objects. References are alternate names for
existing objects.

somewhere else?

No.

You can, however, store pointers in your vector, since
pointers are objects.

Perhaps if you describe what problem you're trying to
solve, we might be able to give advice.

-Mike

 

[ragged_hippy]

Not valid.




No.

Standard library containers store objects. References
are not objects. References are alternate names for
existing objects.


No.

You can, however, store pointers in your vector, since
pointers are objects.

Perhaps if you describe what problem you're trying to
solve, we might be able to give advice.

-Mike

Okay....I am trying to not use extra memory if possible.

I have this list of objects as a private member of a container. And I
have a public method defined in this container, that will take a
reference to vector buffer as a parameter and fill it up with objects
that it contains. If the vector for buffer is a vector of the object,
then all objects will be copied into this buffer. So, I thought may be
a vector of references might be better. But yes I immediately got his
huge set of compiler errors which I didn't expect.

Does this make sense?

-PJ.

 

[Jim Langston]

Okay....I am trying to not use extra memory if possible.

I have this list of objects as a private member of a container. And I
have a public method defined in this container, that will take a
reference to vector buffer as a parameter and fill it up with objects
that it contains. If the vector for buffer is a vector of the object,
then all objects will be copied into this buffer. So, I thought may be
a vector of references might be better. But yes I immediately got his
huge set of compiler errors which I didn't expect.

Does this make sense?

-PJ.

So just store them as a vector of pointers.

std::vector<x*>

 

[Puppet_Sock]

I have this list of objects as a private member of a container.

[snip]

Maybe instead of making some other container to hold this
data, you can keep holding it where it is. Maybe you can
add the functionality you want to the class that is already
doing the work of holding the data.

Alternatively, maybe the class that is doing the work of
holding this data isn't the right spot for it. Maybe it
should be held someplace else, and the work done to it
over there as well.

That is to say, possibly you have some refactoring to do.
Socks

 

[Andre Kostur]

Did you try it? Any compiler will instantly tell you whether pointers
to references are allowed. (Hint: they're not, but vector requires
pointers to its containees.)

Since when? Vectors contain copies of their contained objects, not
pointers to them.

 

[mlimber]

Since when? Vectors contain copies of their contained objects, not
pointers to them.

But vectors dynamically allocate the contained objects, which in turn
requires a pointer to the value type.

Cheers! --M

 

[Andre Kostur]

But vectors dynamically allocate the contained objects, which in turn
requires a pointer to the value type.

Probably not. As least not individually. It requires a pointer to some
memory. IIRC, TR1 specifies that it even must be contiguous memory.
Whether that actually is a pointer to type (or to array of type), or merely
a void *, that's an implementation detail. What's probably happening
behind the scenes is that the vector allocates "sizeof(type) * capacity"
bytes of memory, and uses placement new in each position that holds a valid
object.

From a vector user's point of view, all that is required is that the type
contained in the vector is copy constructable and assignable (and that the
constructed/assigned to object is the same as the original, which is why
auto_ptr can't be stored in STL containers). There are no pointers
anywhere in sight.

 

[mlimber]

@j27g2000cwj.googlegroups.com:





Probably not. As least not individually. It requires a pointer to some
memory. IIRC, TR1 specifies that it even must be contiguous memory.
Whether that actually is a pointer to type (or to array of type), or merely
a void *, that's an implementation detail. What's probably happening
behind the scenes is that the vector allocates "sizeof(type) * capacity"
bytes of memory, and uses placement new in each position that holds a valid
object.

From a vector user's point of view, all that is required is that the type
contained in the vector is copy constructable and assignable (and that the
constructed/assigned to object is the same as the original, which is why
auto_ptr can't be stored in STL containers). There are no pointers
anywhere in sight.

I don't doubt that you're right in theory, but in practice every STL
implementation I've seen uses pointers to the containee internally and
an error in that regard pops up if you try something like what the OP
suggested.

Cheers! --M

 

[Dave Rahardja]

I don't doubt that you're right in theory, but in practice every STL
implementation I've seen uses pointers to the containee internally and
an error in that regard pops up if you try something like what the OP
suggested.

There are ways to make assignable and copy-constructable objects that /behave/
like references. See boost.Ref for instance.

-dr

 

[Kai-Uwe Bux]

There are ways to make assignable and copy-constructable objects that
/behave/ like references.

No there isn't: unfortunately, the dot operator is not overloadable. If
there was, containers for polymorphic objects would be much less of a
problem.

See boost.Ref for instance.

Does not cut it either:

#include <boost/ref.hpp>

struct X {
void inc ( void ) {}
};

int main ( void ) {
X value;
X & ref = value;
ref.inc();
boost::reference_wrapper<X> ref_w ( ref );
ref_w.inc(); // fails
}


Best

Kai-Uwe Bux

 

[Grizlyk]

But yes I immediately got his huge set of compiler errors which I didn't
expect.

Try to read any C++ book about pointers, references and variables, try find
its representation in memory.

Internally reference can be implemented as const pointer, but for C++ users
reference has special behaviour. After reference has been created, you can
not access to the reference itself (can not to the reference internal
address), only to object the reference refers to.

It looks like reference has no default ctor
const X &tmp; //error

also reference can not be reassigned, as if automatically forwarding all its
messages to own stored X object.

const X &tmp=*static_cast<X*>(0);
const X obj;
tmp=obj;

is not the same as

const X obj;
const X &tmp=obj;

The purpose of reference is hiding own existance. So if you do not want the
hiding. If you need address, use POD pointers. If you need ownership of
dynamic memory, use RAII wrappers (as auto_ptr). Else use object itself.

--
Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

"In thi world of fairy tales rolls are liked olso"
/Gnume/