[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: snapshot of Lua 4.1 (work) problems with VC++
- From: "Peter Loveday" <peter@...>
- Date: Fri, 2 Nov 2001 10:10:47 +1030
Well, the age-old convention of macros being upper case would be a start.
Still, G() is of course upper case; though perhaps one-letter macros is
asking for trouble.
If all member variable access is to be done through macros such as val(_n)
etc anyway, perhaps the members could be prefixed with m_, or whatever
your favorite member variable prefix/suffix is.
Love, Light ane Peace,
- Peter Loveday
----- Original Message -----
From: "Eric Ries" <firstname.lastname@example.org>
To: "Multiple recipients of list" <email@example.com>
Sent: Friday, November 02, 2001 10:05 AM
Subject: RE: snapshot of Lua 4.1 (work) problems with VC++
> Having mucked around with the internals of Lua 4.0 a fair bit now, it would
> be nice if there were some more coding conventions in place to help make it
> clear to those of us who are a bit slow when a certain function-call is a
> macro and when it is not. Just my $.02
> > -----Original Message-----
> > From: firstname.lastname@example.org
> > [mailto:email@example.com]On Behalf Of Peter Loveday
> > Sent: Thursday, November 01, 2001 3:21 PM
> > To: Multiple recipients of list
> > Subject: snapshot of Lua 4.1 (work) problems with VC++
> > Thanks for giving us access to this in-progress version!
> > I've found a bit of a problem compiling it for windows. (with VC++ sp5)
> > This seems to be due to an obscure bug in the Microsoft pre-processor,
> > which gets upset with substitution of the G(L) macro from within the
> > (new) cast(t,x) macro.
> > For example, the code in lgc.c in checkMbuffer()
> > luaM_reallocvector(L, G(L)->Mbuffer, G(L)->Mbuffsize, newsize, l_char);
> > where luaM_reallocvector() uses cast() a few times, seems to make the
> > preprocessor attempt to substitute the member variable G (from L->G) as
> > a macro instead of treating it as a variable. This of course causes
> > it to get the code completly wrong.
> > The Intel compiler for VC++ does not have this problem, and while it is
> > clearly a microsoft bug, in the interests of compatibility
> > perhaps something
> > could be done. The true cause of this problem seems to stem from the
> > fact the macro G(L) has the same name as the member variable 'G'
> > in Lua_state.
> > If either were renamed then the problem would no longer exist;
> > and in general
> > I'd say having defines and variables (or members) of the same
> > name is probably
> > best avoided, even if the macro does require an arg in this case.
> > Thanks for your time!
> > Love, Light and Peace,
> > - Peter Loveday