From: Marcus Lindblom (macke_at_[hidden])
Date: 2007-06-19 08:54:41
Alex Burton wrote:
> Marcus wrote:
>>> A fair comment would be that this class actually does nothing,
>>> that a normal pointer would do and this is true.
>>> However, I find it extremely useful, and would like it considered
>>> as an addition to boost.
>> Good initiative. However, there seems to be some orthogonal concepts
>> baked in here, and everyone might not want all of them at the same
>> even if each one is useful on their own. Perhaps each concept could be
>> split up (via policy classes) so that one could define checks for any
> The intent of the pointer is not just to check null dereferences. The
> check that currently throws an exception could be changed to do what
> scoped_ptr etc does, which is to do a debug assertion.
>>> It allows my code to be free of the * pointer notation.
>>> All pointers look the same, ie shared_ptr<Foo>, scoped_ptr<Foo>,
>> Why is that desirable?
> It is desirable so that that the pointers look the same, this means
> that fewer mistakes when changing between pointer types as code changes.
> It is also desirable (at least for me) so that in my code I
> explicitly see the intent of the pointer.
> When (now simple_ptr) is used the programmers intent is to only look
> at the object pointed to, not to own it or share it.
> When a normal pointer is used, the intent is unclear.
IMHO raw pointers are excellent for showing that you're only looking. If
you intend to handle ownership, you'd better wrap it in something
smarter as fast as possible. :)
Therefore I am a bit confused, since, most of the time, a smart_pointer
class implies some form of memory management. But that's not always the
case. I've seen smart-pointers used to select thread-specific data (not
just boost::thread_specific_pointer, which also handles ownership) etc.
>>> It throws an exception if it has been default constructed or set
>>> to 0, this could probably be a debug only behaviour for
>>> efficiency, but i leave it in release code.
>> I find the notion of a null ptr useful. How about just checking
>> that in operator * and -> as other boost::ptr's.
> I do too (though never in production code, only in test code).
> The check is only made as you describe.
Ok. I misunderstood and thought you wanted to disallow it being null
>>> vector<Foo> foos;
>>> BOOST_FOREACH(weak_ptr<Foo> f,foos)
>>> //do something with f->
>> OTOH, the for_each could use an indirect_iterator-range instead, to
>> iterate over IFoo& instead.
> Yes but that would require a change to the code.
True. It all depends where you want to put the deref-or-not logic.
(either in the pointer type or in the container or in a fancy
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk