[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Idea: numbered error messages
- From: David Olofson <david@...>
- Date: Fri, 4 Feb 2005 15:19:21 +0100
On Friday 04 February 2005 14.44, skaller wrote:
> On Fri, 2005-02-04 at 23:31, David Olofson wrote:
>
> > Macro mayhem... *hehe*
>
> > You're going to have to take it a bit further for this, though.
> > The
> > macro preprocessor is actually quite powerful, so it's definitely
> > doable.
>
> LOL. The C macro processor is just about as lame as you can get.
> M4 is much more powerful but even more horrible.
Yeah... I've considered using something else, and since I use GNU
autotools, my projects (at lest the build scripts) depend on M4, AWK,
bash, sed and whatnot anyway.
> I use a *real* preprocessor myself. All my code
> is generated by Python scripts. And I do mean every
> line of it. Including the whole Lua package.
>
> How can you compare the C preprocessor with a full
> scale language?
You can't. It's a simple tool that's part of the C standards, and is
meant to do little more than paste source files together.
But, since we have no other tool that we can rely on being available
everywhere, it's the best bet. It's no major job to grab the source
files from an autotools package and build a project in some IDE tool
or whatever - but if you rely on non-standard tools, you can pretty
much forget about that, unless you can somehow have those tools work
together with that IDE (or whatever) tool.
> I quite dislike the Lua code because, being
> written for C89 it is littered with stupid
> macros for efficiency -- in C99 and C++
> you'd use inline functions instead.
I've been using 'inline' since I started coding in C - but that wasn't
long ago enough that you could find a compiler worth using that
didn't support it. (Though pre-C99 compilers tend to call it
__inline__ or something instead. Autotools takes care of that,
though, so I just type 'inline'. In the worst case, the code simply
isn't inlined.)
> Another solution would be to build a lame
> bootstrap version of Lua, and then use it
> to build your real version -- using Lua
> as the macro processor.
I've considered doing exactly this with EEL.
Problem is that in order to build that bootstrap version, you still
need the source code to be compilable with plain, standard C
development tools...
> Surprisingly, you can do this in a couple
> of lines of Lua code and get *extreme* power.
>
> Interscript basically says:
>
> read a line
> if it starts with a @ character, execute it
> otherwise write it to the current output
>
> and that gives you the most powerful macro processor
> in the world -- a full scale programming language
> of your choice.
Of course - but there's always this "I can't build your code! What's
that funny tool it's asking for!?"
No matter what you're using; if you use it to actually *generate* a
significant part of your source files, you're in portability trouble
as soon as that tool doesn't come with every C compiler worth using.
Also, unless you're using *real* build tools, any tools that need to
be executed whenever you compile a modified source file are likely to
completely screw up the build process. It just won't work with an IDE
that has the preprocessor, compiler, linker and everything in one
integrated, optimized monolith tool, unless the tool has explicit and
properly implemented support for external preprocessors.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---