It depends on the linkage if you use ordinary (static) linkage the
answer is No.
I'm not sure I understand. If he links it statically, then he
doesn't need to use LoadLibrary (or dlopen).
I think that the advantage here in using LoadLibrary/dlopen is
that he can add additional functions later, without having to
recompile/relink the main application; in fact, without even
having to stop the main application.
I've done this in one case, albeit with object types derived
from a common base class, not with pure functions. (But of
course, that could be a trivial wrapper for the pure function.)
Basically, the main application contained an std::map<
std::string, Factory* >, where Factory was an abstract base
class with a virtual function which was called to create the
object. The constructor of Factory (called from the derived
class, of course) took a string with the name of the type it
constructs; it knew about the map, and enroled the instance in
the map. This base class and the map was then statically mapped
into the main application. For the derived classes, I
established a naming convention, associating the string with the
name of the corresponding dynamicly loaded file. That file
contained a static instance of the derived factory, so that when
loaded, the constructor would be called, and the factory
register itself with the map. When I wanted an instance of the
class from a string, I looked up the factory in the map; if I
didn't find it, I constructed the file name, tried to load it,
and then tried the map again.
Under Solaris, the only special action necessary was to link
with -ldl. Under Linux, I also needed some special options when
linking the main application, so that symbols in it (e.g. the
constructor of the base class) would be available to the
dynamically linked object. I've not yet had time to port it to
Windows, but from what I understand: 1) I'll need to do
something special to make the constructor for the base class
visible in the DLL's (note that this is the only symbol needed
to establish the link between the objects), and 2) I may have to
move the constructor of the Base class out into a DLL of its own
(presumably with the map, and everything else which uses it),
since I seem to recall having heard that Windows never makes
symbols in the main application available to DLL's (but I really
have no experience here to be sure).
If you really want to get fancy, you can even upgrade functions
dynamically, without stopping the application. Add code in the
destructor of the base class which deenroles the object from the
map, and a (statically linked) command to unload the DLL, and
all you have to do is unload the DLL, replace the file which
contains it with a new one, and the next time someone tries to
use the command, the new one is loaded.
But if you make some changes to the project specifications or
compiler switches then Yes.
I guess you do not want to use dynamic link libraries;If so
please take a look at my former post.
If he's statically linking, the simplest solution is to use a
static table. Something like:
struct MapElement
{
char const* name ;
void (* func)() ;
} ;
MapElement const table[] =
{
{ "do", &do },
{ "re", &re },
{ "mi", &mi },
// ...
} ;
A simple linear search (with std::find_if) will then take care
of the lookup. (I use a similar construct so often that I have
a template for MapElement, which also defined the corresponding
predicate type for std::find_if. Along with the begin and end
functions which return the "iterators" of a C style array, all I
have to write is something like:
typedef StaticMap< void (*)() >
Map ;
Map const myMap[] =
{
{ "do", &do },
{ "re", &re },
{ "mi", &mi },
// ...
} ;
and then:
Map const* elem
= std::find_if( begin( myMap ), end( myMap ),
Map::Matcher( functionName ) ) ;
if ( elem == end( myMap ) ) {
// Error: function not known...
} else {
(*elem->value)() ;
}
