[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: Inline Functions
- From: "Joshua Jensen" <jjensen@...>
- Date: Thu, 2 Jan 2003 09:23:22 -0700
> 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
#define LUA_API __declspec(dllexport)
#define LUA_API __declspec(dllimport)
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.