I am writing up a code for the bisection method.
My code's below, and somehow the loop doesn't seem to start.
There are no special compiling issues.
I don't think there are any problems with the variable declaration / function prototypes.
Can anyone help me find the real issue here?
The standard binary search algo goes like:
do {
m=(a+b)/2; /* Change 1, 4 lines */
pA=polynomial(a,c3,c2,c1,c0);
pB=polynomial(b,c3,c2,c1,c0);
pM=polynomial(m,c3,c2,c1,c0);
if(pA*pM<0) {
b=m;
}
else {
a=m; /* Change 2, 1 line */
}
} while(pM!=0 && fabs(a-b)>0.0001);
You need to conditionally change both a and b to converge (reach closer to exit condition) and recalculate pA, pB and pM in each iteration.
There is some scope of optimization (avoid some recalculation) that I hope you can figure out once you can get the code to work to your expectation.
Related
I'm more of a student than I am a seasoned programmer and the other day I was refactoring a piece of code I wrote some time ago. In there, there was a function that was rather big in code size and had a structure like this:
if (eval)
return code;
...
if (different test)
return another code;
...
In all there were about 6 or 7 return points some of them with cleanup code inside of the branch. Some of them also responded to erroneous situations, paths where the function wouldn't fully process the input but rather return an error code.
Even though the code was commented and all it seemed to me hard on the eyes and difficult to read. So I was wondering if there are any best practices on the matter.
Reading code from all around the net I found different approaches to this matter. For example one would follow this scheme:
do {
whole body of the function;
while (false);
clean up code if necessary;
return code;
Mainly to be able to use break; sentences in different evaluations (since we were inside a loop) to exit the loop, do the cleanup if necessary and return the exit code. But that feels the same as gotos to me, with the limitation that they place to go to would only be forward in code.
Another one would be similar to mine, but have only one return statement at the end of the function and having a variable to hold error codes.
You can use goto for that.
code = firstCode;
if (condition != 0)
goto label;
code = secondCode;
if (anotherCondition != 0)
goto label;
label:
clean_up_code_if_necessary()
exit(code); // may be you should return from the function
but there could be many other options depending on the specific case.
Here is frequently used linux kernel idiom. When something fails, it rolls back and cleanup after previously executed code.
if(do_a()==FAIL)
goto fail_a;
if(do_b()==FAIL)
goto fail_c;
if(do_c()==FAIL)
goto fail_c;
/* rest of the code goes here */
/* if it's ok then set err to 0 and jump to ok */
err = 0;
goto ok;
// otherwise unroll what have been done
fail_c:
undo_c();
fail_b:
undo_b();
fail_a:
undo_a();
ok:
return err;
well , we need do differentiate between C and C++ , the way of handling things is quite different between C and C++.
In C , I would recommend use an Enum which states the current state of of the code , for example:
enum {State1,State2,Invalid_Argument,Error}
then , create a function that checkes whatever it needs, then return some constant from the enum above as return value:
int check_statement(arg1,arg2...)
and at last , use a switch case on the function above:
switch(check_statment(...)){
case state1:
...
return ...
case Error:
...
return..
}
I'm working with a large SDK codebase glommed together from various sources of varying quality / competence / sanity from Linus Torvalds to unidentified Elbonian code slaves.
There are an assortment of styles of code, some clearly better than others, and it's proving an interesting opportunity to expand my knowledge / despair for the future of humanity in alternate measures.
I've just come across a pile of functions which repeatedly use a slightly odd (to me) style, namely:
void do_thing(foo)
{
do {
if(this_works(foo) != success)
break;
return(yeah_cool);
} while (0);
return(failure_shame_death);
}
There's nothing complicated being done in this code (I haven't cut 10,000 lines of wizardry out for this post), they could just as easily do:
if(this_works(foo) == success)
return(yeah_cool);
else
return(failure_shame_death);
Which would seem somehow nicer / neater / more intuitive / easier to read.
So I'm now wondering if there is some (good) reason for doing it the other way, or is it just the way they always do it in the Elbonian Code Mines?
Edit: As per the "possible duplicate" links, this code is not pre-processed in any sort of macro, it is just in the normal code. I can believe it might be due to a coding style rule about error checking, as per this answer.
Another guess: maybe you didn't quote the original code correctly? I have seen the same pattern used by people who want to avoid goto: they use a do-while(0) loop which at the end returns a success value. They can also break out of the loop for the error handling:
int doXandY() {
do {
if (!x()) {
break;
}
if (!y()) {
break;
}
return 0;
} while( 0 );
/* Error handling code goes here. */
globalErrorFlag = 12345;
return -1;
}
In your example there's not much point to it because the loop is very short (i.e. just one error case) and the error handling code is just a return, but I suspect that in the real code it can be more complex.
Some people use the do{} while(0); construct with break; inside the loop to be compliant in some way with MISRA rule 14.7. This rule says that there can be only single enter and exit point in the function. This rule is also required by safety norm ISO26262. Please find an example function:
int32_t MODULE_some_function(bool first_condition,bool second_condition)
{
int32_t ret = -1 ;
do
{
if(first_condition)
{
ret = 0 ;
break ;
}
/* some code here */
if(second_condition)
{
ret = 0 ;
break ;
}
/* some code here */
} while(0) ;
return ret ;
}
Please note however that such a construct as I show above violates different MISRA rule which is rule 14.6. Writing such a code you are going to be compliant with one MISRA rule, and as far as I know people use such a construct as workaround against using multiple returns from function.
In my opinion practical usage of the do{}while(0); construct truely exist in the way you should construct some types of macros.Please check below question, it was very helpful for me :
Why use apparently meaningless do-while and if-else statements in macros?
It's worth notice also that in some cases do{}while(0); construct is going to be completely optimized away if you compile your code with proper optimization option.
Hm, the code might be preprocessed somehow. The do { } while(0) is a trick used in preprocessor macros; you can define them like this:
#define some_macro(a) do { whatever(); } while(0)
The advantage being that you can use them anywhere, because it is allowed to put a semicolon after the while(0), like in your code above.
The reason for this is that if you write
#define some_macro(a) { whatever(); }
if (some_condition)
some_macro(123);
else
printf("this can cause problems\n");
Since there is an extra semicolon before the else statement, this code is invalid. The do { ... } while(0) will work anywhere.
do {...} while(0) arranged with "break" is some kind of "RAII for Plain C".
Here, "break" is treated as abnormal scope exit (kind of "Plain C exceptions"), so you can be sure that there is only one place to deallocate a resource: after a "while(0)". It seems slightly unusual, but actually it's very common idiom in the world of plain C.
I would guess that this code was originally written with gotos for error handling:
void do_thing(foo)
{
if(this_works(foo) != success)
goto error;
return(yeah_cool);
error:
return(failure_shame_death);
}
But at some point an edict came down from on high "thou shalt not use goto", so someone did a semi-automatic translation from goto style to loop-break style (perhaps with simple script). Probably when the code was merged/moved from one project to another.
I have a while loop as below.
while (*d++ = *sc++)
As I wish to understand pointers in dept I would like to enter the while loop and understand how the while loop is working with the pointers.
I used step in gdb but it does not go into the while loop completely. Is there any way to get into the while loop and understand the manipulation in every step.
* binds tighter then postfix ++. ++ on the right side will be applied last, so:
while (*d++ = *sc++)
is the same as:
while (*d = *sc)
{
d++;
sc++;
The modification is much better to be traced in gdb.
Update:
Don't code like this OP!
Although it might look cool, and prove you are smart. It's difficult to be parsed by the common human brain and therefore error prone? Which we do not want, do we?
Better go for a more clear alternative like proposed above and let the compiler scramble the code.
Option 1:
Look into the assembly code debugging as suggested by Olaf Dietsche.
Option 2:
Use gcc -S test.c to stop compiler after assembling to see the assembly code of your program. Understanding assembly code might be a little hard. More info here
Option 3:
Rewrite your program to something like
while(1)
{
if(*d++ != *sc++)
{
break;
}
}
So that you can put breakpoints and see the values changing.
An alternative, but identical way to write the code is:
*d = *sc;
while (*d > 0)
{
d++;
sc++;
*d = *sc;
}
Hello I am studying for a test for an intro to C programming class and yesterday I was trying to write this program to print out the even prime numbers between 2 and whatever number the user enters and I spent about 2 hours trying to write it properly and eventually I did it. I have 2 pictures I uploaded below. One of which displays the correct code and the correct output. The other shows one of my first attempts at the problem which didn't work correctly, I went back and made it as similar to the working code as I could without directly copying and pasting everything.
unfortunately new users aren't allowed to post pictures hopefully these links below will work.
This fails, it doesn't print all numbers in range with natural square root:
for (i = 2; i <= x; i++)
{
//non relevant line
a = sqrt(i);
aa = a * a;
if (aa == i);
printf("%d ",i);
}
source: http://i.imgur.com/WGG6n.jpg
While this succeeds, and prints even numbers with natural sqaure root
for (i = 2; i <= x; i++)
{
a = sqrt(i);
aa = a * a;
if (aa == i && ((i/2) *2) == i)
printf("%d ", i);
}
source: http://i.imgur.com/Kpvpq.jpg
Hopefully you can see and read the screen shots I have here. I know that the 'incorrect code' picture does not have the (i/2)*2 == i part but I figured that it would still print just the odd and even numbers, it also has the code to calculate "sqrd" but that shouldn't affect the output. Please correct me if I'm wrong on that last part though.
And Yes I am using Dev-C++ which I've read is kinda crappy of a program but I initally did this on code::blocks and it did the same thing...
Please I would very much appreciate any advice or suggestions as to what I did wrong 2 hours prior to actually getting the darn code to work for me.
Thank you,
Adam
your code in 'that' includes:
if (aa == i);
// ^
printf(...);
[note the ; at the end of the if condition]
Thus, if aa == i - an empty statement happens, and the print always occures, because it is out of the scope of the if statement.
To avoid this issue in the future, you might want to use explicit scoping1 [using {, } after control flow statements] - at least during your first steps of programming the language.
1: spartan programmers will probably hate this statement
Such errors are common. I use "step Over", "Step Into", "Break Points" and "watch window" to debug my program. Using these options, you can execute your program line by line and keep track of the variables used in each line. This way, u'll know which line is not getting executed in the desired way.
I have a function with an absurd number of return points, and I don't want to caveman each one, and I don't want to next through the function. Is there any way I can do something like finish, except have it stop on the return statement?
You can try reverse debugging to find out where function actually returns. Finish executing current frame, do reverse-step and then you should stop at just returned statement.
(gdb) fin
(gdb) reverse-step
There is already similar question
I think you're stuck setting breakpoints. I'd write a script to generate the list of breakpoint commands to run and paste them into gdb.
Sample script (in Python):
lines = open(filename, 'r').readlines()
break_lines = [line_num for line_num, line in enumerate(lines) if 'return' in line and
line_num > first and line_num <= last]
break_cmds = ['b %s:%d' % (filename, line_num) for line_num in break_lines]
print '\n'.join(break_cmds)
Set filename to the name of the file with the absurd function, first to the first line of the function (this is a quick script, not a C parser) and last to the number of the last line of the function. The output ought to be suitable for pasting into gdb.
Kind of a stretch, but the catch command can stop on many kinds of things (like forking, exiting, receiving a signal). You may be able to use catch catch (which breaks for exceptions) to do what you want in C++ if you wrap the function in try/finally. For that matter, if you break on a line inside the finally you can probably single-step through the return after that (although how much that will tell you about where it came from is highly dependent on optimization: common return cases are often folded by gcc).
How about taking this opportunity to break up what seems to be clearly a too-large function?
This question's come up before on SO. My answer from there:
Obviously you ought to refactor this function, but in C++ you can use this simple expedient to deal with this in five minutes:
class ReturnMarker
{
public:
ReturnMarker() {};
~ReturnMarker()
{
dummy += 1; //<-- put your breakpoint here
}
static int dummy;
}
int ReturnMarker::dummy = 0;
and then instance a single ReturnMarker at the top of your function. When it returns, that instance will go out of scope, and you'll hit the destructor.
void LongFunction()
{
ReturnMarker foo;
// ...
}