Confused by <bits/predefined_ops.h>

[François Dumont]

Hi

Names of functions and struct in this file are surely not what I am most 
proud of in libstdc++. I even think that I confess it when I proposed 
the patch :-)

As those elements are purely internal and we rarely need to be touch I 
don't consider it as a big issue but if you want to rename everything 
don't hesitate.

Note that I also have this patch pending:

https://gcc.gnu.org/ml/libstdc++/2015-10/msg00071.html

But I can surely rework it on top of your changes unless you just want 
me to forget it.

François

On 18/01/2017 14:19, Jonathan Wakely wrote:
> On 18/01/17 13:00 +0000, Jonathan Wakely wrote:
>> I've been trying to re-read the six (!) different threads about the
>> patch that introduced the <bits/predefined_ops.h> header because I
>> find the header confusing and have some questions about it.
>>
>> At the time I thought removing code from <bits/stl_algo.h> was good,
>> but now 3-4 years later I can't figure out what any of the algos are
>> doing, because of all the __ops::__iter_comp_val calls to create
>> mysterious function objects.
>>
>> The naming of the function objects seems rather arbitrary. We have
>> _Iter_equal_to_iter and _Iter_equals_iter. One of them is stateless
>> and binary, one is stateful and unary (and stores the iterator's
>> reference type, which causes PR78346). Can you guess which is which by
>> the names? I can't. Shouldn't the names indicate whether they are
>> unary or binary function objects? Then we have a function __pred_iter
>> that returns an _Iter_pred ... why are the names reversed?
>>
>> When you're in a long list of things called iter_comp_iter and
>> iter_comp_to_val and iter_less_iter and iter_that_iter_this_iter_val
>> the names are *really* important to understand what the code does.
>>
>> We have three helper functions called __iter_comp_iter but one is
>> unary and two are binary. The unary one is used to wrap an arbitrary
>> binary comparison function (usually coming from user code) to produce
>> another binary function object, but the binary ones are only used with
>> our own internal __ops function objects and they bind an iterator to
>> the function object to produce a unary function object. Why do they
>> have the same name? The unary one should be called something like
>> "make indirect", because it transforms bool(T1,T2) into bool(T1*,T2*),
>> and the binary ones should be "bind second" because they combine
>> bool(T1*,T2*) and T2* to produce bool(T1*) (i.e. partial application).
>
> And __pred_iter is another form of "make indirect", so _Iter_pred
> wouldn't be needed if we gave _Iter_comp_iter another operator()
> overload so it could be called with either one or two iterators. That
> way the same class template could be used for wrapping unary
> predicates and binary comparison functions.
>
>