### Thread: How to return NULL when return type is user defined

1. No Profile Picture
Junior Member
Devshed Newbie (0 - 499 posts)

Join Date
Jun 2003
Posts
9
Rep Power
0

#### How to return NULL when return type is user defined

class Point
{
private:
int x, y;
public:
Point();
Point(int x, int y); //constructor
int getX(); // getter
int getY(); // and
void setX(int x); // setters
void setY(int y); // functions
bool operator==(Point p) const; //overloaded == operator
~Point(); // destructor
};

class Box
{
private:
Point points[40];
public:
Point findPoint(Point p); //what should be the prototype of this function

};

Point Box::findPoint(Point p)
{
Point pTemp;
for(int i=0; i<40; ++i)
{
pTemp = points[i];
if(pTemp == p )
return pTemp;
}
return; // what to return here ?????????????
}

Look at the findPoint function. The responsibility of this function is to search in arrary
for the Point given and if function finds this Point, return it, otherwise if function does
not find the Point given it should return NULL. But I am unable to do it. I can achieve this
by changing the prototype of function like this

Point *findPoint(Point p);

butt I dont want to do this because it will break the conecpts of OOP and give access to
private data memeber.

The problem is if I return by value then I cant return NULL, so in user class or function,
I can not know whether the Point is found or not. and if I return the pointer, then I give

2. Well, since the findPoint method appears to test for equivalence, you can just as well return a boolean value, and if true, continue on using the Point you specified as the argument to the method call.

Another approach might be passing the Point argument by-pointer, having the findPoint method set its attributes accordingly, and return a boolean.

And if you don't want -that-, you can always pass -two- Points, one by value, and one by pointer:

Code:
```Point pTemp, pResult;
findPoint(pTemp, &pResult);```
Good luck :)
3. No Profile Picture
status unknown
Devshed Newbie (0 - 499 posts)

Join Date
Jun 2003
Posts
262
Rep Power
12
I tend to agree with Analyser, that all you're after here is an equivalence test. You already have a copy of the Point you're looking for.

As a general case, though, let's imagine you don't have a copy of the Point, but you're searching based on some matching criteria (maybe just a certain value of x, for instance). In that case, rather than returning a pointer to the Point within the Box object that meets the criteria, you could dynamically create a new copy of that Point object and pass back a pointer to that new copy, or return NULL if no match is found. I guess it depends what you want to do with the Point that gets returned.
4. No Profile Picture
Junior Member
Devshed Newbie (0 - 499 posts)

Join Date
Jun 2003
Posts
9
Rep Power
0

As a general case, though, let's imagine you don't have a copy of the Point, but you're searching based on some matching criteria (maybe just a certain value of x, for instance). In that case, rather than returning a pointer to the Point within the Box object that meets the criteria, you could dynamically create a new copy of that Point object and pass back a pointer to that new copy, or return NULL if no match is found.
Butt if we dynamically create a new of that Point object, who will destroy that Point object. Is it a good idea to allocate memory in one method and deallocate it another location in the program. Will this not lead to the memory leaks????????

By the way, I changed the prototype of finPoint to

bool findPoint(Point pSearch, Point &rpResult);

It is fulfilling the purpose.
5. No Profile Picture
status unknown
Devshed Newbie (0 - 499 posts)

Join Date
Jun 2003
Posts
262
Rep Power
12
Originally posted by shim
Butt if we dynamically create a new of that Point object, who will destroy that Point object. Is it a good idea to allocate memory in one method and deallocate it another location in the program. Will this not lead to the memory leaks????????
[1] It would have to be up to the client to deallocate the memory.

[2] Yes, it's a good idea to allocate memory in one method and deallocate at another location in the program, as long as you tell people that they need to deallocate it. It happens all the time.

[3] No, it won't lead to memory leaks, as long as the client remembers to deallocate the memory. Just as it won't lead to memory leaks if the client allocates memory somewhere and has to remember to deallocate it. There's nothing inevitable about memory leaks with dynamic memory allocation.