C question...little OT

[Army1987]

Which means that the standard's description of string.h
was written by gurus,
and that the standard's description of stdlib.h
was written by neophytes.

void *memset(void *s, int c, size_t n;

void *bsearch(const void *key, const void *base,
size_t nmemb, size_t size,
int (*compar)(const void *, const void *));

Either that, or your comment is silly.

If you count how many vowels are used in function names in
string.h, and how many ones in stdlib.h, you might have some
insight of why they needed gurus for the former but normal people
sufficed for the latter.

 

[shadowman]

Stroustrup once suggested that [now we have unicode] function names
should all be one character but have a different colour to indicate
their use. So you could have 256 functions called A()
I strongly doubt that.

I was there when he said it. However did you miss the caveat?

Stroustrupis not a fool (for all that he
designed C++ ;-) ) and he is certainly not stupid enough to confuse
character sets with colour.

You had to have been there really.

B Stroustrup: Generalizing Overloading for C++2000. Overload, Issue
25. April 1, 1998. Note the date. http://www.research.att.com/~bs/whitespace98.pdf

-- Bjarne Stroustrup; http://www.research.att.com/~bs

That made my day!

 

[David T. Ashley]

To wit, real gurus use one-letter names.

Yes and no.

Most individuals and organizations go through a phase where the believe that
more documentation will solve every problem in the universe. Individuals
usually outgrow this.

One has to make a decision about comments, for example: is it necessary to
document something a person should know or would immediately figure out?

For example, these comments add no value.

#define MAX (2) /* MAX is now 2 */
for (i=0; i<MAX; i++) /* For each i, 0..MAX-1 */

Some comments actually add negative value: it takes unnecessary work to
compare the comment to the code.

K&R, just by the design of the C language, had reached the point where they
realized that typing for the sake of typing adds no value. The "{" and "}"
block delimiters in C are pure genius (compared to the "begin" and "end" of
Pascal). Similarly with +=, ++, /=, ^, etc.

It is the same for function parameters ... "s" and "t" are fine. It adds no
value to say "source" and "target".

And even for a formal parameter that is more complex, I'd be more likely to
add a comment than to type the same long name over and over again. For
example:

/* INPUTS
** gpa : grade point average
** nfa: number of fireworks accidents
** asm: Lifetime number of Arnold Schwarzenegger movies watched.
**
** OUTPUT
** [0,1], probability that the individual is an idiot.
*/
double compute_probability_of_being_an_idiot(double gpa, int nfa, int asm)

 

[Keith Thompson]

For example, these comments add no value.

#define MAX (2) /* MAX is now 2 */
for (i=0; i<MAX; i++) /* For each i, 0..MAX-1 */

Even worse:

for (i=0; i<MAX; i++) /* For each i, 0..MAX */

[...]

It is the same for function parameters ... "s" and "t" are fine. It adds no
value to say "source" and "target".

But it might add value to say "target" and "source". It's not obvious
that the target is the first parameter of strcpy() (unless you know
that it mirrors the order in an assignment statement).

 

[Army1987]

Yes and no.

Most individuals and organizations go through a phase where the believe that
more documentation will solve every problem in the universe. Individuals
usually outgrow this.

One has to make a decision about comments, for example: is it necessary to
document something a person should know or would immediately figure out?

For example, these comments add no value.

#define MAX (2) /* MAX is now 2 */
for (i=0; i<MAX; i++) /* For each i, 0..MAX-1 */

Some comments actually add negative value: it takes unnecessary work to
compare the comment to the code.

K&R, just by the design of the C language, had reached the point where they
realized that typing for the sake of typing adds no value. The "{" and "}"
block delimiters in C are pure genius (compared to the "begin" and "end" of
Pascal). Similarly with +=, ++, /=, ^, etc.

It is the same for function parameters ... "s" and "t" are fine. It adds no
value to say "source" and "target".

Too bad that, in that prototype of strcpy(), s stood for target
and t stood for source.

And even for a formal parameter that is more complex, I'd be more likely to
add a comment than to type the same long name over and over again. For
example:

Agreed. One is more likely to misspell representation than repr,
for example.

/* INPUTS
** gpa : grade point average
** nfa: number of fireworks accidents
** asm: Lifetime number of Arnold Schwarzenegger movies watched.
**
** OUTPUT
** [0,1], probability that the individual is an idiot.
*/
double compute_probability_of_being_an_idiot(double gpa, int nfa, int asm)

Why did you need such a long name? Wouldn't idiocy_chance() be ok?

 

[Flash Gordon]

Army1987 wrote, On 06/07/07 20:08:

On Fri, 06 Jul 2007 12:19:03 -0400, David T. Ashley wrote:

Too bad that, in that prototype of strcpy(), s stood for target
and t stood for source.

No, s stands for "stick it 'ere" and t stands for "take it from 'ere".
You not learnt English proper? ;-)

Agreed. One is more likely to misspell representation than repr,
for example.

There is a balance to be struck, as in all things. How do I know "repr"
isn't the "reprisal" flag?

 

[Army1987]

Army1987 wrote, On 06/07/07 20:08:

No, s stands for "stick it 'ere" and t stands for "take it from 'ere".
You not learnt English proper? ;-)


There is a balance to be struck, as in all things. How do I know "repr"
isn't the "reprisal" flag?

void printrepr(sometype *obj)
{
unsigned char[sizeof *obj]; /* representation */
...
}
or:
damage_t revenge(enemy_t *enemy, damage_t damage)
{
static int repr = 0; /* reprisal */
...
}
(But you'd need longer names if you plan to use both in the same
scope...)

 

[Richard Bos]

Stroustrup once suggested that [now we have unicode] function names
should all be one character but have a different colour to indicate
their use. So you could have 256 functions called A()

I strongly doubt that.

I was there when he said it. However did you miss the caveat?

I didn't miss a caveat, because there was none. Neither did I miss the
smiley, but since smilies can mean anything from "he didn't mean that"
through "I didn't mean that" and "he did mean it and I thought it was
funny" to "this makes me happy", I could not draw any conclusion from
it.

B Stroustrup: Generalizing Overloading for C++2000. Overload, Issue
25. April 1, 1998. Note the date.

This, however, is quite conclusive. ( (fourth meaning))

Richard