1

I have a routine that does some moderately expensive operations, and the client could consume the result as either a string, integer, or a number of other data types. I have a public data type that is a wrapper around an internal data type. My public class looks something like this:

class Result {
 public:
  static Result compute(/* args */) {
    Result result;
    result.fData = new ExpensiveInternalObject(/* args */);
    return result;
  }

  // ... constructors, destructor, assignment operators ...

  std::string toString() const { return fData->toString(); }
  int32_t toInteger() const { return fData->toInteger(); }
  double toDouble() const { return fData->toDouble(); }

 private:
  ExpensiveInternalObject* fData;
}

If you want the string, you can use it like this:

// Example A
std::string resultString = Result::compute(/*...*/).toString();

If you want more than one of the return types, you do it like this:

// Example B
Result result = Result::compute(/*...*/);
std::string resultString = result.toString();
int32_t resultInteger = result.toInteger();

Everything works.

However, I want to modify this class such that there is no need to allocate memory on the heap if the user needs only one of the result types. For example, I want Example A to essentially do the equivalent of,

auto result = ExpensiveInternalObject(/* args */);
std::string resultString = result.toString();

I've thought about structuring the code such that the args are saved into the instance of Result, make the ExpensiveInternalObject not be calculated until the terminal functions (toString/toInteger/toDouble), and overload the terminal functions with rvalue reference qualifiers, like this:

class Result {
  // ...
  std::string toString() const & {
    if (fData == nullptr) {
      const_cast<Result*>(this)->fData = new ExpensiveInternalObject(/*...*/);
    }
    return fData->toString();
  }
  std::string toString() && {
    auto result = ExpensiveInternalObject(/*...*/);
    return result.toString();
  }
  // ...
}

Although this avoids the heap allocation for the Example A call site, the problem with this approach is that you have to start thinking about thread safety issues. You'd probably want to make fData an std::atomic, which adds overhead to the Example B call site.

Another option would be to make two versions of compute() under different names, one for the Example A use case and one for the Example B use case, but this isn't very friendly to the user of the API, because now they have to study which version of the method to use, and they will get poor performance if they choose the wrong one.

I can't make ExpensiveInternalObject a value field inside Result (as opposed to a pointer) because doing so would require exposing too many internals in the public header file.

Is there a way to make the first function, compute(), know whether its return value is going to become an rvalue reference or whether it is going to become an lvalue, and have different behavior for each case?

sffc
  • 6,186
  • 3
  • 44
  • 68
  • I assume you have measured and the overhead of allocating `ExpensiveInternalObject` on the heap instead of the stack is significant? From my experience, any "moderately expensive operations" will typically include operations on things like `std::vector` which will involve heap allocations, so one extra heap allocation is generally insignificant. – Chris Drew Apr 07 '18 at 04:59
  • You might want to look into [The Fast Pimpl Idiom](https://www.google.com/search?q=fast+pimpl+idiom) – Chris Drew Apr 07 '18 at 05:07
  • Have you considered returning a `std::tuple` with multiple types? Something like `auto result = Result::compute(args...);` – super Apr 07 '18 at 05:37

2 Answers2

1

You can achieve the syntax you asked for using a kind of proxy object.

Instead of a Result, Result::compute could return an object that represents a promise of a Result. This Promise object could have a conversion operator that implicitly converts to a Result so that "Example B" still works as before. But the promise could also have its own toString(), toInteger(), ... member functions for "Example A":

class Result {
 public:
   class Promise {
     private:
      // args

     public:
     std::string toString() const { 
        auto result = ExpensiveInternalObject(/* args */);
        return result.toString(); 
     } 
     operator Result() { 
        Result result;
        result.fData = new ExpensiveInternalObject(/* args */);
        return result;
     }
   };

   // ...

};

Live demo.

This approach has its downsides though. For example, what if, instead you wrote:

 auto result = Result::compute(/*...*/);
 std::string resultString = result.toString();
 int32_t resultInteger = result.toInteger();

result is now not of Result type but actually a Result::Promise and you end up computing ExpensiveInternalObject twice! You can at least make this to fail to compile by adding an rvalue reference qualifier to the toString(), toInteger(), ... member functions on Result::Promise but it is not ideal.

Chris Drew
  • 14,926
  • 3
  • 34
  • 54
  • Clever idea! You say that adding an rvalue reference qualifier to the `Result::Promise` functions is "not ideal"; can you elaborate? It seems pretty clean to put an lvalue qualifier (&) on the `Result` functions and then an rvalue qualifier (&&) on the `Result::Promise` functions. – sffc Apr 10 '18 at 05:50
  • I guess the "not ideal" part is that the compiler error message is rather cryptic. Hmm. – sffc Apr 10 '18 at 05:59
  • @sffc this is a similar approach to the one used by `std::vector::operator[]` and is generally considered a mistake. – Chris Drew Apr 10 '18 at 17:24
  • One other option: the `toString` method is expected to be the most common, so a static `computeToString` method can be added next to `compute`. It doesn't carry the risk of improper usage like some of the other options, at the cost of adding another function and making users read the docs to know which one is better. – sffc Apr 12 '18 at 07:30
0

Considering you can't overload a function by its return type, and you wanted to avoid making two different versions of compute(), the only thing I can think of is setting a flag in the copy constructor of Result. This could work with your particular example, but not in general. For example, it won't work if you're taking a reference, which you can't disallow.

Daniel
  • 66
  • 3