Can function return an array?

**Elysia** · 04-17-2008

I would not say a const reference breaks encapsulation. If it returns const, it means "this data is not meant to be modified by any outside code," and if the programmer breaks that, then it isn't the fault of the class and encapsulation is not threatened.
The programmer who breaks the const is the one doing the wrong and when we remember that classes are objects which are typically separated from any outside code, this means that the class itself didn't do any wrong, but the outside code did, and this doesn't really hurt the encapsulation of the class, but rather a programming error, one that shouldn't be made because it's const.
You're giving a clear message here and if the programmer who uses the class choose to ignore that, it's not your fault.

**medievalelks** · 04-17-2008

You also have the potential of a dangling reference if the object goes out of scope. Sorry, that code wouldn't make it out of a code review if I had anything to say about it.

**Elysia** · 04-17-2008

That is not justifiable to copying data, however. I think every programmer is smart enough to know that when taking a reference like this, they won't store it because the object will go out of scope.
This function is also meant more to be for getting access to the member and not storing it (temporary access, not permanent).

**medievalelks** · 04-17-2008

Originally Posted by Elysia

That is not justifiable to copying data, however. I think every programmer is smart enough to know that when taking a reference like this, they won't store it because the object will go out of scope.

Have you read the questions on this forum lately? This can and would get easily abused and is not worth the risk.

The folly of premature optimization is bad enough without writing dangerous code.

**CornedBee** · 04-17-2008

You also have the potential of a dangling reference if the object goes out of scope.

Not really. Unless the reference is a member of a class and you allocate an object of the class on the heap, giving the reference to the constructor, the reference has to be a local variable. Since the object can go out of scope, it's gotta be a local variable too. Since references have to be bound at initialization time, it's guaranteed that the object lives longer than the reference. And if you do the whole allocation thing, it's your code that won't pass review.

What returning a reference does break is the ability to change the underlying storage.

**bulletbutter** · 04-17-2008

Thanks for all the replies. To be honest I have little to no experience with vectors so I will stay away from those for now. And most of what you guys said was way over my head.

I ended up doing away getAbilities(). Instead I just declared a private string mobAbilities[x] where x is the total number of all spells I plan on using (not just the ones a monster is 'allowed' to cast). I set up CastSpell() member function to just roll a random number for only the spells they can use. It should work for now...

Code:

string Mobs::CastSpell() {
if (mobName == "Troll Mage") {
     mobAbilities[x] = {"MageSpell1", "MageSpell2", "Spell3",
"WarriorSpell1","WarriorSpell2"...etc}
     spellCasted = mobAbilities[rand() % 3];

I can already see a future problem, like if a monsters can cast MageSpell1, MageSpell3 and WarriorSpell2....not sure how I can randomize that.

I might have to finally start looking at vectors and take the advice about them.

Thanks again.

**Elysia** · 04-17-2008

I suggest you do. In practice, they're very easy to use (because they are typically used the same as C arrays, with some exceptions). They're the backbone of arrays in C++.

Thread: Can function return an array?

Thread Tools

Search Thread

Display

Similar Threads

Compiling sample DarkGDK Program

Screwy Linker Error - VC2005

Game Pointer Trouble?

Request for comments

qt help