Surely there's no need to call wait until the parent asks for the return value: In fact I'd kind of like the library to be similar to Boost.Threads - a child process is an object that can be waited upon, the library would only need to do something "fancy" like installing a signal hander, if the child object's destructor is called, without the object ever being waited upon.
Consider this:
int main() { child::process mozilla; mozilla.spawn("mozilla"); return 0; };
You're suggestion, that child::process::~process() invokes wait() means that this program will not exit until mozilla exits. That doesn't seem reasonable here. Even less so if the function launching mozilla was in a control loop...
I didn't say that (well I hope I didn't), I'm saying that if there has been no explicit wait then the destructor has to take care of cleanup (as far as is possible in such a case), it should *not* wait as you rightly point out. John.