That's the same pointer version from before, not a reference.

If you are asking for permission, you can do it however you want. That way is functional.

The design you use depends on your actual needs. In the case you just gave you're returning a null pointer, which often works for designs but sometimes not. If your system is built so that it detects null pointers coming from the function, and everywhere you use it you always test for a null result, then it works.

If you really need a reference to an object, some designs will use a special "failure object". It is not a null pointer, instead it is a valid object with a bunch of special features. It can be useful in systems like creating a game object from an object factory in a large data-driven game. Creating a failure object in this kind of game will pull up some dialog boxes on debug builds and test builds so QA can log it, but the failure object can be gracefully used as a valid game object by all the game systems.

I think Brother Bob may have misread the code, "it" is not directly an iterator object. A different name can help disambiguate, e.g. "entry", "element", etc.

Indeed I did. The name sure made me assume it was an iterator so I didn't even pay attention to the loop. Thanks for pointing that out.

Thank you for the reply.

All of this information is great...

But you're just re-implementing std::find_if... So why not use that?

auto foundIterator = std::find_if(m_OneContainer.begin(), m_OneContainer.end(), [id] (const COne& item) {return item.getID() == id;});
// Now, if foundIterator == m_OneContainer.end(), the item wasn't found, otherwise dereference the iterator to get the item

Thank you for the reply. I will try this :).

Hi.

You could define some return codes and pass out the params from the functions params and check the return code of the function.

Like.

DWORD Find(cOne &out, other params if needed)

{

DWORD error = MYDEFINE_ERROR;

if(not found)

return error;

return MYDEFINE_ALLOK;

}

Sorry ankhd, but I cannot see anything positive with that.

Why would you use a Win32-only type like DWORD? Especially with the standard library offering you much better alternatives like std::uint32_t or std::uint_fast32_t. Why use something like that at all when a bool does it? Or if you actually needed more return values, why not a (strongly type) enum? Why defines?

Also, you need cOne to have an input instance here. Not everything is default constructible that easily, if it is not, where to get the input instance? cOne must also by assignable for this to work (and if it's assignable, an assign can be very expensive). Granted, both of these problems could be fixed by using a pointer instead of a reference or knowing exactly what cOne can and cannot do.

But at the end of the day I still see no advantage of this of this compared to SmkViper's use of std::find_if.