Re: Symbols and C++ inline constructor
On Fri, Jan 06, 2012 at 05:14:32PM -0800, Russ Allbery wrote:
> Thomas Weber <tweber@debian.org> writes:
> > On Fri, Jan 06, 2012 at 12:14:11AM +0000, Roger Leigh wrote:
>
> >> IIRC inline is only a hint--it's not guaranteed to
> >> be inlined if the compiler thinks it's more efficient not to.
>
> > That is exactly my problem. A newer compiler version might change the
> > decision of the former version due to better optimization; but then I
> > see no way to guarantee stable symbols in the library.
>
> If it's a private symbol not intended to be used by clients and that
> wouldn't naturally be used by clients, you can mark it optional in the
> symbols file (symbol tag optional), and then the symbols generation won't
> care if it appears and disappears.
This doesn't answer my question, does it? I mean, your statement is true
for whatever symbol that appears in the symbol file. My question is
about inlined class methods specifically and the fact that the compiler
might change its opinion about them with even minor version bumps.
> You have to do that for some things with C++, since there are places where
> C++ just doesn't give you control over what symbols are exported.
One of the things that I find frustrating is the total lack of reliable
and complete documentation about symbols; yet library maintainers are
expected to keep the symbols file sane.
Example from dpkg-gensymbols (5):
"For example, most of C++ template instantiations fall into this
category" (it's talking about optional symbols here).
So, which template instantiations are *not* safe to be tagged as
optional? This is a different question, but I have quite some template
instantiations in the symbol file as well.
Thomas
Reply to: