How do I store a reference?

[Jim]

Or can I? This class failes to compile with the error:

lque.C: In constructor ‘QueTest::QueTest()’:
lque.C:10: error: uninitialized reference member ‘QueTest::que’

#include <deque>
using namespace std;
class QueTest
{
public:
QueTest()
{}

void set_que(deque<string>& q)
{
que = q;
}

private:
deque<string>& que;
};

Thanks,
Jim.

 

[Erik Wikström]

Or can I? This class failes to compile with the error:

lque.C: In constructor ‘QueTest::QueTest()’:
lque.C:10: error: uninitialized reference member ‘QueTest::que’

#include <deque>
using namespace std;
class QueTest
{
public:
QueTest()
{}

void set_que(deque<string>& q)
{
que = q;
}

private:
deque<string>& que;
};

You can not reseat a reference, one it has been made to refer to an
object it will always refer to that object. If you want to be able to
change the referred object use a pointer instead.

 

[Jim]

You can not reseat a reference, one it has been made to refer to an
object it will always refer to that object. If you want to be able to
change the referred object use a pointer instead.

I was afraid of that.

Thanks,
Jim.

 

[Jeff Schwab]

I was afraid of that.

Why? Do you just prefer the reference syntax?

 

[Szabolcs Ferenczi]

You can store a reference in a member if you do that in the
constructor like this:

#include <deque>
using namespace std;
class QueTest
{
public:
QueTest(deque<string>& q)
: que(q)
{}
private:
deque<string>& que;
};

A reference can be assigned only once. In this case it happens when
the object is constructed.

Best Regards,
Szabolcs

 

[Jim]

Why? Do you just prefer the reference syntax?

I don't have any pointers in the code currently. I was just trying to
avoid them if possible. It's no big deal.

Jim.

 

[Micah Cowan]

Hello Jeff,

That's one of the differences between references and pointers.

You __have to__ initialize a reference when declaring it. After
bounded to an object, the reference cannot refer to any other
objects. So you cannot use refernces as data members (maybe can, but I
don't know).

You can: you need to do it in the ctor-initializer. You also need to
explicitly define a copy constructor (with appropriate
initialization), otherwise an implcit but ill-formed one will be
generated.

class A {
const int &x;

public:
A(const A &other) : x(other.x) {}
A(const int &y) : x(y) {}
};

 

[raof01]

Hello Jeff,

That's one of the differences between references and pointers.

You __have to__ initialize a reference when declaring it. After bounded to
an object, the reference cannot refer to any other objects. So you cannot
use refernces as data members (maybe can, but I don't know).

Hope this help you.

Why? Do you just prefer the reference syntax?

raof01
==================
Thoughts are but dreams till their effects be tried.

 

[raof01]

sorry, it's for Jim, not Jeff...

Hello Jeff,

That's one of the differences between references and pointers.

You __have to__ initialize a reference when declaring it. After
bounded to an object, the reference cannot refer to any other objects.
So you cannot use refernces as data members (maybe can, but I don't
know).

Hope this help you.

raof01
==================
Thoughts are but dreams till their effects be tried.

raof01
==================
Thoughts are but dreams till their effects be tried.

 

[Juha Nieminen]

I don't have any pointers in the code currently. I was just trying to
avoid them if possible. It's no big deal.

Just because pointers can cause problems doesn't mean that they can't
be used safely by following some simple programming practices. It also
doesn't mean that references cannot be misused (although, admittedly,
it's slightly more difficult).

 

[James Kanze]

You can: you need to do it in the ctor-initializer.

And once you've done so, you can't reseat them. Which generally
makes the assignment operator unimplementable. (Of course, if
the class doesn't support assignment...)

 

[Richard Herring]

You can: you need to do it in the ctor-initializer. You also need to
explicitly define a copy constructor (with appropriate
initialization), otherwise an implcit but ill-formed one will be
generated.

Really? 12.8 doesn't appear to place any restrictions on
implicitly-defined copy constructors with reference members. That's not
the case with copy assignment operators, of course.

 

[Micah Cowan]

Really? 12.8 doesn't appear to place any restrictions on
implicitly-defined copy constructors with reference members. That's
not the case with copy assignment operators, of course.

I had thought the ill-formedness was implied by how the copy
constructor is implicitly generated; but re-reading now, I see no such
problem, and must have been confusing it with what happens with
implicitly generated _default_ constructors.