Re: Does push_back() do a copy?
Gavin Deane wrote:
On 1 Jul, 10:48, James Kanze <james.ka...@gmail.com> wrote:
On Jun 30, 2:24 pm, Gavin Deane <deane_ga...@hotmail.com> wrote:
On 29 Jun, 09:57, James Kanze <james.ka...@gmail.com> wrote:
On Jun 28, 8:37 pm,GavinDeane<deane_ga...@hotmail.com> wrote:
On 28 Jun, 17:20, Angus <anguscom...@gmail.com> wrote:
On 28 Jun, 16:11, Erik Wikstr=F6m <Erik-wikst...@telia.com> wro=
te:
The correct solution is to do like you did, use new to create=
the
within an appropriate RAII object (e.g. a smart pointer),
It's hard to imagine one with the appropriate semantics for a
socket. This is exactly the sort of thing where one wants
explicit destruction.
I was only thinking about appropriate semantics for managing the
memory. If the object pointed to is responsible for a resource of its
own too (a socket connection) then it too needs to have been written
with RAII (or rather, the corollary of RAII, Destruction is Resource
Release, which is usually the real point of RAII anyway) in mind, but
that's an orthogonal point.
I don't think so. A socket has (or probably should have) a
specific lifetime; it's lifetime is not something that you can
somehow "automate", because it depends on external events.
This isn't necessarily true, however, and I can think of
scenarios, where a socket would have a lifetime which
corresponds to scope. But that isn't the case here, since the
poster is intentionally allocating them.
Raw pointers have scope and lifetime in exactly the same way as smart
pointers. The only difference is:
The main difference is that with raw pointers, you control the
object lifetime. With shared_ptr, and similar smart pointers,
you get whatever object lifetime the pointer decides to give
you. If object lifetime is an important part of the design
(which is probably the case with a socket class), you don't what
some smart pointer handling it. If it's not, you don't need
anything handling it.
Use raw pointers:
While one or more pointers to the object exist, you can use the
object.
What makes you say that? If the object is dead, or invalid, you
can't use it. The fact that you have a pointer to the object
doesn't guarantee it's validity in any way.
You have the option to explicitly delete the object at any time.
At the time the last pointer to the object goes out of scope, if you
haven't explicitly deleted the object, you have no other way of
deleting it so you have a memory leak.
What's all this bullshit about memory leaks. The garbage
collector (Boehm or other) takes care of memory. What we're
concerned about here is object lifetime.
Use smart pointers:
While one or more pointers to the object exist, you can use the
object.
So what you're saying is that you can output to the socket, even
if it has been closed, and---perhaps more importantly---even if
the program design says that you shouldn't. That doesn't sound
like a feature to me.
You have the option to explicitly delete the object at any time.
We must be talking about different smart pointers. Deleting an
object owned by a shared_ptr will result in a double delete.
At the time the last pointer to the object goes out of scope, if you
haven't explicitly deleted the object, the smart pointer does it for
you.
Unless you want objects to exist after you have no pointers to them
left, with no way of using or deleting them, smart pointers are better
aren't they?
No. They try to hide the problem of lifetime management, and
end up making it more difficult.
I am talking here only about one of the two independent resources: the
memory in which the pointee object lives.
In other words, you're talking about garbage collection. If for
some reason, you can't use real garbage collection, shared_ptr
can be used to simulate it. But it's a lot of extra work; you
have to worry about cycles, for example.
I don't think any of the above logic changes depending on
whether the pointee object itself is responsible for some
resource of its own.
There is a second potential problem with regards to using RAII
with a socket: releasing the resource can fail, and you may have
to handle the error. In practice, this would mean that you
cannot release the resource in the destructor. Again, this
depends somewhat on design.
So the conversation goes:
Me: Hello Operating System, I would like a resource [socket
connection] please.
OS: Here you go. Remember to give it back to me won't you - that's
your responsibility.
Me: Of course I will. Thanks very much.
... [time passes] ...
Me: Hi OS. I've finished with that resource you gave me. Here it is
back to you.
OS: No. I'm not taking it.
Me: ??? !!!
How do you handle that then?
Have you ever actually programmed any buffered IO. Closing a
socket or a file will flush the buffers. If there's an error
flushing the buffer, you have to handle it; at the very least,
you need to log the error.
RAII, in its simplest form, works best for objects whose
lifetime depends on scope. Things like shared_ptr can be used
for memory managment, but aren't really applicable for objects
with an explicit lifetime.
I still don't get this. It's no harder to keep a smart pointer around
for as long as I want than it is to do the same for a raw pointer.
As I said, things like shared_ptr can be used for memory
management. They aren't anywhere near as effective as the Boehm
collector, however.
And
when I need to explicitly delete the pointee, I am still left with a
dangling pointer whether I use raw or smart pointers. The only
difference is that, with smart pointers, it is not possible for the
object to still exist after I have no longer got any pointers to it.
There's never a time when you want that to be possible is there?
Sort of:-). If the object is registered with an external source
of events. Obviously, the event source will be keeping a
pointer to it, but in most cases, this will be as a void*, since
the event source knows nothing of your classes.
I'm not sure if this is relevant to your argument, however.
Depending on how you configure things, garbage collection may or
may not be able to track the pointer here, and you may have to
pin the object explicitly (by maintaining a pointer to it in
your own code), regardless.
If I understand you correctly, all you're arguing for is using
smart pointers for garbage collection. Better solutions exist,
and I wouldn't start a new application today without the Boehm
collector.
[...]
I think there are two different things getting confused here.
There are socket connections which are opened and closed (and
an open connection is a resource I am responsible for
closing). Obviously, the lifetime of a connection is from the
time it is opened to the time it is closed (although that does
become more complicated if, as you say above, when I try to
close one I might not be allowed to). And then there are
socket connection objects that manage socket connections. The
lifetime of one of these objects is whatever I choose to
program. During its lifetime, I may use such an object to
open then close just a single connection or I may use it to
open then close many succesive connections. Either way, I am
responsible for ensuring that I don't have a connection open
after the object is destroyed. If it weren't for this issue of
the OS possibly not letting me give the resource back when I
want to, RAII would be the perfect tool to ensure that.
The issue isn't not being able to close the socket. The issue
is handling errors that result when you close it. How do you
report an error from a destructor.
The second issue is arbitrary lifetime. If the lifetime
corresponds to scope, RAII is a perfect solution; it handles all
of the cases automatically. If the lifetime doesn't correspond
to scope, however, it doesn't really handle anything. What's
the difference between explicitly calling delete, and calling
whatever function you need to call to trigger the call to
delete.
[...]
I keep coming back to this (and so I wonder if I'm just missing the
point) but smart pointers don't remove your ability to destroy an
object while pointers to it still exist, they protect against the
possibility of not destroying an object by the time that no pointers
to it exist any more.
I'm not sure I understand what you are claiming here. Are you
saying that something like the following is legal:
class Toto
{
public:
// ...
void finished()
{
delete this ;
}
// ...
} ;
boost::shared_ptr< Toto > p = new Toto ;
// ...
p->finished() ;
// ...
If so, there's something that seriously haven't understood about
boost::shared_ptr.
If, for some reason, you can't use a better garbage collector,
something like boost::shared_ptr can be used. It's just a lot
more work (and typically results in a slower program as well, at
least for the type of work I do).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34