[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[2]: [lmi] a bad MSVC problem with mc_enum
From: |
Vadim Zeitlin |
Subject: |
Re[2]: [lmi] a bad MSVC problem with mc_enum |
Date: |
Mon, 23 Jun 2008 17:36:45 +0200 |
On Mon, 23 Jun 2008 10:48:34 +0000 Greg Chicares <address@hidden> wrote:
GC> On 2008-06-23 05:26Z, Vadim Zeitlin wrote:
GC> >
GC> > I've found what seems an amazingly bad bug in MSVC compiler: it happily
GC> > compiles the current code in mc_enum.[cht]pp but it doesn't seem to be
able
GC> > to handle references to arrays correctly.
GC>
GC> Wow. Can they even compile this...
GC>
GC> // http://www.comeaucomputing.com/techtalk/#arraybounds
GC>
GC> ...tiny C++ example?
No, this does work. And the parameter "n" is deduced correctly in mc_enum
template. But somehow -- and this is really incredible but unless you have
a copy of this compiler (which you can download from Microsoft FWIW) you
have to trust me on this one -- it generates incorrect code when the array
reference itself is used.
GC> > The only workaround I found so far is [...snip...] But,
GC> > again, I just don't seem to be able to find any other way to make the
GC> > compiler generate the correct code after spending close to 2 hours on it.
GC>
GC> Are you close to being able to predict whether this compiler is
GC> going to work at all for lmi?
Right now LMI runs and seems to work fine here. I didn't test all the
functionalities, of course, but what I tested seemed to work. Moreover,
there are finally not that many MSVC-specific changes, the only big ones
are this one, and any_member and value_cast ones. The problem with pointer
to member representation was fixed without any changes to LMI code.
GC> Does it all compile and link now, with your local patches,
GC> so that we're in the final stage? For all binaries, especially
GC> 'lmi_wx_shared$(EXEEXT)', or only for the unit tests?
I built a statically linked version so far but I don't foresee any
problems with the DLL build. I didn't compile all the unit tests (in fact
only a couple of them) yet.
GC> > As usual, if anybody has any ideas about how to make this work
GC> > otherwise, I'd love to hear about them. In the meanwhile, here is the
GC> > patch I'm using right now, just for the reference:
GC>
GC> My position would still be as stated here:
GC> http://lists.nongnu.org/archive/html/lmi/2008-02/msg00029.html
The problem is that not only mc_enum.[ht]pp need changing but also all
declarations of mc_enum specializations (they need to use an extra "address
of" operator). And it seems impractical to fork the other files too... So
we'd need some "#ifdef LMI_COMPILER_MSVC"s in them if we have both array
reference and array pointer versions.
Thanks,
VZ