You could use std::find_if algorithm:

Person * lookForName(vector<Person*> &names, const std::string& input)
{
    auto it = std::find_if(names.begin(), names.end(),
              &input{ return p->getName() == input; });


    return it != names.end() ? *it : nullptr; // if iterator reaches names.end(), it's not found
}

For C++03 version:

struct isSameName
{
    explicit isSameName(const std::string& name)
    : name_(name)
    {
    }

    bool operator()(Person* p)
    {
       return p->getName() == name_;
    }
    std::string name_;
};

Person * lookForName(vector<Person*> &names, const std::string& input)
{
    vector<Person*>::iterator it = std::find_if(names.begin(), names.end(),
                           isSameName(input));


    return it != names.end() ? *it : NULL;
}

You cannot do this during references, as they should never be NULL. There are basically three options, one using a pointer, the others using value semantics.

1. With a pointer (note: this requires that the resource doesn't get destructed while the caller has a pointer to it; also make sure the caller knows it doesn't need to delete the object):

   SomeResource* SomeClass::getSomething(std::string name) {
       std::map<std::string, SomeResource>::iterator it = content_.find(name);
       if (it != content_.end()) 
           return &(*it);  
       return NULL;  
   }
   

2. Using std::pair with a bool to indicate if the item is valid or not (note: requires that SomeResource has an appropriate default constructor and is not expensive to construct):

   std::pair<SomeResource, bool> SomeClass::getSomething(std::string name) {
       std::map<std::string, SomeResource>::iterator it = content_.find(name);
       if (it != content_.end()) 
           return std::make_pair(*it, true);  
       return std::make_pair(SomeResource(), false);  
   }
   

3. Using boost::optional:

   boost::optional<SomeResource> SomeClass::getSomething(std::string name) {
       std::map<std::string, SomeResource>::iterator it = content_.find(name);
       if (it != content_.end()) 
           return *it;  
       return boost::optional<SomeResource>();  
   }
   

If you want value semantics and have the ability to use Boost, I'd recommend option three. The primary advantage of boost::optional over std::pair is that an unitialized boost::optional value doesn't construct the type its encapsulating. This means it works for types that have no default constructor and saves time/memory for types with a non-trivial default constructor.

I also modified your example so you're not searching the map twice (by reusing the iterator).

Value of return type std::vector<int> cannot be nullptr.

The most straightforward way in this case is to return std::unique_ptr<std::vector<int>> instead - in this case it's possible to return nullptr.

Other options:

• throw an exception in case of fail
• use optional<std::vector<int>> as return type (either boost::optional or std::optional if your compiler has this C++17 feature)
• return bool parameter and have std::vector<int>& as output parameter of function

The best way to go really depends on the use case. For example, if result vector of size 0 is equivalent to 'fail' - feel free to use this kind of knowledge in your code and just check if return vector is empty to know whether function failed or succeed.

In my practice I almost always stick to return optional (boost or std, depending on environment restriction). Such interface is the most clear way to state the fact that 'result can either be present or not'.

To sum up - this is not a problem with the only one right solution. Possible options are listed above - and it's only a matter of your personal experience and environmental restrictions/convetions - which option to choose.

In C++, references can't be null. If you want to optionally return null if nothing is found, you need to return a pointer, not a reference:

Attr *getAttribute(const string& attribute_name) const {
   //search collection
   //if found at i
        return &attributes[i];
   //if not found
        return nullptr;
}

Otherwise, if you insist on returning by reference, then you should throw an exception if the attribute isn't found.

(By the way, I'm a little worried about your method being const and returning a non-const attribute. For philosophical reasons, I'd suggest returning const Attr *. If you also may want to modify this attribute, you can overload with a non-const method returning a non-const attribute as well.)

Returning NULL in case of success (the most simple case for success at that) is definitely contrary to what most people will expect.

Returning a pointer that the user has to manually destruct isn’t super great either. I’d suggest using C++11 unique_ptr but using C++11 may not be feasible in your case.

One thought I had is to make TestRoute private and have the Planner call it whenever it computes a new route.

If the test fails, return NULL, otherwise return the route.

What’s nice about this approach is that you can implement TestRoute however you (or your colleague) please, and the user of the class won’t need to know the details of how it is implemented. The user will just ask for a route from point A to point B and will be guaranteed it’s a valid route with refueling points so long as they don’t receive NULL.

You could also split your method into a few different methods if the performance hit isn’t too great.

For example, for TestRoute, have it return true if the route is possible, false if not.

bool TestRoute(const Route* r)

Have another method TestRouteNeedRefuel that returns true if the route will require refueling, false if not

bool TestRouteNeedRefuel(const Route* r)

Then have a final method, GenerateRefuelRoute that returns a new route with the proper refuel points

Route* TestRoute(const Route* r)
//use this if at all possible
std::unique_ptr<Route> TestRoute(const Route* r)

As far as performance goes, remember to profile before making assumptions. If your colleague is worried about copying Route more than needed (and he may have good reason to, as we don't know how expensive it is or what the target platform is) then clearly performance is an important requirement. I would suggest first implementing as clean an interface as can be done, profiling to find where the bottlenecks REALLY are, and then implementing a few speed hacks where necessary.

Since both are pointing to the same object, if either obj or d_header is changed, the change will be reflected in the other.

That is incorrect. If the contents of what they point to is changed, that change can be seen through either pointer but if one of them is changed so that it points to something different, the other will still point to the previous object.

Simple example:

int i = 10;
int j = 20;

int* ptr1 = &i;
int* ptr2 = ptr1;

At this point, both the pointers point to the same object, i. Value of i can be changed by:

1. Directly by assigning a value to i.

    i = 15;
   

2. Indirectly by assigning a value to where ptr1 points to.

    *ptr1 = 15;
   

3. Indirectly by assigning a value to where ptr2 points to.

    *ptr2 = 15;
   

However, you can change where ptr1 points to by using:

ptr1 = &j;

Now, ptr1 points to j but ptr2 still points to i.

Any changes made to i will be visible through ptr2 but not ptr1.
Any changes made to j will be visible through ptr1 but not ptr2.

Isn't obj also pointing to null, since both object were pointing to the same object?

The answer should be clear now. obj continues to point to what d_header used to point to. It is not NULL.

So what is the deal of returning a Null pointer?

The function does not necessarily return a NULL pointer. The function returns whatever d_header used to point to before it was changed to be nullptr. It could be a NULL pointer if d_header used to be NULL before the call to the function.

is nullptr in this case would be the same as delete?

No, it is not. There are two different operations. Assigning a pointer to nullptr does not automatically mean that delete gets called on the pointer. If you need to deallocate memory that a pointer points to, you'll have to call to call delete explicitly.

The return nullptr statement is implicitly constructing a unique_ptr<MyClass> instance and you're then returning a reference to it, hence the warning. A simple fix is to define a static unique_ptr<MyClass> that holds nullptr and return a reference to that instead.

const unique_ptr<MyClass>& find_it(const string &key, const DB &db)
{
  static unique_ptr<MyClass> not_found;

  auto itr = db.find(key);
  if (itr == db.end()) {
    return not_found;
  }
  return itr->second;
}

A better fix might be to use boost::optional. Change the return type to boost::optional<std::unique_ptr<MyClass>> const&, and then return boost::none if the object is not found.