Newbie question: new/delete

[Guest]

I have a question regarding deleting a dynamically created objects.

Thread 1 of my application create a new object using "new", say
MyClass* p1 = new MyClass
And I pass the address pointer to thread 2, where pointer p2 stores the
address from p1, thread 1. My question is: can I successfully delete the
object by
delete p2;
in thread 2?

Thanks a lot!!

 

[Carl Daniel [VC++ MVP]]

I have a question regarding deleting a dynamically created objects.

Thread 1 of my application create a new object using "new", say
MyClass* p1 = new MyClass
And I pass the address pointer to thread 2, where pointer p2 stores
the address from p1, thread 1. My question is: can I successfully
delete the object by
delete p2;
in thread 2?

Yep.

-cd

 

[William DePalo [MVP VC++]]

I have a question regarding deleting a dynamically created objects.

Thread 1 of my application create a new object using "new", say
MyClass* p1 = new MyClass
And I pass the address pointer to thread 2, where pointer p2 stores the
address from p1, thread 1. My question is: can I successfully delete the
object by
delete p2;
in thread 2?

Generally, yes, you can.

That's because the threads of your process always share the same virtual
address space so pointers have the "same meaning" across threads.

The threads also need to share the same C++ heap for dynamic memory
allocations for this to work. If both threads were created in the same
executable (either .dll file or .exe file) that's guaranteed.

Regards,
Will

 

[Larry Brasfield]

Generally, yes, you can.

I would have to qualify that assurance. If you are using
either the multi-threaded static form of the C runtime,
or its multi-threaded DLL form, then there should be
no problem with using the allocator from multiple threads.
However, if you link against the single-threaded static
form of the CRT, then it would be prudent to avoid
using the allocation routines, along with many others
that are designed for only single-threaded use.

That's because the threads of your process always share the same virtual address space so pointers have the "same meaning" across
threads.

I would agree with that statement provided no call
into the allocator is active.

 

[William DePalo [MVP VC++]]

I would have to qualify that assurance. If you are using
either the multi-threaded static form of the C runtime,
or its multi-threaded DLL form, then there should be
no problem with using the allocator from multiple threads.
However, if you link against the single-threaded static
form of the CRT, then it would be prudent to avoid
using the allocation routines, along with many others
that are designed for only single-threaded use.

All very true. But realize the the recent tools don't even let you call
__beginthreadex() when building against the single threaded runtime. Yes, I
know, that still leaves Win32's CreateThread() to cause grief. OP, if you
are "listening", forget CreateThread() exists; using it is _almost_ always
the wrong thing to use in a C or C++ application.

It's always a fine line to walk providing advice here. There is rarely a
question that can be answered adequately in a line or two. Too much
information increases the chances that the OP won't understand. That's why I
used the qualifier, "generally" and tried to steer the OP away from try to
sharing runtime widgets across a DLL boundary.

I would agree with that statement provided no call
into the allocator is active.

I'm not sure I get you here. Do you mean that you have to prevent one thread
from deleting an object to which another holds a pointer? If so, I heartily
agree. But that's just one example of the kinds of things to consider in a
multi-threaded environment. No matter which runtime the OP uses, he has to
synchronize access to the "updates" of the objects he shares among threads
just as the runtime does. But the mere choice of proper runtime won't do
that for him.

Regards,
Will

 

[Larry Brasfield]

All very true. But realize the the recent tools don't even let you call __beginthreadex() when building against the single
threaded runtime. Yes, I know, that still leaves Win32's CreateThread() to cause grief. OP, if you are "listening", forget
CreateThread() exists; using it is _almost_ always the wrong thing to use in a C or C++ application.

My concern here is that it is easy to initiate threads with
CreateThread(), especially since the docs purporting to
describe _{begin,end}thread{,ex}() do not provide the
slightest clue as to *why* they should be called. As far
as those docs will say, those functions do little beyond
merely wrapping the CreateThread() API.

It's always a fine line to walk providing advice here. There is rarely a question that can be answered adequately in a line or
two. Too much information increases the chances that the OP won't understand. That's why I used the qualifier, "generally" and
tried to steer the OP away from try to sharing runtime widgets across a DLL boundary.

I'm not sure I get you here. Do you mean that you have to prevent one thread from deleting an object to which another holds a
pointer? If so, I heartily agree. But that's just one example of the kinds of things to consider in a multi-threaded environment.
No matter which runtime the OP uses, he has to synchronize access to the "updates" of the objects he shares among threads just as
the runtime does. But the mere choice of proper runtime won't do that for him.

That last statement of mine was quite unclear. Sorry.
What I was trying to say, (in too few words), is:
Use of the allocator in the single-threaded CRT should
be strictly serialized. Otherwise, no pointers to the kind
of objects being discussed, (see subject line), can be
assumed to have any useful meaning. Better yet, be sure
to never use the single-threaded CRT in a multi-threaded
program. This can be assured by using _beginthreadex()
to create threads.

Best regards,