By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,336 Members | 2,315 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,336 IT Pros & Developers. It's quick & easy.

where to add the delete statement in try and catch?

P: 56
I have the following function and there is memory leak as there is no "delete" for the corresponding "new". I am confused where to add delete. Kindly let me know where all to add the delete statement?

Expand|Select|Wrap|Line Numbers
  1. int  IsSwapClearable ( const sTRADE* pSummitTrade )
  2. {
  3. cout<<"INSIDE IsSwapClearable()"<<endl;
  4.    try
  5.    {
  6.       int retval = sFALSE;
  8.       CheckSwapClear* mySwapClearChecks = new CheckSwapClear();
  10.       // must be a mapped counterparty so do not call IsSwapClearCounterparty();
  12.       if ( mySwapClearChecks->IsSwapClearMappedCounterparty ( pSummitTrade->Base
  13. .Env->Cust.Name ) == sTRUE )
  14.       {
  15.          switch ( pSummitTrade->Base.TradeType )
  16.          {
  17.             case sTT_SWAP :
  18.                  retval = mySwapClearChecks->IsSwapClearableSwap ( pSummitTrade
  19. );
  20.                  break;
  21.             default :
  22.                  break;
  23.          }
  24.       }
  25.       return retval;
  26.    }
  27.    catch( DmgException& aExcep )
  28.    {
  29.       mLogMessage ( "EXCEPTION caught in IsSwapClearable()" );
  31.       throw;
  32.    }
  33.    catch ( ... )
  34.    {
  35.       mLogMessage ( "Unknown Exceptions caught in IsSwapClearable()" );
  37.       throw;
  38.    }
  39. }
  41. And the destructor is defined as below:
  43. CheckSwapClear::~CheckSwapClear()
  44. {
  45.    try
  46.    {
  47.    }
  48.    catch( DmgException& aExcep )
  49.    {
  50.       aExcep.ReThrowGpo("CheckSwapClear::~CheckSwapClear()", sSERIOUS );
  51.    }
  52.    catch ( ... )
  53.    {
  54.       DmgException::ThrowGpo( "CheckSwapClear::~CheckSwapClear() : Unknown Excep
  55. tion", sSERIOUS );
  56.    }
  57. }
Kind Regards,
Aug 14 '07 #1
Share this Question
Share on Google+
7 Replies

P: 56
Any reply from anyone please.

Aug 14 '07 #2

Expert 100+
P: 671
You've made two grevious mistakes in your conduct. You bumped a thread within the span of four hours. And your post is unreadable because you failed to use CODE tags. Read the posting guidelines. You can acknowledge that you have done so by marking up your posted code with the appropriate tags.

You delete dynamically allocated objects where you can guarantee code flow. For example, in a try/catch block, the catch part is not guaranteed. It only runs when there is an exception. A very bad hack would be to force an exception at the end by doing a throw 1, and then deleting the resource in a catch block. But that's not what you should be doing.

If you can figure out where you know the code will definitely flow, and it is valid to release the resource (is this true of right after the try/catch block?), that's where you put the delete. I normally try to avoid these kind of naked resources. Look up RAII and auto_ptr. See and the wikipedia article on RAII (as well as Google).
Aug 14 '07 #3

Expert Mod 5K+
P: 9,197
The try block is very poorly designed. Your pointer is inaccessible after the try block so you have a very large try block. Don't do that. Do this instead:

Expand|Select|Wrap|Line Numbers
  1. int IsSwapClearable ( const sTRADE* pSummitTrade )
  2. {
  3. cout<<"INSIDE IsSwapClearable()"<<endl;
  4. CheckSwapClear* mySwapClearChecks = 0;
  5. int retval = sFALSE;
  7. try
  8. {
  10.    mySwapClearChecks = new CheckSwapClear();
  11. }
  12. catch (etc...)
  13. {
  14.      delete mySwapClearChecks;
  15. }
  17. // must be a mapped counterparty so do not call IsSwapClearCounterparty();
  19. if ( mySwapClearChecks->IsSwapClearMappedCounterparty ( pSummitTrade->Base
  20. .Env->Cust.Name ) == sTRUE )
  21. {
  22. switch ( pSummitTrade->Base.TradeType )
  23. {
  24. etc...
Remember that any exception thrown in this code does not unwind the new allocation. To do that, you would need to delete the allocation in the catch block.
Aug 14 '07 #4

Expert 100+
P: 463
The general rule is that you must delete the object at every exit point. In your method, you have 2 exits from exceptions and one normal exit. You have to account for all of them.

Also, forget about putting a try/catch block in the destructor. Since your try block has nothing in it, it's not going to catch anything. Remember, try/catch blocks can be nested. If your idea is to catch an exception from the calling method in the destructor, this isn't going to work.
Aug 14 '07 #5

P: 11
Question: Why do you use dynamical memory allocation at all? Just type
Expand|Select|Wrap|Line Numbers
  1. CheckSwapClear mySwapClearChecks;
The compiler will free the memory automatically when leaving IsSwapClearable.
Generally: Only use "new" if you need a variable outside of the block where it is allocated. Even then it might be better to copy the variable into another allocated on the stack instead on the heap. Saves you alot of trouble
Aug 15 '07 #6

Expert Mod 5K+
P: 9,197
Question: Why do you use dynamical memory allocation at all? Just type
Code: ( text )
CheckSwapClear mySwapClearChecks;
When the function completes, mySwaoClearChecks is destroyed. That means you can't usee it any other function. That means your entire program must be in one function. That means you can never reuse any of your code without making copies of it. Actually, this was how you did things before 1972.

Defining the object on the stack may not work as stack memory is limited and you may run out of it before you have all the variables created.

I suppose you could make everything global but then global memory is limited. Using global variables is the same as using one giant function for the entire program.

But the worst thing is that the size of the object must be known at compile time. If you have a name field that could vary from 3 to 150 characters, you will need to make all names 150 characters to avoid possible program faulires.

Even worse than worst, the kind of object to create must bne known at compile time. That means you can't create an object based on user inoput when the program is running. Bascially, you can't write either an object-based or an object-oriented program.

So, you have to go exactly in the opposite direction: You never use the stack for objects passing between functions or for objects that can't be created at compile time. Instead, you use handles (not pointers). There is an article on handles in the C/C++ Articles forum that sshows you how to do this.
Aug 15 '07 #7

P: 56
Thanks a lot to all of you. Now I could able to successfully write my code. Thanks.
Aug 16 '07 #8

Post your reply

Sign in to post your reply or Sign up for a free account.