454,507 Members | 1,758 Online
Need help? Post your question and get tips & solutions from a community of 454,507 IT Pros & Developers. It's quick & easy.

# A Philisophical Question

 P: n/a 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? Nov 15 '05 #1
26 Replies

 P: n/a 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. Nov 15 '05 #2

 P: n/a In article <11**********************@g47g2000cwa.googlegroups .com>, wrote: Here are two different ways of accomplishing the same end:to_len ? memmove(ptr, l_to, to_len), ptr += to_len : NULL;orif ( to_len ) { memmove( ptr, l_to, to_len ); ptr += to_len;}I like the first one, but in light that not everyone grasps the ternaryand comma operators the second is more likely to make sense. Any otherideas? 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 Nov 15 '05 #3

 P: n/a Richard Tobin wrote: In article <11**********************@g47g2000cwa.googlegroups .com>, wrote:Here are two different ways of accomplishing the same end:to_len ? memmove(ptr, l_to, to_len), ptr += to_len : NULL;orif ( to_len ) { memmove( ptr, l_to, to_len ); ptr += to_len;}I like the first one, but in light that not everyone grasps the ternaryand 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 Nov 15 '05 #4

 P: n/a 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 Nov 15 '05 #5

 P: n/a > 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. Nov 15 '05 #6

 P: n/a 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 Nov 15 '05 #7

 P: n/a 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. :) Nov 15 '05 #8

 P: n/a 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. Nov 15 '05 #9

 P: n/a Skarmander 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 San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Nov 15 '05 #10

 P: n/a Keith Thompson wrote: Skarmander writes: [...]English is good for writing poetry in; C is good for writing computerprograms in. If you can write a sort of poetry in C, that's great(Obfuscated C Contest, anyone?) but that's not usually whatprogramming is about. Elegance in a program is a quality not usuallypropagated 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. Nov 15 '05 #11

 P: n/a 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 Nov 15 '05 #12

 P: n/a "Peter Nilsson" 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 San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Nov 15 '05 #13

 P: n/a 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 Nov 15 '05 #14

 P: n/a 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. Nov 15 '05 #15

 P: n/a 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) { 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. Nov 15 '05 #16

 P: n/a Skarmander wrote: August Karlstrom wrote: st*****@yahoo.com wrote: 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 Nov 15 '05 #17

 P: n/a Keith Thompson wrote: "Peter Nilsson" 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. Nov 15 '05 #18

 P: n/a August Karlstrom 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; } Nov 15 '05 #19

 P: n/a pete wrote: Skarmander wrote:August Karlstrom wrote:st*****@yahoo.com wrote:if ( to_len ) {Say what you mean: if (to_len != NULL) {Unlike theuse of the ternary operator in this case, using or not using NULL whentesting 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. Nov 15 '05 #20

 P: n/a 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. Nov 15 '05 #21

 P: n/a August Karlstrom wrote: pete wrote: Skarmander wrote: August Karlstrom wrote: st*****@yahoo.com wrote: > 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. Nov 15 '05 #22

 P: n/a 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. Nov 15 '05 #23

 P: n/a 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. Nov 15 '05 #24

 P: n/a 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 Nov 15 '05 #25

 P: n/a 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 Nov 15 '05 #26

 P: n/a 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. Nov 15 '05 #27

### This discussion thread is closed

Replies have been disabled for this discussion.