RE: Inline Functions

["Joshua Jensen" <jjensen@...>]

> There, I don't quite agree. I think you can learn a lot
> from other people's code, especially when it's 
> well-written code. Ah well it's a matter of taste, I guess.

Although I don't agree with rewriting Lua in Visual Basic when it is
easily accessible via DLL, I do agree that the incessant use of macros
makes for understanding what is truly going on very difficult...
especially when debugging.

> I've always thought that debuggers are overrated. Yeah, when 
> programming C, they can be useful to see where you make 
> a memory handling error. But for interpreted languages with 
> garbage collection, crashes because of memory handling 
> errors can  normally not occur. Most of the errors will be 
> logical errors, and those can be solved only by thinking.

I think that having a Lua debugger saved our butts on a commercial
project I once released.  Yes, most of the errors were logic-related,
but when trying to find the logic error in the middle of thousands of
lines of code, stepping line by line beats a 'print' every single time.

> > IDL? Alas, I know nothing of writting DLLs in C. And I only 
> have VB6 
> > so don't have access .NET stuff.
> Well, writing DLLs in C is simple on unix/linux, and complex 
> on Windows... 

That's an entirely baseless assumption.  At the top of lua.h, merely
insert:

	#ifdef LUA_BUILDDLL
		#define LUA_API __declspec(dllexport)
	#else
		#define LUA_API __declspec(dllimport)
	#endif

Building C COM-based DLLs is another story.  These days, I'd just make a
.NET component anyway, as making one of those, even in C, is a no
brainer.  If you were going to write a COM-based DLL on Unix without any
particular compiler support, you'd have the same complexity as on
Windows, when using compilers from several years ago.

-Josh