On 11 Mai, 17:42, "Alf P. Steinbach" <al...@[EMAIL PROTECTED]
> 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 la****ngs 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 cir***stances.
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 cl***** 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 do***entation 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! ]
|
