Re: when to call auto_ptr release?
George wrote:
1.2 What about if there are some types of resource which we could
allocated on heap? (currently I can not think of such a type of resource,
do you know any? If there does exist such type of resource, your code has
the same allocation performance issue as mine)
There is a reason you don't know of any such type, and that is that they
don't exist because they don't make sense.
If you compare auto_handle<R> to an auto_ptr<T>, you will find that it is
very similar. An R is the equivalent of a T*. Both R (a handle type) and T*
(a pointer) are ways to refer to some resource, either a C++ object of type
T or an opaque type that is represented by the handle. In both cases, the
pointer/handle that is used to refer to something (R or T*) is copyable,
while the thing they refer to is not copied and usually not even copyable.
Dynamically allocating a handle or pointer doesn't make sense, because you
can well pass the pointer along.
2. Unless you also provide a release() function, your code is not as
flexible. Sure, it is to some extent safer, because there is nothing that
could go wrong.
Because of default release() provided by the auto_ptr will make 0
assignment for wrapped pointer, which does not work for resource type?
(for example, invoking close function on resource handle is more
appropriate for assignement of 0?)
No, that's not what I meant. The reasons for allowing a release() functions
are the same as for std::auto_ptr, i.e. when transferring ownership to a
shared_ptr or to a special container (which can't use auto_ptr internally).
the contained HANDLE itself can be null. You could change this by stating
that a non-null HANDLE is a class invariant and then throw in the
constructor. It depends on the context whether that makes sense.
You mean in design, we do not allow wrapper handler to be NULL through the
life cycle of the auto_ptr object instance and if user set NULL handle to
object instance constructor, exception will be thrown to indicate the fail
to create such an object instance?
Right. If you can't establish that class invariant, the constructor must
throw. BTW: I used 'null' in a non-strict way to refer to a signal value
that means "invalid" or "no resource". For win32 HANDLEs, that could be
NULL or INVALID_HANDLE_VALUE, for Unix filedscriptors (int) that would
be -1 (Note: 0 is a valid FD!).
template <typename T>
struct traits
{
};
template <>
traits <int> // struct traits <int> compiles
{
};
1>d:\visual studio 2008\projects\test_autoptr1\test_autoptr1\goo.cpp(9) :
error C2988: unrecognizable template declaration/definition
1>d:\visual studio 2008\projects\test_autoptr1\test_autoptr1\goo.cpp(9) :
error C2059: syntax error : '<end Parse>'
Hmmm, line 9 is in the middle of the leading comment here and I can't find
a 'struct traits' anywhere else either, so I can't reproduce this....
Uli
--
C++ FAQ: http://parashift.com/c++-faq-lite
Sator Laser GmbH
Gesch??ftsf??hrer: Michael W??hrmann, Amtsgericht Hamburg HR B62 932