Crash when using KIdentityManagement::IdentityManager

[Volker Krause]

On Donnerstag, 15. April 2021 21:16:03 CEST David Faure wrote:
> On jeudi 15 avril 2021 18:19:36 CEST Volker Krause wrote:
> > even that symbol is then local/not exported.
> 
> OK, thanks. And this happens even if the method implementation is 100 lines
> long then I assume? Which means inlining methods really forces the compiler
> to inline them at call site -- at least if it comes from a different
> library.

That's two different things, a very long inline method will most likely result 
in a single local/non exported symbol in the consuming binary with regular 
local function calls to it, rather than being copy/pasted into each call site. 
In that sense it's no different from any other non-exported method in that 
library then.

The decision of the optimizer to replace a function call by copy/pasting the 
implementation into a call site is independent of that. It can do that 
whenever it has access to the implementation, which is the case for your own 
local code as well as inline code from any header file. Whether that header 
belongs to the consuming code itself or an external dependency isn't even 
distinguishable for the compiler at that point.

I agree that using the term "inline" for both things is unfortunate and 
confusing. The "inline" keyword is actually mainly about the former (in C++ at 
least, no idea about the semantic details in C), the confusion with the latter 
I think comes from the fact that inline code used to be a prerequisite for the 
optimizer to do the copy/pasting (when looking at a single translation unit it 
would otherwise have nothing to copy from). I suspect that this no longer 
holds with link time optimization though.

> > > In any case, pimpl'ing kills this idea, so I suggest we make the rule
> > > simple: no QVector/QList iterators in public API.
> > 
> > pimpl'ing could be overcome here by a private method returning a reference
> > to the vector, and using that in the inline code.
> 
> OK, that would work...
> 
> > Such a method might be
> > the better and simpler API in the first place anyway.
> 
> Well, yeah. Doesn't that bring you back to my simple rule? ;)

sure, I'm not objecting to that at all :)

> I guess it's all about
>    for (const Identity &identity: manager)
> vs
>    for (const Identity &identity: manager.identities())
> ...

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20210415/a2cfe954/attachment.sig>