Q: c++ function that can't return a meaningful value under some conditions I have a member function with an object type as the return value type:
MyObject myfunction(parameters) {
    if (some condition) { 
        return MyObject(parameters);
    } else { 
        ... no valid object can be created ... 
    } 
}

Under certain conditions (checked for in the function body) an object of type MyObject cannot be created and returned.
Beeing just an occasional c++ programmer I can spontaneously come up with three solutions:


*

*Changing the return value type to * MyObject and returning nullptr if no valid object can be created (C++11), then checking for equality to nullptr in the calling code.

*Throwing an exception if no object can be created and catching that one in the calling code.

*Creating an object with some values that I define as invalid and check for that before using the returned object.


What would be the standard way of dealing with such a situation and the best solution in terms of performance? ... or some obvious work-around that I just don't see ...
A state-of-the-art C++11 solution would be perfect :-)
My thoughts so far:
Solution 1 seems OK, but is C++11 only and I would have to create the returned object on the heap in order to be able to pass it to the main program (returning the object itself to the calling function, thus keeping it in the stack might be quicker for small objects?).
Solution 2 might be slower and leads to verbose coding in the main program.
Solution 3 is probably the slowest (an object is created in vain) and not very convenient to check for in the main program.
For my code no valid return object is rather the default situation than the exception and the created object is rather small, but general considerations considering different cases are certainly useful for other readers' applications ...
Thanks a lot to all of you for help :-)

A: In the usual case, returning a Boost.Optional works:
boost::optional<MyObject> myfunction(parameters) {
    if (some condition) { 
        return MyObject(parameters);
    } else { 
        return boost::none;
    } 
}

And at the call site:
auto ret = myfunction(...);
if(ret)
  // use '*ret'  or 'ret.get()'

But as R. Martinho mentions, there are drawbacks to this solution (namely, move-only types don't work because Boost.Optional is not yet updated to support move-semantics).

A: Since your question is phrased in generalities, I will also respond in generalities.
If you have a function whose job it is to create and return an object, then that is it's job.  
Now if you want to design this function in such a way so that when certian conditions needed to build the object are not met then not return the object, you have actually changed the semantics of this function.  Now instead on just one responsibility, it has three:


*

*Determine if the right conditions exist to construct the object

*If yes, construct and return the object

*If no, return nothing, or some condition value that indicates non-creation


The "Single Responsibility Principle"  suggests that in general, good design dictates that one function (or class or what have you) should have one job to do.  Here, your function has three.
I would suggest that none of your suggested approaches is best in general.  Rather, I would go with:

4: Implement a separate function to determine the eligibility to
  construct the object. If that function returns true, then call
  myFunction which constructs the object & returns it.


A: All 3 of your suggested solutions are valid and common, depending on the circumstances.
If being unable to create the object is an error condition that is likely to cause the calling function to have to abort, back up and retry, or take other drastic measures, then throw an exception.
If inability to create the object is a routine event, and you expect the caller to check if an object was created and proceed fairly normally in either case, returning null is a good solution.
If there's a reasonable dummy or blank object that can be created, that's a fine solution. But this is pretty rare. You should only do this if the caller will actually process the dummy object.
If you return a null pointer and then you find that every place you call this function you are writing
MyObject* myobject=myfunction(whatever);
if (myobject==null) throw new PanicException;

Then you might as well just throw the exception inside the function.
Worse, if you are writing:
MyObject* myobject=myfunction(whatever);
if (myobject!=null)
{
  ... process it ...
}
else
{
   ... display error message ...
}

Then you are just simulating exception handling with an IF statement. Use a real exception.
On the other hand, if you throw an exception and then you find you are regularly writing:
MyObject* myobject;
try
{
  myobject=myfunction(whatever);
}
catch (PanicException pe)
{
  myobject=null;
}

Well then, you would have been better off to just return the null.
I've occasionally created dummy objects. The most common case is when a function returns a collection, like an array or linked list, and if I find no data to put in the collection, then return a collection with zero elements. Then the caller loops through the elements in the collection, and if there are none, that's just fine. I've had a few cases where I've returned an object with a zero-length string for the name or customer id or whatever. But in general, if you're just returning a dummy object so that the caller can test and say, oh, it's a dummy object, and then throw it away, I think you're better off to return null.
BTW not sure what you meant when you said that you could only return a null pointer in C++11. The ability to pass around nulls goes back to the earliest version of C++ that I ever saw.

A: The first solution should be used except if the conditions that prevent the creation of the object are exceptional. Otherwise returning a NULL pointer is a perfectly valid solution... even in C++11.
The "pointer" should of course be wrapped using an RAII container such as a std::unique_ptr. Should be common practice for you code really.
The third solution is a total waste of resources if you ask me. You would have to create an invalid (not useful) object, and copy it for the return value... only for it to be discarded.
