Precompilers!

[Spike]

was just wondering :)

[Chip]

FTEQCC, I'm an optimization freak, and your compiler does the job.

[Spike]

This is more a question of if you ever use a qcc which doesn't support #ifdef / #ifndef than anything else, tbh. Really not trying to advertise, but thanks :)

[Pulseczar]

Why does a compiler need to support a precompiler? I wouldn't think a compiler would even have any concept of a precompiler. As long as the precompiler gives the compiler compilable code, the precompiler and compiler will be compatible.

Seems like the question one might ask is whether a precompiler supports a compiler. Not the other way around.

[Teiman]

A precompiler builtin in a compiler is a nice feature.

So with a single exe, everything works out of the box.

I use to miss a precompiler on QC for years, but I suppose once you get use to not having one, is not that bad.

Precompilers are a delicious perversion.

[Spike]

If the language is designed such that a precompiler is not really required, you won't really miss one unless you're acoustomed to the aproach.
With that said, precompilers help to cover upgrading things like APIs. Which is why I started this poll.
The question is really 'can I use #ifdef in an extensions.qc to provide correct types to compilers that support it, and fake types to ones that do not'.

precompilers built into the compiler itself are guarenteed to be available.

there are a lot of ways to use a precompiler. and even more ways to abuse them. seriously, #ifdefs *within* #define was never intentional!
as far as quake goes, precompilers can be useful for the quakeworld/netquake split. but also for protecting innards of generic portable modules that take advantage of extensions of the qcc only when those extensions are available, without breaking other qccs.

[frag.machine]

I agree with Spike: while in the past precompilers were overkill, with the current splitted status of QuakeC in engine-specific dialects they became a requirement. And while in the subject, I'd suggest to study a way to allow one to keep one single QuakeC codebase for both SSQC and CSQC using some kind of precompiler directive for functions or identifiers CSQC related, like this:

Code: Select all

#csqc
void () CSQCfoobar = {
(...)
};

[Spike]

fteqcc -DCSQC -srcfile csprogs.src

#ifdef CSQC
void() mycsqconlyfunc =
{
};
#else
void() myssqconlyfunc =
{
};
#endif

is one such use for precompiler.

My personal use of precompiler involves putting the #define CSQC inside the csprogs's defs.qc-equivelent (the system defs anyway).
Then the same qc file can be used for both progs. For dual nq/qw compatibility mods, generally I just include an extra file in one that wasn't in another, which contains just a #define saying to build it for QW instead, then have ifdefs through defs.qc abstracting the differences.
But its best to write a wrapper/function to abstract the differences between nq/qw than to use ifdef for each and every function that uses something that differs. My example is particles.

Actually, on the topic of csqc simplification..
#pragma sourcefile csprogs.src
Add that to your ssqc code somewhere. This pragma will request that fteqcc compile your csprogs.src afterwards. So you only run it once and you get your two progs.dats.

Oh, and another #pragma that I'm not sure anyone knows about...
#pragma noref 1
Put that at the top of dpextensions.qc :D
You ought to put a '#pragma noref 0' at the bottom too. But hey.
You can also '#warning disable Q302' to disable unreferenced defs, or a few other warning ids.

Strictly speaking, pragmas are compiler features, rather than precompiler ones. But hey, whatever. :P

I must admit that it would be nice to have a keyword for the type that basically says 'ignore this object that I'm defining'. Then you can do #ifdef CSPROGS #define csqc #else #define csqc ignoreme #endif. Which would basically make your code sample work (yes, including the leading #).