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

[David Harmon]

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

>context in the program while it is by itself updated by f. Could you
comment on the invalidity of modifiable reference?

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

[Jim Langston]

"Filimon Roukoutakis" <fi*****@phys.u oa.grwrote in message
news:et******** **@cernne03.cer n.ch...

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,

By your replies to the other posts, I take it you meant

void g() {
vec push_back( new Object );
f( vec[size() - 1] );
}

f( *(vec.end() - 1) );
may also work.

Your question seems to be, g made a new object, can f access that object?
The answer is yes. It would be the same if you did something like:

Object* MyObject = NULL;

f( Object*& obj )
{
// ...
}

Object* g
{
return new Object;
}

int main()
{
MyObject = g();
f( MyObject );
delete( MyObject );
}

You just happen to be storing it in a vector instead of (in thsi case) a
global variable. Once an object is allocated using new all you need is the
pointer to that memory to access the instance, until delete is called on it.
However you happen to get that pointer (global, from a vecotr, a paramter,
whatever).

Incidently, now a days "heap" is commonly called the "free store". I'm not
sure what the standard calls it.

Just make sure you delete the pointer when done.

[Filimon Roukoutakis]

Jim Langston wrote:

"Filimon Roukoutakis" <fi*****@phys.u oa.grwrote in message
news:et******** **@cernne03.cer n.ch...

>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,

By your replies to the other posts, I take it you meant

void g() {
vec push_back( new Object );
f( vec[size() - 1] );
}

f( *(vec.end() - 1) );
may also work.

Your question seems to be, g made a new object, can f access that object?
The answer is yes. It would be the same if you did something like:

Object* MyObject = NULL;

f( Object*& obj )
{
// ...
}

Object* g
{
return new Object;
}

int main()
{
MyObject = g();
f( MyObject );
delete( MyObject );
}

You just happen to be storing it in a vector instead of (in thsi case) a
global variable. Once an object is allocated using new all you need is the
pointer to that memory to access the instance, until delete is called on it.
However you happen to get that pointer (global, from a vecotr, a paramter,
whatever).

Incidently, now a days "heap" is commonly called the "free store". I'm not
sure what the standard calls it.

Just make sure you delete the pointer when done.

My problem is that when I try to delete the pointer inside f I get a
segmentation violation, so I figured that maybe new Object inside g is
stored as a const reference in the vector which cannot be modified
somehow and this produces the problem.

[David Harmon]

On Mon, 19 Mar 2007 10:28:48 +0100 in comp.lang.c++, Filimon Roukoutakis
<fi*****@phys.u oa.grwrote,

>
My problem is that when I try to delete the pointer inside f I get a
segmentation violation, so I figured that maybe new Object inside g is
stored as a const reference in the vector which cannot be modified
somehow and this produces the problem.

No. The contents of the vector, in this case the pointers, are fully
modifiable just as you thought. Even if that were not the case, const
pointers can be deleted as long as they came from 'new' to begin with.
I apologize for muddying the waters.

seg violation on deleting usually means either you are trying to delete
the same object twice, or some pointer that was never new'ed, or that
some random memory write elsewhere in the program has corrupted the
heap. Or something along those lines. Can be tricky to track down.

[Ivan Vecerina]

"Filimon Roukoutakis" <fi*****@phys.u oa.grwrote in message
news:et******** **@cernne03.cer n.ch...
: 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,

That part is ok. The only problem I see in the above code is
something that hasn't been mentioned yet:
vec.push_back(n ew Object);
This is not exception-safe: if push_back fails (because it
is unable to allocate a larger block of memory), the newly
allocated object will be leaked.

But this of course will be unrelated to the problem
you described later.
For that, be careful that you do not modify the vector
(e.g. by adding another element) as long as you are
using the reference returned by back().

hth -Ivan

--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

[Roland Pibinger]

On Tue, 20 Mar 2007 07:27:17 +0100, "Ivan Vecerina" wrote:

>The only problem I see in the above code is
something that hasn't been mentioned yet:
vec.push_back(n ew Object);
This is not exception-safe: if push_back fails (because it
is unable to allocate a larger block of memory), the newly
allocated object will be leaked.

Out-of-memory in C++ is usually handled by the new_handler, not with
exception handling. If one really needs to handle OOM with exception
handling vector::reserve () may be called in advance.

Best regards,
Roland Pibinger

[Ivan Vecerina]

"Roland Pibinger" <rp*****@yahoo. comwrote in message
news:45******** ******@news.uta net.at...
: On Tue, 20 Mar 2007 07:27:17 +0100, "Ivan Vecerina" wrote:
: >The only problem I see in the above code is
: >something that hasn't been mentioned yet:
: vec.push_back(n ew Object);
: >This is not exception-safe: if push_back fails (because it
: >is unable to allocate a larger block of memory), the newly
: >allocated object will be leaked.
:
: Out-of-memory in C++ is usually handled by the new_handler, not with
: exception handling.

What is your definition of "usually" ???
http://www.google.com/codesearch?q=set_new_handler
This gives 2-3'000 hits, many of them being declarations
in library headers. Not quite was I would call "usual".
Plus new_handler is required to either throw an exception,
or terminate the program. Does it really help here ?

: If one really needs to handle OOM with exception
: handling vector::reserve () may be called in advance.

Yes, this is one of several ways to address the problem.
All I am saying is that this issue is worth attention.

Regards,
Ivan

--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Brainbench MVP for C++ <http://www.brainbench.com

[Filimon Roukoutakis]

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,

filimon

Problem solved. The problem was that the above code produced a
segmentation violation in another part of the program. The fix was to
replace std::vector<Obj ect*with std::vector<Obj ect**and
vec.push_back(n ew Object*). Probably this was not obvious in the context
of the code snippet that was presented here. Thanks for the answers.

filimon

[Jim Langston]

"Filimon Roukoutakis" <fi*****@phys.u oa.grwrote in message
news:eu******** **@cernne03.cer n.ch...

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,

filimon

Problem solved. The problem was that the above code produced a
segmentation violation in another part of the program. The fix was to
replace std::vector<Obj ect*with std::vector<Obj ect**and
vec.push_back(n ew Object*). Probably this was not obvious in the context
of the code snippet that was presented here. Thanks for the answers.

std::vector<som eclass*is usually bad design unless you are working with
polymorphism. Even then some would say use a smart pointer (although I use
naked pointers myself).

std::vector<som eclass**I could only think is bad design. You may want to
relook at what you are doing and see if this is absolutly necessary, it
sounds like a maintainance nightmare.

[Bo Persson]

Filimon Roukoutakis wrote:
:: 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,
:::
::: filimon
::
:: Problem solved. The problem was that the above code produced a
:: segmentation violation in another part of the program. The fix was to
:: replace std::vector<Obj ect*with std::vector<Obj ect**and
:: vec.push_back(n ew Object*).

Agreeing with Jim Langston's post, I can only say that dynamically
allocating a single pointer is EXTREMELY unusual.

In my opinion, it is HIGHLY LIKELY that you have not actually solved the
problem, but only happen to hide it.
Bo Persson