defining NULL/Empty value for standard C++ types

Question

My class has methods that return const <Container>& because I don't want the returned container to be modified outside and copying could be expensive. for Example: const std::set<ClassA>& foo() and I want foo() to be able to return a const reference to an empty std::set<ClassA> if it has to. i.e.

const std::set<ClassA>& foo(const std::string& key) {
    std::map<std::string, std::set<ClassA>>::iterator itr = m_elements.find(key);
    return (itr != m_elements.end()) ? *itr : /*empty std::set<ClassA>*/;
}

But I cannot really return a const reference to a temporarily constructed empty std::set<ClassA> in foo(). To solve this I am defining a generic template singleton class in a common place so that it can be used with any type

template <typename T> class cNull
{
  public:
    static const T& Value() {
      static cNull<T> instance;
      return instance.d;
    }
  private:
    cNull() {};
    cNull(const cNull<T>& src);
    void operator=(cNull<T> const&);
    T d;
};

So now foo() can be something like

const std::set<ClassA>& foo(const std::string& key) {
    std::map<std::string, std::set<ClassA>>::iterator itr = m_elements.find(key);
    return (itr != m_elements.end()) ? *itr : cNull<std::set<ClassA> >.Value();
}

What I was wondering is, if there's a better way to solve this problem and if there are any issues with this design?

Answer 1

In such situation, you've usually two alternatives:

• Either you throw exception if no element is found.
• Or return some object like boost::optional which might contain the found element.

Answer 2

What I was wondering is, if there's a better way to solve this problem and if there are any issues with this design?

Sure there is: don't return a reference but a copy. When you say that "you want to be able to return an empty std::set<T>" you are just stating that you may want to change the value returned in respect to it's original state (as a member variable). A copy is perfectly fine in this case.

Answer 3

Depends a little on why you're returning a reference.

If it is because the caller expects to retain the reference and have it reflect changes made via the object on which foo was called, then what happens if you return a reference to your singleton empty set, and the same key is later added to m_elements? The reference doesn't do what it's advertised to do. It might be better to add an empty set to the map when foo is called, so the code becomes:

const std::set<int>& foo(const std::string& key) {
    return m_elements[key];
}

If you're returning a reference solely for performance reasons (to avoid a potentially expensive copy of a large set), not because you actually want the semantics of a reference to a part of the object, then returning a static empty set will work, and I suppose there's nothing wrong with having a template helper to achieve it if you find yourself doing the same thing often with several types. Be very careful to document, though, that the reference returned may or may not reflect further changes to the object (according to whether key was present when foo was called, although you might not want to guarantee that). Then callers will know to avoid using it past its sell-by date, which is whenever anyone next makes a relevant change to the object.

If you don't know why you're returning a reference, then either return a copy or else work out what it is that callers are expected to do with this set, and replace foo with one or more functions that does it. That way, you don't allow references to your class's innards to fall into the hands of users.

I've assumed that the empty set is correct for some good reason -- perhaps to avoid every caller having to test the return value and/or check for the existence of key before calling foo.

Answer 4

There are several options for doing this, but before you can pick one, you have to answer: Do I really need to return a reference?

If you are trying to operate on the result (and want it reflected in the changes - and cannot otherwise change the interface), the answer is yes. If any one of those conditions changes, you can return by copy, which makes this much easier:

std::set<int> foo(const std::string& key) const
{
    std::set<int> results;
    std::map<std::string, std::set<int>>::iterator it = m_elements.find(key); // assuming m_elements is std::map<std::string, std::set<int>>
    if (it != m_elements.end())
    {
        results = it->second;
    }
    return results;
}

If you must return a reference, you can do something like boost::optional (or use std::pair to simulate it), throw an exception, have an internal null-set. The option that is closest to what you are attempting to do is the optional/pair approach:

std::pair<bool, std::set<int>*> foo(const std::string& key)
{
    std::pair<bool, std::set<int>*> results = std::make_pair(false, nullptr);
    std::map<std::string, std::set<int>>::iterator it = m_elements.find(key);
    if (it != m_elements.end())
    {
        results.first = true;
        results.second = &(it->second);
    }
    return results;    
}

Then you can check the boolean value (guaranteed to be valid) to see if the pointer value is valid. boost::optional does something similar (and if you can use boost, prefer it over using the std::pair version to simulate it).

Answer 5

I would return a pointer, or nullptr to denote not found.

const std::set<ClassA>* foo(const std::string& key) 
{
    auto it = m_elements.find(key);
    if (it == m_elements.end()) return NULL;
    return &(*it);
}

simple, and it doesn't suffer from singletonitis.