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

Because a reference carries the semantic that it points to a valid memory address that never changes; i.e. that dereferencing it is safe/defined and so no NULL checks are required. References cannot be reassigned by design.

You use a pointer when the var can be NULL and client code has to handle that case. You use a reference when you can guarantee a valid/initialised memory address.

One example of using pointers is as a member of a class to store a "reference" to some instance that might not be known or able to be initialised at class construction time. However, member references must be initialised at construction time (via initialiser lists) and their assignment cannot be deferred.

If you allow a null reference it is then no different to a pointer besides syntax (the same NULL checks would need to take place.)

Update:

"And, in most OOP languages, objects can be NULL - Pascal, C#, Java, JavaScript, PHP, etc. [...] So why is C++ somehow special and doesn't have a NULL object? Was it just an overlook or an actual decision?"

I think you are a bit confused about this. Java and C# etc. might give the impression of "NULL objects", but these object references are more or less like a C++ pointer with simpler syntax, GC instrumentation and exception throwing. In those languages if you operate on a "Null Object" you will get some kind of exception like NullReferenceException (C#). Hell, in Java its called a NullPointerException.

You have to check for null before you can use them safely. Kind of like C++ pointers (except in most managed languages, pointers are initialised to NULL by default, whereas in C++ its usually up to you to take care of setting the initial pointer value (otherwise undefined/whatever memory was already there)).

The C++ view is about having choice, and hence being verbose:

• Use a plain pointer to do how you please, checking NULL where necessary.
• Use references which have a compiler-enforced validity semantic/constraint.
• Roll your own smart pointers that do bookkeeping and behave whichever way you want them to.
• Using void pointers (cautiously!) to reference an untyped block of memory if ever required.

In C and C++, pointers are inherently unsafe, that is, when you dereference a pointer, it is your own responsibility to make sure it points somewhere valid; this is part of what "manual memory management" is about (as opposed to the automatic memory management schemes implemented in languages like Java, PHP, or the .NET runtime, which won't allow you to create invalid references without considerable effort).

A common solution that catches many errors is to set all pointers that don't point to anything as NULL (or, in correct C++, 0), and checking for that before accessing the pointer. Specifically, it is common practice to initialize all pointers to NULL (unless you already have something to point them at when you declare them), and set them to NULL when you delete or free() them (unless they go out of scope immediately after that). Example (in C, but also valid C++):

void fill_foo(int* foo) {
    *foo = 23; // this will crash and burn if foo is NULL
}

A better version:

void fill_foo(int* foo) {
    if (!foo) { // this is the NULL check
        printf("This is wrong\n");
        return;
    }
    *foo = 23;
}

Without the null check, passing a NULL pointer into this function will cause a segfault, and there is nothing you can do - the OS will simply kill your process and maybe core-dump or pop up a crash report dialog. With the null check in place, you can perform proper error handling and recover gracefully - correct the problem yourself, abort the current operation, write a log entry, notify the user, whatever is appropriate.

This code doesn't work, though it may appear to work. This line dereferences a null pointer:

return *static_cast<MyType*>(0);

The zero, cast to a pointer type, results in a null pointer; this null pointer is then dereferenced using the unary-*.

Dereferencing a null pointer results in undefined behavior, so your program may do anything. In the example you describe, you get a "null reference" (or, it appears you get a null reference), but it would also be reasonable for your program to crash or for anything else to happen.

Just like this is never null. In fact, GCC will remove checks for null this because it can never be null.

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

If the function checks the index then a general approach in such a case is to throw an exception std::out_of_range.

Take into account that there is already the member function at in the class template std::vector.

If you may not use exceptions and the task is

P.S. Original task is searching item with property equal to.

then you can use either the standard algorithm std::find_if that returns an iterator or you can write your own function that returns the index that corresponds to the searched element. If there is no such an element then return the size of the vector, For example

#include <iostream>
#include <vector>

template <typename Predicate>
std::vector<int>::size_type find_if( const std::vector<int> &v, Predicate predicate )
{
    std::vector<int>::size_type i = 0;

    while ( i != v.size() && !predicate( v[i] ) ) ++i;

    return i;
}

int main() 
{
    std::vector<int> items = {1, 2, 5, 0, 7};

    auto i = ::find_if( items,  { return item % 2 == 0; } );

    if ( i != items.size() ) std::cout << items[i] << '\n';

    return 0;
}