RE: Understanding Macro Pre-processor

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

>So, my old concept(it's just replace the source text) is right??

Correct.  The preprocessor just replaces text in the source.  Slightly more domain specific than using 'sed -e s/something/somethingelse/g'.

>Then, the ones who frequently insists that using macros makes part of the processing at compile-time is really wrong?

"Wrong"?  Welllllll... by some metric of "wrongness", I suppose.  Not wrong by other metrics.  Depends on the context and scope, too.

For C, preprocessor macro functions can be more faster than C functions.

For C++, preprocessor macro functions should be replaced with inline functions and/or templates.

Using C++ instead of the preprocessor allows for type safety and additional optimizations that a preprocessor cannot provide.  Plus it eliminates the sharp-edge side-effect gotchyas with preprocessor macro functions.

In both cases -- C with preprocessor macro functions and C++ with inline functions and/or templates -- premature optimization is the root of all evil, to paraphrase Tony Hoare.

I recommend profiling, or very limited employment of "educated guesses" (those that avoid premature pessimization, as per Sutter's C++ Coding Standards).

>Going out of the original question, does someone recommend me a good doc about how to optimize my programs, making it run fast.

For performance, most programs benefit by thoughtful architecture and design, than lovingly hand optimized portions.

I like these books:
Large-Scale C++ Software Design by Lakos
Debugging the Development Process by Maguire
Writing Solid Code by Maguire
Code Complete by McConnell
Design Patterns by Gamma et al

And a book that really got into nitty gritty details of performance honing, even though the 680x0 CPU is no longer a popular CPU and Mac OS 7 (and 8 and 9) is a bygone OS, I really learned a lot from:
Sex, Lies and Video Games by Hensler
(The subject material is no longer topical, but the concepts are still very relevant.  I don't expect an updated version any time soon, however.)

Profiling is the best way to identify your performance bottlenecks.

Those few routines that need to be highly optimized should be isolated.  Using preprocessor functions as a pervasive optimization technique, in my opinion, is misguided.  Even in plain C.  But that's just me.  Your mileage may vary.

HTH,
--Eljay


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux