Re: preprocessor
On 2007-06-06 10:19, Gennaro Prota wrote:
On Tue, 05 Jun 2007 21:04:02 -0500, Jack Klein wrote:
On Tue, 05 Jun 2007 18:07:23 +0200, Gennaro Prota <address@yahoo.com>
wrote in comp.lang.c++:
On Tue, 05 Jun 2007 05:29:32 -0700, Erik Wikstr?m wrote:
On 5 Juni, 13:45, Gennaro Prota <addr...@yahoo.com> wrote:
On Tue, 5 Jun 2007 03:55:59 -0700, osmium wrote:
Producing specialized versions of software for specialized targets
is another place where the preprocessor is needed.
Could you please clarify this?
#idfef _OPENMP
// Do something in parallel
#else
// Do something single-threaded
#end
Or
#ifdef _WIN64
// use some 64-bit type
#else
// use a 32-bit type
#end
That's what I was afraid Osmium was talking about. Now, as late as
2007, is there still a need to say that no competent software engineer
would use such "techniques"?
There's never a need to make an inane, incorrect statement.
The statement was a bit "strong", because this is something which
really needs to be pushed. It severely affects software quality, not
to talk about code, such as OpenSSL, which is supposed to be
"validated" (FIPS validated in that case) when actually just *one* of
the several combinatorial variants of #if's actually is.
I've personally used conditional compilation in Boost, for instance,
either because I wasn't aware of better alternatives at that time and
because, in any case, that is the Boost "way". However it just
requires a minimal infrastructure to elevate everything to much higher
engineering standards, as you can see from James Kanze code.
Since I have not seen any of James KAnze's code that relates to the
question at hand I'm a bit curious about this infrastructure which would
elevate the code to those higher engineering standards.
Working as I am on a piece of software that performs some calculations
and being a bit performance concious I have been experimenting a bit.
Since the code is performing some linear algebra operations (which often
involves performing the same operation to all elements in a vector) one
of ways to improve performance that I tested was to us OpenMP to
parallelise those loops.
The results of the tests showed that on multi CPU/core computers there
was a significant gain to be had but on single CPU/core computers the
application ran slightly slower, which I believe comes from some
additional overhead associated with OpenMP (or just my failure to use it
correctly).
From this I decided that it might be interesting to have two versions
of the program, one which is OpenMP enabled and on which isn't, and
using macros and #ifdefs I can easily manage both configurations in one
file and all I have to do to create an OpenMP enabled release is specify
a preprocessor flag.
I have a hard time to see how this can be achieved in any better way,
but I'd like to find out, because all the
#ifdef _OPENMP
#pragma omp ...
#endif
makes the code less readable and ugly.
--
Erik Wikstr?m