returning an array from a class via a method.

[Soneji]

This is a pretty specific problem, so I'm not posting the whole program. ( but I can if you really need it )
I have a good understanding of what's wrong, I just can't figure out how to combat it.

Basically, I was fooling around with copy constructors, and overloaded assignment operators, and I ran into an array return problem.

I made a method to return a character array from a class:

class entry
{
  char name[20];
public:
  char show_name(){return *name;}   // I tried both  'name',  &  'name[]',  but 
                                    // neither worked.
  // other code -- inconsequential right now. 
}
 

Then, I made my objects, and used the CC/OAO:

int main()
{
  entry object1("Object 1", 25.50);  // Initializes the character array, and a float.
 
  entry object2 = object1;  // Using overloaded assignment operator.
 
  entry object3(object2);  // Using copy constructor.
 
// Here's where the problem comes into play:
//   ( code has been extremely condensed )
 
  std::cout << object2.show_name() << "\n";
  std::cout << object3.show_name() << "\n";
 
  return 0;
}
 

The result of the 'cout':

O
O

As you can imagine, I am a bit perplexed.

I know the copy constructor, and overloaded assignment operators worked,
because I made another method to display the values from the method:

void show(){cout << name << "\n";}

It displayed fine. However, I want to get the array out of the class.

I tried using 'strcpy' to put the value into a new array, a pointer with new memory, etc.
I know someone out there is going to suggest vectors, but I haven't gotten that far in my learning.

( I'm also working on my C-style string abilities,
so that's why I didn't use a C++ string object there. )

I appreciate any help.

Lates,
-*Soneji

[RedSon]

class entry
{
  char name[20];
public:
  char show_name(){return *name;}   // I tried both  'name',  &  'name[]',  but 
                                    // neither worked.
  // other code -- inconsequential right now. 
}
 

Your method must have a proper return type, if you want to return a pointer then you should say so in your method declaration. You can also see if there is a generic pointer macro definition like LPVOID.

[weaknessforcats]

Functions return a type. An array is not a type. Rather it is a bunch of some type.

You can return the address of the array, however.

class entry
{
  char name[20];
public:
   char* show_name(){return name;}  
  //...
};
 

However, this is extremely bad design. The reason is that you expose your private array. That means it can be changed without needing to use a member function. It also requires that the object not be deleted until all of the returned pointers are out of scope. Otherwise, when this entry object goes out of scope, the name array dies with it and all the exposed pointers are now invalid.
You will crash shortly thereafter and, unfortunately, the location of the crash will be far, far away from the cause.

This class should be using a string and the method should return a copy of it:

class entry
{
     string name
   public:
     string show_name(){return *name;} 
     //etc... 
};
 

[Soneji]

Thanks for the answers!

I can't believe I missed that. I thought, at one time I had added the asterisk to
the return type, but it still wouldn't compile.

I tested it, and I was right. BUT! After removing the dereference from the returned
name ( return *name; <-- That one ) it ran perfectly!

I really appreciate the answers.

Also, thanks for the warning about using the array this way.

It didn't occur to me that the array could be altered after it was returned, but
as soon as I saw your post, it hit me like a ton of bricks. ( This, of course, raises a new question though )

The scope problem has me a bit worried. This is another thing I didn't think about. ( This also leads into the new question... )


My new question(s): Given the new information I now have ( thanks again, to you two ), would it be better not to use arrays inside a class at all?

Or, at the very least, should I relegate them to public access?

But, even if I only use them with public access, this still doesn't address the scope issue.
Is there any way to effectively use an array in a class without leaving an inordinate amount of out-of-scope pointers roaming my program?

*sigh* It can be so confusing. Maybe I should have chosen Python, or Perl as my first language. ( I'll get to them. I swear! )

Thanks again for the help RedSon, and weaknessforcats . I really appreciate it!

Lates,

-*Soneji

P.S. I know I should have used a string, but I understand them very well, and I still need some work on my arrays. ( obviously :) )

[AdrianH]

Thanks for the answers!

I can't believe I missed that. I thought, at one time I had added the asterisk to
the return type, but it still wouldn't compile.

I tested it, and I was right. BUT! After removing the dereference from the returned
name ( return *name; <-- That one ) it ran perfectly!

I really appreciate the answers.

Also, thanks for the warning about using the array this way.

It didn't occur to me that the array could be altered after it was returned, but
as soon as I saw your post, it hit me like a ton of bricks. ( This, of course, raises a new question though )

Memory management is a pain in the ass. Things like pointers require great care. A useful approch is to think of pointers as 'giving' an object, where as passing a reference is like 'lending' an object. That paradigm doesn't work so well for c-strings as they have to be pointers, in which case documentation or using the string class is the best bet.

Passing a string (or any object) is giving you the object, because it is copied.

For general use, a string object is best, using a c-string should be reserved for when you have decided that it is the best route to go because the design requires it (embedded app with limited memory). And in that case you need to think about life span.

A c-string should never be kept, but requested when needed, used and then the pointer discarded. Deletion should only be done by the 'owner' (i.e. the class that gave it) or else it can become confusing.

Much easier to deal with string objects.

The scope problem has me a bit worried. This is another thing I didn't think about. ( This also leads into the new question... )


My new question(s): Given the new information I now have ( thanks again, to you two ), would it be better not to use arrays inside a class at all?

Or, at the very least, should I relegate them to public access?

But, even if I only use them with public access, this still doesn't address the scope issue.
Is there any way to effectively use an array in a class without leaving an inordinate amount of out-of-scope pointers roaming my program?

*sigh* It can be so confusing. Maybe I should have chosen Python, or Perl as my first language. ( I'll get to them. I swear! )

Thanks again for the help RedSon, and weaknessforcats . I really appreciate it!

Lates,

-*Soneji

P.S. I know I should have used a string, but I understand them very well, and I still need some work on my arrays. ( obviously :) )

Again arrays are not exactly bad, they just require a lot of care (so much so that they can be bad if you don't establish proper protocols in your design).

The only reason to use them (and even then, you should think twice) is when you have very limited memory resources. Try using a vector instead.


Adrian

[Soneji]

I see. I'll keep that in mind. Strings it is! Thanks for the response Adrian.

Thanks for all the help everybody!

I always hate asking for help. I like to figure these things out myself,
and I try to exhaust all avenues that I can think of before I do ask.

( even though most of the time, the answer is simple. -- Like missing the asterisk this time. )

( plus, I have seen some forums, where the people that respond are real... ummm.... you know.... not nice. )

But everyone that has responded to the few question I have asked here on 'thescripts' has been very nice.
It's nice to see that in this day of "Keyboard Courage".

Thanks everyone! Hopefully one day ( soon ), I'll be one of the people helping,
instead of being helped.

All the best,

-*Soneji

[AdrianH]

( plus, I have seen some forums, where the people that respond are real... ummm.... you know.... not nice. )

But everyone that has responded to the few question I have asked here on 'thescripts' has been very nice.
It's nice to see that in this day of "Keyboard Courage".

Thanks everyone! Hopefully one day ( soon ), I'll be one of the people helping,
instead of being helped.

All the best,

-*Soneji

Most of the time we are nice. The only times that we might not be is when users whine that all they want is the code, or start posting the question from the text and figure we are an answer machine.

And even then we try and be civil. ;)


Adrian