Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Returning scanned values instead of passing by reference #2

eliaskosunen opened this issue May 9, 2019 · 3 comments


Copy link

commented May 9, 2019

A concern has been raised by multiple people, as to why does scn take arguments by reference, instead of returning a tuple, forcing the user to default construct their arguments.

// What we have now
int i;
scn::input("{}", i);
// Hypothetical alternative
auto [err, i] = scn::input<int>("{}");

This comment has been minimized.

Copy link
Owner Author

commented May 9, 2019

This had been under consideration in the initial design stages of the library, but I decided on pass-by-reference for the following reasons:

  1. Consistent with scanf and std::cin

  2. Consistent with {fmt}/std::format

Argument handling/type-erasure facilities from std::format could be utilized in the future.

  1. Using tuples as return values in clunky (pre-C++17)

The library supports C++11 and 14. Without structured bindings, returning a tuple would, in my opinion, be worse than passing by reference.

int i;
scn::result<int> r;
std::tie(r, i) = scn::input<int>("{}");

This doesn't remove the problem of default-constructing the arguments before the call.

But I want to scan non-default-constructible values!

This would prevent us from scanning multiple values with a single call.

Consider this example:

auto stream = scn::make_stream("foo");

// Going to reach EOF mid-operation
auto [err, str, i] = scn::scan<std::string, int>(stream, "{} {}");
// err.error() == scn::error::end_of_stream
// str == "foo"
// i is default constructed

If a scanning operation of multiple values fails, the arguments that couldn't be read must be default-constructed.

This could be worked around of with the pass-by-reference API, by implementing a optional-like type, that only constructs the underlying non-default-constructible value on assignment. I cannot think of a way to go around this with a returning API.

// Note: this would need scn::scanner<std::optional<T>> to be specialized
std::optional<non_default_constructible> val(std::nullopt);
scn::input("{}", val); // val is only going to be assigned to if the scan succeeds

An additional advantage of the pass-by-reference API is the ability to have default values for scanned values in case of an error, because the value is not going to be modified in case of an error.

int i{42};
auto ret = scn::input("{}", i);
if (!ret) {
    assert(i == 42);
} else {
    // whatever we got from stdin

This comment has been minimized.

Copy link
Owner Author

commented May 10, 2019

An alternative API, returning a std::tuple, is available on the branch return-api.


This comment has been minimized.

Copy link
Owner Author

commented May 15, 2019

return-api-branch has been merged. The alternative API causes a ~5% slowdown, and requires C++17 to be any usable, but it's there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
1 participant
You can’t perform that action at this time.