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]

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]

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]

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.

 

[Peter Nilsson]

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;

 

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

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

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

Then it should be

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

 

[Kelsey Bjarnason]

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]

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]

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.

 

[Skarmander]

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]

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?

 

[Keith Thompson]

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.

 

[pete]

(e-mail address removed) wrote:

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


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

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

 

[August Karlstrom]

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

 

[Skarmander]

(e-mail address removed) wrote:


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]

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.

 

[Stan Milam]

"Peter Nilsson" <[email protected]> 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.

 

[Tim Rentsch]

(e-mail address removed) 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]

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