Your choice?

[PIEBALDconsult]

The latter. I try to avoid void functions; there should be something to return, at least a boolean (for success or failure) or a count of items, but returning the collection makes the most sense, even if you also pass in the collection to fill or add to: list& GetAllItems(list& lst) the caller can then use or ignore the return value.

[Lost User]

I'd prefer the second one. 1. It requires less code (I don't even have to declare a variable to hold the results if all I have to do is to pass it on to another method - call chaining). 2. 'Get' should 'get' something, not load or fill something.

[John M Drescher]

bool GetAllItems(list& lstItems)

John

[BobJanova]

Any reason for that?

[BobJanova]

It depends on the language, to some extent. In most modern languages I'd definitely do the second one, and I think that a method called 'GetXxx' should always return Xxx. However, the second way almost guarantees that you are having to create a new list inside that method, and there may be situations where that is important. In that case, I'd at least allow passing in a list, but I probably wouldn't call it GetXxx in that case. If memory was critical, I'd do something like (pseudo)

list& GetAllItems(){
return FillWithAllItems(new list());
}

list& FillWithAllItems(list& input){
input.add(item1);
// etc
return input;
}

... and in the positions where you want to re-use an existing list, you can do so, but if you don't care, you can still use the more user-friendly Get method. Ideologically returning the list is correct because

• it is closer to functional programming
• you are logically getting a list, so that's what the method should do
• you can chain method calls that way

... but in certain circumstances it may be necessary to re-use memory and pass an instance in. I've actually faced exactly this situation with Vector.<Vector3D>, and maths operations on my vector class, in Flash (AS3). I started with the nice way and then added the option to reuse instances for efficiency reasons.

[Eytukan]

__yash__ wrote:

LIST_GET_STATUS GetAllItems( LIST *pLst )

Well, using LIST* might make the code look more manlier, but I wouldn't like the idea of doing this.

LIST_GET_STATUS GetAllItems( LIST *pLst )
{

if(NULL!=pLst)//forgetting this would give you a bang at times!
{
}
}

Hence, & > * .

Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.

[__yash__]

It's been really long since I last worked with C++, hence posted in C. In any case my point was to have a return value also so as to know whether

GetAllItems()

succeeded or failed. If failed, then what was the reason.

[CPallini]

"More Professional" :-D

Veni, vidi, vici.

[CPallini]

There's NULL for that.

Veni, vidi, vici.

[__yash__]

You could have more than "binary" number of reasons why something failed. An error code can be used to indicate just that.

[CPallini]

There's GetLastError or errno or whatever, for this.

Veni, vidi, vici.

[TheGreatAndPowerfulOz]

Assuming this is C++, then certainly not the second since it returns a reference to something that I assume would be local (on the stack -- upon return the stack is destroyed) or a member of the class (violation of data hiding). In modern C++, I'd use

list GetAllItems()

because it's a move operation (no copy ctor is used), and throw an exception if there were an error. In pre-modern C++, I'd use

void GetAllItems(list& items)

because returning an object causes a copy to be made. (And throw an exception if there were an error.)

If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun

[wizardzz]

Wow, the tribe has spoken and you are correct!

"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson

[GParkings]

had to happen at least once, eh?

Pedis ex oris Quidquid latine dictum sit, altum sonatur

[W Balboos GHB]

Interesting. My habits in C++ (new or old) would be to return a pointer to the list. If managed, then it will persist. If unmanaged, then it will stay until I delete it. Returning non-pointers is usually relegated to either native types or structures, but 'never' to an array. For array-returns, null for failures (particularly if they're an expected result) possibly via an exception caught in the callee, and throwing an exception to the caller only if I need to diagnose/handle true error conditions.

"The difference between genius and stupidity is that genius has its limits." - Albert Einstein

"As far as we know, our computer has never had an undetected error." - Weisert

"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010

[Chris Maunder]

VuNic wrote:

void GetAllItems(list& lst)

Why call it "Get..." when you're actually setting the ref value? A Get should return something.

cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP

[Eytukan]

It's like pushing a mug to the bar attender & saying "get" me some beer. Though there's some "set" it's actually a Get. :)

Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.

[Chris Maunder]

I always ask my bartender to instantiate a new Mug(Beer);.

cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP

[Eytukan]

Hidden implementation of your optimized bartender.

void* operator new(size_t size)
{
static Mug m;
return &m;
}

Hope there were less people before you :rolleyes:

Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.

[Lost User]

The first( passing a reference in) allows the caller to control how memory is allocated especially when using stl collections which allow a custom allocator.