Boost logo

Boost :

From: Mark Rodgers (mark.rodgers_at_[hidden])
Date: 2000-05-26 03:18:51


> An argument in favor might be that a programmer instantiating fred is
> probably misunderstanding it, so there is a benefit to letting the
> programmer know the usage is amiss. It might make the intent of fred
> clearer to a human reader, too.

OTOH, it _might_ prevent a legitimate use. Suppose we have

  namespace library
  {
      struct some_thing
      {
         static void foo() { /*...*/ }
      };
  }

Now, suppose some user wants to write a function that could use
library::some_thing, or could use an instance of their own class
which has state, and therefore can and should be instantiated.

They might write

  namespace user
  {
      struct my_thing
      {
          void foo() const { /*...* }
          //...
      };

      template <typename T>
      void bar(const T &t)
      {
         //...
         t.foo();
         //...
      }
  }

  user::bar(library::some_thing());
  user::bar(user::my_thing());

As it stands, this would be legitimate and might even be useful.
However, make library::some_thing non-instantiable and we would
prevent this usage.

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.

In short, if no harm can come from instantiating a class, and some
benefit just might result, do we need to prevent instantiation?

Mark
Devil's Advocate


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk