Richard heathfields C programming article

[dj3vande]

D> In article <[email protected]>,

D> [Talking about javac, though the comments here apply just as
D> much to any other compiler]

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

 

[Richard Heathfield]

Ben Pfaff said:

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.

 

[CBFalconer]

.... snip ...


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.

 

[Charlie Gordon]

[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.

 

[Keith Willis]

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 bollocks!', we prefer the
phrase 'Sadly that turns out not to be the case'"

 

[Richard Heathfield]

Keith Willis said:

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 bollocks!', 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.

 

[dj3vande]

[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

 

[Charlie Gordon]

[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.