Boost logo

Boost :

From: Marco Costalba (mcostalba_at_[hidden])
Date: 2007-09-02 04:59:01


On 9/2/07, Dean Michael Berris <mikhailberis_at_[hidden]> wrote:
> On 9/1/07, Tobias Schwinger <tschwinger_at_[hidden]> wrote:
> > Marco Costalba wrote:
> > > This is a simple yet interesting object factory.
> >
> > Please see
> >
> > http://tinyurl.com/35vlvb
> >

Probably there is a difference in naming conventions between mine and
the above proposed link.

There "Factory" is actual what in my example is called "Creator", i.e.
the _thing_ that calls the object constructor. It is bounded to one
object class.

While what I called factory, it seems to be called "dispatcher", i.e.
a _thing_ that given a key in input, as example a string with the
class name, calls the actual object "creator", you would say the
object factory.

Indeed in the above link I fail to see the mapping framework between
class identifiers and actual creators/factories for that class, or put
in other words I don't see the dispatcher.

>
> A similar approach could be done with
> http://dispatcher.sourceforge.net/ -- only this time it's not required
> that the function registered is a "factory". It could very well be any
> function registered.
>

The dispatcher is much nicer ;-) i.e. is what I'm looking for
especially for the clean syntax.
I will study better.

Anyhow dispatcher does not support contructor overloading, as example
I can register functions that calls two different object constructors:

MyObject* function_0() {
        return MyObject();
};

MyObject* function_1(int v) {
        return MyObject(v);
};

d["MyObject_0"] = function_0;
d["MyObject_1"] = function_1;

But when I call I have to use two different keys, in this case
"MyObject_0" and "MyObject_1".

d["MyObject_0"]();
d["MyObject_1"](7);

With my example factory I would say instead:

Factory::object("MyObject"); // calls function_0
Factory::object("MyObject", 7); // calls function_1

Indeed I didn't find this "constructor overloading" feature in any place.

Marco


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