Is this valid and moral C++?

[Filimon Roukoutakis]

Suppose that we have a function

f(Object*& obj)

and have declared a global std::vector<Obj ect*vec;

Is it valid to do

void g() {
vec.push_back(n ew Object);
f(vec.back());
}

ie does f() internally actually have read/write access to the Object
allocated in g() on the heap? If not, what would be the trick to achieve
this? Thanks,

filimon

[Gianni Mariani]

Filimon Roukoutakis wrote:

Suppose that we have a function

f(Object*& obj)

and have declared a global std::vector<Obj ect*vec;

Is it valid to do

void g() {
vec.push_back(n ew Object);
f(vec.back());
}

ie does f() internally actually have read/write access to the Object
allocated in g() on the heap? If not, what would be the trick to achieve
this? Thanks,

Yes, it is valid.

Objects allocated by new are available to any function before delete is
called on it.

[David Harmon]

On Sun, 18 Mar 2007 21:09:22 +0100 in comp.lang.c++, Filimon Roukoutakis
<fi*****@phys.u oa.grwrote,

>Suppose that we have a function

f(Object*& obj)

and have declared a global std::vector<Obj ect*vec;

Is it valid to do

void g() {
vec.push_back(n ew Object);
f(vec.back());
}

No. The function should receive the pointer argument by value. i.e.
f(Object* obj)

It is invalid to try to pass a modifiable reference to the result of
..back() , and while a const reference would work it has no particular
advantage.

Secondly, your global vector of Object* will NOT delete the objects
pointed to when it's destructor runs at the end of the program. There's
no big deal about reclaiming the memory at that point, but if Object's
destructor does anything else important you've got a problem.

>ie does f() internally actually have read/write access to the Object
allocated in g() on the heap?

Yes. In fact that is the only way of accessing the object that you have
left yourself at this point, which is fine.

[Gianni Mariani]

David Harmon wrote:

On Sun, 18 Mar 2007 21:09:22 +0100 in comp.lang.c++, Filimon Roukoutakis
<fi*****@phys.u oa.grwrote,

>Suppose that we have a function

f(Object*& obj)

and have declared a global std::vector<Obj ect*vec;

Is it valid to do

void g() {
vec.push_back(n ew Object);
f(vec.back());
}

No. The function should receive the pointer argument by value. i.e.
f(Object* obj)

It is invalid to try to pass a modifiable reference to the result of
.back() , and while a const reference would work it has no particular
advantage.

Why is it "invalid" ?

[Filimon Roukoutakis]

David Harmon wrote:

On Sun, 18 Mar 2007 21:09:22 +0100 in comp.lang.c++, Filimon Roukoutakis
<fi*****@phys.u oa.grwrote,

>Suppose that we have a function

f(Object*& obj)

and have declared a global std::vector<Obj ect*vec;

Is it valid to do

void g() {
vec.push_back(n ew Object);
f(vec.back());
}

No. The function should receive the pointer argument by value. i.e.
f(Object* obj)

It is invalid to try to pass a modifiable reference to the result of
.back() , and while a const reference would work it has no particular
advantage.

I do want to pass a reference to the pointer so the pointer is
modifiable, or more precicely I want to use this pointer in another
context in the program while it is by itself updated by f. Could you
comment on the invalidity of modifiable reference?

>
Secondly, your global vector of Object* will NOT delete the objects
pointed to when it's destructor runs at the end of the program. There's
no big deal about reclaiming the memory at that point, but if Object's
destructor does anything else important you've got a problem.

>ie does f() internally actually have read/write access to the Object
allocated in g() on the heap?

Yes. In fact that is the only way of accessing the object that you have
left yourself at this point, which is fine.

ok for the above I knew, it was just a minimal example.

filimon

[Kai-Uwe Bux]

David Harmon wrote:

On Sun, 18 Mar 2007 21:09:22 +0100 in comp.lang.c++, Filimon Roukoutakis
<fi*****@phys.u oa.grwrote,

>>Suppose that we have a function

f(Object*& obj)

and have declared a global std::vector<Obj ect*vec;

Is it valid to do

void g() {
vec.push_back(n ew Object);
f(vec.back());
}

No. The function should receive the pointer argument by value. i.e.
f(Object* obj)

Why?

It is invalid to try to pass a modifiable reference to the result of
.back() , and while a const reference would work it has no particular
advantage.

The call f(vec.back()) does not pass anything "to the result of .back()".
What it does is: it initializes the Object*& parameter of f() with the
result of vec.back(), which so happens to be a reference (non-const in case
the non-const version of back() is called). There is nothing invalid about
it, as far as I can see.

E.g., f() could be:

f ( Object* & p_ref ) {
Object * dummy = new Object ();
std::swap( p_ref, dummy );
delete dummy;
}

Then f(vec.back()) would replace the last pointer with a new pointer whose
pointee has been default constructed.

Secondly, your global vector of Object* will NOT delete the objects
pointed to when it's destructor runs at the end of the program. There's
no big deal about reclaiming the memory at that point, but if Object's
destructor does anything else important you've got a problem.

Right: the vector will not do that by itself. So, the OP will have to take
care of deleting the pointers by himself.
[snip]

[David Harmon]

On Sun, 18 Mar 2007 22:37:29 +0100 in comp.lang.c++, Filimon Roukoutakis
<fi*****@phys.u oa.grwrote,

>I do want to pass a reference to the pointer so the pointer is
modifiable, or more precicely I want to use this pointer in another
context in the program while it is by itself updated by f. Could you
comment on the invalidity of modifiable reference?

What does it mean when your code attempts to modify via the reference,
giving in effect:
vec.back() = (some expression);

As I wrote to Gianni, It is forbidden by the standard to bind a
non-const reference to a temporary. This is one case where that rule
probably even makes sense. If you could actually change the value of
vec.back() without resizing the vector, it would break the vector. If
you think you can resize the vector by, for instance, incrementing
vec.back(), it doesn't work that way.

[David Harmon]

On Mon, 19 Mar 2007 08:30:34 +1100 in comp.lang.c++, Gianni Mariani
<gi*******@mari ani.wswrote,

>It is invalid to try to pass a modifiable reference to the result of
.back() , and while a const reference would work it has no particular
advantage.

Why is it "invalid" ?

It is forbidden by the standard to bind a non-const reference to a
temporary. This is one case where that rule probably even makes sense.
If you could actually change the value of vec.back() without resizing
the vector, it would break the vector. If you think you can resize the
vector by, for instance, incrementing vec.back(), it doesn't work that
way.

[David Harmon]

On Sun, 18 Mar 2007 18:13:46 -0400 in comp.lang.c++, Kai-Uwe Bux
<jk********@gmx .netwrote,

>The call f(vec.back()) does not pass anything "to the result of .back()".
What it does is: it initializes the Object*& parameter of f() with the
result of vec.back(), which so happens to be a reference (non-const in case
the non-const version of back() is called). There is nothing invalid about
it, as far as I can see.

Doh! I was confusing the element access front() and back() with the
iterator functions begin() etc. Disregard all.

[David Harmon]

On Mon, 19 Mar 2007 08:30:34 +1100 in comp.lang.c++, Gianni Mariani
<gi*******@mari ani.wswrote,

>It is invalid to try to pass a modifiable reference to the result of
.back() , and while a const reference would work it has no particular
advantage.

Why is it "invalid" ?

Doh! I was confusing the element access front() and back() with the
iterator functions begin() etc. Disregard all.