From: Miki Jovanovic (miki_at_[hidden])
Date: 2000-05-26 09:41:21
--- In boost_at_[hidden], "Mark Rodgers" <mark.rodgers_at_c...> wrote:
> Now, I'm not going to say this is important or even likely. I'm
> just asking whether we can be too clever in trying to second guess
> how users might want to use our code, and so cut off options
Huh... Until now I did not care very much about noninstantiable. I
seldom use completely static classes. But your example sent shivers
down my spine... Instantiating completely static class in order to
call static member on it. Wow! Now I'll support noninstantiable, just
to explicitly discourage that kind of usage.
In a perfect world, noninstantiable probably should not exist. But it
is useful during development, until you know what instantiating the
static class would do.
My standard practice is to start with a very restrictive class:
noncopyable, noninstantiable... all protections I can find. Then, as
I develop the interface and implementation, I slowly release the
restrictions into those areas I have thought of. This keeps the
not-so-well-thought-out parts of the code non-accessible to the user.
So until you explicitly test your class for instantiation, I would
suggest keeping it noninstantiable.
Yours slightly frightened,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk