Re: [lmi] Forcing linking of the library modules (again)

[Vadim Zeitlin]

On Sat, 04 Oct 2014 21:56:09 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2014-10-04 14:52Z, Vadim Zeitlin wrote:
GC> > On Sat, 04 Oct 2014 13:20:57 +0000 Greg Chicares <address@hidden> wrote:
GC> > GC> instead, I've cloned this code:
GC> > GC>   
http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/include/wx/link.h?view=co
GC> > GC> to provide lmi-specific macros in new header 'force_linking.hpp'.
GC> 
GC> I'm puzzled. I think I preserved the original's substance faithfully, but...
GC> 
GC> >  But I'd like to notice that there is a small problem with the new
GC> > LMI_FORCE_LINKING_{IN,EX}_SITU() macros: they are inconsistent in their
GC> > handling of the subsequent semicolon as the former requires it, while the
GC> > latter does not. I would prefer if the latter one required the semicolon 
as
GC> > well, i.e. remove the trailing semicolon from the line 61 of
GC> > force_linking.hpp
GC> 
GC> Isn't that the same as the trailing semicolon on line 28 here?
GC> 
GC>   
http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/include/wx/link.h?view=annotate
GC> 28                  } wx link dummy var##module_name;
GC> 
GC> Or are you advocating a change to <wx/link.h> as well, for the
GC> following reason?
GC> 
GC> > , as not terminating the macro definition with a semicolon
GC> > is the common rule

 Sorry, I have indeed managed to notice the speck in your code but not the
log in our own version. I must have used the wx macros completely
automatically, without thinking about this issue at all, while reviewing
your changes triggered my subconscious C++ critical feeling...

 Unfortunately it's too late to change wxFORCE_LINK_XXX() macros as they
are certainly used outside wxWidgets and we don't want to break existing
code for such relatively unimportant issue. As for LMI macros, I'd still
prefer if they required a semicolon, but it's not very important, of
course. The best might be to not have them at all and just use the wx
macros because like this we could avoid agonizing over this question.

 In any case, sorry again for not noticing that the problem stemmed from
the original version,
VZ