Re: which pointer
On 11 Dec 2009, 16:19, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
NickKeighleywrote:
I wanted my code to look something like this
void new_call (Msg& msg)
{
smart_ptr<Call> call_ptr ();
Declared a function.
CallList::add (*call_ptr); // may throw
Dereferenced a function???
Call *call = call.release();
If 'call' is a pointer, the dot operator cannot be used with it, not to
mention it's not initialized yet...
call.process_msg (msg);
Again, if 'call' is a pointer (as you declared just above), there is no
"dot" operator for it.
}
now that may not be quite right,
You bet your sweet donkey it isn't. Post real code, please.
ok, fair point
// a smart pointer question
#include <memory>
#include <vector>
using namespace std;
class Msg
{
public:
Msg()
{}
};
class Call
{
public:
explicit Call(Msg& msg): msg_(msg)
{}
void process_msg(Msg&)
{}
private:
Msg& msg_;
};
class CallList
{
public:
static void add (Call* call)
{
vec_.push_back( call);
}
private:
static vector<Call*> vec_;
};
vector<Call*> CallList::vec_;
void new_call (Msg& msg)
{
auto_ptr<Call> call_ptr (new Call(msg)); // auto_ptr may not b
what I want
CallList::add (call_ptr.get()); // may throw
Call* call = call_ptr.release();
call->process_msg (msg);
}
int main (void)
{
Msg msg;
new_call (msg);
return 0;
}
this at least compiles.
> but the aim was to allocate a Call
and store it in CallList. If CallList throws the smart_ptr will
destroy the Call, otherwise process the message and the call remains
in the CallList for more message processing.
smart_ptr would not allow copy or assignment. Release returns the
pointer value and zeros its record. I was going to call it
ExplicitReleasePointer. But then I thought,surely boost have already
done this. Aha! scoped_ptr! Oops no. No release(). The rationale for
this is that scoped_ptr implies no transfer of ownership. But I want
to transfer ownership. That I should use auto_ptr if I want transfer
of ownership semantics.
The last sentence makes no sense.
perhaps this is better:
The rationale for [scoped_ptr lacking a release()] is that scoped_ptr
implies no transfer of ownership (but I want to transfer ownership),
and that auto_ptr should be used if transfer of ownership semantics is
required.
This may be wrong but should at least make sense.
> But how do I coerce auto_ptr into doing the cleanup.
"Coerce"?
make it? get it to do? ask it to?
> Should I be making my container class do the cleanup?
Who owns the object?
if the add succeeds the container. If it fails the smart_ptr.
And if it is at different points in your program,
if it is owned by different things at different points in the program?
do specify that.
I thought I did
Cleanup is done by the owner.
ok...
> Or
should I be using shared_ptr in both the container class and my
calling function?
Probably. The ownership transfer is automatic then.
ok, thanks
My thought was that I didn't want the container class to do the
deletion as the caller might want to do with the something with the
"with the something with the"?
"do somethign with the call on failure"- say stuff a special call end
reason or something.
Call even in the failure case (log data from the call or pass the call
to someone else to deal with).
Uh... OK. Where is the spec? Is that the spec? It doesn't rea=
lly
look or sound like one...
its a rather waffly vague spec. Allocate an object. Put it in a
container. If something goes wrong call the object's dtor.
I suppose the logic is that ownership is shared so you need a shared
pointer.
Perhaps you should start by trying to describe the algorithm and
indicate who owns what at every point.
I was attempting that.