A Philisophical Question

[stmilam]

Here are two different ways of accomplishing the same end:

to_len ? memmove(ptr, l_to, to_len), ptr += to_len : NULL;

or

if ( to_len ) {
memmove( ptr, l_to, to_len );
ptr += to_len;
}

I like the first one, but in light that not everyone grasps the ternary
and comma operators the second is more likely to make sense. Any other
ideas?

[Skarmander]

st*****@yahoo.com wrote:

Here are two different ways of accomplishing the same end:

to_len ? memmove(ptr, l_to, to_len), ptr += to_len : NULL;

or

if ( to_len ) {
memmove( ptr, l_to, to_len );
ptr += to_len;
}

I like the first one, but in light that not everyone grasps the ternary
and comma operators the second is more likely to make sense. Any other
ideas?

Yes, here's one: don't use statements as expressions just so you can be
terse.

Here's another one: instead of NULL, any other pointer expression would
do. The NULL is an arbitrary element, which should tell you that what
you're doing isn't right.

In short: use if for conditionally executing statements, that's what
it's there for. Use the ternary operator for conditionally evaluating
expressions, that's what that's there for. That you can mix and match in
C doesn't mean you should.

It's not a question of philosophy, it's a question of style.

S.

[Richard Tobin]

In article <11**********************@g47g2000cwa.googlegroups .com>,
<st*****@yahoo.com> wrote:

Here are two different ways of accomplishing the same end:

to_len ? memmove(ptr, l_to, to_len), ptr += to_len : NULL;

or

if ( to_len ) {
memmove( ptr, l_to, to_len );
ptr += to_len;
}

I like the first one, but in light that not everyone grasps the ternary
and comma operators the second is more likely to make sense. Any other
ideas?

The first one might be useful in a macro, so that it could be used in
an expression, but otherwise the meaningless return of a value reduces
the readability so much as to outweigh the terseness.

If all you want to do is save vertical space, then

if(to_len) {memmove(ptr, l_to, to_len); ptr += to_len;}

is clearer than the expression version and also shorter.

-- Richard

[pete]

Richard Tobin wrote:

In article <11**********************@g47g2000cwa.googlegroups .com>,
<st*****@yahoo.com> wrote:

Here are two different ways of accomplishing the same end:

to_len ? memmove(ptr, l_to, to_len), ptr += to_len : NULL;

or

if ( to_len ) {
memmove( ptr, l_to, to_len );
ptr += to_len;
}

I like the first one, but in light that not everyone grasps the
ternary
and comma operators the second is more likely to make sense.
Any other ideas?
The first one might be useful in a macro,

OK
so that it could be used in
an expression, but otherwise the meaningless return of a value reduces
the readability so much as to outweigh the terseness.

If all you want to do is save vertical space, then

if(to_len) {memmove(ptr, l_to, to_len); ptr += to_len;}

is clearer than the expression version and also shorter.

Once you start writing programs that don't fit on a screen,
it becomes obvious that the priority should be on improving
the clarity of what does fit on the screen.
I don't think there's much point in trying that hard
to save vertical space.

--
pete

[Peter Nilsson]

st*****@yahoo.com wrote:

Here are two different ways of accomplishing the same end:

to_len ? memmove(ptr, l_to, to_len), ptr += to_len : NULL;

or

if ( to_len ) {
memmove( ptr, l_to, to_len );
ptr += to_len;
}

I like the first one, but in light that not everyone grasps the ternary
and comma operators the second is more likely to make sense. Any other
ideas?

If l_to is always valid, what's wrong with just...?

memmove(ptr, l_to, to_len);
ptr += to_len;

--
Peter

[stmilam]

> I like the first one, but in light that not everyone grasps the ternary

and comma operators the second is more likely to make sense. Any other
ideas?

If l_to is always valid, what's wrong with just...?

memmove(ptr, l_to, to_len);
ptr += to_len;
--
Peter

Originally that is what I did, but l_to can be zero at times. To the
other commentators: Thanks! I just wanted other opinions. To me it is
not how terse the code is or how many lines. To me C is a very
expressive language. If one approaches C as just another computer
language they miss the beauty and expressiveness available to them.
English is a language, but not everyone writes it like, say Dylan
Thomas.

[pete]

st*****@yahoo.com wrote:

If l_to is always valid, what's wrong with just...?

memmove(ptr, l_to, to_len);
ptr += to_len;

--
Peter

Originally that is what I did, but l_to can be zero at times.

Then it should be

if (l_to != NULL) {
memmove(ptr, l_to, to_len);
ptr += to_len;
}

--
pete

[Kelsey Bjarnason]

On Tue, 08 Nov 2005 11:34:24 -0800, stmilam wrote:

Here are two different ways of accomplishing the same end:

to_len ? memmove(ptr, l_to, to_len), ptr += to_len : NULL;

or

if ( to_len ) {
memmove( ptr, l_to, to_len );
ptr += to_len;
}

I like the first one

I don't. While the ternary operator is common enough that it shouldn't be
too confusing, the inclusion of the comma operator, in a manner almost
"hidden", makes the whole thing vastly less readable than the latter.

Rule 1 of good coding: if it ain't clear, it's crap. Or something like
that. :)

[Skarmander]

st*****@yahoo.com wrote:

To me it is not how terse the code is or how many lines. To me C is
a very expressive language. If one approaches C as just another
computer language they miss the beauty and expressiveness available
to them.
If one does not approach C as just another computer language they miss
the opportunity for writing clear code. Beauty is in the eye of the
maintainer.
English is a language, but not everyone writes it like, say Dylan
Thomas.

English is good for writing poetry in; C is good for writing computer
programs in. If you can write a sort of poetry in C, that's great
(Obfuscated C Contest, anyone?) but that's not usually what programming
is about. Elegance in a program is a quality not usually propagated from
its syntax (though ugliness might be).

S.

[Keith Thompson]

Skarmander <in*****@dontmailme.com> writes:
[...]

English is good for writing poetry in; C is good for writing computer
programs in. If you can write a sort of poetry in C, that's great
(Obfuscated C Contest, anyone?) but that's not usually what
programming is about. Elegance in a program is a quality not usually
propagated from its syntax (though ugliness might be).

Obfuscated C Contest are the equivalent of poetry written entirely in
words you can't say on television. They're more pornographic than
poetic.

Not that that's a bad thing, of course.

Duff's device is poetic, I suppose.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Skarmander]

Keith Thompson wrote:

Skarmander <in*****@dontmailme.com> writes:
[...]

English is good for writing poetry in; C is good for writing computer
programs in. If you can write a sort of poetry in C, that's great
(Obfuscated C Contest, anyone?) but that's not usually what
programming is about. Elegance in a program is a quality not usually
propagated from its syntax (though ugliness might be).

Obfuscated C Contest are the equivalent of poetry written entirely in
words you can't say on television. They're more pornographic than
poetic.

I'd say that depends on the nature of obfuscation. This is poetic to me,
not pornographic:

#define _ F-->00 || F-OO--;
long F=00,OO=00;
main(){F_OO();printf("%1.3f\n", 4.*-F/OO/OO);}F_OO()
{
_-_-_-_
_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_
_-_-_-_
}
Not that that's a bad thing, of course.

Duff's device is poetic, I suppose.

It also captures the imagination by solving a problem in a practical
way, albeit one that's not universally applicable.

S.

[Peter Nilsson]

st*****@yahoo.com wrote:

I like the first one, but in light that not everyone grasps the ternary
and comma operators the second is more likely to make sense. Any other
ideas?
If l_to is always valid, what's wrong with just...?

memmove(ptr, l_to, to_len);
ptr += to_len;

Originally that is what I did, but l_to can be zero at times.

ITYM to_len, but I reply with... And?
To the other commentators: Thanks!
None to me though. I'll get over it, I'm sure...
I just wanted other opinions. To me it is not how terse the code is or how many lines.
To me C is a very expressive language. If one approaches C as just another computer
language they miss the beauty and expressiveness available to them.
The above sample is expressive to me. Ever heard of minimalist art?
Simplicity does not
mean blandness.
English is a language, but not everyone writes it like, say Dylan
Thomas.

And not everyone is willing to pay millions of (US) dollars for code
that looks like
Blue Poles by Jackson Pollock. Me included...

If you look at Mathematics, beauty is often not in the complexity or
simplicity, rather, it
tends to lie in the obvious truth.

If l_to is always valid, the behaviour of the code I posted is obvious
to me. So, again I ask...
What is wrong with it?

--
Peter

[Keith Thompson]

"Peter Nilsson" <ai***@acay.com.au> writes:

st*****@yahoo.com wrote:

> > I like the first one, but in light that not everyone grasps the
> > ternary and comma operators the second is more likely to make
> > sense. Any other ideas?
> If l_to is always valid, what's wrong with just...?
> memmove(ptr, l_to, to_len); ptr += to_len;

Originally that is what I did, but l_to can be zero at times.

ITYM to_len, but I reply with... And?

If the OP really meant that l_to can be zero at times, he probably
should have said that l_to can be a null pointer. If it is, the
memmove() call invokes undefined behavior; he needs to test
the value of l_to before calling memmove().

If he actually meant that to_len can be zero, there's no need to test
it; memmove() with a third argument of zero does nothing (which is
exactly what you want in that case).

I'm not going to try to guess what he actually meant.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[pete]

Peter Nilsson wrote:

st*****@yahoo.com wrote:

If l_to is always valid, what's wrong with just...?

memmove(ptr, l_to, to_len);
ptr += to_len;

Originally that is what I did, but l_to can be zero at times.

ITYM to_len, but I reply with... And?

To the other commentators: Thanks!

None to me though. I'll get over it, I'm sure...

You're the only one who read the code correctly.
Congratulations!!!

--
pete

[August Karlstrom]

st*****@yahoo.com wrote:

Here are two different ways of accomplishing the same end:

to_len ? memmove(ptr, l_to, to_len), ptr += to_len : NULL;
This is language obfuscation.
or

if ( to_len ) {
memmove( ptr, l_to, to_len );
ptr += to_len;
}
Say what you mean:

if (to_len != NULL) {
memmove(ptr, l_to, to_len);
ptr += to_len;
}
I like the first one, but in light that not everyone grasps the ternary
and comma operators the second is more likely to make sense. Any other
ideas?

There is nothing wrong with using the ternary operator as long as it is
used in a standard way, e.g.

z = (y < x)? a: b;

but your example is language abuse.
August

--
I am the "ILOVEGNU" signature virus. Just copy me to your
signature. This email was infected under the terms of the GNU
General Public License.

[Skarmander]

August Karlstrom wrote:

st*****@yahoo.com wrote:

<snip>

if ( to_len ) {
memmove( ptr, l_to, to_len );
ptr += to_len;
}

Say what you mean:

if (to_len != NULL) {
memmove(ptr, l_to, to_len);
ptr += to_len;
}

Please see 5.3 in the FAQ, and the question that leads to. Unlike the
use of the ternary operator in this case, using or not using NULL when
testing pointers is a stylistic issue that has no consensus.

S.

[pete]

Skarmander wrote:

August Karlstrom wrote:

st*****@yahoo.com wrote: <snip>

if ( to_len ) {

Say what you mean:

if (to_len != NULL) {

Unlike the
use of the ternary operator in this case, using or not using NULL when
testing pointers is a stylistic issue that has no consensus.

I used to like the first way, but now these days,
I've come to think
that the full meaning of the second way, is clearer.

--
pete

[Stan Milam]

Keith Thompson wrote:

"Peter Nilsson" <ai***@acay.com.au> writes: If the OP really meant that l_to can be zero at times, he probably
should have said that l_to can be a null pointer. If it is, the
memmove() call invokes undefined behavior; he needs to test
the value of l_to before calling memmove().

No, l_to is tested for NULL before the code I posted. I was just asking
a simple question.
If he actually meant that to_len can be zero, there's no need to test
it; memmove() with a third argument of zero does nothing (which is
exactly what you want in that case).
Yes, l_to can be zero at times. The reason I surrounded it with
conditional code is to avoid the overhead of setting up and calling an
external function which can be expensive on some systems.

I'm not going to try to guess what he actually meant.

[Tim Rentsch]

August Karlstrom <fu********@comhem.se> writes:

st*****@yahoo.com wrote:

[...]

if ( to_len ) {
memmove( ptr, l_to, to_len );
ptr += to_len;
}

Say what you mean:

if (to_len != NULL) {
memmove(ptr, l_to, to_len);
ptr += to_len;
}

The variable to_len is clearly supposed to be a length. It
shouldn't be compared to NULL. If we think the 'if' is
necessary, a test that makes more sense would be:

if( to_len > 0 ){
memmove( ptr, l_to, to_len );
ptr += to_len;
}

[August Karlstrom]

pete wrote:

Skarmander wrote:

August Karlstrom wrote:

st*****@yahoo.com wrote:

<snip>

if ( to_len ) {
Say what you mean:

if (to_len != NULL) {

Unlike the
use of the ternary operator in this case, using or not using NULL when
testing pointers is a stylistic issue that has no consensus.

I used to like the first way, but now these days,
I've come to think
that the full meaning of the second way, is clearer.

Same here. I see it as a light form of language abuse.
August

--
I am the "ILOVEGNU" signature virus. Just copy me to your
signature. This email was infected under the terms of the GNU
General Public License.

[August Karlstrom]

Tim Rentsch wrote:

The variable to_len is clearly supposed to be a length. It
shouldn't be compared to NULL. If we think the 'if' is
necessary, a test that makes more sense would be:

if( to_len > 0 ){
memmove( ptr, l_to, to_len );
ptr += to_len;
}

Yes, of course. I mixed it up with Pete's suggestion to use

if (l_to != NULL) {
memmove(ptr, l_to, to_len);
ptr += to_len;
}
August

--
I am the "ILOVEGNU" signature virus. Just copy me to your
signature. This email was infected under the terms of the GNU
General Public License.

[Skarmander]

August Karlstrom wrote:

pete wrote:

Skarmander wrote:

August Karlstrom wrote:

st*****@yahoo.com wrote:
<snip>

> if ( to_len ) {

Say what you mean:

if (to_len != NULL) {

Unlike the
use of the ternary operator in this case, using or not using NULL when
testing pointers is a stylistic issue that has no consensus.

I used to like the first way, but now these days, I've come to think
that the full meaning of the second way, is clearer.

Same here. I see it as a light form of language abuse.

C abuses itself by not having a `nil' keyword. You can pretend NULL is
that keyword for code you write yourself, of course, but since you'll
have to know the full story anyway to read existing code, it doesn't
help much. In any case, this is like brace style: you'll have to decide
for yourself, and as long as you're consistent with the environment
you're working in, it really doesn't matter.

S.

[August Karlstrom]

Skarmander wrote:

August Karlstrom wrote:
> Say what you mean:
>
> if (to_len != NULL) {

.... C abuses itself by not having a `nil' keyword. You can pretend NULL is
that keyword for code you write yourself, of course, but since you'll
have to know the full story anyway to read existing code, it doesn't
help much. In any case, this is like brace style: you'll have to decide
for yourself, and as long as you're consistent with the environment
you're working in, it really doesn't matter.

The symbol for the nil pointer is not the issue here. If p is a pointer
then I think `if (p != 0) ...' is perfectly OK although I prefer `if (p
!= NULL) ...".
August

--
I am the "ILOVEGNU" signature virus. Just copy me to your
signature. This email was infected under the terms of the GNU
General Public License.

[Skarmander]

August Karlstrom wrote:

Skarmander wrote:

> August Karlstrom wrote:
>
>> Say what you mean:
>>
>> if (to_len != NULL) {

...

C abuses itself by not having a `nil' keyword. You can pretend NULL is
that keyword for code you write yourself, of course, but since you'll
have to know the full story anyway to read existing code, it doesn't
help much. In any case, this is like brace style: you'll have to
decide for yourself, and as long as you're consistent with the
environment you're working in, it really doesn't matter.

The symbol for the nil pointer is not the issue here. If p is a pointer
then I think `if (p != 0) ...' is perfectly OK although I prefer `if (p
!= NULL) ...".

Ah, but *that* particular wart is the result of C not having a proper
boolean type. It all conspires. :-)

S.

[pete]

Skarmander wrote:

August Karlstrom wrote:

The symbol for the nil pointer is not the issue here.
If p is a pointer
then I think `if (p != 0) ...'
is perfectly OK although I prefer `if (p != NULL) ...".

Ah, but *that* particular wart is the result of C not having a proper
boolean type. It all conspires. :-)

My convention for using

if (x)

instead of

if (x != 0)

is when the meaning of x is boolean in it's nature.
In the below example, it's "while" instead of "if".

int a_toi(const char *nptr)
{
int n;

n = 0;
while (isspace(*nptr)) {
++nptr;
}
if (*nptr != '-') {
if (*nptr == '+') {
++nptr;
}
while (isdigit(*nptr)) {
n = 10 * n - '0' + *nptr++;
}
} else {
++nptr;
while (isdigit(*nptr)) {
n = 10 * n + '0' - *nptr++;
}
}
return n;
}
--
pete

[pete]

August Karlstrom wrote:

st*****@yahoo.com wrote:

if ( to_len ) {
memmove( ptr, l_to, to_len );
ptr += to_len;
}

Say what you mean:

if (to_len != NULL) {

YOU TRICKED ME!!!

--
pete

[August Karlstrom]

pete wrote:

My convention for using

if (x)

instead of

if (x != 0)

is when the meaning of x is boolean in it's nature.

Yes, that's certainly the correct way. It's a classical beginners
mistake is to compare a boolean (or in C an int with boolean
interpretation) with a boolean literal.
August

--
I am the "ILOVEGNU" signature virus. Just copy me to your
signature. This email was infected under the terms of the GNU
General Public License.