Re: ANN: AutoNewPtr (oh yes, yet another smartpointer)
On 11 Mai, 17:42, "Alf P. Steinbach" <al...@start.no> wrote:
I just coded this up, and hopefully by mentioning it here I'll get some
useful
feedback, like, bugs, shortcomings, improvements...
[..]
Since I haven't yet used this beast, other than testing the basic
functionality,http://code.google.com/p/alfps/source/browse/trunk/test/pointers/auto...
r/01/main.cpp,
I really don't know how it fares. I suspect -> access is not the most
efficient
since it's checking for voidness. But that shouldn't be a problem with e.g.
files and windows and such objects where this pointer would be relevant, I
think, and the main objective here is programmer productivity, not
efficiency.
It's not just one file (AutoNewPtr just wraps CheckedPtr, which uses various
things), so I think one would need the whole shebang, which Google says
# Non-members may check out a read-only working copy anonymously over
HTTP.
svn checkouthttp://alfps.googlecode.com/svn/trunk/alfps-read-only
In there is also an adapted version of Howard Hinnants C++0x unique_ptr
emulation, and an adapted version of Turkani's (et.al.'s) move_ptr. I'd
hoped
to be able to use unique_ptr instead of e.g. auto_ptr, looking to the
future!
But unfortunately MSVC 7.1 doesn't really like the unique_ptr code, and
neither
adaption has been used by me for anything, or seriously tested by me. I
will
probably remove these smart pointer adaptions. Just didn't think of it
before
putting the code out there.
Praise and lashings and wild ideas all welcome.
Note that this is just freshly coded, it's currently more idea stuff than
anything else, but, might still be useful as-is!
Let me begin with some apologies that I only took
a short sweep over the code, so that I have not
*fully* grasped all it's miracles. Therefore it would
be a shame if I would start with a lot of praises - on
the other side the same reason hinders me to unpack my
large whip, so all in all this seems like some kind of
balance ;-)
So here are some points that caught my eyss:
1) AutoNewPtr<>::operator Base(): Is practically useless, see
[class.conv.fct]/1:
"[..] A conversion function is never used to convert a (possibly cv-
qualified)
object to the (possibly cv-qualified) same object type (or a reference
to it),
to a (possibly cv-qualified) base class of that type (or a reference
to
it),[..]"
2) CheckingPtr: CheckingPtr::CheckingPtr( T* p ) is not exception
safe, if I
read your code correctly. Consider that
new detail::AutoClearingRefCountedDeleter<T>( p )) fails, and no-one
cleans up
p. Note that shared_ptr, which has basically to cope with the same
problem,
does solve this, by carefully ensuring that p will be cleaned-up even
under
those circumstances.
3) Personally I don't like the choice to use the notion of "void" to
signal a
meaning of "empty" (makeVoid, isVoid, ...). I assume that you have
chosen this
different name to prevent the meaning "dubiety" of empty in
shared_ptr? ;-)
Whatever the reason was I strongly propose to clarify it's meaning.
4) DestructionEventSource:
a) The decision to introduce the pair
void setDestructionEventHandler( IHandler& handler )
void clearDestructionEventHandler()
Since there obviously exists an "empty" state (otherwise clearing
does not make much sense), I probably would have reduced this pair
to the single function
void setDestructionEventHandler( IHandler* handler )
This decision is largely a matter of taste, but you were asking also
for "wild ideas" and this is one of mine;-)
b) What was the main reason to provide copy constructor and copy
assignment of DestructionEventSource (with an unusual semantic) at
all?
As far as I see, the corresponding user classes are non-copyable.
5) Second overload of throwX( char const s[] ): I wonder concerning
the
unusual argument type, which is basically the same as const char*. Is
this supposed to be a documentation to the reader? If you want a
proper
protection against potential NULL arguments I propose to use a
template
based approach like this one:
template<std::size_t N>
FUNCATTR_NORETURN inline bool throwX( char const (&s)[N] ) {
... // Your code
}
This will only accept char arrays.
PS: Yes I'm aware that adding things to namespace std is formally
prohibited,
except specializations of existing templates. The stuff added is such
things
that will be added by C++0x. I think it's better to just use namespace std
than
to keep changing code as things migrate boost -> tr1 -> std.
I probably would have used the boost functionality
explicitly since you use it already where the standard
has no similar feature (Not even for C++0x).
Greetings from Bremen,
Daniel
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]