lmi
[Top][All Lists]
Advanced

[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





reply via email to

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