generic get object function

Hi Guys,

Is is possible to create a generic get object function?
For ex. in code below, right now I have different functions for creating different objects.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

class base { 

} ; 

class base1 { 
} ; 

base* getBase(void) { 

    base *retVal = NULL ; 
    try {
       retVal = new base ; 
    } catch(bad_alloc &failed) { 
      cerr<<failed.what() ; 
      exit(-1) ; 
    } 
} 

base1* getBase1(void) { 

    base1 *retVal = NULL ; 
    try {
       retVal = new base1 ; 
    } catch(bad_alloc &failed) { 
      cerr<<failed.what() ; 
      exit(-1) ; 
    } 
} 
      


Is there a way that I can have only one getObject function?

Please let me know

Thanks
Is it good to do this way?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
class base { 
    public:
        base() { 
            cout<<"base "<<endl; 
        }   
        ~base() { 
            cout<<"base des"<<endl; 
        }   
} ; 

class derived : public base { 
    public:
        derived() { 
            cout<<"derived "<<endl; 
        }   
        ~derived() { 
            cout<<"derived des"<<endl; 
        }   
} ; 

template<class T> T* getObject() { 
    T* retVal ; 
    retVal = new T ; 
    return retVal ; 
} 


int main() { 

    base *p = getObject<base>() ; 
    return 0;
}

Why not just

1
2
3
4
5
6
7
8
int main() {
    try {
         // body here
    } catch( const std::bad_alloc& ba ) {
        std::cerr << ba.what() << std::endl;
        exit( 1 );
    }
}

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.
Last edited on
@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?

Please let me know
Last edited on
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.
Last edited on
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


Is it then OK to avoid try-catch around new?
Last edited on
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.
Could you please suggest a good way of doing that?
What was wrong with jsmith's example? I'm assuming that you don't need to recover from a bad_alloc exception, right?
Last edited on
Hi moorecm,

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.
Last edited on
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 = new char[ 1024*1024 ];
will return you a valid pointer, but pbuf[ 0 ] = 42; will crash because there
is no memory available.


Thanks so much for the explanation jsmith.
Topic archived. No new replies allowed.