Re: [Xnews] Open Source Xnews?

Discussion in 'C Programming' started by Darrien, Nov 1, 2003.

  1. Darrien

    Darrien Guest

    On Sat, 01 Nov 2003 13:08:44 GMT, "Richard Hoskins" Enlightened the world
    by saying:

    [FollowUp set]

    > Darrien <Darrien_Lambert@> writes:
    >
    >> On Sat, 01 Nov 2003 03:45:23 GMT, "Richard Hoskins" Enlightened the
    >> world by saying:
    >>
    >> [snip]
    >>
    >>> I would hate to use a different newsreader, that might be written in a
    >>> platform specific language like C or Delphi, and then abandoned after
    >>> a few years.
    >>>

    >>
    >> C is not a platform specific language.
    >>

    >
    > That's the theory anyway.
    >


    Can you explain this statement?

    Why do you believe that C is platform specific?


    --
    Registered Linucks hater #7011799107
     
    Darrien, Nov 1, 2003
    #1
    1. Advertising

  2. Darrien

    127.0.0.1 Guest

    Darrien wrote:

    > > >
    > >> C is not a platform specific language.
    > > >

    > >
    > > That's the theory anyway.
    > >

    >
    > Can you explain this statement?
    >
    > Why do you believe that C is platform specific?


    Well it is platform specific, if it wasn't you wouldn't need 10,000
    lines of #ifdefs to cater for all the different platforms would you.

    Delphi has a true cross platform environment (WIndows/Linux) that
    allows the same code to be compiled on each platform. No weird batch
    files, make files and pre-processor directives to make pretend.

    --
    Spam:newsgroup(at)
    EMail:<0110001100101110011000100111010101110010011010110
    11001010100000001100011011100100110000101111010011011100
    1100001011100100010111001100011011011110110110100100000>
     
    127.0.0.1, Nov 1, 2003
    #2
    1. Advertising

  3. Darrien

    Simon Biber Guest

    "127.0.0.1" <newsgroup(at)> wrote:
    > Well it is platform specific, if it wasn't you wouldn't need 10,000
    > lines of #ifdefs to cater for all the different platforms would you.


    You don't need any #ifdefs if you write portable C code.

    The difficulty of course is that portable C code is more restrictive
    than portable Delphi code, or portable Java code, etc.

    --
    Simon.
     
    Simon Biber, Nov 1, 2003
    #3
  4. Darrien

    James Hu Guest

    On 2003-11-01, Simon Biber <> wrote:
    > "127.0.0.1" <newsgroup(at)> wrote:
    >> Well it is platform specific, if it wasn't you wouldn't need 10,000
    >> lines of #ifdefs to cater for all the different platforms would you.

    >
    > You don't need any #ifdefs if you write portable C code.


    Hmm... How do you portably make your header files to be #include
    idempotent with using #ifdef ... (or #if defined(...))?

    Some C99 features help make the code better (inline keyword, restrict
    keyword). How do you make your portable C code opportunistically
    leverage standard C99 features and still be compiled on systems that
    only have a C90 compiler without using conditional compilation? Is
    it really valid to say such code is not portable C code?

    -- James
     
    James Hu, Nov 1, 2003
    #4
  5. Darrien

    Simon Biber Guest

    "James Hu" <> wrote:
    > On 2003-11-01, Simon Biber <> wrote:
    > > You don't need any #ifdefs if you write portable C code.

    >
    > Hmm... How do you portably make your header files to be #include
    > idempotent with using #ifdef ... (or #if defined(...))?


    I use #ifndef rather than #ifdef for this purpose. :)

    > Some C99 features help make the code better (inline keyword,
    > restrict keyword). How do you make your portable C code
    > opportunistically leverage standard C99 features and still
    > be compiled on systems that only have a C90 compiler without
    > using conditional compilation? Is it really valid to say
    > such code is not portable C code?


    I did not claim the reverse (ie. that code with #ifdefs is not
    portable C code). However, I don't typically do this. For a
    particular project I pick either C90 or C99. When I do pick C99
    I use features which are not so simple to conditionally remove.

    --
    Simon.
     
    Simon Biber, Nov 2, 2003
    #5
  6. Darrien

    James Hu Guest

    [OT] Contrapositive (was Re: [Xnews] Open Source Xnews?)

    "Simon Biber" <> wrote in message news:<3fa51b64$0$30391$>...
    > "James Hu" <> wrote:
    > > On 2003-11-01, Simon Biber <> wrote:
    > > > You don't need any #ifdefs if you write portable C code.

    > >
    > > Some C99 features help make the code better (inline keyword,
    > > restrict keyword). How do you make your portable C code
    > > opportunistically leverage standard C99 features and still
    > > be compiled on systems that only have a C90 compiler without
    > > using conditional compilation? Is it really valid to say
    > > such code is not portable C code?

    >
    > I did not claim the reverse (ie. that code with #ifdefs is not
    > portable C code).


    Just a nit on logic. You said:

    If you write portable C code, then you don't need any #ifdefs.

    The contrapositive is:

    If you need #ifdefs, then you do not write portable C code.

    And, the contrapositive of a conditional statement is equivalent
    to the original conditional statement.

    -- James
     
    James Hu, Nov 3, 2003
    #6
  7. Re: [OT] Contrapositive (was Re: [Xnews] Open Source Xnews?)

    James Hu wrote:
    > "Simon Biber" <> wrote in message news:<3fa51b64$0$30391$>...
    >> "James Hu" <> wrote:
    >> > On 2003-11-01, Simon Biber <> wrote:
    >> > > You don't need any #ifdefs if you write portable C code.
    >> >
    >> > Some C99 features help make the code better (inline keyword,
    >> > restrict keyword). How do you make your portable C code
    >> > opportunistically leverage standard C99 features and still
    >> > be compiled on systems that only have a C90 compiler without
    >> > using conditional compilation? Is it really valid to say
    >> > such code is not portable C code?

    >>
    >> I did not claim the reverse (ie. that code with #ifdefs is not
    >> portable C code).

    >
    > Just a nit on logic. You said:
    >
    > If you write portable C code, then you don't need any #ifdefs.
    >
    > The contrapositive is:
    >
    > If you need #ifdefs, then you do not write portable C code.
    >
    > And, the contrapositive of a conditional statement is equivalent
    > to the original conditional statement.


    There's a distinction between code with #ifdefs and code that /needs/
    #ifdefs. No portable C program needs to use #ifdef (since #ifndef and
    #else will always do instead), but a program that does use #ifdef may
    still be portable.

    Jeremy.
     
    Jeremy Yallop, Nov 3, 2003
    #7
  8. Darrien

    James Hu Guest

    Re: [OT] Contrapositive (was Re: [Xnews] Open Source Xnews?)

    On 2003-11-03, Jeremy Yallop <> wrote:
    > James Hu wrote:
    >> "Simon Biber" <> wrote in message news:<3fa51b64$0$30391$>...
    >>> "James Hu" <> wrote:
    >>> > On 2003-11-01, Simon Biber <> wrote:
    >>> > > You don't need any #ifdefs if you write portable C code.
    >>> >
    >>> > Some C99 features help make the code better (inline keyword,
    >>> > restrict keyword). How do you make your portable C code
    >>> > opportunistically leverage standard C99 features and still
    >>> > be compiled on systems that only have a C90 compiler without
    >>> > using conditional compilation? Is it really valid to say
    >>> > such code is not portable C code?
    >>>
    >>> I did not claim the reverse (ie. that code with #ifdefs is not
    >>> portable C code).

    >>
    >> Just a nit on logic. You said:
    >>
    >> If you write portable C code, then you don't need any #ifdefs.
    >>
    >> The contrapositive is:
    >>
    >> If you need #ifdefs, then you do not write portable C code.
    >>
    >> And, the contrapositive of a conditional statement is equivalent
    >> to the original conditional statement.

    >
    > There's a distinction between code with #ifdefs and code that /needs/
    > #ifdefs.


    Please define what you mean by "needs". In my definition, if I cannot
    accomplish a task (such as "opportunistically leverage C99 features
    and still be compiled by a C90 compiler" as stated in my hypothetical
    question) without some mechanism, then I /need/ that mechanism.

    > No portable C program needs to use #ifdef (since #ifndef and
    > #else will always do instead),


    Sure. But hypothetical question makes it clear I am generalizing
    Simon's #ifdef term. That is, I am treating all the different standard
    C mechanisms for achieving conditional compilation (i.e., one of #if,
    #ifdef, or #ifndef, optionally coupled with some number of #elif,
    optionally followed by an #else, and terminated by #endif) as equivalent
    mechanisms. In fact, in standard C, all the conditional directives are
    defined in terms of #if. So, standard C treats them equivalently.

    > but a program that does use #ifdef may
    > still be portable.


    Using your "needs" distinction (but by my definition, since I have not
    seen yours), I am claiming that a program that /needs/ #ifdef's may
    still be portable. In fact, I will strengthen it, and say that it
    may still be a strictly conforming program in the standard C sense.
    Furthermore, it may be a strictly conforming program in both C99 and
    C90.

    (BTW, if it is not clear by now, my hypothetical question is largely
    rhetorical.)

    -- James
     
    James Hu, Nov 3, 2003
    #8
  9. Re: [OT] Contrapositive (was Re: [Xnews] Open Source Xnews?)

    James Hu wrote:
    > On 2003-11-03, Jeremy Yallop <> wrote:
    >> There's a distinction between code with #ifdefs and code that /needs/
    >> #ifdefs.

    >
    > Please define what you mean by "needs".


    I already have, implicitly.

    > In my definition, if I cannot accomplish a task (such as
    > "opportunistically leverage C99 features and still be compiled by a
    > C90 compiler" as stated in my hypothetical question) without some
    > mechanism, then I /need/ that mechanism.


    #ifdef is no more necessary in a portable C program than `while', in
    that any portable C program that uses "#ifdef" can also be modified
    not to use it, without loss of functionality or portablility.

    OOI, are you talking about testing for the presence of particular C99
    features, or testing for a C99 implementation? If the latter, I'd
    prefer:

    #if __STDC_VERSION__ >= 199901L

    Actually, I'd probably take Simon's approach, and write the program in
    either C89 or C99. Conditional compilation just adds to the
    maintenance burden.

    > Sure. But hypothetical question makes it clear I am generalizing
    > Simon's #ifdef term. That is, I am treating all the different standard
    > C mechanisms for achieving conditional compilation (i.e., one of #if,
    > #ifdef, or #ifndef, optionally coupled with some number of #elif,
    > optionally followed by an #else, and terminated by #endif) as equivalent
    > mechanisms. In fact, in standard C, all the conditional directives are
    > defined in terms of #if. So, standard C treats them equivalently.


    Well, #ifdef only provides a small subset of the functionality of #if,
    so I wouldn't use "equivalent" here.

    Jeremy.
     
    Jeremy Yallop, Nov 3, 2003
    #9
  10. Darrien

    James Hu Guest

    Re: [OT] Contrapositive (was Re: [Xnews] Open Source Xnews?)

    As a preface, the original intent of this thread was to simply point
    out a *minor* falacy of logic. That point has not been refuted.

    Jeremy Yallop <> wrote in message news:<>...
    > James Hu wrote:
    > > On 2003-11-03, Jeremy Yallop <> wrote:
    > >> There's a distinction between code with #ifdefs and code that /needs/
    > >> #ifdefs.

    > >
    > > Please define what you mean by "needs".

    >
    > I already have, implicitly.


    Well, call me a collapsed star with a mass of 2.99 solar masses, your
    post did not make it clear.

    > > In my definition, if I cannot accomplish a task (such as
    > > "opportunistically leverage C99 features and still be compiled by a
    > > C90 compiler" as stated in my hypothetical question) without some
    > > mechanism, then I /need/ that mechanism.

    >
    > #ifdef is no more necessary in a portable C program than 'while', in
    > that any portable C program that uses "#ifdef" can also be modified
    > not to use it, without loss of functionality or portablility.


    *Now* I see your definition of need.

    To write a portable C program, 'static' is not necessary, 'for' is
    not necessary, 'switch' is not necessary, functions are not necessary,
    'enum' is not necessary, 'struct' and 'union' are not necessary,
    arrays are not necessary, and pointers are not necessary. Neither are
    any of the types except unsigned char.

    But those unnecessary mechanisms are /needed/ to make programs easier
    to write, comprehend, verify, correct in the present, and make those
    same programs easier to maintain in the future.

    Just because it is possible to exist without some "thing" does not
    mean that "thing" is not needed for reasons other than to simply be.

    > OOI, are you talking about testing for the presence of particular C99
    > features, or testing for a C99 implementation? If the latter, I'd
    > prefer:
    >
    > #if __STDC_VERSION__ >= 199901L


    This is what I had in mind.

    > Actually, I'd probably take Simon's approach, and write the program in
    > either C89 or C99. Conditional compilation just adds to the
    > maintenance burden.


    Sure, we can all make that choice with a clear conscience. But it is no
    better or worse than the hypothetical choice of not wanting to maintain
    two sets of essentially identical source code, modulo certain desirable
    C99 features that result in syntax errors in C90.

    > > Sure. But hypothetical question makes it clear I am generalizing
    > > Simon's #ifdef term. That is, I am treating all the different standard
    > > C mechanisms for achieving conditional compilation (i.e., one of #if,
    > > #ifdef, or #ifndef, optionally coupled with some number of #elif,
    > > optionally followed by an #else, and terminated by #endif) as equivalent
    > > mechanisms. In fact, in standard C, all the conditional directives are
    > > defined in terms of #if. So, standard C treats them equivalently.

    >
    > Well, #ifdef only provides a small subset of the functionality of #if,
    > so I wouldn't use "equivalent" here.


    #ifdef coupled with #elif is just as general as #if.

    -- James

    --
    I can play the pedantic game too! :)
     
    James Hu, Nov 3, 2003
    #10
  11. Re: [OT] Contrapositive (was Re: [Xnews] Open Source Xnews?)

    James Hu wrote:
    > Jeremy Yallop <> wrote in message news:<>...
    >> James Hu wrote:
    >> > Sure. But hypothetical question makes it clear I am generalizing
    >> > Simon's #ifdef term. That is, I am treating all the different standard
    >> > C mechanisms for achieving conditional compilation (i.e., one of #if,
    >> > #ifdef, or #ifndef, optionally coupled with some number of #elif,
    >> > optionally followed by an #else, and terminated by #endif) as equivalent
    >> > mechanisms. In fact, in standard C, all the conditional directives are
    >> > defined in terms of #if. So, standard C treats them equivalently.

    >>
    >> Well, #ifdef only provides a small subset of the functionality of #if,
    >> so I wouldn't use "equivalent" here.

    >
    > #ifdef coupled with #elif is just as general as #if.


    This is true, but irrelevant to my point, which is that #ifdef (with
    #else, if you like) is not as general as #if (and #elif). #if allows
    arithmetic; #ifdef does not.

    Jeremy.
     
    Jeremy Yallop, Nov 3, 2003
    #11
  12. Darrien

    James Hu Guest

    Re: [OT] Contrapositive (was Re: [Xnews] Open Source Xnews?)

    Jeremy Yallop <> wrote in message news:<>...
    > James Hu wrote:
    > > Jeremy Yallop <> wrote in message news:<>...
    > >> James Hu wrote:
    > >> > Sure. But hypothetical question makes it clear I am generalizing
    > >> > Simon's #ifdef term. That is, I am treating all the different standard
    > >> > C mechanisms for achieving conditional compilation (i.e., one of #if,
    > >> > #ifdef, or #ifndef, optionally coupled with some number of #elif,
    > >> > optionally followed by an #else, and terminated by #endif) as equivalent
    > >> > mechanisms. In fact, in standard C, all the conditional directives are
    > >> > defined in terms of #if. So, standard C treats them equivalently.
    > >>
    > >> Well, #ifdef only provides a small subset of the functionality of #if,
    > >> so I wouldn't use "equivalent" here.

    > >
    > > #ifdef coupled with #elif is just as general as #if.

    >
    > This is true, but irrelevant to my point, which is that #ifdef (with
    > #else, if you like) is not as general as #if (and #elif). #if allows
    > arithmetic; #ifdef does not.


    I understand your point and it is true. But my point is that my
    premise (which remains quoted above but copied here for clarity)
    was:

    ... I am treating all the different standard C mechanisms
    for achieving conditional compilation (i.e., one of #if,
    #ifdef, or #ifndef, optionally coupled with some number of
    #elif, optionally followed by an #else, and terminated by
    #endif) as equivalent mechanisms.

    So I defined the premise required to achieve equivalency, and
    coupling #ifdef with #elif lies within that premise.

    -- James
     
    James Hu, Nov 4, 2003
    #12
    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. Aaron Watters
    Replies:
    0
    Views:
    630
    Aaron Watters
    Mar 8, 2008
  2. Nancy 8

    Re: Best Xnews Replacement?

    Nancy 8, May 9, 2011, in forum: Java
    Replies:
    1
    Views:
    517
    Mike Faramis
    May 10, 2011
  3. Jane Doe
    Replies:
    1
    Views:
    390
    thoolen
    Jul 18, 2011
  4. pat eyler
    Replies:
    1
    Views:
    466
    Masayoshi Takahashi
    Mar 5, 2005
  5. Jenny
    Replies:
    3
    Views:
    265
    Dag Sunde
    Dec 17, 2004
Loading...

Share This Page