Can I use a string to create a object?

[dolphin]

Hi All
I have a question now. Can I use a string to create a object?
For example ,I have a function

void fun(cha *str)

the str is a name of a type. If I call the function fun("int"),how do
I create a int type variable.And if there is a class name classtype, I
also call the function fun("classtype"),how do I create a classtype
type variable?

Thanks

 

[Ian Collins]

Hi All
I have a question now. Can I use a string to create a object?
For example ,I have a function

void fun(cha *str)

the str is a name of a type. If I call the function fun("int"),how do
I create a int type variable.And if there is a class name classtype, I
also call the function fun("classtype"),how do I create a classtype
type variable?

See yesterday's thread 'Is there any """Anti Stringizing operator #"""".

 

[dolphin]

See yesterday's thread 'Is there any """Anti Stringizing operator #"""".

Do you mean that I can not do this in C++?

 

[Ian Collins]

*Please* don't quote signatures.

Do you mean that I can not do this in C++?

Not directly, no. Read up on the factory pattern and its use in C++.

 

[dolphin]

*Please* don't quote signatures.




Not directly, no. Read up on the factory pattern and its use in C++.

I know the factory pattern.But the different is that the factory need
know all the type in advance. But in this function,we do not know what
type we will pass.

 

[dolphin]

*Please* don't quote signatures.




Not directly, no. Read up on the factory pattern and its use in C++.

I know the factory pattern.The different is that the factory need know
all the type that it would create in advance.In this funtion we do not
know what type we will pass.Is there any method?Thanks!

 

[Stuart Redmann]

I know the factory pattern.But the different is that the factory need
know all the type in advance. But in this function,we do not know what
type we will pass.

It sounds a bit like you have chosen the wrong language. C++ is stronly typed,
so you should always know which classes are available in your code (it's not as
if code could get added at run-time as this is possible with Java). Maybe you
should change to a scripting language (one should always carefully think about
which tools are the most suitable for a given problem space).

I know only a single scenario where the factory pattern actually makes sense:
When you program using some component framework like MS's COM or OMG's CORBA,
you can create components by giving their names to the framework. This way the
user can decide by external configuration files which functionality should be used.

What exactly are you trying to achieve? Maybe your problem can be solved in an
entirely different way?

Regards,
Stuart

 

[Matthias Buelow]

I know the factory pattern.The different is that the factory need know
all the type that it would create in advance.In this funtion we do not
know what type we will pass.Is there any method?Thanks!

You can create some kind of ad-hoc dynamic type mechanism, usually
consisting of a stub struct (or class) with a type identifier slot which
determines the rest of the "object". It thus mimicks how dynamic
languages do their thing, only written manually in C++ (or C). Sometimes
this is a good way to organize stuff although I have some doubt it is in
your case. What exactly do you need this for?

 

[James Kanze]

It sounds a bit like you have chosen the wrong language. C++
is stronly typed, so you should always know which classes are
available in your code

For the moment, if you limit yourself to the standard. In
practice, under both Posix and Windows, you can load new classes
dynamically; I've done so in specific cases. If you really want
to get tricky, it's also possible to unload them---or to unload
them and then reload them, to update parts of the code without
stopping the application.

(it's not as if code could get added at run-time as this is
possible with Java).

In practice, the constraints aren't much more than they are in
Java. You do have to write a bit more code---on the other hand,
if you don't need this capability (and most programs don't), you
don't pay for it.

Maybe you should change to a scripting language (one should
always carefully think about which tools are the most suitable
for a given problem space).

Scripting languages often go one step further---you can treat
part of the data as code. This can be very useful at times, but
can also lead to very unreadable programs if misused.

I know only a single scenario where the factory pattern
actually makes sense: When you program using some component
framework like MS's COM or OMG's CORBA, you can create
components by giving their names to the framework. This way
the user can decide by external configuration files which
functionality should be used.

It's quite useful for many different types of persistence, as
well. The persistent data contains a type identifier, followed
by the class data.

It's also useful in any number of scenarios where parsing is
involved, or additional dynamicism is required. (I used it for
specifying the encoding of an input file, for example.)

 

[Peter]

Hi All
I have a question now. Can I use a string to create a object?
For example ,I have a function

void fun(cha *str)

the str is a name of a type. If I call the function fun("int"),how do
I create a int type variable.And if there is a class name classtype, I
also call the function fun("classtype"),how do I create a classtype
type variable?

Thanks

I would make the string the name of a shared library or dll.
And please pass a const char * or even better a const std::string &.
This DLL should export a well-known function by name.
This well known function can be a function to create a factory class
instance
or maybe the finally class directly.
This way you can introduce new functionality which is not known at
compile time.

 

[Frank Bergemann]

I would make the string the name of a shared library or dll.
And please pass a const char * or even better a const std::string &.
This DLL should export a well-known function by name.
This well known function can be a function to create a factory class
instance
or maybe the finally class directly.
This way you can introduce new functionality which is not known at
compile time.

I was playing with a similar idea for some generic I/F handler.
There was actually no requirement by customer for this and i didn't find
"spare time" to exercise.
But my approach would have been to do it the other way around:
Let the libraries (which implement the types of objects, that are to be
created by the factory) themselves invoke some (static?) register()
function of the (one!) factory to make them be known by the factory.
I.e. the factory doesn't need to know in advance, which kind of
polymorphic objects it handles. It just needs to know the subset of
their interface needed to construct them. BTW: for the "things" to
contruct, you then "naturally" would already have defined an abstract
base class. And actually this base type is the only type of object the
factory need to return for its make().
Also the "string" that identifies the type of objects could be
registered by the various object types themselves:

static bool(?) factory::register(std::string const& myId)

factory could use a std::map<std::string> to save a list of registered
objects.
And so it could delegate its make() to the make() of the types themselves.

The main module (configuration setup) could just have a configuration
file, that list the libs to load dynamically.

I am pretty sure it will work (at least on unix).

\Frank

 

[James Kanze]

Peter schrieb:

I was playing with a similar idea for some generic I/F
handler. There was actually no requirement by customer for
this and i didn't find "spare time" to exercise.

But my approach would have been to do it the other way around:
Let the libraries (which implement the types of objects, that
are to be created by the factory) themselves invoke some
(static?) register() function of the (one!) factory to make
them be known by the factory. I.e. the factory doesn't need
to know in advance, which kind of polymorphic objects it
handles. It just needs to know the subset of their interface
needed to construct them. BTW: for the "things" to contruct,
you then "naturally" would already have defined an abstract
base class. And actually this base type is the only type of
object the factory need to return for its make().

That's the usual solution when this idiom is used with static
linking. For dynamic linking, the look-up code has to know the
name of the library, in order to be able to load it.

Also the "string" that identifies the type of objects could be
registered by the various object types themselves:

static bool(?) factory::register(std::string const& myId)

factory could use a std::map<std::string> to save a list of
registered objects. And so it could delegate its make() to
the make() of the types themselves.

My preferred solution in such cases is to make the entries in
the map pointers to a factory interface. The constructor of the
base class is passed the name of the object, and takes care of
the registration. All that is then needed is a static instance
of the concrete factory object.

The main module (configuration setup) could just have a
configuration file, that list the libs to load dynamically.

Or the code could simply try to load the object dynamically any
time it doesn't find the entry in the map. (This supposes, of
course, some sort of naming convention by which the code
generates the name of the library from the key it is given.)

I am pretty sure it will work (at least on unix).

I use different variants of it pretty regularly on Unix. From
what I understand concerning Windows, you'd have to take some
additional steps so that the dynamic object could link correctly
to the base class constructor or the map---I've not actually
experimented yet, but if I understand correctly, a dynamically
linked object cannot link against symbols in the root, so you'd
probably have to put the lookup mechanism in a DLL as well. (In
addition to arranging for the necessary symbols to be exported.)