lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] PCH


From: Vadim Zeitlin
Subject: Re: [lmi] PCH
Date: Sun, 5 Jun 2016 18:53:23 +0200

On Sun, 5 Jun 2016 16:29:17 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-06-05 15:36, Vadim Zeitlin wrote:
GC> >  Does this mean I could propose a patch enabling PCH for MSVC now?
GC> 
GC> Probably. Could you show me a simple conceptual proposal, e.g., a
GC> diff for a single file? I was thinking of doing something like:
GC> 
GC> -#if defined __BORLANDC__
GC> +#if defined LMI_USE_PCH
GC>  #   include "pchfile.hpp"
GC>  #   pragma hdrstop
GC> -#endif // defined __BORLANDC__
GC> +#endif // defined LMI_USE_PCH
GC> 
GC> i.e. 's/__BORLANDC__/LMI_USE_PCH/' for these PCH blocks only.

 Unfortunately this is not going to work for MSVC because the precompiled
header inclusion must be the first non-trivial line of the file, i.e. it
can't occur inside a preprocessor conditional.

 Currently the code looks like this:

        #include LMI_PCH_HEADER
        #ifdef __BORLANDC__
        #   pragma hdrstop
        #endif // __BORLANDC__

where LMI_PCH_HEADER is defined, on compiler command line, as either
"pchfile.hpp" or "pchfile_wx.hpp" and both these files include config.hpp
unconditionally and then include a subset of common headers inside

        #if defined LMI_COMPILER_USES_PCH && !defined LMI_IGNORE_PCH

check.

 Many variations are, of course, possible, but to be able to use PCH with
MSVC there must be an #include before anything else. So either all files
should start with

        #include "pch_if_used.hpp"

or

        #include "wx_pch_if_used.hpp"

(depending on whether the file is part of GUI code or not) or the file name
must be a macro as it is now. Do you have any preference for one or the
other of these solutions?


GC> (BTW, I'm leaving some workarounds in place because they seem to
GC> indicate genuine differences rather than standard-nonconformance.
GC> Even though borland will probably never work, some other compiler
GC> might need similar workarounds.)

 IMO if a workaround is not needed for any of the currently used compilers,
it's not useful to keep it because it's impossible to verify if it still
works or not, so the chances of it bit-rotting anyhow are very high.

 Regards,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]