Re: Symbols and C++ inline constructor
Just a general remark just came into my mind about the symbols
dicssusion:
Is is really *safe* to use inline methods as API in libraries?
My belly states "no", because you might found yourselg to be unable to
fix bugs in library, if the software using the interface will use a
inline here and if there is a change the software needs to be
recompiled.
(For example one needs a new variable in the to be
instanciated class, the inlined "code-copy" constructor will
not know about that and will not initiate this one...)
coldtobi
Am Samstag, den 07.01.2012, 19:46 +0100 schrieb Thomas Weber:
> 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: