Difference between revisions of "Talk:cpp/algorithm"
(algorithms is in the spec) |
|||
(13 intermediate revisions by 6 users not shown) | |||
Line 31: | Line 31: | ||
[[Special:Contributions/192.64.159.11|192.64.159.11]] 09:46, 16 March 2018 (PDT) Slava | [[Special:Contributions/192.64.159.11|192.64.159.11]] 09:46, 16 March 2018 (PDT) Slava | ||
+ | |||
+ | == Making the constrained algorithms more obvious == | ||
+ | |||
+ | I suspect that newcomers will skip past the constrained algorithms section straight to the ''Cpp17Algorithms'' (sic) below, so it might be worthwhile moving the unconstrained algorithms into a ''Legacy Algorithms'' sub-page. [[User:Cjdb|Cjdb]] ([[User talk:Cjdb|talk]]) 20:11, 1 July 2020 (PDT) | ||
+ | |||
+ | : how about inlining the technical differences in the same cpp/algorithm page, keeping the grouping by type, e.g. | ||
+ | {{dsc begin}} | ||
+ | {{dsc h2 | Modifying sequence operations}} | ||
+ | {{dsc inc | cpp/algorithm/dsc copy}} | ||
+ | {{dsc inc | cpp/algorithm/ranges/dsc copy}} | ||
+ | {{dsc inc | cpp/algorithm/dsc copy_n}} | ||
+ | {{dsc inc | cpp/algorithm/ranges/dsc copy_n}} | ||
+ | {{dsc end}} | ||
+ | : we'd have to drop "included in header" to avoid noise in that list --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 06:08, 2 July 2020 (PDT) | ||
+ | :: I'd want the names of the constrained algos to have {{tt|ranges::}} prefixed. [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 06:50, 2 July 2020 (PDT) | ||
+ | ::: SGTM (it's already been done for the CPOs) [[User:Cjdb|Cjdb]] ([[User talk:Cjdb|talk]]) 09:30, 2 July 2020 (PDT) | ||
+ | :: Done, but I'm not entirely sure how to make the navbar's content not appear overcrowded. Any suggestions? [[User:Cjdb|Cjdb]] ([[User talk:Cjdb|talk]]) 11:10, 2 July 2020 (PDT) | ||
+ | ::: One possible way is to simply replace the cpp/algorithms navbar with cpp/algorithms/ranges' navbar, which includes the former in its breadcrumbs. [[User:Cjdb|Cjdb]] ([[User talk:Cjdb|talk]]) 13:15, 2 July 2020 (PDT) | ||
+ | :::: I missed this discussion when reverting the changes, but the changes are awful, the page is incredibly noisy with all the ranges stuff inlined. I suggest either keeping things the way they are and relying on readers to see the constrained algorithms section at the top of the page (would be nice to assume that technical reference readers wouldn't miss something like that); or do what the standard text does by including the ranges versions of the algorithms alongside the regular versions in each page and deleting the constrained algorithms section. --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 09:27, 3 August 2020 (PDT) | ||
+ | ::::: separate page for what should be front and center is much worse that having to browse a longer page (also, sub-headings make it somewhat less tedious). I do like the idea of adding an overload to each algorithm's page because, IMO, any way you look up "sort" on cppreference, be it browsing /cpp/algorithm or landing directly on /cpp/algorithm/sort should present the modern sorts (rangified and parallel) along with the old STL sort. Otherwise cppreference falls in the same trap as so many C++ books that bias for old features by describing the new ones as an afterthought. I don't think /cpp/algorithm list would that be much shorter, but it would avoid awkward repeated descriptions on the right: | ||
+ | current: | ||
+ | {{dsc begin}} | ||
+ | {{dsc h2 | Modifying sequence operations}} | ||
+ | {{dsc inc | cpp/algorithm/dsc copy}} | ||
+ | {{dsc inc | cpp/algorithm/ranges/dsc copy}} | ||
+ | {{dsc inc | cpp/algorithm/dsc copy_n}} | ||
+ | {{dsc inc | cpp/algorithm/ranges/dsc copy_n}} | ||
+ | {{dsc end}} | ||
+ | possible: | ||
+ | {{dsc begin}} | ||
+ | {{dsc h2 | Modifying sequence operations}} | ||
+ | {{dsc tfun | cpp/algorithm/copy | copies a range of elements to a new location | title=copy<br>copy_if<br>ranges::copy<br>ranges::copy_if | notes=<br>{{mark c++11}}<br>{{mark c++20}}<br>{{mark c++20}} }} | ||
+ | {{dsc tfun | cpp/algorithm/copy_n | title=copy_n<br>ranges::copy_n | copies a number of elements to a new location | notes={{mark c++11}}<br>{{mark c++20}} }} | ||
+ | {{dsc end}} | ||
+ | ::::: I'll flip it back to Cjdb's version for now though, it's better than a separate page. --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 11:53, 3 August 2020 (PDT) | ||
+ | Okay I agree with that reasoning. I think it's probably the repeated description that make the page look so noisy in the first place. I do worry that a combined old-school and ranges description of the algorithms would become super noisy instead though, mostly due to the ranges' use of concepts and the extra template parameters. --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 16:58, 3 August 2020 (PDT) | ||
+ | |||
+ | == Page name? == | ||
+ | |||
+ | The page URL is "algorithm" the header is <code><algorithm></code>, yet the name on the page is "Algorithms library". Is there any reason not to have that text say "Algorithm library"? That has the distinct advantage that it's consistent with the header name and so helps people remember to <code>#include <algorithm></code>. [[User:BenFrantzDale|BenFrantzDale]] ([[User talk:BenFrantzDale|talk]]) 16:25, 1 April 2021 (PDT) | ||
+ | |||
+ | : Not a chance, IMO, - too may links to update, to say the least. Also HTML/browsers-diversity put their own restrictions.<br/> You may download the site's archive (if not yet) [[https://en.cppreference.com/w/File:cppreference-doc-20190607.zip]](~53mb) to investigate this site's dirs/pages structure.) Hm, 1 April? --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 06:03, 2 April 2021 (PDT) | ||
+ | |||
+ | :: FWIW the C++ standard calls it "Algorithms library" https://eel.is/c++draft/algorithms --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 07:15, 6 April 2021 (PDT) |
Latest revision as of 06:15, 6 April 2021
Simple question: Why is count() listed here and distance() listed in the iterators library?--Gemini67 (talk) 06:35, 19 September 2014 (PDT)
- The most direct answer is probably that std::count is a part of the algorithms library in C++ (chapter 25 of the standard), while std::distance is part of the Iterators library (chapter 24 of the standard). They are also declared in different headers. Note that
std::count
does something with the elements of a sequence, whilestd::distance
operates on iterators only. --Cubbi (talk) 04:21, 19 September 2014 (PDT)- Thank you for the detailed explanation.
However, the question arose because I was looking for a count() without a condition == distance(). But I never used distance() before so I did not think about it ...
Is it possible to add a link to the iterators library, saying something like 'for more operations on iterators look here'?--Gemini67 (talk) 06:35, 19 September 2014 (PDT) - It's an interesting observation that count degenerates into distance: I made a note on std::count page. Many libraries in C++ are closely related, especially the ones that originated in STL (containers, algorithms, function objects, and iterators): I'm not sure it makes sense to single one out. --Cubbi (talk) 07:06, 19 September 2014 (PDT)
- Thank you for the detailed explanation.
134.130.191.106 05:51, 12 June 2015 (PDT)Would it be possible to show the return type of the algorithms in this page?
Rather a very general question with respect to the Wiki engine, but as the "problem" hit me the first time here, I ask here:
I now frequently link (from my C++ training documents) to en.cppreference.com pages, and sometimes I want to link directly to a sub-section. Usually this is quite easy by taking the title of the sub-section, replace spaces with underscore and append the result with a '#' to the page URL.
But I don't know how the parentheses - as in some subsection names of this page, e.g. "... (on sorted ranges)" - need to be mapped and what I tried naively doesn't appear to work.
Mwe (talk) 09:38, 12 July 2015 (PDT)
- It's http://en.cppreference.com/w/cpp/algorithm#Binary_search_operations_.28on_sorted_ranges.29. T. Canens (talk) 12:06, 12 July 2015 (PDT)
Contents |
[edit] Is it appropriate to place for_each under non-modifying sequence operations?
If the elements in the sequence are mutable, it's possible to modify the elements with std::for_each algorithm.
Or do I misunderstand the terminology here?
- 'Modifying' in this context is referring to the sequence itself rather than the values within the sequence. std::for_each won't invalidate any iterators (unlike e.g. std::reverse), nor is it capable of producing a new sequence (e.g. std::transform). --Ybab321 (talk) 06:15, 29 November 2017 (PST)
[edit] Explicit statement for empty ranges should be added
I think there should be added an explicit statement that executing any algo on empty range (first==last) is safe and either a noop or returns last immediately (if algo returns something or not).
192.64.159.11 09:46, 16 March 2018 (PDT) Slava
[edit] Making the constrained algorithms more obvious
I suspect that newcomers will skip past the constrained algorithms section straight to the Cpp17Algorithms (sic) below, so it might be worthwhile moving the unconstrained algorithms into a Legacy Algorithms sub-page. Cjdb (talk) 20:11, 1 July 2020 (PDT)
- how about inlining the technical differences in the same cpp/algorithm page, keeping the grouping by type, e.g.
Modifying sequence operations | |
(C++11) |
copies a range of elements to a new location (function template) |
(C++20)(C++20) |
copies a range of elements to a new location (niebloid) |
(C++11) |
copies a number of elements to a new location (function template) |
(C++20) |
copies a number of elements to a new location (niebloid) |
- we'd have to drop "included in header" to avoid noise in that list --Cubbi (talk) 06:08, 2 July 2020 (PDT)
- I'd want the names of the constrained algos to have
ranges::
prefixed. T. Canens (talk) 06:50, 2 July 2020 (PDT) - Done, but I'm not entirely sure how to make the navbar's content not appear overcrowded. Any suggestions? Cjdb (talk) 11:10, 2 July 2020 (PDT)
- One possible way is to simply replace the cpp/algorithms navbar with cpp/algorithms/ranges' navbar, which includes the former in its breadcrumbs. Cjdb (talk) 13:15, 2 July 2020 (PDT)
- I missed this discussion when reverting the changes, but the changes are awful, the page is incredibly noisy with all the ranges stuff inlined. I suggest either keeping things the way they are and relying on readers to see the constrained algorithms section at the top of the page (would be nice to assume that technical reference readers wouldn't miss something like that); or do what the standard text does by including the ranges versions of the algorithms alongside the regular versions in each page and deleting the constrained algorithms section. --Ybab321 (talk) 09:27, 3 August 2020 (PDT)
- separate page for what should be front and center is much worse that having to browse a longer page (also, sub-headings make it somewhat less tedious). I do like the idea of adding an overload to each algorithm's page because, IMO, any way you look up "sort" on cppreference, be it browsing /cpp/algorithm or landing directly on /cpp/algorithm/sort should present the modern sorts (rangified and parallel) along with the old STL sort. Otherwise cppreference falls in the same trap as so many C++ books that bias for old features by describing the new ones as an afterthought. I don't think /cpp/algorithm list would that be much shorter, but it would avoid awkward repeated descriptions on the right:
- I missed this discussion when reverting the changes, but the changes are awful, the page is incredibly noisy with all the ranges stuff inlined. I suggest either keeping things the way they are and relying on readers to see the constrained algorithms section at the top of the page (would be nice to assume that technical reference readers wouldn't miss something like that); or do what the standard text does by including the ranges versions of the algorithms alongside the regular versions in each page and deleting the constrained algorithms section. --Ybab321 (talk) 09:27, 3 August 2020 (PDT)
- One possible way is to simply replace the cpp/algorithms navbar with cpp/algorithms/ranges' navbar, which includes the former in its breadcrumbs. Cjdb (talk) 13:15, 2 July 2020 (PDT)
- I'd want the names of the constrained algos to have
current:
Modifying sequence operations | |
(C++11) |
copies a range of elements to a new location (function template) |
(C++20)(C++20) |
copies a range of elements to a new location (niebloid) |
(C++11) |
copies a number of elements to a new location (function template) |
(C++20) |
copies a number of elements to a new location (niebloid) |
possible:
Modifying sequence operations | |
(C++11)(C++20)(C++20) |
copies a range of elements to a new location (function template) |
(C++11)(C++20) |
copies a number of elements to a new location (function template) |
Okay I agree with that reasoning. I think it's probably the repeated description that make the page look so noisy in the first place. I do worry that a combined old-school and ranges description of the algorithms would become super noisy instead though, mostly due to the ranges' use of concepts and the extra template parameters. --Ybab321 (talk) 16:58, 3 August 2020 (PDT)
[edit] Page name?
The page URL is "algorithm" the header is <algorithm>
, yet the name on the page is "Algorithms library". Is there any reason not to have that text say "Algorithm library"? That has the distinct advantage that it's consistent with the header name and so helps people remember to #include <algorithm>
. BenFrantzDale (talk) 16:25, 1 April 2021 (PDT)
- Not a chance, IMO, - too may links to update, to say the least. Also HTML/browsers-diversity put their own restrictions.
You may download the site's archive (if not yet) [[1]](~53mb) to investigate this site's dirs/pages structure.) Hm, 1 April? --Space Mission (talk) 06:03, 2 April 2021 (PDT)
- FWIW the C++ standard calls it "Algorithms library" https://eel.is/c++draft/algorithms --Cubbi (talk) 07:15, 6 April 2021 (PDT)