Re: preprocessor
On 2007-06-06 14:33, Gennaro Prota wrote:
On Wed, 06 Jun 2007 10:22:55 GMT, Erik Wikstr?m wrote:
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.
A curiosity which you can satisfy by seeing his code (and docs):
<http://kanze.james.neuf.fr/>
(you have to be willing to get out of your comfort zone, though, and
actually try --the benefits might not appear clearly, at first)
I can see the value for code that needs to compile on many different
platforms where the API might differ. But for simple things like adding
debug checks in code or such I find it a bit much to duplicate parts of
the code and trust the build-magic to do the rest. One should notice
that much of the complexity still exist but in the form of build-magic
instead.
If you consider my code that looks something like this (from memory):
template<typename T>
inline Vector<T>& Vector<T>::operator+=(const Vector<T>& v)
{
for (size_t i = 0; i < size_; ++i)
data_[i] += v.data_[i];
return *this
}
About 90% of all the methods of the code is like this. Now, if I would
like to introduce an OpenMP version of this code I could either insert
the lines
#ifdef _OPENMP
#pragma omp ...
#endif
above the if statement or I could create two versions of the files, one
with and one without OpenMP, some parts could remain in some common
files (about 10%). The problem with this would be that any changes I'll
make I'd have to do in both files, with the risk of me forgetting. I
just can't see that as a better solution.
Another solution might be to replace the for statement with a macro,
something like this:
FOR (size_t i = 0; i < v.size_; ++i)
{
// ...
}
And then let FOR expand to either just 'for' or '#pragma omp ... \n for'
but that's a bit too much macro-magic for me.
--
Erik Wikstr?m