|
Hello to all, Sorry for posting such question here but couldn't find any more suitable place on
CodeProject, and I have no intention of posting to any other forum!!!!!!!!
the problem is as follows.
I have an application to calculate the results of a square polynom:
#include<iostream.h>
#include<math.h>
void equall(int a,int b,int c)
{
float x1;
x1=(-b/(2*a));
cout<<"there is only one root and it's: x1="<<x1<<".\n";
}
void equall(int a,int b,int c)
{
float x1, delta;
delta=0;
x1= (-b+delta)/(2*a);
cout<<"there is only one root and it's: x1="<<x1<<".\n";
}
void bigger(int a,int b,int c)
{
float x1,x2,delta;
delta=sqrt((b*b)-(4*a*c));
x1=(-b-delta)/(2*a);
x2=(-b+delta)/(2*a);
cout<<"the two roots are x1="<<x1<<" and x2="<<x2<<".\n";
}
void main()
{
int a,b,c;
float delta;
cout<<"enter 3 variables (a,b,c) for the square equation: (the integer of the number is the one that counts) ";
cin>>a>>b>>c;
delta=((b*b)-(4*a*c));
if(delta<0)
cout<<"the square roots,x1 and x2,doesn't exist!\n";
if(delta==0)
equall(a,b,c);
if(delta>0)
bigger(a,b,c);
}
</math.h></iostream.h>
So it's like that, if I use version 1 x1 always gets a value of 0 no metter what I put
into a, b, c. this is of course not correct!!!
if I use version 2 it's acting OK.
this behavior is weird to me, I can't seem to understand what is it deriving from.
|
|
|
|
|
Hi,
I've had some problems like this sometimes. In your version 1, all of the variables on the right-hand side are integers, so the division is done using all integers (even though on the left-hand side you have a float), and any result less than 1 gets rounded down to 0 before being placed in x1. In your version 2, you use a variable of type float (the variable called delta) on the right-hand side as well, so the division is done using floats and a non-integer value can now be placed in x1.
You can fix it by using either:
x1 = (float)(-b)/(2*a);
or
x1 = -b/(2.0f*a);
It is weird, but I've seen it before!
modified on Wednesday, December 26, 2007 7:30:08 PM
|
|
|
|
|
oh man thanks, so stupid of me not to notice that,
you really helped me.
thank you very much.
|
|
|
|
|
You're welcome!
|
|
|
|
|
Good, just a note:
Californian2 wrote: x1 = (float)(-b)/(2*a);
brackets around -b have no effect. On the other hand you're relying on higher precedence of cast operator with respect of the division one, nothing wrong with that, but maybe
x1 = ((float)-b)/(2*a);
better illustrates what are you doing.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Hi,
you should not have ints at all in this program; I suggest you use floats or better
yet doubles for all coefficients, delta, x, etc. It simply is not an integer problem,
it is a real (or complex) problem.
If you want to deal with the delta<0 case, have a look at some CodeProject articles
on complex classes.
|
|
|
|
|
When using float and double types, it's a good idea to not use integer constants. In other words, use 0.0 and 2.0 instead of 0 and 2 so that the math library is loaded and initialized properly.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Gents,
is it possible to somehow 'receive' the data from another program and it's Listbox control ?
|
|
|
|
|
|
Yes if you have a handle to that window of program you can get data of lists.
|
|
|
|
|
Hello everyone,
Here is a sample from Dr. Dobb C++. In the analysis, the code is bad below.
But I do not think the code is bad,
1. if bad_alloc is thrown in new int[], we just catch it and write some log;
2. if there are any exception in B's constructor, we will also be in catch block and we could also write some log.
Why it is bad code? Any comments?
(I do not agree that there is resource leak, since if we met with bad_alloc in new int[], there is no memory allocated at all, so no root of memory/resource leak).
http://www.ddj.com/cpp/184401297
C::C(int)
try
: B(new int[n])
{
...
}
catch(Error &e)
{
}
thanks in advance,
George
|
|
|
|
|
IMHO the problem is: if something go wrong inside B constructor the will reach the catch block, where there is no chance to release the acquired resource (i.e. allocated memory).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Hi CPallini,
I think you mean the memory allocation of new int[] is successful, but in somewhere in constructor, there is an exception, right?
I think in this case, we can use a catch block in B's constructor to invoke delete[] to free memory, and then re-throw the exception to constructor of class C.
Any comments? Please feel free to correct me if I am wrong.
regards,
George
|
|
|
|
|
My doubt is that, if B swallow the exception in its ctor, how C can know that same? B will be partially constructed without knowing that, C completed it's initialization. Those who using the class, C misunderstand that the whole construction was successful and will start using partially constructed objects. I think the error handling can't be done properly if we approach this method. Correct me if I'm wrong.
-Sarath.
"Great hopes make everything great possible" - Benjamin Franklin
|
|
|
|
|
Hi Sarath,
If there are any exception in B's constructor, the exception will be thrown to C's constructor. Why do you say,
Sarath. wrote: B will be partially constructed without knowing that, C completed it's initialization.
and,
Sarath. wrote: misunderstand that the whole construction was successful and will start using partially constructed objects.
regards,
George
|
|
|
|
|
Suppose you cannot change B class, B constructor hasn't a catch block able to face such a situation (after all B class doesn't even know that memory is allocated on the heap), and C class cannot access B internal data (OOP information hiding, he he  ).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Hi CPallini,
I think when there is exception in B's constructor, the exception will also be thrown to C's constructor. So, C will know its sub-components failed to be initialized in C's catch handler block. Do you agree?
(So, C will always be aware of that whether or not B's constructor fails with exceptions)
regards,
George
|
|
|
|
|
George_George wrote: I think when there is exception in B's constructor, the exception will also be thrown to C's constructor.
...
George_George wrote: (So, C will always be aware of that whether or not B's constructor fails with exceptions)
Nope:
If B handles the exception and doesn't throw again it (or a new exception) then C has no chance to handle it.
George_George wrote: So, C will know its sub-components failed to be initialized in C's catch handler block
Even if C can handle the exception, it cannot delete the array allocated with new if C cannot access the B data members.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Sorry, CPallini.
I may not make myself 100% understood. I mean we catch exception in B's constructor function try block handler, and free the memory in the handler, then re-throw the exception to C. Do you think it is good approach?
regards,
George
|
|
|
|
|
Nope.
B constructor has no knowledge about memory allocation of the passed pointer
(B can't even tell if it was allocated on the stack or on the heap) so it must not delete it. On the other hand, C, even if involved by a B re-thrown exception, cannot delete such memory having no access to B data members.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Thanks CPallini,
Maybe I have not made my ideas clear enough. Here is the pseudo code. Please let me know what is wrong with the code.
class B
{
private:
int* p;
public:
A (int* input) : p(input)
try
{
}
catch (bad_alloc)
{
}
catch (...)
{
if (p) delete[] p;
}
}
regards,
George
|
|
|
|
|
George_George wrote: Maybe I have not made my ideas clear enough.
No, IMHO I've understood your ideas  .
The trouble with your code come out whenever you use it the following way:
int foo[100];
B(foo);
If an exception happens inside B constructor, you'll try to delete memory allocated onto the stack!
My point is: your code is specialized to handle that particular weird situation, but it can't cope with other (more simple and reasonable) ones.
i.e. your code as flaw that my above example detects.
BTW:
George_George wrote: A (int* input) : p(input)
The above should be
B (int* input) : p(input)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Thanks CPallini,
If according to component design, p is always pointed to memory on heap other than stack, do you think my code is good? Any potential issues?
regards,
George
|
|
|
|
|
Well, forcing the client of B to always use the heap is a very bad policy (even supposing that you are the only client of yoursef: you can forget about it  , or you may simply be frustrated by, because, sometimes you may prefer to use the stack).
Anyway it is worth nothing that it doesn't help a lot because you're deleting a memory chunk allocated by the caller on unpredictable (by the caller) grounds: you delete only whenever B constructor raises an exception. This is ugly, since the caller usually (i.e. when all goes fine) relies on that chunk of memory:
int *p;
p = new int[25];
assert(p);
B b(p);
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Thanks CPallini,
I assume that you mean if p always pointed to some object on heap, my code is bug free.
BTW: I agree with your analysis that always making assumption on heap is not a good idea, but in this discussion, I extract my issue in a simple way, and we should discuss under in this simple and special condition.
regards,
George
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
