Re: [lmi] Branch lmi-so

[Greg Chicares]

On 12/29/20 12:22 AM, Vadim Zeitlin wrote:
> 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.

Thanks, now I see where I went astray. I had written this:

  /// Statutory interest rate for 7702 and 7702A (except GSP).
  LMI_SO double iglp()
  {
      return 0.04;
  }

using LMI_SO because I wanted that function to be visible across
shared-library barriers. But it was in a header, and including it
in multiple TUs led to a multiple-definition error, which I
resolved by adding "inline"...when I should instead have replaced
"LMI_SO" by "inline". And I should have interpreted the lack of
any "LMI_SO inline" example in the lmi corpus to guide me as an
indication that I was on the wrong track, but I was trying to
push forward impatiently. While I did at least pose the question,
I didn't appropriately question the question. Now it's all clear.