preprocessor

Discussion in 'C++' started by josh, Jun 5, 2007.

  1. josh

    josh Guest

    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, Jun 5, 2007
    #1
    1. Advertising

  2. josh

    osmium Guest

    "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.
     
    osmium, Jun 5, 2007
    #2
    1. Advertising

  3. josh

    Sarath Guest

    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/

    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?
    >
    > Thanks.
     
    Sarath, Jun 5, 2007
    #3
  4. 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, Jun 5, 2007
    #4
  5. josh

    osmium Guest

    "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.
     
    osmium, Jun 5, 2007
    #5
  6. On 5 Juni, 13:45, Gennaro Prota <> 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 Wikström
     
    =?iso-8859-1?q?Erik_Wikstr=F6m?=, Jun 5, 2007
    #6
  7. On Tue, 05 Jun 2007 05:29:32 -0700, Erik Wikström wrote:

    >On 5 Juni, 13:45, Gennaro Prota <> 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"?

    --
    Gennaro Prota -- C++ Developer, For Hire
    https://sourceforge.net/projects/breeze/
    (replace 'address' with 'name.surname' to mail)
     
    Gennaro Prota, Jun 5, 2007
    #7
  8. josh

    Pete Becker Guest

    Gennaro Prota wrote:
    > On Tue, 05 Jun 2007 05:29:32 -0700, Erik Wikström wrote:
    >
    >> On 5 Juni, 13:45, Gennaro Prota <> 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"?
    >


    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)
     
    Pete Becker, Jun 5, 2007
    #8
  9. josh

    Jack Klein Guest

    On Tue, 05 Jun 2007 18:07:23 +0200, Gennaro Prota <>
    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 <> 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.

    --
    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
     
    Jack Klein, Jun 6, 2007
    #9
  10. On Tue, 05 Jun 2007 21:04:02 -0500, Jack Klein wrote:

    >On Tue, 05 Jun 2007 18:07:23 +0200, Gennaro Prota <>
    >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 <> 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. 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)
     
    Gennaro Prota, Jun 6, 2007
    #10
  11. josh

    James Kanze Guest

    On Jun 6, 10:19 am, 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 <>
    > >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:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Jun 6, 2007
    #11
  12. 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 <>
    >>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 <> 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
     
    =?ISO-8859-1?Q?Erik_Wikstr=F6m?=, Jun 6, 2007
    #12
  13. 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)

    --
    Gennaro Prota -- C++ Developer, For Hire
    https://sourceforge.net/projects/breeze/
    (replace 'address' with 'name.surname' to mail)
     
    Gennaro Prota, Jun 6, 2007
    #13
  14. 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>::eek:perator+=(const Vector<T>& v)
    {
    for (size_t i = 0; i < size_; ++i)
    data_ += v.data_;
    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
     
    =?ISO-8859-1?Q?Erik_Wikstr=F6m?=, Jun 6, 2007
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris P
    Replies:
    0
    Views:
    447
    Chris P
    Oct 28, 2003
  2. The Weiss Family

    VHDL Preprocessor

    The Weiss Family, Jul 14, 2004, in forum: VHDL
    Replies:
    2
    Views:
    3,257
    The Weiss Family
    Jul 14, 2004
  3. =?Utf-8?B?SSBhbSBTYW0=?=

    C# Preprocessor

    =?Utf-8?B?SSBhbSBTYW0=?=, Mar 13, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    1,598
    =?Utf-8?B?SSBhbSBTYW0=?=
    Mar 13, 2005
  4. Replies:
    0
    Views:
    2,712
  5. Cronus
    Replies:
    1
    Views:
    706
    Paul Mensonides
    Jul 15, 2004
Loading...

Share This Page