Date: Sun, 4 Oct 2020 19:53:57 +0200
Il 03/10/20 21:28, Kosher Yosher via Std-Proposals ha scritto:
> 1. Yes, that's why I had the first version using size_t, which I still
> think is better for the signed / unsigned reason you mention. That
> should be changed back.
This would instead trigger warnings for containers that use signed
integers for indexing (e.g. Qt containers) or just an index type which
is smaller than size_t. So it's another no-go.
> 2. The return value for "no match found" would be v.size() in the
> amended version, so
>
> auto i = std::count_until(v.begin(), v.end(), [](const auto& e) { return
> e.abc == 2; });
> if (i < v.size())
> {
> std::cout << "Found match at " << i << std::endl;
> }
Doesn't work. What about containers with no concept of size (e.g.
forward_list), or for which size() is O(N)?
> 3. / 4. Like I said, the function should not imply index semantics. It's
> only concern is counting elements. If the user has reasonable concern
> that the target container might be refactored into something where
> indices don't make sense, the user can put a static_assert into the code
> and catch it at compile time. Which leads into point 4. It's not going
> to help make guarantees along those lines. The responsibility for
> correctness ends with returning the correct count value. If I could
> amend the title of this thread I would drop the word index. Using the
> return value as an index should be incidental as far as the standard
> library is concerned. That's easier to defend.
I'm not sure what's meant here. What guarantees?
Thanks,
> 1. Yes, that's why I had the first version using size_t, which I still
> think is better for the signed / unsigned reason you mention. That
> should be changed back.
This would instead trigger warnings for containers that use signed
integers for indexing (e.g. Qt containers) or just an index type which
is smaller than size_t. So it's another no-go.
> 2. The return value for "no match found" would be v.size() in the
> amended version, so
>
> auto i = std::count_until(v.begin(), v.end(), [](const auto& e) { return
> e.abc == 2; });
> if (i < v.size())
> {
> std::cout << "Found match at " << i << std::endl;
> }
Doesn't work. What about containers with no concept of size (e.g.
forward_list), or for which size() is O(N)?
> 3. / 4. Like I said, the function should not imply index semantics. It's
> only concern is counting elements. If the user has reasonable concern
> that the target container might be refactored into something where
> indices don't make sense, the user can put a static_assert into the code
> and catch it at compile time. Which leads into point 4. It's not going
> to help make guarantees along those lines. The responsibility for
> correctness ends with returning the correct count value. If I could
> amend the title of this thread I would drop the word index. Using the
> return value as an index should be incidental as far as the standard
> library is concerned. That's easier to defend.
I'm not sure what's meant here. What guarantees?
Thanks,
-- Giuseppe D'Angelo | giuseppe.dangelo_at_[hidden] | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
Received on 2020-10-04 12:54:06