Re: [lmi] Upgrading to gcc-4.9.2

[Vadim Zeitlin]

On Sat, 19 Dec 2015 20:32:14 +0000 Greg Chicares <address@hidden> wrote:

GC> Here's the relevant part of 'database_document.hpp':
GC> 
GC>   #include "dbdict.hpp"
GC> [...]
GC>   class LMI_SO database_entity;
GC> 
GC> Header "dbdict.hpp" happens to include "dbvalue.hpp", which defines
GC>   class LMI_SO database_entity
GC> and g++4.9.2 complains when it sees a perfectly-matching forward
GC> declaration after that definition.
GC> 
GC> I could remove the forward declaration--and it would compile, for now
GC> at least. But I don't want to do that. It's not guaranteed to work
GC> forever: I might make a change that makes the forward declaration
GC> non-redundant, so removing it introduces a latent error.
GC> 
GC> Vadim, do the WXDLLIMPEXP_FWD macros work around this compiler anomaly?

 Yes, exactly. They expand to nothing when using gcc while expanding to the
same thing as the FWD-less versions for the other compilers (MSVC,
basically). OTOH I admit I never really understood when exactly MSVC gave
the warning about the attributes mismatch between declaration and
definition and I don't seem to be able to reproduce it with the current
version of the compiler, so another solution would be to just omit LMI_SO
in the declarations -- this is definitely what gcc wants, anyhow.

 Notice that the problem solved by these FWD macros indicated by "type
attributes ignored after type is already defined" warning is different from
the original one with "previous dllimport ignored" warning, even if both
warnings fall under -Wattributes. The latter warning, with the class
redeclaration after its definition had been already seen, is harmless and
it's enough to just not use the attributes in the forward declaration to
get rid of it as using or not using them doesn't actually change anything.

 The former one is quite different and potentially serious and occurs with
DLL-imported functions only, not the DLL-exported ones. What happens with
_get_output_format() is that it's declared as DLL-imported in the standard
header, meaning that it is defined in the standard library used as a DLL,
but then it's redefined in the program itself. I don't really understand
how this is even supposed to work and IMO a better idea than avoiding the
warning here would be to stop redefining this standard library function
entirely as I already wanted to do back in 2011:

        https://lists.gnu.org/archive/html/lmi/2011-06/msg00039.html

 Maybe it's finally time to do it?
VZ