new and delete from different threads

I am aware that the C++ standard in its present form does not say
anything about threads, however I do have a relevant question.

What makes your question on topic? I don't see anything other than a
question about threading, which is not on topic since this newsgroup
only covers standard C++.
I am working on Windows XP/VC++ 8.0.
Yes, but that's irrelevant on this newsgroup.
Should I be careful about new'ing and deleting from the same thread?

Is there a problem new'ing a bunch of objects from one thread and
deleting them in another? ...

I am aware that the C++ standard in its present form does not say
anything about threads, however I do have a relevant question.

I am working on Windows XP/VC++ 8.0.

Is there a problem new'ing a bunch of objects from one thread and
deleting them in another? I do something like:

struct GenericPointerD eleter
{
template<typena me T>
void operator()(T* p)
{
if (ptr != 0)
{
delete ptr;
ptr = 0;
}
}
};

typedef vector<classofp ointers*> vecptrs;
int main()
{
vecptrs myptrs;
CreateThread(.. .... (LPVOID)&myptrs ........);
// use some platform specific API to wait until
threadcallbackr outine terminates
pseudo_wait_for _terminate(thre adcallbackrouti ne);

for_each(myptrs .begin(), myptrs.end(), GenericPointerD eleter());
}

DWORD WINAPI threadcallbackr outine(LPVOID param)
{
vecptrs* my_ptrs = static_cast<vec ptrs*>(param);
my_ptrs->push_back(ne w classofpointers ());
return 0;
}

I have vastly simplified what is essentially happening in my
application...

Should I be careful about new'ing and deleting from the same thread?

I am aware that the C++ standard in its present form does not say
anything about threads, however I do have a relevant question.
You could frame it in terms of Boost.Threads, since something along
those lines will likely be included in C++09. Then it would be on
topic. :-)

I am working on Windows XP/VC++ 8.0.

Is there a problem new'ing a bunch of objects from one thread and
deleting them in another? I do something like:

struct GenericPointerD eleter
{
template<typena me T>
void operator()(T* p)
{
if (ptr != 0)
{
delete ptr;
ptr = 0;
}
}
};
First, there's no need to check for null before deleting. Second,
zeroing the pointer is generally unnecessary, though it might be useful
if you reuse the pointer (doesn't look like you do below) but such
reuse is often considered bad practice. Lastly, you're duplicating
existing functionality. You could use std::tr1::share d_ptr (aka
boost::shared_p tr) for a smart pointer that works with standard
containers.

typedef vector<classofp ointers*> vecptrs;
If you do this...

typedef vector< shared_ptr<clas sofpointers> > vecptrs;
int main()
{
vecptrs myptrs;
CreateThread(.. .... (LPVOID)&myptrs ........);
// use some platform specific API to wait until
threadcallbackr outine terminates
pseudo_wait_for _terminate(thre adcallbackrouti ne);

for_each(myptrs .begin(), myptrs.end(), GenericPointerD eleter());
....then this is completely unnecessary. It is done automagically by the
destructors.
}

DWORD WINAPI threadcallbackr outine(LPVOID param)
{
vecptrs* my_ptrs = static_cast<vec ptrs*>(param);
my_ptrs->push_back(ne w classofpointers ());
return 0;
}

I have vastly simplified what is essentially happening in my
application...

Should I be careful about new'ing and deleting from the same thread?

Dilip wrote: First, there's no need to check for null before deleting.
I know.. more like defensive coding. :)
Second,
zeroing the pointer is generally unnecessary, though it might be useful
if you reuse the pointer (doesn't look like you do below) but such
reuse is often considered bad practice. Lastly, you're duplicating
existing functionality. You could use std::tr1::share d_ptr (aka
boost::shared_p tr) for a smart pointer that works with standard
containers.

If you do this...

typedef vector< shared_ptr<clas sofpointers> > vecptrs;

for_each(myptrs .begin(), myptrs.end(), GenericPointerD eleter());

...then this is completely unnecessary. It is done automagically by the
destructors.

First, there's no need to check for null before deleting.
I know.. more like defensive coding. :)

The FAQ calls it "wrong":

http://www.parashift.com/c++-faq-lit....html#faq-16.8
I would like nothing better than using Boost but management has a
policy on open-source projects and one of them involves being paranoid
about downloading them. :-) NIH syndrome is very prevalent around here.

You might try to make the
case that shared_ptr is part of the standard C++ library working
group's technical report -- (currently) non-normative extensions to the
C++ standard library that will likely be included in the next version
of the library

I would like nothing better than using Boost but management has a
policy on open-source projects and one of them involves being paranoid
about downloading them. :-) NIH syndrome is very prevalent around here.

Dilip wrote:
shared_ptr is probably the single most valuable part of Boost. It truly
increases the stability of your code, not only by automatically cleaning
up resources, but also by virtually eliminating accidental double
deletions and dereferencing dead or uninitialized pointers. Using
weak_ptr you can ensure that your weak references automatically expire
when the last copy of the owned object they point to goes out of scope.