Re: snapshot of Lua 4.1 (work) problems with VC++

["Peter Loveday" <peter@...>]

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" <eries@there.com>
To: "Multiple recipients of list" <lua-l@tecgraf.puc-rio.br>
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
> 
> Eric
> 
> > -----Original Message-----
> > From: owner-lua-l@tecgraf.puc-rio.br
> > [mailto:owner-lua-l@tecgraf.puc-rio.br]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
> >
> >
> 
>