Re[2]: [lmi] patch to include curses.h only for CLI code

[Vadim Zeitlin]

On Tue, 17 Jun 2008 19:25:34 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2008-06-13 01:01Z, Vadim Zeitlin wrote:
GC> > 
GC> >  Currently the Linux build fails because platform_dependent.hpp includes
GC> > curses.h which defines many macros with very common names. At least one of
GC> > them, namely "border", conflicts with this innocently-looking code from
GC> > wx/renderer.h:
GC> > 
GC> >     wxSplitterRenderParams(wxCoord widthSash_, wxCoord border_, bool 
isSens_)
GC> >         : widthSash(widthSash_), border(border_), isHotSensitive(isSens_)
GC> >         {
GC> >         }
GC> > 
GC> > and the compilation fails with mysterious error
GC> > 
GC> > wx/renderer.h:82:48: error: macro "border" requires 8 arguments, but only 
1 given
GC> 
GC> Shame on the maintainers of that library.
GC> 
GC> Thanks for presenting various options with thoughtful analysis.
GC> The problem is bigger than a conflict between wx and curses:
GC> it's curses versus the lawful universe. I might use a name like
GC> 'border' in code that does calculations independent of platform
GC> or user interface. It could take tremendous effort to debug the
GC> sort of errors this might cause. I'm inclined to avoid including
GC> "curses.h" altogether, and just write
GC>   extern "C" int getch();
GC> where needed, with enough explanation that no one later tries to
GC> "improve" the code by including that header again. That's mildly
GC> distasteful, but I see no other guaranteed and permanent way to
GC> banish the problem. What do you think? If you agree, then you
GC> needn't write a patch....

 Sorry for forgetting to answer to this question: I do agree that this is
probably the best solution. The only problem could be with using curses
under Win32 systems where the function may be declared as

        extern __declspec(dllimport) int __cdecl getch(void);

but LMI doesn't use curses under Win32 AFAICS so this shouldn't be a
problem.

 Thanks,
VZ