Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

C++ Programming

preprocessor


Hi, I've read that in the future the C++ will not more support  the
preprocessor and now some preprocessor functionality have already been
implemented in the language itself. What are that?

Thanks.

"josh" wrote:
> Hi, I've read that in the future the C++ will not more support  the
> preprocessor and now some preprocessor functionality have already been
> implemented in the language itself. What are that?

The preprocessor must be supported till the end of time, include guards
depend on it. Producing specialized versions of software for specialized
targets is another place where the preprocessor is needed.  For example, a
crippled version of a Web Browser for use in a library.

The *usage*, OTOH, can be minimized.  Inline functions for example can
replace some macro usage.

preprocessors are the best simple established way to specify different
compiler and linker specification. So in near future it should be
there. After 15 or 20 years  I can't predict :D

Regards,
Sarath
mY bLoG: http://sarathc.wordpress.com/

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?

--
Gennaro Prota -- C++ Developer, For Hire
https://sourceforge.net/projects/breeze/
(replace 'address' with 'name.surname' to mail)

"Gennaro Prota" writes:
> 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?

I don't know what needs clariifcation so I will belabor the library example
I mentioned.

#define LIBRARY

Executables produced with this line will not be able to do file saves. And
other stuff as well, but that is the general idea.

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

--
Erik Wikstrm

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"?

--
Gennaro Prota -- C++ Developer, For Hire
https://sourceforge.net/projects/breeze/
(replace 'address' with 'name.surname' to mail)

I hope nobody says that. It isn't true.

--

        -- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

On Tue, 05 Jun 2007 18:07:23 +0200, Gennaro Prota <addr@yahoo.com>
wrote in comp.lang.c++:

There's never a need to make an inane, incorrect statement.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

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. I learned
this from him, as a lot of other things. "C++ Gotchas" by Steve
Dewhurst also has an item which briefly covers the problem:

    Gotcha #27: Overuse of #if

    "However," you state with a knowing look, "my code is platform
    independent. I have to use #if to handle the different platform
    requirements." To prove your point, such as it is, you display the
    following code: [code along the lines of the above omitted]

    This code is not platform-independent. It's multiplatform
    dependent. Any change to any of the platforms requires not only
    a recompilation of the source but change to the source for all
    platforms. You've achieved maximal coupling among platforms: a
    remarkable achievement, if somewhat impractical.

Steve has more to say about it, but I felt that the long quote above
is already at the limits of "fair use", which is why I snipped as much
as possible.

--
Gennaro Prota -- C++ Developer, For Hire
https://sourceforge.net/projects/breeze/
(replace 'address' with 'name.surname' to mail)

On Jun 6, 10:19 am, Gennaro Prota <addr@yahoo.com> wrote:

> On Tue, 05 Jun 2007 21:04:02 -0500, Jack Klein wrote:
> >On Tue, 05 Jun 2007 18:07:23 +0200, Gennaro Prota <addr@yahoo.com>
> >wrote in comp.lang.c++:
> >> 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"?

    [...]

> 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. I learned
> this from him, as a lot of other things. "C++ Gotchas" by Steve
> Dewhurst also has an item which briefly covers the problem:

The idea is not new.  I got it from a paper published by Henry
Spencer and Geoff Collyer, way back in 1992, see
http://www.literateprogramming.com/ifdefs.pdf.  And in fact, the
only #ifdef's in my code are normally header guards.  The
results are much more readable than, say, Boost, but are far
from perfect, either.  In the end, no matter how you cut it, you
have two (or more) versions of the same code; all have to be
understood, all have to be tested, and all have to be validated.
(The combinatorial is far easier to understand, however, which
at least makes it clearer what is or is not being validated.)

There are doubtlessly exceptions to the rule, as well.  For
example, most of the code I write is application code, in a
production environment, where I can write to a lowest common
denominator of a small set of production compilers.  Some new
feature isn't suported by one of the compilers, just don't use
it anywhere.  Library purveyors may not always have this
liberty; if I think back to the days when many compilers still
did not implement member templates, for example, a third party
vendor of the standard library would certainly want to support
them where the targetted compiler did.  No matter how much more
difficult it made maintenance for them.

There are different degrees of difficulty.  A simple, binary
#ifdef at the top of the file, around, say, an include and a
#define, doesn't bother me too much.  Where as #ifdef's in the
body of a function, or nested #ifdef's, are simply not
acceptable (although common) in professional code.  When I see
such things, I generally throw the code out and start over,
because it is less work than trying to figure out what is
actually going on.  (Regretfully, you can't always do that, and
on more than one occassion, I've had to run the code through the
preprocessor in order to figure out what definitions I was
getting from include files under /usr/include under Solaris.)

--
James Kanze (GABI Software)             email:james.ka@gmail.com
Conseils en informatique oriente objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Smard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34

On 2007-06-06 10:19, Gennaro Prota 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.

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 Wikstrm

On Wed, 06 Jun 2007 10:22:55 GMT, Erik Wikstrm 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)

--
Gennaro Prota -- C++ Developer, For Hire
https://sourceforge.net/projects/breeze/
(replace 'address' with 'name.surname' to mail)

On 2007-06-06 14:33, Gennaro Prota wrote:

> On Wed, 06 Jun 2007 10:22:55 GMT, Erik Wikstrm 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 Wikstrm

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc