[boost] Re: Re: Re: [circular_buffer] comparison operators

From: Fredrik Blomqvist (fredrik_blomqvist_at_[hidden])
Date: 2005-04-22 05:36:52

Jan Gaspar wrote:
> Hi Frederik,
>
> the discussion didn't end up with a conclusion. (I
> appended all the submissions regarding this comparison
> operators issue.)
Ok.

> In my opinion, there was an idea behind the fact the
> comparison operators don't work for different types at
> the time the STL was being designed. Although I don't
> know what idea it was. (Does anyone?)
I would be interested in the rationale too. Perhaps it was
as "simple" as Pavel's note below.

> Regardless it
> was good or not I'd like the circular_buffer to behave
> the same way as other STL containers. I don't want to
> break the contract.
As I said, compliance with the standard is something
I fully agree with, but when I (briefly..) looked into the
standard it seemed like the only requirement was that
containers of same type should be comparable to eachother.
I don't interpret that as disallowing comparison with other
instances _also_.

> On the other hand when we consider comparison between
> 2 circular_buffers of different types, why not to take
> it one step further and allow comparison of 2
> different containers. E.g.
> circular_buffer<int> x  = { 1, 2, 3};
> deque<short> y  = { 1, 2, 3};
>
> x == y; // makes sense?
>
> It doesn't matter that the containers are of different
> types - it is about comparing content, isn't it?
>
Well, I don't think that's totally unreasonable.
The big catch in this case though, is that it would require an
"infrastrucure" around an is_range<> metafunction protocol
to be used with enable_if (SFINAE) code in all the operators.
This is a considerable larger effort than per container lhs/rhs type
flexibility.

Finally, my intention wasn't to make a big deal of this. I was
mostly curios about rationales and the fact that many other
components already use such a scheme, and that a recommendation
for future components perhaps could be agreed upon.

Regards
// Fredrik Blomqvist

>
> --- Fredrik Blomqvist <fredrik_blomqvist_at_[hidden]>
> wrote:
>> Jan Gaspar wrote:
>>> Hi Fredrik,
>>>
>>> I'm attaching the discussion during the formal
>> review
>>> regarding the comparison operators.
>> Thanks. I now remember reading some of those posts.
>> Did you reach a conclusion then? (Guess I have to
>> dig the archives a bit...)
>>
>>> into the reading, I'd like to say that my
>> intension
>>> was to write STL compliant container nothing less
>> or
>>> more and I'd like to stick with this.
>> That's a goal I fully support! But to my
>> understanding
>> making this change wouldn't compromise compliance
>> (?).
>> And as mentioned, several other boost components
>> already
>> use this scheme, in this context most notably
>> multi-index.
>>
>> Regards
>> // Fredrik Blomqvist
>>
>>
>>> Subject: RE: [boost] Formal Review: Circular
>> Buffer
>>> Date: Tue, 9 Mar 2004 09:44:34 -0800
>>> From: "Powell, Gary" <powellg_at_[hidden]>
>>> To: boost_at_[hidden]
>>>
>>>
>>> Shouldn't the comparison functions allow the types
>> to
>>> differ? I mean
>>> don't they still lexigraphically compare as long
>> as
>>> there is a comparison
>>> function F that a F b for each element exists
>>>
>>> circular_buffer<T, MyAlloc> x;
>>> circular_buffer<S, YourAlloc> y;
>>>
>>> bool b = x == y; for where the operator T == S is
>>> valid? And what does
>>> the allocator have to do with it?
>>>
>>> Therefore IMO, all of the comparison functions
>> should
>>> change from
>>>
>>> template< typename T, typename Alloc>
>>> bool operator F ( circular_buffer<T, Alloc> &lhs,
>>>                  circular_buffer<T, Alloc> &rhs);
>>>
>>> to
>>>
>>> template< typename T1, typename Alloc1,
>>>          typename T2, typename Alloc2>
>>> bool operator F ( circular_buffer<T1, Alloc1>
>> &lhs,
>>>                  circular_buffer<T2, Alloc2>
>> &rhs);
>>>
>>>  Yours,
>>>  -Gary-
>>>
>>> -----------------------------------------------
>>>
>>>
>>> To: boost_at_[hidden]
>>> From: "Pavel Vozenilek"
>> <pavel_vozenilek_at_[hidden]>
>>>
>>> Date: Tue, 9 Mar 2004 20:52:29 +0100
>>> Subject: [boost] Re: Formal Review: Circular
>> Buffer
>>>
>>>
>>> Hmm, do you know a STL implementation/some
>> container
>>> with this feature? It may be often bug to compare
>>> containers with
>>> different types.
>>>
>>> /Pavel
>>>
>>>
>>
> -----------------------------------------------------
>>>
>>> Subject: RE: [boost] Re: Formal Review: Circular
>>> Buffer
>>> Date: Tue, 9 Mar 2004 13:55:15 -0800
>>> From: "Powell, Gary" <powellg_at_[hidden]>
>>> To: boost_at_[hidden]
>>>
>>>
>>> No, but just because the standard libraries
>> scr*wed up
>>> is no reason to perpetuate the mistake.
>>>
>>> It's the rule of unexpected consequences.
>>>
>>> Is
>>> circular_buffer<int> x  = { 1, 2, 3};
>>> circular_buffer<short> y = { 1, 2 ,3};
>>>
>>> x == y ?? or not?
>>>
>>> Sure looks like it should work.
>>>
>>> The VTL library does it IMO correctly, allowing
>> that
>>> if there is an operation T1 F T2, then V1 F V2
>>> compiles. Otherwise you just force the user to
>> write
>>> what should be library code.
>>>