a nifty feature for c preprocessor

[David Brown]

On 29/12/2011 00:08, R A wrote:
>
>> And if you want portable pre-processing or code generation, use
>> something that generates the code rather than inventing tools and
>> features that don't exist, nor will ever exist. It is also quite
>> common to use scripts in languages like perl or python to generate
>> tables and other pre-calculated values for inclusion in C code.
>
> though there are things that i will not disclose, i've never had to
> invent any tools for the project i'm working on.... everything is
> legit. this is the only time that i've had to. so believe me if i
> said i've considered all *conventional* solutions
>

No, you haven't considered all conventional solutions.  I've given you a 
couple of pointers.  You are not the first person who wanted to include 
pre-calculated values in portable C code.

>
>> Most modern compilers will do a pretty reasonable job of constant
>> propagation and calculating expressions using constant values. And
>> most will apply "inline" as you would expect, unless you
>> intentionally hamper the compiler by not enabling optimisations.
>> Using macros, incidentally, does not "FORCE" the compiler to do
>> anything - I know at least one compiler that will take common
>> sections of code (from macros or "normal" text) and refactor it
>> artificial functions, expending stack space and run time speed to
>> reduce code size. And "immediate addressing" is not necessarily a
>> good optimisation - beware making generalisations like that. Let
>> the compiler do what it is good at doing - generating optimal code
>> for the target in question - and don't try to second-guess it. You
>> will end up with bigger and slower code.
>
> i'm not one to share techniques/methodologies, 1) but if it's the
> case for more than, say 70%, of systems/processors and 2) it takes
> very little penalty; then i'd write it that way. if it's not
> optimized, just let the compiler (if it's as good as you say it is)
> re-optimize it. if the compiler ain't good enough to do that, well
> it's not a good compiler anyway. but the code will still work.
>
>> I really don't want to discourage someone from wanting to
>> contribute to gcc development, but this is very much a dead-end
>> idea. I applaud your enthusiasm, but keep a check on reality - you
>> are an amateur just starting C programming. C has been used for the
>> last forty years - with gcc coming up for its 25th birthday this
>> spring. If this idea were that simple, and that good, it would
>> already be implemented. As you gain experience and knowledge with C
>> (and possibly C++), you will quickly find that a preprocessor like
>> you describe is neither necessary nor desirable.
>
> you know there's no way i can't answer that without invoking the
> wrath of the community.
>

You are not expected to answer it - you are expected to accept it as 
reality.

The gcc developers, and everyone else involved in the development of C 
as a language, are perhaps not superhuman - but I suspect their combined 
knowledge, experience and programming ability outweighs yours.

Good luck with your project, but I strongly encourage you to find a 
different way to cope with your issues here.  Work /with/ your tools, 
not against them.