{"action":"created","issue":{"url":"https://api.github.com/repos/Microsoft/GSL/issues/423","repository_url":"https://api.github.com/repos/Microsoft/GSL","labels_url":"https://api.github.com/repos/Microsoft/GSL/issues/423/labels{/name}","comments_url":"https://api.github.com/repos/Microsoft/GSL/issues/423/comments","events_url":"https://api.github.com/repos/Microsoft/GSL/issues/423/events","html_url":"https://github.com/Microsoft/GSL/issues/423","id":190558734,"number":423,"title":"More algorithms","user":{"login":"MikeGitb","id":13987901,"avatar_url":"https://avatars.githubusercontent.com/u/13987901?v=3","gravatar_id":"","url":"https://api.github.com/users/MikeGitb","html_url":"https://github.com/MikeGitb","followers_url":"https://api.github.com/users/MikeGitb/followers","following_url":"https://api.github.com/users/MikeGitb/following{/other_user}","gists_url":"https://api.github.com/users/MikeGitb/gists{/gist_id}","starred_url":"https://api.github.com/users/MikeGitb/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MikeGitb/subscriptions","organizations_url":"https://api.github.com/users/MikeGitb/orgs","repos_url":"https://api.github.com/users/MikeGitb/repos","events_url":"https://api.github.com/users/MikeGitb/events{/privacy}","received_events_url":"https://api.github.com/users/MikeGitb/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-11-20T13:39:11Z","updated_at":"2016-11-20T13:48:33Z","closed_at":null,"body":"Now that we have an implementation of `gsl::copy` I wonder, if more standard algorithms should be ported.\r\nThe two general advantages I see are:\r\n- More convenient interface \r\n\r\n      gsl::find(my_span, v); //vs\r\n      std::find(my_span.begin(), my_span.end(), v);\r\n- A varying degree of performance benefits \r\n\r\n`Copy` was a pretty clear cut case for me because\r\n- Copying data into a buffer while protecting against buffer-overflow was certainly one of the prime usage examples of `gsl::span`, so the usage should be as simple as possible to further encourage the use of it.\r\n- The performance benefits could be quite noticable (> 10x on microbenchmarks on my system). \r\n\r\nFor most other algorithms I don't expect the performance difference being really that noticeable (#376) but the more convenience interface would still be a big win. On the other hand, I'm not sure we should  add a lot of functions that become obsolete, as soon as the ranges TS gets implemented.\r\n\r\nIf you do decide that at least some additional algorithms should be added, my personal favorites would be\r\n - `equal`, `transform` and `inner_product` (here the parameter reduction would be most noticeable and I measured similar performance improvements)  \r\n - `rotate` (The interface would not improve much, but it would also gain similar performance benefits as copy)\r\n - the sorting ( `sort`, `stable_sort`, `partion` ..) and find algorithms (`find` / `find_if` ... and lower-/upper_bound) - just because I'm using them most often (I didn't make any measurements at all).\r\n"},"comment":{"url":"https://api.github.com/repos/Microsoft/GSL/issues/comments/261779403","html_url":"https://github.com/Microsoft/GSL/issues/423#issuecomment-261779403","issue_url":"https://api.github.com/repos/Microsoft/GSL/issues/423","id":261779403,"user":{"login":"rianquinn","id":5932003,"avatar_url":"https://avatars.githubusercontent.com/u/5932003?v=3","gravatar_id":"","url":"https://api.github.com/users/rianquinn","html_url":"https://github.com/rianquinn","followers_url":"https://api.github.com/users/rianquinn/followers","following_url":"https://api.github.com/users/rianquinn/following{/other_user}","gists_url":"https://api.github.com/users/rianquinn/gists{/gist_id}","starred_url":"https://api.github.com/users/rianquinn/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rianquinn/subscriptions","organizations_url":"https://api.github.com/users/rianquinn/orgs","repos_url":"https://api.github.com/users/rianquinn/repos","events_url":"https://api.github.com/users/rianquinn/events{/privacy}","received_events_url":"https://api.github.com/users/rianquinn/received_events","type":"User","site_admin":false},"created_at":"2016-11-20T13:48:33Z","updated_at":"2016-11-20T13:48:33Z","body":"I am always a huge fan of simplifying interfaces, and think this is a good idea, however I would like to play devils advocate with three questions:\r\n- If span is adopted by the STL, do we envision also pitching these new interfaces?\r\n- This would be a lot of additional code to maintain, so is this something that adds enough value to warrant to additional work?\r\n- Do you intend these to always use .begin() and .end() and if so, is it your intention that a user should use subspan to work on a sub portion of the span with these new interfaces? "}}
{"actor":{"display_login":"rianquinn"}}