What would be the advantage of doing that? How about just:
base * p = new base();
In other words, on line 30, you have to specify what you are creating anyway... The getObject method only seems to be restricting its use to types that are default constructable.
@jsmith & moorecm: It's because I have several classes whose object I want to create at different points and I don't want to write try catch everytime I create a new object. I know I can have just one big try catch block for everything, but would that be a good practice to do that? I thought that may be I should have separate function for allocating memory for objects. Is it bad?
It's because I have several classes whose object I want to create at different points and I don't want to write try catch everytime I create a new object.
I didn't see how your template function was handling exceptions. How does the template code allow you to avoid extra try..catch blocks? You could use some kind of a factory pattern but even so you will have to catch exceptions somewhere if it is part of your software development plan. I have never seen a bad_alloc exception in real life so that is one of those where maybe you catch the exception at some high level where you don't have to wrap every call to operator new where it is used but at some higher level. I'm not sure what the template code is really doing to help you with exception handling.
Sorry I didn't included try catch block in that function.
How does the template code allow you to avoid extra try..catch blocks?
It definitely does not. Sorry for not being clear. What I am trying to do is, suppose if we have 10 different classes whose object we will want to create again and again in different functions. So for that I thought that if I can have a generic function which creates the object for me, then I just have to include one line of code (i.e. calling getObject) instead of doing try-catch everytime I create a new object.
Edit:
I have never seen a bad_alloc exception in real life so that is one of those where maybe you catch the exception at some high level where you don't have to wrap every call to operator new where it is used but at some higher level
Well what happens if the exception is caught? The caller needs to know that the object wasn't actually created correct? Hiding the try catch may simplify one thing but you'll still have to handle the error above that level somehow in order to avoid using an uninitialized pointer.
There is nothing wrong with jsmith's example. It's just that I was actually doing the same thing and then I thought that may be I should follow some good practice of memory allocation when we have to allocate for many different objects by using generic function or something. :-(
But, oh well, I guess I will just stick with not using "functions" for object creation.
Most programs don't usually handle out of memory conditions. What would it do? Even
std::cout << "uh-oh"; can attempt to allocate memory, which would then throw again.
Unless it's a matter of life and death, I wouldn't even bother catching std::bad_alloc.
Moreover, that won't even catch all out of memory conditions. For example, some OSes
use an optimistic allocation strategy where the OS will gleefully extend the process'
address space as requested without ensuring that there is physical (or virtual) memory
available to suffice it. So, for example, char* pbuf = newchar[ 1024*1024 ];
will return you a valid pointer, but pbuf[ 0 ] = 42; will crash because there
is no memory available.