Re: Undefined reference to...
On Nov 11, 4:01 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
* James Kanze, on 11.11.2010 10:16:
[...]
It's not clear what you're attempting, but it may be that you
want a Meyers' singleton:
class Base
{
public:
virtual void printOut() = 0;
static Base& getLower();
};
class Extended: public Base
{
public:
void printOut() { cout<< "hello"; }
};
Base& Base::getLower()
{
static Extended e;
// Whatever code you were intending to have here, then:
return e;
}
Note that with this scheme you always get the same object --
a singleton -- from 'getLower'.
Just for the record, that's *not* a Meyers' singleton, or any
other type of singleton.
Sorry, it is a singleton, and it is a Meyers' singleton.
There are many definitions of "singleton".
I'm using the one specified by the people who invented the
pattern, the one documented in the GoF book, and the one which
served as the basis of the name.
Simplistic definitions (e.g., Wikipedia's article on
singletons) focus on a restriction to a single object, as you
do, since that's common usage.
And since that's what the design pattern was designed for.
What applies here is the more general concept of a globally
single object that can only be accessed via a function and
that is created on demand.
Lazy construction. A concept which goes back even before
singletons. With another name.
The key feature of Meyers' singleton is that the object is
created as a static local variable in the function.
That is, in fact, the implementation detail which distinguishes
Meyers' singleton from some other implementation.
First, as discussed above, the condition you state is not
a condition of singletons in general (e.g., it conflicts
directly with the common view of Python bool values as
singletons), although such a restriction is often desirable
and is often the reason for *using* a singleton.
It is, in fact, the definition of "singleton".
Secondly, in the OPs case those conditions will probably be
satisfied anyway, by having Extended as a class defined in an
implementation file.
However, what you've just shown *is* the closest working
approximation of what he seems to be trying to do. Unless he
actually wants more than one instance---it's not really clear.
For more than one instance, he'd need a factory function, e.g.
class Base
{
public:
virtual void printOut() = 0;
static std::auto_ptr<Base> getLower();
};
class Extended: public Base
{
public:
void printOut() { cout<< "hello"; }
};
std::auto_ptr<Base> Base::getLower()
{
return std::auto_ptr<Base>( new Extended );
}
Sorry, the simplest way and the practical way to support
multiple instances is to expose class Extended to the client
code.
If that's what you want to do. If you don't, the factory
function pattern, above, works quite well.
--
James Kanze