Re: [lmi] Branch lmi-so

[Greg Chicares]

On 2020-10-18 15:44, Vadim Zeitlin wrote:
> On Sun, 18 Oct 2020 14:55:58 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[...]
> GC> apparently the "SO" decoration for forward declarations is...
> GC>   #define LMI_SO_FWD_DECL        // GNU/Linux current gcc
> GC>   #define LMI_SO_FWD_DECL        // MinGW-w64 since we began using it
> GC>   #define LMI_SO_FWD_DECL LMI_SO // historical mingw.org gcc
> GC> [...] therefore, the preceding documentation:
> GC> 
> GC> // [...] It is unknown
> GC> // whether this difference represents deliberate evolution of gcc or
> GC> // a MinGW-w64 regression, so both versions are preserved.
> GC> 
> GC> can now be revised (it really is evolution, and perhaps mingw.org
> GC> was just lax in accepting the decoration)

Forward declarations may indeed have required "declspec" attributes
for older msw compilers. That gcc-4.x warns against them was seen as
  https://gcc.gnu.org/legacy-ml/gcc-help/2006-11/msg00269.html
| a big malus for cross-platform projects which need the M$'s
| __declspec() attribute also on forward declarations....
| To remove all those warnings from the sources of my apps I'd need
| to use a DLLEXPORT_FORWARD macro when forward-declaring stuff
| (which would be defined as __declspec(dllexport) for win32 compilers
| like MSVC or Borland and which would expand to nothing for GCC).

Apparently msvc doesn't require it these days; a couple years ago,
it was necessary in a fairly exotic case, but that was acknowledged
to be a defect:

https://developercommunity.visualstudio.com/content/problem/294867/c-member-template-specialization-as-forward-decl-a.html

It may have been required by the pre-standard borland compiler,
a later incarnation of which still required it about a decade ago:

http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devwin32/vclclassdeclarations_xml.html
| You must use __declspec(delphiclass) for any forward declaration of classes
| that are directly or indirectly derived from TObject.

>  Yes. The question is whether we should remove LMI_SO_FWD_DECL completely
> or still keep it. Personally I think we should remove it, but I've decided
> not to do it for now to avoid having even more changes in this PR.

I'm always reluctant to eradicate a debugged solution to an old problem,
because sometimes old problems come back to life and the old weapons we
used to defeat them become useful again. I think of the time I had an
infection that was resistant to all the usual antibiotics, but was cured
by an older antibiotic that the largest US pharmacy chain didn't even
keep in stock. At least it wasn't chloramphenicol.

So I'll keep it, but with an implausible preprocessor conditional.
Pushing soon, after the tests finish.