Simonson, Lucanus J wrote:
Stewart, Robert wrote:
Simonson, Lucanus J wrote:
I'm a little confused why there is such a narrow focus on ordering relationships here. What seems to be the most
Why is it confusing? The OP focused the thread and no one generalized it beyond the is_ordered idea.
general solution to this is a generic range adaptor that given a range over elements of type T returns an adapted range over pairs of elements of type T that are adjacent to eachother in the input range. I'm constantly writing such adaptors to convert polygon vertices to polygon edges as pairs of vertices. Combine that with a foreach or just a while loop and you can apply the predicate. We can
You say that like there's no code involved.
I'm paraphrasing, but given the adaptor and foreach the solution is a one liner:
foreach_with_early_termination(a in pair_range_adapt(input_range)), predicate());
To write that requires knowledge of foreach_with_early_termination, pair_range_adapt, whatever "a in pair_range_adapt(input_range)" means in code, and the correct way to wire them together. is_ordered looks quite compelling by contrast. That code looks almost write only. I'd expect a comment explaining it each time it appeared, so why not create a named algorithm that makes the code self documenting?
As it happens we have boost libraries that provide a basis for each of these generally useful constructs. It seems a little pointless to propose a library to combine them to solve a very specific problem. Nobody is at a loss as to how to code up something to figure out whether elements in an iterator range are sorted, and nobody would or even should look in boost for such a simple thing.
If you say so. I don't happen to agree. Unless one does such a thing with any regularity, one must find a recipe or reinvent it again each time. Your statement seems rather like suggesting that std::for_each shouldn't be in the Standard Library because "nobody is at a loss as to how to code up something" to do such a loop.
You can take my statement and apply the falicy of taking to an absurd extreme, but that doesn't prove anything. In your example for_each is a more general feature than the proposed library. We could similarly say that for loops are not needed in the language because while loops can always get the job done and nobody is at a loss as to how. This misses the point of what I was saying.
I don't think I was being absurd or extreme, or that I missed the point. I was trying to make the point that something specific is often much easier to use -- and find, for that matter -- than a more generalized solution.
Any time a library can provide a useful, robust, *named* solution to a common problem, it seems worthwhile. As could be seen from this thread, using std::adjacent_find was not immediately obvious, so there is room to write less than optimal solutions, making a Boost library solution helpful. Furthermore, if there are any compiler-specific quirks that should arise, the library can account for those and user code need not do so.
Have I missed something in your concern? Do you still disagree with including such tools in Boost, possibly in addition to your generalization?
Creating a named solution for a problem incurrs a cost in complexity in addition to a benefit. The benefit of convenience of having a named solution for a problem people face regularly needs to be greater than the cost of learning the name for all the people who need the solution. In this
That's not quite accurate. Those that know the general tools and find their assembly obvious and straightforward, can always use the general tools. Those that only want to determine whether a sequence is ordered are likely to look for is_ordered or use some search terms that easily locate it. That algorithm will be easy to understand for the simple purpose at hand.
case I think the proposed library fails the test. I find it easier to figure out how to code up whether a iterator range is sorted based on the stl alone, or on general boost capabilities than to remember a name, order of arguments and header file to include to get a library solution. In this
You propose that all must follow that approach though not all will find things as easy to figure out as you? Most folks I know of would not even begin to think in the terms you've outlined.
particular case all four uses for creasing are covered by std::is_sorted directly with predicate less<T>, greater<T>, less_equal<T> and greater_equal<T>. If you pass greater_equal<T> to is_sorted it returns true only if all elements in the range are decreasing and there are no duplicates. Now, I agree that is_sorted(b, e, greater_equal<T>()) is kind of hard to understand as meaning decreasing with no duplicates, rather than write a new library function it would be better to put /*decreasing with no duplicates*/ preceding that line in your code. So the named solution in this case is to the problem that people don't know to use the existing named solution? I hardly think adding more named solutions is going to solve that problem.
It could well be that is_ordered is sufficient, as Joachim suggested, given the set discussed before you joined the thread, but only if there were specific examples in the documentation to show how and why to use those four predicates. However, is_ordered remains far easier to grasp and use than what you described above. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.