Re: [lmi] Branch lmi-so

[Vadim Zeitlin]

On Mon, 28 Dec 2020 23:59:43 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 10/18/20 2:55 PM, Greg Chicares wrote:
GC> > [...some github branch already applied...]
GC> >> This branch generally moves "LMI_SO" to the left
GC> 
GC> A new question arises: if "inline" and "LMI_SO" compete for
GC> leftmost position, which wins? I think it should be "LMI_SO":
GC>   LMI_SO inline double foo() {return 3.14;} // This way.
GC>   inline LMI_SO double foo() {return 3.14;} // No, not this way.

 Well, this is a trick question, isn't it? Because inline functions don't
need to be defined in the shared library at all, as they're compiled as
part of the code using them itself, so they don't need LMI_SO in the first
place.

 I guess you could still use it with them, and in this case I would indeed
put it to the left, but I don't see any advantage in doing it and I do know
that at least with MSVC you get link errors if you use the moral equivalent
of LMI_SO with a class having only inline functions. AFAICS using LMI_SO
with functions, rather than classes, should be harmless but, still, why use
it if it's not necessary?

GC> For completeness, I should ask whether "LMI_SO" should be
GC> written to the left of "static" and "constexpr". I think the
GC> answer will be that only "template<whatever>" and "class" can
GC> take the leftmost position away from "LMI_SO". Thus:
GC>   template<typename T> LMI_SO static constexpr inline foo<T>(T t) {...}

 I'm even less sure about how this works in practice, because I haven't yet
used LMI_SO-like macros and constexpr in the same project, but I am almost
certain that LMI_SO should be never necessary with anything constexpr,
which is even more inline (inliner?) than the plain inline.

 Please let me know if I'm missing anything,
VZ

pgpuBL5snrmPy.pgp
Description: PGP signature