Your choice?

[Eytukan]

When you define an API like

GetAllItems()

You'll write

void GetAllItems(list& lst)

or

list& GetAllItems()

What's your choice? Which one looks more API-consumer friendly?

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

[GParkings]

to me a 'Getfoo()' should always return a foo. if you want something to populate a collection argument it should be 'FillFoo(foo fooToFill)' choice of option depends on the details of how you expect the method to be used. if you expect the user to be working with a pre-existing collection or to call the method several times for the same collection then the latter makes sense, if you expect a one-shot 'gimme the stuffs' useage (used only to create the collection) then the former is better

Pedis ex oris Quidquid latine dictum sit, altum sonatur

[Alberto Bar Noy]

More "professional" is

void GetAllItems(list& lst)

IMO

Alberto Bar-Noy --------------- “The city’s central computer told you? R2D2, you know better than to trust a strange computer!” (C3PO)

[Aamir Butt]

Second one for three reasons: 1. It is closer to functional programming principles. 2. Allows method chaining. 3. If your function is GetSomething it should return Something

A year spent in artificial intelligence is enough to make one believe in God

[TorstenH]

I second to use the second one.

regards Torsten When I'm not working

[Lost User]

It depends.

[Tim Groven]

Agreed!

[__yash__]

LIST_GET_STATUS GetAllItems( LIST *pLst )

I would use this where LIST_GET_STATUS would either return SUCCESS or a failure code.

[Maximilien]

Language ? In C++ (pre 11), I'd do

void GetAllItems(list& lst)

c++11, I'd do (I think that's the good syntax):

list GetAllItems();

That will be a move operation on the list.

Watched code never compiles.

[W Balboos GHB]

Most commonly I'd use the second one (unless I've a particular need for the first, actually) BUT - - - it would be declared as list* GetAllItems(). [or in managed C++, list ^GetAllItems() ]. There's another option occasionally of use: Declaring the list at a scope higher (outside) the call. Then one can feed back different info, such as boolean as a success flag, or an int count of items in the list. This depends a lot on where I need to use the list and the type of persistence I require. This makes the call essentially an init or load method. Does anyone else ever use this type of method?

"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

[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.