[Top][All Lists]

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

[lmi] the rest of MSVC compilation patch

From: Greg Chicares
Subject: [lmi] the rest of MSVC compilation patch
Date: Thu, 21 Aug 2008 12:30:02 +0000
User-agent: Thunderbird (Windows/20080708)

['mailman' had rejected this due to a size limitation. I "approved" it,
but neglected to "forward" it to the list, so it never appeared here as
intended; now I quote it in full, but without any attachment.]

[On 2008-07-12 19:27Z, Vadim Zeitlin wrote:]

 Hello again,

 Unfortunately I didn't find any other/better way to make mc_enum template
work with MSVC than mentioned previously, i.e. using array pointer instead
of array reference in its declaration. And this change can't be done just
for MSVC as it affects not only the class declaration but also all uses of
it and so the only way to hide it would be to define a macro which would
use a reference for the standard-conforming compilers and pointer for MSVC
but this would IMO make the code even more difficult to understand and
maintain and so I don't think it would be a good idea to do it like this.
OTOH using pointers doesn't really present any problems for the other
compilers neither AFAICS (although I didn't test with Comeau yet).

 In any case, I spent a lot of time on this problem already and I think it
would be more productive if I stopped working on it and started doing
something more productive. We can keep this change in our local tree if you
find it unacceptable for the master LMI sources, although this, of course,
would be less convenient and cost us some extra time on merges in the
future. It would however mean that it would be impossible to build LMI from
the cvs with MSVC and in this case we should probably also keep the MSVC
project files out from cvs too...

 For now, let me attach all the changes done in my local msvc branch. Most
of them are related to mc_enum, a few others are hopefully simple enough to
be non-controversial:

- MessageBox() call can be either MessageBoxA() (taking "const char *"
  arguments) or MessageBoxW() (taking "const wchar_t *" ones) depending
  on whether _UNICODE is defined when windows.h is included. To make it
  possible to build LMI with Unicode version of wxWidgets (default, and
  soon only, build of wx 3.0) you should explicitly use MessageBoxA() when
  passing C strings to it.

- config_msvc.hpp contains the workarounds for MSVC CRT and other MSVC-
  specific stuff.

- lmi.bkl is the input of bakefile from which lmi.vcproj and lmi.sln files
  (MSVC project and solution files, respectively) can be generated. I also
  included the generated files in the diff although I'm not sure whether
  they should be in the cvs at all, in principle they're generated and the
  general rule is not to have the generated files under VCS control. And
  they definitely shouldn't be included if cvs is not compilable with MSVC
  anyhow because of mc_enum problems as mentioned above. OTOH if you do
  want to allow people to easily build LMI from cvs with MSVC it could make
  sense to include them to avoid an extra step of generating them with

- the change of mc_enum_test from struct to class is due to the fact that
  it is forward-declared as class elsewhere and MSVC warns about it. So an
  alternative fix would be to forward-declare it as struct. Or, of course,
  this warning could just be suppressed as it's a relatively harmless one
  anyhow. But I'd rather not suppress more warnings than strictly

- the rest of the changes are all due to the change of mc_enum to use array
  pointers instead of references.

 Please let me know what do you think of this patch, thanks,

reply via email to

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