Re: Suggestion to add class nonistantiable to utility.hpp

From: Miki Jovanovic (miki_at_[hidden])
Date: 2000-05-26 09:41:21

--- In boost_at_[hidden], "Mark Rodgers" <mark.rodgers_at_c...> wrote:
>   user::bar(library::some_thing());
>   user::bar(user::my_thing());

<snip>

> 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 
> needlessly.  

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,

Miki.