Re: Dealing with HANDLEs

"Arnaud Debaene" wrote:

Think more about it : Are you sure you want your "Process" class to be
copiable? A process is a unique entity, with it's own identity (it's
ProcessID), which can't be duplicated : the closest thing to copying a
process is forking it, which is quite unnnatural on Windows and is NOT a
mere copy.
It should be the same thing with your class : it shouldn't be copiable In
that case, making it's copy constructor private and undefined should do
the trick.

Now, if your class is more a "ProcessInformation" than a "Process", and
you really want to be able to copy it, DuplicateHandle is the way to go
(in both the copy constructor and the asignement operator).

Duplicated handles are not necessarily interchangeable. Each handle
has its own flags that can be set with SetHandleInformation for
example. The actual numeric value of the handle is also often used
for things like tracing/debugging, or even passing it as a command
line argument to child processes (for inheritable handles).

So I don't think using DuplicateHandle in a copy constructor or
operator= is a good idea. I would just make this class non-copyable.

--
This posting is provided "AS IS" with no warranties, and confers no
rights.


.

Relevant Pages

  • Re: Dealing with HANDLEs
    ... the closest thing to copying a ... you really want to be able to copy it, DuplicateHandle is the way to go ... (in both the copy constructor and the asignement operator).Duplicated handles are not necessarily interchangeable. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Dealing with HANDLEs
    ... DuplicateHandle works 100%. ... source object before doing the copy or assignment. ... Assignment Constructor: ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Dealing with HANDLEs
    ... with copying a handle. ... DuplicateHandle as long as you play along the rules, ... The problem I noticed is about object model: ...
    (microsoft.public.win32.programmer.kernel)