division by 7 without using division operator

[boa sema]

Serve Laurijssen said:




Right; as I have said dozens of times in this newsgroup, assert is for
validating code, not data.

assert() is for validating code & data, but not input data.

Boa

 

[Richard Heathfield]

boa sema said:

assert() is for validating code & data, but not input data.

What kind of data did you have in mind, other than input data?

 

[boa sema]

boa sema said:




What kind of data did you have in mind, other than input data?

How about function arguments?

One may of course argue that the calling *code* is broken if the data is
broken.

Boa

 

[Richard Heathfield]

boa sema said:

How about function arguments?

That sure sounds like input data to me.

One may of course argue that the calling *code* is broken if the data is
broken.

Quite so.

 

[Richard Tobin]

well, using assert for things that can happen in production code too is also
not correct

If you had said "... in correct production code ...", I would have
agreed. But I don't see any point removing assert()s from production
code (unless they're expensive to compute), because even in production
code it's generally better to abort with a useful message if there
turns out to be a bug in the code. No doubt there are exceptions.

-- Richard

 

[Serve Laurijssen]

If you had said "... in correct production code ...", I would have
agreed. But I don't see any point removing assert()s from production
code (unless they're expensive to compute), because even in production
code it's generally better to abort with a useful message if there
turns out to be a bug in the code. No doubt there are exceptions.

Well assert is not the way to gio then. You can add an assert like debug
facility that can be turned on/off by the user

 

[Keith Thompson]

Yes so it is allowed....but here we go already. standard this year standard
that year and all about stuff that doesnt make you a better C coder. Like
with the assert(p)

I don't understand your point. How does understanding what's defined
in the C90 and C99 standards not make you a better C coder?

 

[Richard Tobin]

If you had said "... in correct production code ...", I would have
agreed. But I don't see any point removing assert()s from production
code (unless they're expensive to compute), because even in production
code it's generally better to abort with a useful message if there
turns out to be a bug in the code. No doubt there are exceptions.

[/QUOTE]

Well assert is not the way to gio then. You can add an assert like debug
facility that can be turned on/off by the user

If there's a bug in my code, I probably don't want the user to be able
to disable its detection.

-- Richard

 

[Keith Thompson]

Well assert is not the way to gio then. You can add an assert like debug
facility that can be turned on/off by the user

The point, I think, is that an assert() that will be triggered *only*
if there's a bug in the code is acceptable, even in production code.

For example suppose you have a function that's intended only to accept
an argument value in the range 1..10. You might write it like this:

void func(int n)
{
assert(n >= 1 && n <= 10);
/* ... */
}

Assuming that func() is invoked by code in your application, that you
control, and never with some user-defined input value. Then a call
func(11) is a genuine bug in the program, not a data error.

If there's any combination of user data that can cause the assert() to
be triggered, then a different mechanism should be used, even if the
program just prints an error message and dies.

Now if you're able to recover from the error (perhaps by saving any
user data), that's even better, but your efforts as a developer are
probably better spent fixing the bug.

 

[Beej]

But I don't see any point removing assert()s from production
code (unless they're expensive to compute), because even in production
code it's generally better to abort with a useful message if there
turns out to be a bug in the code. No doubt there are exceptions.

I can offer that console video game DVDs ship with all the asserts
removed.

After all, there's no going back and fixing it after that. (At least
with the PS2/Xbox generation.)

-Beej

 

[Richard Bos]

Well assert is not the way to gio then. You can add an assert like debug
facility that can be turned on/off by the user

If there's a bug in my code, I probably don't want the user to be able
to disable its detection.[/QUOTE]

True, but neither do I want to present him with a cryptic, tenth-of-a-
second flash of (to him) unintelligible console text and an immediate
return to his desktop. So rather than assert(), my preference is for a
function which can put a quotable, repeatable error message on his
screen and keep it there until he's finished phoning me.

Richard

 

[Richard Tobin]

True, but neither do I want to present him with a cryptic, tenth-of-a-
second flash

??? Why do your assert messages only last a tenth of a second?

of (to him) unintelligible console text and an immediate
return to his desktop.

Ah. I don't use one of those desktop thingies. Most of my programs
have no graphical interface. But I don't see any excuse for systems
where output to stderr vanishes immediately.

So rather than assert(), my preference is for a
function which can put a quotable, repeatable error message on his
screen and keep it there until he's finished phoning me.

Assert error messages may be cryptic, but they come with a file and
line number. I don't see why they would not be repeatable.

-- Richard

 

[Richard Bos]

??? Why do your assert messages only last a tenth of a second?


Ah. I don't use one of those desktop thingies.

_So_ nice for you.

Most production peons wouldn't know which end of a CLI was which.

Assert error messages may be cryptic, but they come with a file and
line number. I don't see why they would not be repeatable.

Your species of luser much be about twelve thousand years futher along
the evolutionary ladder than mine. Congratulations.

I wasn't talking about assert() messages that _I_ see, but about those
that the average, Windows-only, can't-remember-any-numbers, Word-is-
complicated data entry employee sees.

Richard

 

[Serve Laurijssen]

I don't understand your point. How does understanding what's defined
in the C90 and C99 standards not make you a better C coder?

I'm talking about the assert and enum comma example. Knowing those rules
doesnt help one at all to become a better C coder.

 

[Christopher Layne]

If you had said "... in correct production code ...", I would have
agreed. But I don't see any point removing assert()s from production
code (unless they're expensive to compute), because even in production
code it's generally better to abort with a useful message if there
turns out to be a bug in the code. No doubt there are exceptions.

-- Richard

I have found on more than one occasion developers leaving in assertions in
production code on hardware (network equipment) for serious "should not
happen" cases. When it does happen - you submit a bug and they follow up.
What are people's opinions on this?

 

[Keith Thompson]

I'm talking about the assert and enum comma example. Knowing those rules
doesnt help one at all to become a better C coder.

Of course it does. I can't imagine why you would think it doesn't.
For example, coding includes maintaining existing code, some of which
might depend on those rules you're trying to ignore.

 

[Francois Grieu]

Last month I appeared for an interview with EA sports and they asked
me this question.

How would you divide a number by 7 without using division operator ?

To suceed in these interviews, I fear that you must not be so smart as
to outsmart the person asking the questions. So I suspect the right
answer might have been

number *= 0.142857142857143; // divide by 7

which indeed, in quite a few contexts, is an approriate answer.

Francois Grieu

 

[Dik T. Winter]

> To suceed in these interviews, I fear that you must not be so smart as
> to outsmart the person asking the questions. So I suspect the right
> answer might have been
>
> number *= 0.142857142857143; // divide by 7
>
> which indeed, in quite a few contexts, is an approriate answer.

Indeed, it gives the correct answer for all integers from 0 to
2147483647.

 

[CBFalconer]

Indeed, it gives the correct answer for all integers from 0 to
2147483647.

And probably down to -2147483648.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Richard Heathfield]

CBFalconer said:

And probably down to -2147483648.

An exercise for those with way too much time on their hands: what is the
smallest-magnitude integer (i.e. regardless of sign) for which it
fails? If this number is negative, what is the smallest *positive*
integer for which it fails?