🔒 Locked

Returning an private array?

Started by Zeraan Mar 9, 2003 at 3:19 PM 4 replies 500+ views

Original Post

Zeraan

107

Zeraan

Mar 9, 2003 at 3:19 PM

I want to know how to return an private class array member class. This is what the array look like

    
struct APart
{
   int x, y;
};

class WholeParts
{
   private:
      APart PartArray[20][20];

   ...
}

How can I use the array outside the class? Do I make APart array in a function, then pass it to that class, and that class supplys it with data and I use what it returns? [edited by - Zeraan on March 9, 2003 4:21:33 PM]

Qw3r7yU10p!

Mar 9, 2003 at 3:42 PM

put the functions on the WholeParts class, then you don''t have to pass anything around.

Shannon Barber

Mod

368

Shannon Barber

Mar 9, 2003 at 9:25 PM

There''s lots of different ways... here''s the two I would personally favor:

This way lets you see both index parameters (you could validate them in a debug build)

  
class WholeParts
{
APart& operator()(int x, int y)
   {
   return this->PartArray[x][y];
   }
private:      
   APart PartArray[20][20];  
};

WholeParts parts;

parts(4,5).x  7;
cout << parts(4,5).x;

This way gives a more conventional use syntax

  
class WholeParts
{
APart* operator[](int x)
   {
   return this->PartArray[x];
   }
private:      
   APart PartArray[20][20];  
};

WholeParts parts;

parts[4][5].x = 7;
cout << parts[4][5].x;

You could return an APart iterator from WholeParts::operator[] that, then you could use the conventional syntax and validate the indices - it''s also more work.

Zeraan

Author

107

Zeraan

Mar 9, 2003 at 9:55 PM

Thanks, I havn''t even thought of operator overloading. I keep underestimating the power of OOP...

The problem is, I have the array in a class in one header file, and I want to pass that data to another array in another header file (Bullets vs Asteroids)

Shannon Barber

Mod

368

Shannon Barber

Mar 9, 2003 at 10:09 PM

Operator overloading isn''t exactly part of OOP... It''s something they added to C++ to pursue the goal of having user-defined data-types indistinguishable from built-in types. Its roots are in functional programming.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.