RE: [boost] A nonnewable class

From: Jeff Paquette (paquette_at_[hidden])
Date: 2000-08-22 09:14:15

I tried to make this point a couple of months back when I suggested the same
idea (class nonallocatable) but was unable to convince anyone of its
usefulness. My version was:

#include <new>

class nonallocatable {
private:
  // single instance new and delete
  void *operator new(size_t);
  void operator delete(void *);
  void *operator new(size_t, const std::nothrow_t&) throw ();
  void operator delete(void *, const std::nothrow_t&) throw ();
  // array new and delete
  void *operator new[](size_t);
  void operator delete[](void *);
  void *operator new[](size_t, const std::nothrow_t&) throw ();
  void operator delete[](void *, const std::nothrow_t&) throw ();
  // placement new and delete
  void *operator new(size_t, void *) throw ();
  void operator delete(void *, void *) throw ();
  void *operator new[](size_t, void *) throw ();
  void operator delete[](void *, void *) throw ();
};

Any class that inherits from nonallocatable can not be dynamically
allocated, unless the subclass overloads operators new and delete itself. I
think the normal usage pattern for this class is for preventing 'guard' or
'sentinel' objects that are being used for ctor/dtor side effects (ie,
lock() / unlock() ) from being being misused. When a potential misuse
arises, I think the engineer will ask "gee, why can't I allocate this class"
and look at the header. At that point it should be clear that the class was
not intended to be dynamically allocated. It is true that it could be
misused, but that falls under the heading of "enemy action" and not due to
poor design.
--
Jeff Paquette
paquette at mediaone.net
http://www.atnetsend.net
> -----Original Message-----
> From: Milutin Jovanovic [mailto:miki_at_[hidden]]
> Sent: Tuesday, August 22, 2000 9:04 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] A nonnewable class
>
>
>
> From: "David Abrahams" <abrahams_at_[hidden]>
> > 1. noncopyable can be used when no sensible copy semantics
> exist. There is
> > simply no analogue for dynamic construction. If it makes sense to write
> >     X x;
> > then it also makes sense to say
> >    std::auto_ptr<X> x(new X);
>
> Until recently I did not see much use for it, but we have a
> concrete example
> in our thread conversations. The mutex_lock class that locks a mutex only
> within a scope should not be allowed to exist on heap and that
> way keep the
> lock outside of scopes. Object stored in your auto_ptr can very legaly
> survive past the end of your scope.
>
> > 2. noncopyable prevents copying even when the type in question is a
> > subobject. nonnewable can't prevent dynamic allocation as a subobject.
>
> True, but the writer of the subclass takes responsibility for
> that. Yes, it
> opens a door for workarounds, but at least you warned (strongly) the user.
>
> Cheers,
>
> Miki Jovanovic.
>
>
> 
>
>
>