I find an interesting and confusing code..have a look.
-
fun(){
int temp;
throw temp;
}void fun1(){
try{
int a;
fun();
int* p=null;
p=new int[40]}
catch(int temp){
delete[] p;}
}main(){
fun1();
}I write some code that supposed to make you understand, rather than make it perfect without any mistakes. Alas, just edit a bit can make it compliable.
-
If you'll clean up the compiler errors, you should be able to answer your question. :|
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
-
fun(){
int temp;
throw temp;
}void fun1(){
try{
int a;
fun();
int* p=null;
p=new int[40]}
catch(int temp){
delete[] p;}
}main(){
fun1();
}I write some code that supposed to make you understand, rather than make it perfect without any mistakes. Alas, just edit a bit can make it compliable.
What exactly do you find interesting, in the above code? :)
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
lol.... you make me largh! Please look into this code because it's not that simple and it contain some deadly fallacies in it! And not just one, many! My confusion is that I don't find a way out to solve it.
So has your question changed from "What will hapen?" to "How can I fix it?"
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
-
lol.... you make me largh! Please look into this code because it's not that simple and it contain some deadly fallacies in it! And not just one, many! My confusion is that I don't find a way out to solve it.
JackPuppy wrote:
it contain some deadly fallacies in it!
Possibly yes.
JackPuppy wrote:
And not just one, many!
Again, possibly yes.
JackPuppy wrote:
My confusion is that I don't find a way out to solve it.
No doubt about. :-D BTW: just kidding.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
What exactly do you find interesting, in the above code? :)
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]OK，let me expain:
fun(){
int temp;
throw temp;
}void fun1(){
try{
int a;
fun();
int* p=null;
p=new int[40]}
catch(int temp){
delete[] p;}
}main(){
fun1();
}when main() call fun1(), a,p are push into stack without initialize. fun()throw an exception so the try-catch block detect it. and the program jump into catch{} and in the catch{} it delete[] p; wait for a sec, p wasn't initialize yet so this is wrong; however how can we determine whether p was initialize? because when p was pushed into stack it contain some data and become a dangling pointer. by convention, we will write catch{ if(p!=NULL) delete[] p; } but it wasn't the case at this circumstance because p is not null at the very begining! of cause you can write like this: int* p=null; fun(); p=new int[40]; so p is null before calling fun(). so It's OK now. I find this interesting because I have to pay so much programing knowledge to explain this small mistake, the knowledge concerned are : stack, heap management, PE format, linker, loader, lib.
-
OK，let me expain:
fun(){
int temp;
throw temp;
}void fun1(){
try{
int a;
fun();
int* p=null;
p=new int[40]}
catch(int temp){
delete[] p;}
}main(){
fun1();
}when main() call fun1(), a,p are push into stack without initialize. fun()throw an exception so the try-catch block detect it. and the program jump into catch{} and in the catch{} it delete[] p; wait for a sec, p wasn't initialize yet so this is wrong; however how can we determine whether p was initialize? because when p was pushed into stack it contain some data and become a dangling pointer. by convention, we will write catch{ if(p!=NULL) delete[] p; } but it wasn't the case at this circumstance because p is not null at the very begining! of cause you can write like this: int* p=null; fun(); p=new int[40]; so p is null before calling fun(). so It's OK now. I find this interesting because I have to pay so much programing knowledge to explain this small mistake, the knowledge concerned are : stack, heap management, PE format, linker, loader, lib.
-
Apart from the fact his bug ain't subtle...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p