Re: boost::scoped_ptr rationale?
On 20 juuli, 13:22, Juha Nieminen <nos...@thanks.invalid> wrote:
=D6=F6 Tiib <oot...@hot.ee> wrote:
On 19 juuli, 18:10, Juha Nieminen <nos...@thanks.invalid> wrote:
Can someone give me an example where it makes any sense to use
boost::scoped_ptr?
There is nothing better for a polymorphic component of object.
boost::scoped_ptr data member automatically disables default
assignment and copy construction unlike std::auto_ptr.
I suppose that makes sense.
(OTOH, it might be a bit more obfuscated to get an error message rela=
ted
to some private member of a class when you try to copy instances of it,
Depends on compiler perhaps. I think most will just say that you do
not have copy constructor or assignment operator of class available
and not drop too deeply into details why it is so.
than it would be to get a direct error message that says "sorry, the copy
constructor / assignment operator of this class is not accessible". If yo=
u
want to make it more explicit that you really have disabled copying, then
you would declare the copy constructor / assignment operator private, in
which case it doesn't really matter if you use scoped_ptr, auto_ptr or
something else for your polymorphic Pimpl opject...)
OK, may be matter of taste. I like complex class interface definition
arranged like that:
class Something // :,, possible bases
{
public:
// ... interface type defs
public:
Something(); // may be missing
Something(Something const& that); // may be missing
// ... other constructors
virtual ~Something(); // may be missing
Something& operator=(Something const& that); // may be missing
// **comment**
// ... rest of public interface
// ... is sometimes not that short
protected:
// ...
private:
// ...
};
Like you see private section is at bottom and i do everything i can to
not make someone who just wants to use the class for something not to
need to read the protected section or below. There are too lot of
possible class layouts to make interface intuitive without commenting
construction/destruction/copying within public section.
That **comment** therefore explains all oddities of construction/
destruction/copying. What about missing ones from that section? Are
default, compiler-generated things OK? Why? Was something from default
interface disabled by something? Why? Was something moved to non-
public for some reason? Why? Are there factories/recyclers? Why?
Where? ... so on.
It is perhaps matter of taste, but i feel it is one place where i am
pondering "why? .. why? ... wtf?" most often when looking at someones
class definition and comments help there greatly. This pondering gets
boring after a while when there are hundreds of classes.