Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: [Xnews] Open Source Xnews?

Reply
Thread Tools

Re: [Xnews] Open Source Xnews?

 
 
Darrien
Guest
Posts: n/a
 
      11-01-2003
On Sat, 01 Nov 2003 13:08:44 GMT, "Richard Hoskins" Enlightened the world
by saying:

[FollowUp set]

> Darrien <Darrien_Lambert@(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
127.0.0.1
Guest
Posts: n/a
 
      11-01-2003
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)(E-Mail Removed)
EMail:<0110001100101110011000100111010101110010011 010110
11001010100000001100011011100100110000101111010011 011100
11000010111001000101110011000110110111101101101001 00000>
 
Reply With Quote
 
 
 
 
Simon Biber
Guest
Posts: n/a
 
      11-01-2003
"127.0.0.1" <newsgroup(at)(E-Mail Removed)> 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.


 
Reply With Quote
 
James Hu
Guest
Posts: n/a
 
      11-01-2003
On 2003-11-01, Simon Biber <(E-Mail Removed)> wrote:
> "127.0.0.1" <newsgroup(at)(E-Mail Removed)> 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
 
Reply With Quote
 
Simon Biber
Guest
Posts: n/a
 
      11-02-2003
"James Hu" <(E-Mail Removed)> wrote:
> On 2003-11-01, Simon Biber <(E-Mail Removed)> 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.


 
Reply With Quote
 
James Hu
Guest
Posts: n/a
 
      11-03-2003
"Simon Biber" <(E-Mail Removed)> wrote in message news:<3fa51b64$0$30391$(E-Mail Removed). au>...
> "James Hu" <(E-Mail Removed)> wrote:
> > On 2003-11-01, Simon Biber <(E-Mail Removed)> 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
 
Reply With Quote
 
Jeremy Yallop
Guest
Posts: n/a
 
      11-03-2003
James Hu wrote:
> "Simon Biber" <(E-Mail Removed)> wrote in message news:<3fa51b64$0$30391$(E-Mail Removed). au>...
>> "James Hu" <(E-Mail Removed)> wrote:
>> > On 2003-11-01, Simon Biber <(E-Mail Removed)> 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.

 
Reply With Quote
 
James Hu
Guest
Posts: n/a
 
      11-03-2003
On 2003-11-03, Jeremy Yallop <(E-Mail Removed)> wrote:
> James Hu wrote:
>> "Simon Biber" <(E-Mail Removed)> wrote in message news:<3fa51b64$0$30391$(E-Mail Removed). au>...
>>> "James Hu" <(E-Mail Removed)> wrote:
>>> > On 2003-11-01, Simon Biber <(E-Mail Removed)> 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
 
Reply With Quote
 
Jeremy Yallop
Guest
Posts: n/a
 
      11-03-2003
James Hu wrote:
> On 2003-11-03, Jeremy Yallop <(E-Mail Removed)> 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.
 
Reply With Quote
 
James Hu
Guest
Posts: n/a
 
      11-03-2003
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 <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> James Hu wrote:
> > On 2003-11-03, Jeremy Yallop <(E-Mail Removed)> 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!
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Open Source vs Closed Source Security Lawrence D'Oliveiro NZ Computing 1 03-04-2010 05:16 AM
Closed-Source vs Open-Source Drivers Lawrence D'Oliveiro NZ Computing 2 05-04-2009 11:36 PM
off topic: 2 videos on source control and open source development Aaron Watters Python 0 03-08-2008 10:13 PM
Open-Source Good, Closed-Source Bad Lawrence D'Oliveiro NZ Computing 1 10-16-2005 05:02 AM
Open Source Conference in Japan: Open Source Realize Forum 2005 pat eyler Ruby 1 03-05-2005 03:50 AM



Advertisments