integers to binary

[Mark McIntyre]

On 14 Dec 2005 03:51:59 -0800, in comp.lang.c , Tim Rentsch

(on the topic of the 'niceness' of)

buffer = (n & j) == j ? '1' : '0';

The original single assignment is precisely the sort of situation
where using the ?: operator makes sense.

Perhaps, once suitably parenthesised so that future maintenance drones
can understand it easily and w/o recourse to a manual of operator
precedence.
And it'd be a bit different if it were

foobar = (banana(12,34,pip(),333, printf("hello"))&&z)==blabla(bl,pl,
ypr)?pfngetarraycnt(yaddayadda,4) : atoi(getstringfrom(ww));

which is technically also a single assignment.

If Mr. McIntyre says he
finds the if/else form with two assignments more readable, I'm expect
that's so, but his reaction isn't shared by everyone.

Of course. Some people /like/ obfuscated code

IMO the
single assignment using ?: is both more readable and more clear
than using if/else and two assignments.

YMMV.

 

[Chuck F.]

"Pieter Droogendijk" <[email protected]> wrote:

.... snip ...

This expression could be nicer. How's this:

if ( (n & j) == j ) {
buffer = '1';
}
else {
buffer = '0';
}

I agree that to some it's more readable, but as it's more lines
of code, and duplicates the assignment etc, I think it's more
prone to errors later - like if someone changes it.

Sure it's six lines for what could be one assignment, but it's
as clear as it's going to get. That's what I aim for, Unless
obfuscation is what I want.

How about:

if ((n & j) == j) buffer = '1';
else buffer = '0';

Just a matter of style. Fairly hard to misread.

More important is the meaning of "(n & j) == j", which expresses
the assertion that all bits set in j are set in n. Thus another
alternative could be:

buffer = '0' + ((n & j) == j);

All this exposes some possible portability problems, dependent on
the types of n and j.

 

[Dave Thompson]

On Tue, 13 Dec 2005 19:06:40 +0000, Mark McIntyre

IME readable code is considerably easier to maintain than unreadable
code. Write for readability first. Consider clever tricks only if
trying to obfuscate code.

if ( (n & j) == j )
buffer='1';
else
buffer='0';

<snip: rather than conditional aka 'ternary' expression>

Agree on the principle, disagree strongly on the result.

The conditional operator in C is not obfuscation when it matches the
operation you want to perform, and here that fact that we want to put
one or another digit value in the _same_ output location is important.

What about (slightly sanitized from code I've worked on):
if( (n & j) == j )
currentOutputPtr->outputControl.workingbuffer[1].byte = '1';
else
currentOutputPtr->outputControl.workingbuffer[1].byte = '0';

Or suppose it were octal:
if( ( inputField.workingvalue4 >> shiftthisdigit & 7) == 0 )
currentOutputPtr->outputControl.workingbuffer[1].byte = '0';
else if( ( inputField.workingvalue4 >> shiftthisdigit & 7) == 1 )
currentOutputPtr->outputControl.workingbuffer[1].byte = '1';
and so on up to 7

and during maintenance you need to change to use workingbuffer[3]
will you get it right -- or if not, easily see, or test, the error?

Do you consider some_long[and].complicated->expression += 1
to be obfuscated for some_long[and].complicated->expression
= some_long[and].complicated->expression + 1? AFAIK compound
assignments are unique to the C family among HLLs.

In fact, what I would consider obfuscated is the (n & j) == j part. In
the example upthread j is always one bit and to me the natural way of
expressing "the/any bit on" is (n & j) != 0 -- or in a boolean context
like this just (n & j), but that's a whole 'nother argument.
To me (n & j) == j implies that we are at least sometimes looking for
multiple bits, and then I find it at least as clear to deMorganize to
"no masked bits off" and write !(~n & j) .

DG(N?)D.

- David.Thompson1 at worldnet.att.net

 

[Mark McIntyre]

On Tue, 13 Dec 2005 19:06:40 +0000, Mark McIntyre


Agree on the principle, disagree strongly on the result.

Thats fine - I was advocating readability rather than removal of the
ternary operator.

The conditional operator in C is not obfuscation when it matches the
operation you want to perform,

Cautiously agree, with caveat that examples the other way are easy to
find too.

(snip examples of where ternary would be considerably clearer)

 

[Dik T. Winter]

> > On Tue, 13 Dec 2005 10:21:09 +0000, rayw wrote: ....

> >> buffer = (n & j) == j ? '1' : '0';

> >
> > This expression could be nicer. How's this:
> >
> > if ( (n & j) == j ) {
> > buffer = '1';
> > }
> > else {
> > buffer = '0';
> > }

>
> I agree that to some it's more readable, but as it's more lines of code, and
> duplicates the assignment etc, I think it's more prone to errors later -
> like if someone changes it.

Why not just: buffer = (n & j) == j;
?

>
> Thanks for the ref and the comments.

I think itoa expects an int and you pass it a (probably) signed char.
You ought to know how a signed char with a negative value is passed
in a position where an int is expected.

 

[Dik T. Winter]

> > > On Tue, 13 Dec 2005 10:21:09 +0000, rayw wrote: > ...
> > >> buffer = (n & j) == j ? '1' : '0';
> > >
> > > This expression could be nicer. How's this:
> > >
> > > if ( (n & j) == j ) {
> > > buffer = '1';
> > > }
> > > else {
> > > buffer = '0';
> > > }

> >
> > I agree that to some it's more readable, but as it's more lines of code, and
> > duplicates the assignment etc, I think it's more prone to errors later -
> > like if someone changes it.

>
> Why not just: buffer = (n & j) == j;
> ?

Sorry, an error. Should be: buffer = ((n & j) == j) + '0';

 

[pete]

"Pieter Droogendijk" <[email protected]>
wrote in message

'0';

This expression could be nicer. How's this:

if ( (n & j) == j ) {
buffer = '1';
}
else {
buffer = '0';
}

I agree that to some it's more readable,
but as it's more lines of code, and
duplicates the assignment etc,
I think it's more prone to errors later -
like if someone changes it.

Why not just: buffer = (n & j) == j;
?

The above examples indicate that he wants
either a '1' or '0' in buffer,
rather than either a 1 or 0.

 

[Tim Rentsch]

On 14 Dec 2005 03:51:59 -0800, in comp.lang.c , Tim Rentsch

(comparison of using if/else or ?: for assigning to buffer)

If Mr. McIntyre says he
finds the if/else form with two assignments more readable, I'm expect
that's so, but his reaction isn't shared by everyone.

Of course. Some people /like/ obfuscated code

Everyone's entitled to an opinion. IME, however, those
who express opinions and little else, and who don't bother
to differentiate between what is opinion and what is fact,
rarely say anything worth listening to.

 

[Chuck F.]

(comparison of using if/else or ?: for assigning to buffer)

If Mr. McIntyre says he finds the if/else form with two
assignments more readable, I'm expect that's so, but his
reaction isn't shared by everyone.

Of course. Some people /like/ obfuscated code

Everyone's entitled to an opinion. IME, however, those who
express opinions and little else, and who don't bother to
differentiate between what is opinion and what is fact, rarely
say anything worth listening to.

In these style matters, all is opinion. The fact is that the
opinions vary in close correlation with the language flavor on
which one has been brought up. Users of languages without esoteric
symbol reuse (such as Pascal) will almost always eschew funny
statements involving question marks and colons. In the long run it
shouldn't matter, since a moderately intelligent compiler will
produce the same object code for either style.

 

[Mark McIntyre]

In these style matters, all is opinion. ....
In the long run it
shouldn't matter, since a moderately intelligent compiler will
produce the same object code for either style.

I guess my /opinion/ is that you don't write code to be legible by
the compiler, but by the maintenance droid in 3 years time. And for
anyone who says maintenance droids ought to be smart enough to figure
out your code, I direct your attention to the sig below.

Mark McIntyre

 

[Chuck F.]

I guess my /opinion/ is that you don't write code to be legible
by the compiler, but by the maintenance droid in 3 years time.
And for anyone who says maintenance droids ought to be smart
enough to figure out your code, I direct your attention to the
sig below.

My, you got out of the wrong side of the bed this morning. Has the
cat recovered from the kicking? I didn't even take a position on
which code style was preferable, just pointed out the background
that influences the choice. You snipped that part.

 

[kleuske]

Mark McIntyre schreef:

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

Words to code by.

 

[Mark McIntyre]

Mark McIntyre wrote:

(stuff which chuck interpreted as a diatribe against him (if one can
have a personal diatribe) but which wasn't)

My, you got out of the wrong side of the bed this morning. Has the
cat recovered from the kicking?

Its Christmas. I've had to suffer a week of all three children in
hyperdrive mode, the aged relatives in dribble mode, and several wooly
jumpers from my aunties.... :-(

I didn't even take a position on
which code style was preferable, just pointed out the background
that influences the choice. You snipped that part.

Actually I didn't intend anything I said as any sort of attack on what
you said, I was merely stating my opinion.
Mark McIntyre

 

[Tim Rentsch]

(comparison of using if/else or ?: for assigning to buffer)

If Mr. McIntyre says he finds the if/else form with two
assignments more readable, I'm expect that's so, but his
reaction isn't shared by everyone.

Of course. Some people /like/ obfuscated code

Everyone's entitled to an opinion. IME, however, those who
express opinions and little else, and who don't bother to
differentiate between what is opinion and what is fact, rarely
say anything worth listening to.

In these style matters, all is opinion. [snip]

In discussing questions about style, some people express
only opinion. But that doesn't mean opinion is all there
is. For example, doing bracing this way

if(...)
{
...
}

rather than this way

if(...){
...
}

takes more vertical space. (Or, if someone prefers, the
second form takes less vertical space.) That observation is
a fact. As another example, consider these alternatives for
placing close braces (open braces omitted):

if(...)
...
...
...
}


if(...)
...
...
...
}

Studies have been done that show the second form results in
fewer errors. That is another fact (ie, that the studies
reported those results).

How pertinent such facts are, and how much weight (and on
which side of the scale) should be given to them, depends on
the situation, and different people - or different
circumstances - may very well arrive at different
conclusions. Even so, unless some statements of fact are
included in the discussion, the discussion is usually not
very fruitful. "I think X." "I think Y." "So what?" "So
what?"

In the long run it
shouldn't matter, since a moderately intelligent compiler will
produce the same object code for either style.

I have to admit I didn't see this one coming. Surely most
people have other and better metrics for code quality than
only what object code is produced.

 

[Mark McIntyre]

On 29 Dec 2005 20:02:04 -0800, in comp.lang.c , Tim Rentsch

(of other different bracing examples)

Studies have been done that show the second form results in
fewer errors.

Studies also recently showed that twice as many people would jump off
a ship to rescue their hat as would do it to rescue their spouse. That
doesn't mean its true...

That is another fact (ie, that the studies
reported those results).

Indeed, its a fact that a study has been done.


Mark McIntyre

 

[Al Balmer]

On 29 Dec 2005 20:02:04 -0800, in comp.lang.c , Tim Rentsch

(of other different bracing examples)


Studies also recently showed that twice as many people would jump off
a ship to rescue their hat as would do it to rescue their spouse. That
doesn't mean its true...

I would be interested if both of you provided some references to these
studies.

 

[Tim Rentsch]

[edited for brevity]

I would be interested if you provided some references to these
studies.

I'm sorry to report that I don't have a reference. It's something I
remember reading at some point, but that was before I started keeping
track of references to such things. It's unfortunate, because I think
the programming community would benefit from doing more studies on
these kinds of issues and accumulating references to them.

 

[Mark McIntyre]

I would be interested if both of you provided some references to these
studies.

The hat/spouse thing was printed in The Week, which is a UK magazine
summarising the best of each week's UK and world press. The survey was
apparently originally printed in the Daily Mail. Those of you who know
the Mail will infer from this what you will.... .
Mark McIntyre

 

[Al Balmer]

The hat/spouse thing was printed in The Week, which is a UK magazine
summarising the best of each week's UK and world press. The survey was
apparently originally printed in the Daily Mail. Those of you who know
the Mail will infer from this what you will.... .
Mark McIntyre

Thanks. Confirms my guess about the reliability of the information.

 

[Mark McIntyre]

Thanks. Confirms my guess about the reliability of the information.

.... which was sorta my point about the original topic - vis that
contextless survey results quoted 2nd or 3rd hand are as worthwhile as
articles in tabloid newspapers. ...
Mark McIntyre