• Advertisement
Sign in to follow this  

New Keyword In Function Parameter Bad?

This topic is 4711 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, Is it bad form to use the new keyword in a function parameter? For example a=test(new D3DXVECTOR2(0.1f, 0.2f)); Assuming that the new keyword allocates memory for this class, does this mean that it never gets freed, or does it automatically free as soon that that statement goes out of scope? Also, does a declaration using new within a function automatically get freed also, when the function goes out of scope, for example... void test() { D3DXVECTOR2 *pMyVector=new D3DXVECTOR2(0.1f, 0.2f); } does this memory get freed when the function exits, or do I need to put... delete pMyVector; at the end of the function? Thanks

Share this post


Link to post
Share on other sites
Advertisement
It does not get freed automatically in both cases.

General rule: If you new it you have to delete it.

You might encapsulate it with std::auto_ptr. This will call delete for you once it leaves the scope.

Share this post


Link to post
Share on other sites
About the only place where you can (not necessaraly should) use "new" in an argument list is if the function takes only one argument (reasons for this are complicated), and you know that the function will "take ownership" of what you pass in (it will be responsible for deleting it).

C++ has no garbage collector, so you are responsible for deleting anything you create with new.

Share this post


Link to post
Share on other sites
Quote:
About the only place where you can (not necessaraly should) use "new" in an argument list is if the function takes only one argument
Why does it have to take only one argument? Surely, so long as the function handles deletion of the arguments, it's possible to "new" as many arguments as you like, even if it isn't good form to do so?

Share this post


Link to post
Share on other sites
Quote:
Original post by MumbleFuzz
Quote:
About the only place where you can (not necessaraly should) use "new" in an argument list is if the function takes only one argument
Why does it have to take only one argument? Surely, so long as the function handles deletion of the arguments, it's possible to "new" as many arguments as you like, even if it isn't good form to do so?


I think he more likely is speaking of syntax issues, as opposed to memory leakage.

Share this post


Link to post
Share on other sites
Quote:
Original post by MumbleFuzz
Quote:
About the only place where you can (not necessaraly should) use "new" in an argument list is if the function takes only one argument
Why does it have to take only one argument? Surely, so long as the function handles deletion of the arguments, it's possible to "new" as many arguments as you like, even if it isn't good form to do so?


Someone can correct me if I'm wrong, but it's due to exception safety. If the constructor of one of the objects throws an exception, then the memory for one of the other objects you just allocated might not get freed, even if you were putting it in a safe pointer structure, because the constructor of the safe pointer would never get called.

As has already been said, if you use safe pointers, like std::auto_ptr, or boost::shared_ptr, you can use new in this way, as the memory will automatically be freed when the shared pointer goes out of scope.

Also, you're probably already aware of this, but assuming you're not just using that function as an example, you know that you can do this, right? (obviously test would have to take a reference to a D3DXVECTOR for this code to work)

test ( D3DXVECTOR(0.1f, 1.0f) );

This way your D3DXVECTOR gets allocated on the stack, rather than the heap, and you don't have to worry about it being freed.


One thing you should bear in mind Raeldor, memory allocated by new is NEVER freed automatically by the compiler. The only time it's freed automatically is if you're using some kind of smart pointer, as I mentioned already. (something that I'd recommend you do, look at boost::shared_ptr www.boost.org)

Share this post


Link to post
Share on other sites
Thanks for all the replys. Is there much of an overhead in using smart pointers? Would you recommend them for use in game programming? I guess allocating smaller structures on the heap is fine, but larger classes should use 'new' or smart pointers, I assume?

Thanks

Share this post


Link to post
Share on other sites
The reason is, arguments are evaluated in any order. You may "new" something, but before it can be taken by whatever is going to "delete" it, something might throw, causing that object to leak.

So there is an exception to the not-more-than-one-argument rule - and that is - arguments that won't ever throw don't count (basic types, POD types, functions and objects with constructors that can never throw).


So basically, unless your passing, via one argument (except non-throwers), to a function or object constructor that will take ownership of your new'd object, you should never have a "new" inside an argument list.

This includes nesting - functions called inside argument lists - the outer functions must also abide by the same one-argument-only rule.


Edit: Oxyacetylene beat me to it [smile].

Share this post


Link to post
Share on other sites
Quote:
Original post by Raeldor
Thanks for all the replys. Is there much of an overhead in using smart pointers? Would you recommend them for use in game programming? I guess allocating smaller structures on the heap is fine, but larger classes should use 'new' or smart pointers, I assume?

Thanks


Smart pointer overhead is generally not a big deal.

Basically - once you've written your nice, working program, you can then go around with a profiler and see what is actually causing your program to be slow and optimise that. If it's your smart pointers - then you can speed them up, or use a different technique (garbage collector, memory pooling, etc). If it's something else - you won't have wasted time optimising something that dosn't actually slow you down.


Additionally - it's not really that big of a deal if you have "big" objects on the stack. Although, you don't really want "huge" objects on the stack.

Share this post


Link to post
Share on other sites
Quote:
Thanks for all the replys. Is there much of an overhead in using smart pointers? Would you recommend them for use in game programming? I guess allocating smaller structures on the heap is fine, but larger classes should use 'new' or smart pointers, I assume?


The heap is where you allocate memory using new/malloc. Variables and objects with no pointer indirection go to the stack. In general, only use the heap when you must. There is no point in writing functions which take a D3DXVECTOR3 * if it isn't for C compatibility.

Normally, you just put everything except larger arrays on the stack and design your function to use const references (eg. const D3DXVECTOR3 &) instead of a pointer to avoid needlessly copying the objects around on the stack. But even if you would copy the D3DXVECTOR3 each time the function is called, it would probably still be quicker than using new.

Smart pointers are very helpful, especially if you are actively working with exceptions and do not bring that much of a performance loss with them. Modern compilers are able to optimize such stuff very well.

-Markus-

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement