Re: Self-registration in a library
On Jan 26, 1:03 pm, Kaba <n...@here.com> wrote:
James Kanze wrote:
On Jan 25, 11:58 pm, Sam <s...@email-scan.com> wrote:
Have a look at the following:
And the result is... That nothing is printed. The first question is: why
not? When all of the three files are built together, then the result is
the string "aFunction" printed on screen.
I'd suggest you learn what a library is. If you don't tell the
compiler/linker somehow that your automatically registered file
is part of the program, it's not part of the program. How you
tell this to the translation system is system dependent, but by
definition, if the object file is in a library, you've told the
system to only include it if it resolves an otherwise unresolved
external. Which leads to...
Right. So a static library does not behave equivalent to a set of object
A "library" is a library, not something else:-). But I can
understand that there is some ambiguity. Historically, for
example, Unix used "archive" files as libraries, and an archive
file is just a set of files---except when the linker considers
it to be a library.
Anyway, the behavior of a library is a desirable, even
a necessary behavior, and it won't (hopefully) change. The
problem as I see it is that you don't want the behavior of
a library, so you have to use something else.
This kind of a linkage issue is really platform specific. You did not
specify what platform you are using. This is not really a C++ question.
I am targeting cross-platform, so portability is important to me.
James Kanze wrote:
The simplest (and the most portable) is probably to just link
the object file, rather than going through a library.
In this case I was specifically set out to avoid this. I am creating a
mex file (an "extension") to Matlab, and here the final build set has to
be invoked from within Matlab. What I want to do is to maximize the
amount of work done in my own build system, and then just do a trivial
build in Matlab. Hence my approach of first building a library. I want
to keep the library a static one, rather than shared.
I'm not sure I understand correctly. I'm not familiar with
Matlab, but all of the "extensions" I am familiar with work by
means of loading a DLL (or an so under Unix---basically the same
thing). You provide this DLL, and logically, I don't see why
you'd want to use static libraries anywhere. Static libraries
are really only useful when you want to deliver your code to
other C++ (or C) users, who will link against it.
To guarantee that aFile.cpp gets registered, I need to explicitly refer
to something in it. Is it enough to refer to a single name in a
translation unit (say call a function in it) to guarantee its inclusion,
or is the process even more fine grained? I.e. if I call a function in
it, am I guaranteed that the 'call' global variable in aFile.cpp gets
In practice, yes. The granularity of all of the linkers I know
is the object file, at least by default. (VC++ has an option to
support granularity at the function level, but I think this is
more a space optimization: the true granularity is still the
object file, but the linker suppresses *functions* which aren't
referenced when it links the object file in.)
And you don't need to "call" a function; just include somewhere
a table which takes the address of a set of functions. Or
variables, or whatever. (If I do have to do something like
this, I'll do it automatically, from the makefile, or by using
a pre-build step in Visual. One doesn't actually write this
sort of code.)