srand(time(NULL))

[Richard]

Keith Thompson said:

I'd say [Henry Spencer's] 4th and 9th commandments are similarly
obsolete. The 8th
(which mandates K&R brace style) is something that I *wish* everyone
obeyed,

Fortunately, your wishing well is broken. K&R style is *dire*.

Cue the Brace Wars.

<snip>

K&R style is easily the most maintainable and easiest on the eye I have
ever used. It just "makes sense. header, body, footer. e.g

if(expr){
expr;
}

 

[Ioannis Vranos]

Keith Thompson said:

I'd say [Henry Spencer's] 4th and 9th commandments are similarly
obsolete. The 8th
(which mandates K&R brace style) is something that I *wish* everyone
obeyed,

Fortunately, your wishing well is broken. K&R style is *dire*.

Cue the Brace Wars.

<snip>

K&R style is easily the most maintainable and easiest on the eye I have
ever used. It just "makes sense. header, body, footer. e.g

if(expr){
expr;
}

LOL. I prefer the "more sense" to me

if(expr)
{
/* ... */
}

style.

 

[Ioannis Vranos]

It's very odd to see the cast in the online FAQ, because the text
version that I keep on my local file system, which says it was
last modified February 7, 1999, omits the cast. Odd that it was
apparently (re?)introduced after that.

I should really update my local copy.

Perhaps he formatted his hard disk at some time, and his backup was a
bit old...

 

[santosh]

Keith Thompson said:

<snip>
I'd say [Henry Spencer's] 4th and 9th commandments are similarly
obsolete. The 8th
(which mandates K&R brace style) is something that I *wish*
everyone obeyed,
Fortunately, your wishing well is broken. K&R style is *dire*.

Cue the Brace Wars.

<snip>

K&R style is easily the most maintainable and easiest on the eye I
have ever used. It just "makes sense. header, body, footer. e.g

if(expr){
expr;
}

LOL. I prefer the "more sense" to me

if(expr)
{
/* ... */
}

style.

This tends to waste vertical space. I tend to prefer your style for
function's opening and closing brace and use the K&R style for other
purposes, except for code blocks.

foo()
{
if (condition) {
/* ... */
}
else {
/* ... */
}

{
/* some code */
}

return;
}

 

[Ioannis Vranos]

>

This tends to waste vertical space.

More space sometimes means more readable.

I tend to prefer your style for
function's opening and closing brace and use the K&R style for other
purposes, except for code blocks.

foo()
{
if (condition) {
/* ... */
}
else {
/* ... */
}

{
/* some code */
}

return;
}

I like complete consistency myself. You know how this stuff goes,
everyone has his/her style.

 

[Richard Heathfield]

santosh said:

I prefer the "more sense" to me

This tends to waste vertical space.

That's the disadvantage (for those who consider it so, of whom I am not
one). The advantage (for those who consider it so, of whom I am very
definitely one) is that the braces very obviously line up with each other,
visually reinforcing one's perception of the block scope.

<snip>

 

[Default User]

santosh said:



That's the disadvantage (for those who consider it so, of whom I am
not one).

Yeah, I was unaware that vertical space was in short supply.

The advantage (for those who consider it so, of whom I am
very definitely one) is that the braces very obviously line up with
each other, visually reinforcing one's perception of the block scope.

My personal preference is Whitesmiths style:

if(exp)
{
/* code */
}

The braces are part of the compound statement, and I like them at the
same indent level as the code.

Alas, the coding standard we use these days prefers your style, so I'm
shifting even my personal code to that style.




Brian

 

[Bill Cunningham]

Reference: <http://www.lysator.liu.se/c/ten-commandments.html>,
written by Henry Spencer.

The original version of this fine document was written, I believe,
before the existence of ANSI C. The Third Commandment is:

Thou shalt cast all function arguments to the expected type if
they are not of that type already, even when thou art convinced
that this is unnecessary, lest they take cruel vengeance upon thee
when thou least expect it.

The newer annotation reads, in part:

It may be thought that the radical new blessing of ``prototypes''
might eliminate the need for caution about argument types. Not so,
brethren. Firstly, when confronted with the twisted strangeness of
variable numbers of arguments, the problem returns... and he who
has not kept his faith strong by repeated practice shall surely
fall to this subtle trap. Secondly, the wise men have observed
that reliance on prototypes doth open many doors to strange
errors, and some indeed had hoped that prototypes would be decreed
for purposes of error checking but would not cause implicit
conversions. Lastly, reliance on prototypes causeth great
difficulty in the Real World today, when many cling to the old
ways and the old compilers out of desire or necessity, and no man
knoweth what machine his code may be asked to run on tomorrow.

This was good advice *at the time it was written*. Today, C compilers
that don't support prototypes are vanishingly rare, and this advice is
IMHO obsolete. You still need to be careful when calling variadic
functions; for example, when passing a pointer to printf with the "%p"
format, you should cast it to void*. (Quibbles: If it's already
void*, you don't need to cast it; if it's char*, you can probably get
away without casting it, but you should anyway; if it's a function
pointer, you can't portably print it with "%p" with or without a
cast.)

snip

Keith this wouldn've worked before c99. What did people do before C99 ? In
C89 if I'm right there was no time.h or time_t type. This answers a previous
question of mine.

Bill

 

[Harald van Dijk]

In C89 if I'm right there was no time.h or time_t type.

Both the <time.h> header and the time_t type are present in C89.

 

[Randy Howard]

Yeah, I was unaware that vertical space was in short supply.

Somewhere, in a dark whole, is someone still left on an 80x25 terminal.


Get a widescreen monitor that supports rotation, and run it vertically.
All the vertical space you need and then some.

 

[Antoninus Twink]

Alas, the coding standard we use these days prefers your style, so I'm
shifting even my personal code to that style.

There's no way in hell you're a professional programmer bound by any
coding standard at all - with your idiotic attitude you'd be drummed out
of any shop I've ever experienced before you could say "don't top post".

 

[Gordon Burditt]

Is srand(time(NULL)); an effective solution for seeding rand(), or is

there any better approach?

If you use this approach to generate random numbers for a game of chance
(such as, say, blackjack or craps) and make it available to the public
to play for real money, you're going to go bankrupt.

This is true for this method of seeding _any_ pseudo-random number
generator.

 

[Ioannis Vranos]

If you use this approach to generate random numbers for a game of chance
(such as, say, blackjack or craps) and make it available to the public
to play for real money, you're going to go bankrupt.

This is true for this method of seeding _any_ pseudo-random number
generator.

What is your suggestion?

 

[Peter Nilsson]

Reference: <http://www.lysator.liu.se/c/ten-commandments.html>,
written by Henry Spencer.

The original version of this fine document was written,
I believe, before the existence of ANSI C.  The Third
Commandment is:

    Thou shalt cast all function arguments to the expected
type if they are not of that type already, even when
thou art convinced that this is unnecessary, lest they
take cruel vengeance upon thee when thou least expect
it.

The newer annotation reads, in part:

    It may be thought that the radical new blessing of
``prototypes'' might eliminate the need for caution
about argument types. Not so, brethren. Firstly, when
confronted with the twisted strangeness of variable
numbers of arguments, the problem returns... and he
who has not kept his faith strong by repeated practice
shall surely fall to this subtle trap. Secondly, the
wise men have observed that reliance on prototypes
doth open many doors to strange errors, and some
indeed had hoped that prototypes would be decreed for
purposes of error checking but would not cause
implicit conversions. Lastly, reliance on prototypes
causeth great difficulty in the Real World today, when
many cling to the old ways and the old compilers out
of desire or necessity, and no man knoweth what
machine his code may be asked to run on tomorrow.

This was good advice *at the time it was written*.
 Today, C compilers that don't support prototypes are
vanishingly rare, and this advice is IMHO obsolete.

Although the commandment talks about parameters, I can't
help but notice the parallels with advice given to those
who cast malloc in clc.

No conforming compiler is allowed to _enforce_ prototypes,
but those who deliberately prefer to use compilers with
broken conformance in this regard are chastised heavily
for doing so.

 

[santosh]

Bill Cunningham wrote:

Keith this wouldn've worked before c99. What did people do before C99?
In C89 if I'm right there was no time.h or time_t type. This answers
a previous question of mine.

No, both time.h and time_t were there in C89. And the same method that
Keith explained will work for all versions of standard C.

 

[Gordon Burditt]

Is srand(time(NULL)); an effective solution for seeding rand(), or is

What is your suggestion?

Use specialized (and probably expensive) hardware based on physics
that is currently believed to be true random due to quantum effects.
This includes things like detection of radioactive decay and thermal
noise of a reverse-biased diode. Some processors (certain models
of Intel Pentium) have this built in, but I'm not sure how good it
is.

Also, use a seed much bigger than 32 bits. And you probably want to
use the time down to picoseconds.

Keystroke timing probably doesn't alone provide enough randomness
for online gambling with real money.

 

[Morris Dovey]

Somewhere, in a dark whole, is someone still left on an 80x25 terminal.

Hmm. I see a light up there. Hellooo?

The link below leads to my latest project. Scroll to the bottom
of the page...

:-D

 

[Default User]

Somewhere, in a dark whole, is someone still left on an 80x25
terminal.

I still use them when I telnet in places. That just seems the "right"
size for that.




Brian

 

[santosh]

Hmm. I see a light up there. Hellooo?

The link below leads to my latest project. Scroll to the bottom
of the page...

Well, for my personal programming I prefer 80x25 text mode, because I
find that it minimises eye strain. I also prefer text mode due to long
years with DOS and UNIX (without X).

Most workplaces here are still full of old CRTs with terrible flicker,
set inappropriately to something like 1024x768, minimising the refresh
rate.

 

[Richard Tobin]

Somewhere, in a dark whole, is someone still left on an 80x25
terminal.

[/QUOTE]

I still use them when I telnet in places. That just seems the "right"
size for that.

It was too small 30 years ago and it's too small now.

-- Richard