I made this post before, but I did''nt get a lot of help. Here''s my problem: I have a class that contains a private array. I want to access this array from outside the class. How do I do it? I know it''ll include pointers or references, but how do i do it? DX++ The DirectX Programming Site

there's a few possible ways...

        class CFoo{    public:        //method one        int accessArray(int index) { return arr[index]; }        void setArray(int value,int index) { arr[index]=value; }            //method two (simplest, though arguably goes against        //encapsulation        int* Array(void) { return arr; }        //method three (same problem as two)        //(not sure about the exact syntax        int& operator[](int index) { return arr[index]; }    private:        int arr[ARR_SIZE];};        

hopefully this was helpful...

by the way, to use that last method you'd do something like this:

CFoo foo;
foo[2] = 3;

Edited by - pUnkOuter on August 25, 2000 11:40:07 AM

And, of course, if you just want to be able to modify it directly using pointers or references, the -real- question you should ask yourself is: why bother making it private in the first place?

Only reason I can think of is that the array is allocated on the heap and he doesn''t want someone deleting it. But if this is the case, I have to wonder why he just doesn''t use vector...

I like the first of pUnkOuter''s methods the best. Its the most encapsulated, and easy to use. If you want to modify the way the array works, all you do is change the accessor function and none of your other code. Very encapsulated.

deakin: How are the other methods harder/impossible to change?


- null_pointer
Sabre Multimedia

If you''ve written C++ code before with the vain attitude of "it''s easier to write directly to the variable so what''s the point in making it private?", consider this oh so simple yet highly propogating example...

1. You have texture co-ordinates: u, v.
2. They range from 0-255.
3. Access them directly, littered through your code with gross proficiency.
4. Oooo bugger, I want them to range from 0-1.
5. *sigh* Go through code, clearing up mess, trying to remember where you modify everything.

Or, rather, with an access method...

u = incoming_u / 255;

That''s just one small example of the possibilities. Think about it...

Anony Moose....

Your example isn''t a very good one, as it is an example of something that is probably so low-level, that to have a divide or multiply every time you access it is going to be inefficient. The point is, encapsulating everything is not always a good idea. If in doubt, do so. But if you know your design does not require it, then don''t. If you really know what you''re doing, you won''t need to make big changes such as the one you mentioned.

better yet...

Design your class so you don''t have to directly access the array from the outside... depending on what the array is used for, implement those uses in functions inside the class that has the array.

Making a variable private just so you can use accessor functions whose one-line operation perform the same actions that making the variable public would do, is just a waste and goes against the idea of encapsulation.

Even if all you do is bounds-checking, at least you now have a purpose for encapsulating the array (or whichever value you have).

For instance, if you had a C_Screen class that controlled output to the video display, and in that class you had a buffer variable representing the screen, don''t simply allow access to that buffer from outside the class through an array variable. There''s no checking for if the surface is locked, or if you are drawing outside the screen. Even these checks in an accessor function really don''t necessitate the use of a private value in this way. What could be done, is something like passing a sprite object (pointer) to a function in this C_Screen class, which then draws the sprite to its x,y coord, with clipping and animation...

There are several other examples of good use of encapsulation... but if you''re just going to end up directly accessing the variables anyway, either don''t make it private, or rethink your design.

"Man is the only animal that laughs and weeps; for he is the only animal that is struck with the difference between what things are and what they ought to be."
        --William Hazlitt

Someone posted a link to a great article on proper C++ class design and encapsulation a while ago. I''m hoping someone will read this and remember what I''m talking about... it would come in very handy right now. Basically, an object should not have set and get functions. If your design requires the use of such, then you are not practicing OOP. Consider this -

Do Not:
cout << "The value of Bar is " << Foo.getBar();

Do:
Foo.print(); {cout << "The value of Bar is " << this->Bar;}