Add pass-by-reference option for `operator>>` about sqlite_modern_cpp HOT 6 CLOSED

@Killili I also removed the extensions folder, since the type system is not working and those are extra files.
Sorry about that :-)

from sqlite_modern_cpp.

This seems to be the exact use-case for which reference-wrappers were designed. Would you consider that an option?

Basically, your all function would look like this:

std::vector<Route> all(sqlite::database db) {
  route_builder.results.empty();
  db << "SELECT * FROM routes;"
    >> std::ref(route_builder);
  return route_builder.results;
};

Note that route_builder is wrapped in a call to std::ref.

from sqlite_modern_cpp.

From the example in the docs on std::ref, it looks like std::ref is primarily intended for creating reference types to be passed to functions which take reference parameters (That's a terrible explanation. Hopefully the example they give makes it a little more clear). In this case, however, I'm trying to pass a reference to a function that takes a value, so I don't think std::ref will work as intended.

When I tried using std::ref as you showed above, I got this error:

include/modern_sqlite/utility/function_traits.h:12:13:
error: reference to overloaded function could not be resolved; did you mean to call it?
    decltype(&Function::operator())
             ^~~~~~~~~~~~~~~~~~~~~

which confuses me, because there are no obvious (to me) overloads of operator() anywhere in my code, or in std::reference_wrapper. Note that without std::ref, the code compiles/works, the only issue being the copy semantics invoked by the pass-by-value function signature.

That said, is there any advantage to using a pass-by-value signature and not implementing the pass-by-reference method? My thoughts on the matter:

• Passing by value doesn't readily allow using side-effects of the passed functions (the issue I originally ran into with the empty result vector).
• With C++11, rvalues (like temporary lambdas) can be passed "by reference" using the rvalue reference syntax - T&& - as I showed above.
• Using references avoids invoking unnecessary copy semantics. This is pretty minimal for simple types like lambdas. But with complex custom types (like my actual Builder class), invoking the copy constructor can be quite costly.

from sqlite_modern_cpp.

I see the point you are trying to make, and its a valid point.
But in this case isn't it a failure of the builder class for not having a working copy constructor? Or not being a proper Singleton? Even adding a copy constructor that just returns the object to be copied would solve this without the C++ Magic needed to work around it.

I'm trying to come up with better example where we would need that additional template but all i can think of would be solved by adding proper code or trivial in terms of performance loss.

Or and that's very possible i totally miss the point of this ;)

from sqlite_modern_cpp.

@faultyserver Thanks for the detailed explanation.

@bjoernpollex @Killili
I think faultyserver has a good point, we should support lvalue functors as well.
I did implement it in #61 vai Universal References, Let me know if you think something is missing.
If it looks good to you i will merge it tomorrow. (I think github recently added the git-apporve feature, i'm not sure if it is visible to you or not).

from sqlite_modern_cpp.

@aminroosta Wonderful! Your implementation certainly looks cleaner than mine. I was unaware of Universal References.

@Killili I think you were mostly on point, and a proper Singleton definitely would've solved the immediate issue as well. Thanks for the suggestion.

PS: Thanks for this line.

return std::move(person_builder.results); // move to avoid copying data ;-)

from sqlite_modern_cpp.