This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: a nifty feature for c preprocessor


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]