On 04/27/2012 11:12 AM, Ilya Chernykh wrote:
On Friday 27 April 2012 16:03:40 Philipp Thomas
of templates ;)
And the joy of maintaining a package written in C++ without much knowledge
Anyway it seems wrong for me that the compiler brings no error in this case.
Should this issue be reported to the gcc upstream? Is not it wrong that the compiler
a totally unusable object module without any error thrown?
No, this is a fundamental feature of C/C++ that allows you to separate
the declaration from the implementation.
And now for some details, and a longer answer, that you may or may not
One of the paradigms of OO programming is to hide your implementation
details. Anyone wanting to use your interfaces only has to see the
header file at compile time. Then at link time the linker stitches
With non templated implementations any link problem then boils down to
including the appropriate .o, .a, or .so file on the link line, as you
noted previously. However, with templates things get a bit more tricky
as the compiler will only emit an implementation when a template is
actually instantiated. Template instantiation happens when the compiler
sees the use of the template and the template implementation in the same
compilation unit, or the compiler is "told" to instantiate a template.
To achieve this, implementers have some choices.
- Put all template implementations in the header file that gets include
by whomever my use the template
~ this approach basically defeats the goal of "hide your implementation"
- Put template implementations into separate files (often ending in .T)
and include the .T file whenever the .h file is included (in a .cpp, .C,
.c++, .cpp .. file)
~ this still achieves the "hide your implementation" goal as users of
the template only need to look at the header file to understand the
interfaces and while doing so they do not see the implementation
~ but this approach implies that there may be a significant amount of
growth for the number of files in a project, many people do not like
- Put template implementations into a regular file (.C, .cc, .c++, .CC)
and compile the file
~ this achieves the "hide your implementation" goal in the way most
users think of the organization of C++ code
~ but this implies that in the implementation file one has to have
instantiators for the template with all possible types, or linking will
fail. This leads to binary bloat as templates that may never be used are
~ it is not possible to think of every possible type that might be
used to instantiate a template, thus everytime a template instance is
needed with a new type one has to add a new instantiator and modify the
file that contains the template implementation
This last case is the issue you ran into. Yes, one has to have an
understanding of how C++ and the compiler work to figure things like
this out. But as a packager you do not have to know everything since
there's always some one around who can help in one way or another.
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org