C language paradox

[Nomen Nescio]

"A colleague and I drove our boss nuts by ..."

"A colleague and I did a drive-by on our boss, bye-bye"

 

[Kaz Kylheku]

"Me ... drove (my) boss nuts" ?

(me and a colleague) drove (our) boss nuts.

The pronoun "our" has a clear antecedent in the plural compound "me and a
colleague".

Your way works also, because "my" can be used without an antecedent; it refers
to the narrator himself or herself.

 

[army1987]

Get a faster computer. It shouldn't take that long to write 100 or 200
empty lines. (Unless you have a test harness that you haven't shown
us.)

IIRC stdout is required to be unbuffered or fully buffered when an
interactive terminal, so the lines are written one at a time, and 3.8
milliseconds doesn't sound like *that* long for the overhead of actually
doing output.

 

[army1987]

IIRC stdout is required to be unbuffered or fully buffered when an
interactive terminal, so the lines are written one at a time, and 3.8
milliseconds doesn't sound like *that* long for the overhead of actually
doing output.

(Yes it is. I've tried it and it does take about 300 times shorter than
that on my laptop.)

 

[Eric Sosman]

IIRC stdout is required to be unbuffered or fully buffered when an
interactive terminal, so the lines are written one at a time, and 3.8
milliseconds doesn't sound like *that* long for the overhead of actually
doing output.

3.8 milliseconds might be fairly good, but what would
you think of 380?

Besides, I think you're confused about the kinds of buffering,
and about the requirements on the buffering of stdout:

- The three styles of output buffering defined in the Standard
are "unbuffered" (transmit each new character ASAP), "line
buffered" (retain characters until a newline, then transmit
the whole thing at once), and "fully buffered" (retain an
entire block of characters and transmit when the block fills).

- At program startup, stdout is fully buffered "if the stream
can be determined not to refer to an interactive device,"
otherwise the buffering is unspecified.

So: (1) If stdout is directed to an interactive device the one thing
we're sure of is that it is *not* fully buffered, and (2) if it were
fully buffered it's unlikely that lines would be transmitted intact.

 

[Keith Thompson]

(Yes it is. I've tried it and it does take about 300 times shorter than
that on my laptop.)

On my system, both versions of the loop took too little time to measure
(using the "time" command).

 

[Robert Miles]

On 3/3/2012 9:05 PM, Geoff wrote:
[... time / relativity ...]

But when considering clocks in orbit vs. clocks on earth one has to
account for the "acceleration" of the clocks on the surface of the
earth due to gravity and the lesser acceleration of an object in orbit
where the gravity field is weaker as well as the relative velocity of
the clock on orbit.

But this analogy is completely inapplicable to a "C language paradox".

Does "for(;;" complete sooner on the system in orbit, or on the
Earth's surface?

Depends heavily on the speed of systems you can put in orbit
versus the speed of systems you can use on the Earth's surface.

Robert Miles

 

[88888 Dihedral]

Keith Thompsonæ–¼ 2012å¹´3月6日星期二UTC+8上åˆ1時35分29秒寫é“：

On my system, both versions of the loop took too little time to measure
(using the "time" command).

--
Keith Thompson (The_Other_Keith) (e-mail address removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

I think for a program to perform text i/o in programs that generates 32 interrupts in one second is more than enough of line based texts.


A buffered text I/O function upto 16 times of interrupts per second to show something is faster than the 32 times version.