Defining a GetArray() Method

I've got a class ("ParentClass") which has several private attributes, one of those being an array of type "ChildClass". All I need is a method which can return the array contained within the "ParentClass". How do I return an array from a method? Note the following example scenario.

The header file's private attributes definition, defining the array attribute (with a fixed size), among other attributes:

Code:

---

private:
  ChildClass super_array[5];
  int whatever_number;
  ...
  ...

---

My attempt at defining a GetSuperArray() Method, (which does not work):

Code:

---

ChildClass ParentClass::GetSuperArray() {
  return *super_array;
}

---

I don't know what I am suppose to be returning...a pointer to the first element in an array, some sort of reference, or what. I don't want a single element returned--I want the entire array.

Again, this is an array of type "ChildClass" which is stored as an attribute of "ParentClass". All I need is a GetSuperArray() method to be appropriately defined in the parent_class.cc file, that which contains all "ParentClass" methods.

It'd be less confusing and less messy to use a
std::array<ChildClass, SIZE> super_array;
and then return super_array from your getarray function.


Remember to use a compiler supporting C++0x/11 features.

I probably don't know what I am talking about since I am such a beginner, but I'm just gonna take a shot in the dark anyway, and hopefully be enlightened or proven wrong (or both). Upon doing more research, it seems as though it is impossible to return an array using a function in C++. Sources to support this claim are here:

c++ return array in a function - Stack Overflow

howto return a array in a c++ method? - Stack Overflow

I'm not exactly sure why this would be, but it seems that vectors are the much preferred way of doing just about anything in C++. I don't even know how to use vectors--I'm making the previous claim based on what has been said on other forums and what other people I know (programmers who have used vectors) have said. If vectors are not generally better or more useful than arrays, their use seems to be a lot more popular in other random source code I come across and their mention seems to be a lot more common in casual programming/forum discussions in which I partake/spectate. For solving my specific problem, that of needing to return an array, it cannot be done simply/directly, but I can use vectors to solve the problem because those can be returned from a function--just like user defined objects can be--just like primitive data types can be (ex. ints).

If arrays are lacking in this way mentioned above, should I just be avoiding arrays altogether? If I can't even return them from a function, it seems like relying on arrays should be avoided at all costs. Perhaps there is a cost/benefit analysis regarding arrays and vectors to be had about which I am not informed.

Did you actually read my reply (and/or try it out)?

Using a std::array gets around those problems because then it just passes an object ..not an address to the beginning of a series of objects.

If you need them of variable size or to dynamically allocate them...use std::vector .

I read it but did not attempt it because I wanted to avoid C++0x, since I have never used it before. Also, I assumed solving a somewhat basic problem like my own was already solved using more conventional methods before C++0x even existed--so I was going to look for those methods.

If I should go down the path of using C++0x, I guess I can make that decision when I know more information. Right now, I am such a beginner, I wanted to err on the side of "simple is safe"--sticking with vanilla C++.

The answer is you can return a pointer to the array. The problem with this is you are giving raw access to a private member of a class and anyone could delete it or do anything else they want with it...IE: it's not all that safe. If you don't mind the copy you can provide a method that returns the size of the array so the caller can allocate an array of the same type and size of the one in the class. You can then provide a method in the class that copies the contents of the class array to the allocated array being passed in to the GetArray() method. Alternatively you could allocate the array in the GetArray() method and also return the size of the array....but this would mean the array is allocated in one class and cleaned up or deleted in another which is not the best idea. Ideally cleanup or de-allocation should be performed by the object that did the initial allocation.

Quote:

---

Originally Posted by nair

I read it but did not attempt it because I wanted to avoid C++0x, since I have never used it before.

---

If you always avoid what you've never used before, you are NEVER going to learn anything.

Quote:

---

If I should go down the path of using C++0x, I guess I can make that decision when I know more information. Right now, I am such a beginner, I wanted to err on the side of "simple is safe"--sticking with vanilla C++.

---

A few points:
1. NOW is an excellent time get more information.
2.std::array s like most STL containers have very simple interfaces. In fact you can forget that your array is actually an object and use it like 'normal' arrays.
3.'simple' may not be safe...particularly in this case, as is suggested in the post by "VirtualAce". It would not even remain simple.(so..both your points are somewhat invalid)

Ultimately it is your decision whether to learn or not. It is not as if C++ox is going to disappear like an April Fools' joke !

Quote:

---

Originally Posted by nair

I read it but did not attempt it because I wanted to avoid C++0x, since I have never used it before.

---

In a sense, no one has used C++0x before. We have only ever used compiler and standard library extensions that implement features destined for inclusion into C++0x, or should I say C++11.

Quote:

---

Originally Posted by nair

I wanted to err on the side of "simple is safe"--sticking with vanilla C++.

---

Note that when the standard is finally published later this year (I sincerely hope they don't drag it to become C++12), C++11 will be "vanilla C++".