Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Richard heathfields C programming article

Reply
Thread Tools

Richard heathfields C programming article

 
 
dj3vande@csclub.uwaterloo.ca.invalid
Guest
Posts: n/a
 
      11-09-2007
In article <(E-Mail Removed)>,
Charlton Wilbur <(E-Mail Removed)> wrote:
>>>>>> "D" == dj3vande <(E-Mail Removed)> writes:

>
> D> In article <(E-Mail Removed)>,
> D> Charlton Wilbur <(E-Mail Removed)> wrote:
>
> D> [Talking about javac, though the comments here apply just as
> D> much to any other compiler]
>
> >> I expect the compiler can actually be written entirely in
> >> standard C, although as a practical matter I don't see any
> >> reason to restrict it that far.

>
> D> The things a compiler does are helped immensely by code
> D> generators for things like the tokenizer and the parser, but
> D> the generated code (and the generators themselves!) can very
> D> easily be entirely standard C, and it's not immediately obvious
> D> how going beyond the standard for the rest of the compiler
> D> would help either.
>
> D> If there's no benefit for going outside what the standard
> D> provides, wouldn't that be a reason to restrict it that far?
>
>There may be no academic benefit (i.e., everything you might use
>outside the standard can be reimplemented in standard C), but there's
>a lot of possible practical benefit (i.e., using strsep or strtok_r,
>for instance, or other BSD or POSIX standard calls).


Because nobody would ever want to run your compiler on a non-BSD,
non-POSIX platform like, say, Windows.


>There's a tradeoff between portability and programmer convenience, and
>it should not come as a great surprise to anyone in this newsgroup
>that there are times when one opts for convenience over portability --


The examples you've given are terrible ones to use to illustrate this
point, since the cost of writing your own code to get that
functionality is not only a vanishingly small fraction of the total
cost of writing a compiler, but also highly unlikely to be larger than
the cost of going back after system-specific code has been written and
porting it to another hosted system (which, depending on how well the
design was done and how well the non-portable parts were separated out,
may or may not also be vanishingly small compared to the total cost of
building the whole thing in the first place).


dave

 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      11-09-2007
Ben Pfaff said:

> Richard Heathfield <(E-Mail Removed)> writes:
>
>> "C programs and libraries are woven into the very fabric of the modern
>> programming world, and anyone who thinks otherwise betrays their
>> ignorance of that world."

>
> Still not that friendly.


Weeeelllll, it's friendly to C programmers.

> I prefer to use the term "uninformed"
> to "ignorant" when I am trying to avoid offense. (It is easier
> to educate people when they are not offended.)


Understood. But, although it was not my intent to offend anyone, I wasn't
particularly trying to avoid it, either.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      11-10-2007
Charlton Wilbur wrote:
> Charlie Gordon <(E-Mail Removed)> writes:
>

.... snip ...
>
>> What do you think javac does that cannot not be implemented in
>> Standard C ?

>
> Hrm, I was thinking of the runtime, which does low-level IO and
> threading.
>
> I expect the compiler can actually be written entirely in standard
> C, although as a practical matter I don't see any reason to
> restrict it that far.


How about to port the compiler to almost anywhere instantaneously?
This is also an adequate reason to write as much as possible of the
runtime in standard C.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Charlie Gordon
Guest
Posts: n/a
 
      11-10-2007
<(E-Mail Removed)> a écrit dans le message de news:
fh25tq$opr$(E-Mail Removed)...
> In article <(E-Mail Removed)>,
> Charlton Wilbur <(E-Mail Removed)> wrote:
>
> [Talking aboutjavac, though the comments here apply just as much to
> any other compiler]
>>I expect the compiler can actually be written entirely in standard C,
>>although as a practical matter I don't see any reason to restrict it
>>that far.

>
> The things a compiler does are helped immensely by code generators for
> things like the tokenizer and the parser, but the generated code (and
> the generators themselves!) can very easily be entirely standard C, and
> it's not immediately obvious how going beyond the standard for the rest
> of the compiler would help either.
>
> If there's no benefit for going outside what the standard provides,
> wouldn't that be a reason to restrict it that far?


The compiler could use multiple threads in an attempt to take advantage of
todays multi-core processors, or just for the fun of spreading the peanut
butter on both sides of the slice of bread.

--
Chqrlie.


 
Reply With Quote
 
Keith Willis
Guest
Posts: n/a
 
      11-12-2007
On Fri, 09 Nov 2007 10:41:54 -0800, Ben Pfaff <(E-Mail Removed)>
wrote:

>Richard Heathfield <(E-Mail Removed)> writes:
>
>> "C programs and libraries are woven into the very fabric of the modern
>> programming world, and anyone who thinks otherwise betrays their ignorance
>> of that world."

>
>Still not that friendly. I prefer to use the term "uninformed"
>to "ignorant" when I am trying to avoid offense. (It is easier
>to educate people when they are not offended.)


Reminds me of a manager telling me many years ago, after a meeting
where I had upset the project sponsor who clearly knew very little:

"Keith, rather than telling people 'That's *******s!', we prefer the
phrase 'Sadly that turns out not to be the case'"
--
PGP key ID 0xEB7180EC
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      11-12-2007
Keith Willis said:

> On Fri, 09 Nov 2007 10:41:54 -0800, Ben Pfaff <(E-Mail Removed)>
> wrote:
>
>>Richard Heathfield <(E-Mail Removed)> writes:
>>
>>> "C programs and libraries are woven into the very fabric of the modern
>>> programming world, and anyone who thinks otherwise betrays their
>>> ignorance of that world."

>>
>>Still not that friendly. I prefer to use the term "uninformed"
>>to "ignorant" when I am trying to avoid offense. (It is easier
>>to educate people when they are not offended.)

>
> Reminds me of a manager telling me many years ago, after a meeting
> where I had upset the project sponsor who clearly knew very little:
>
> "Keith, rather than telling people 'That's *******s!', we prefer the
> phrase 'Sadly that turns out not to be the case'"


Y2K. On behalf of a client, I was at a meeting with that client's customer
in their head office. Also present were representatives of another
supplier to that customer. Lots of big wheels there, plus me (a very
little wheel). They were all discussing a report that called into question
the feasibility of my sub-project, while I quietly read through the report
in increasing disbelief. Eventually, I cried out in sheer exasperation,
"who wrote all this junk anyway?"

There was a stunned silence, my project manager looked like he wanted the
earth to open up, but then up went a hand... belonging to someone who
worked for the other supplier. Everyone (well, almost everyone) in the
room breathed again, as I proceeded to back my "junk" claim with a
blizzard of appropriate technical detail (and, if I recall correctly, a
scary diagram) that demonstrated exactly why the sub-project was perfectly
feasible and the objections that had been raised were on the same level as
a claim that "we can't go shopping today, because it might rain" by
someone who had never figured out how to raise an umbrella.

During the trip back to base, the project manager tried hard to tell me off
for my lack of tact, but he couldn't, because he couldn't stop laughing.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
dj3vande@csclub.uwaterloo.ca.invalid
Guest
Posts: n/a
 
      11-12-2007
In article <4734fd58$0$27292$(E-Mail Removed)>,
Charlie Gordon <(E-Mail Removed)> wrote:
><(E-Mail Removed)> a icrit dans le message de news:
>fh25tq$opr$(E-Mail Removed)...
>> In article <(E-Mail Removed)>,
>> Charlton Wilbur <(E-Mail Removed)> wrote:
>>
>> [Talking aboutjavac, though the comments here apply just as much to
>> any other compiler]
>>>I expect the compiler can actually be written entirely in standard C,
>>>although as a practical matter I don't see any reason to restrict it
>>>that far.

>>
>> The things a compiler does are helped immensely by code generators for
>> things like the tokenizer and the parser, but the generated code (and
>> the generators themselves!) can very easily be entirely standard C, and
>> it's not immediately obvious how going beyond the standard for the rest
>> of the compiler would help either.
>>
>> If there's no benefit for going outside what the standard provides,
>> wouldn't that be a reason to restrict it that far?

>
>The compiler could use multiple threads in an attempt to take advantage of
>todays multi-core processors,


Development tools are one of the (not too many these days) areas where
this doesn't make sense; any sensible developer with access to a
multi-core system (which have already been available to the general
public for a decade or so if you didn't mind the cores being on
separate physical CPUs) already has a build system set up that runs
multiple jobs in parallel to take advantage of it. Having individual
tools try to do the same just increases contention and breaks things.
So this is still a clear cost (a compiler targeting a widely ported VM
especially would benefit from avoiding non-portable features where it's
reasonable to do so) for a questionable benefit.

> or just for the fun of spreading the peanut
>butter on both sides of the slice of bread.


I want the tools I use to be written by somebody who's trying to build
good tools, not by somebody who's trying to show off. There are plenty
of other places to show off.


dave

 
Reply With Quote
 
Charlie Gordon
Guest
Posts: n/a
 
      11-16-2007
<(E-Mail Removed)> a écrit dans le message de news:
fha55f$at2$(E-Mail Removed)...
> In article <4734fd58$0$27292$(E-Mail Removed)>,
> Charlie Gordon <(E-Mail Removed)> wrote:
>><(E-Mail Removed)> a icrit dans le message de news:
>>fh25tq$opr$(E-Mail Removed)...
>>> In article <(E-Mail Removed)>,
>>> Charlton Wilbur <(E-Mail Removed)> wrote:
>>>
>>> [Talking aboutjavac, though the comments here apply just as much to
>>> any other compiler]
>>>>I expect the compiler can actually be written entirely in standard C,
>>>>although as a practical matter I don't see any reason to restrict it
>>>>that far.
>>>
>>> The things a compiler does are helped immensely by code generators for
>>> things like the tokenizer and the parser, but the generated code (and
>>> the generators themselves!) can very easily be entirely standard C, and
>>> it's not immediately obvious how going beyond the standard for the rest
>>> of the compiler would help either.
>>>
>>> If there's no benefit for going outside what the standard provides,
>>> wouldn't that be a reason to restrict it that far?

>>
>>The compiler could use multiple threads in an attempt to take advantage of
>>todays multi-core processors,

>
> Development tools are one of the (not too many these days) areas where
> this doesn't make sense; any sensible developer with access to a
> multi-core system (which have already been available to the general
> public for a decade or so if you didn't mind the cores being on
> separate physical CPUs) already has a build system set up that runs
> multiple jobs in parallel to take advantage of it. Having individual
> tools try to do the same just increases contention and breaks things.
> So this is still a clear cost (a compiler targeting a widely ported VM
> especially would benefit from avoiding non-portable features where it's
> reasonable to do so) for a questionable benefit.
>
>> or just for the fun of spreading the peanut
>>butter on both sides of the slice of bread.

>
> I want the tools I use to be written by somebody who's trying to build
> good tools, not by somebody who's trying to show off. There are plenty
> of other places to show off.


I agree completely on both counts. I was just giving examples of what
temptations tool developers might fall for, and make their tools non
portable.

--
Chqrlie.


 
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
posible minour buggs in dick heathfields book Nomen Nescio C Programming 0 10-27-2008 05:40 AM
Richard heathfields casting operation sophia.agnes@gmail.com C Programming 21 11-10-2007 07:31 PM
All programming related issues and you can submit ur own article also. john Java 2 12-30-2006 02:06 AM
Article: The Fine Art of Computer Programming Christophe Grandsire Ruby 1 09-17-2005 08:28 AM
Interesting article about concurrent programming, any thoughts? Sonoman C++ 3 01-20-2005 10:09 AM



Advertisments