Re: [boost] Re: Re: [circular_buffer] comparison operators
Hi Frederik, the discussion didn't end up with a conclusion. (I appended all the submissions regarding this comparison operators issue.) 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?) 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. 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? Jan --- Fredrik Blomqvist <fredrik_blomqvist@home.se> 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@amazon.com> To: boost@lists.boost.org
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@lists.boost.org From: "Pavel Vozenilek" <pavel_vozenilek@hotmail.com>
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@amazon.com> To: boost@lists.boost.org
No, but just because the standard libraries
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
scr*wed up 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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Send instant messages to your online friends http://uk.messenger.yahoo.com
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@home.se> 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@amazon.com> To: boost@lists.boost.org
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@lists.boost.org From: "Pavel Vozenilek" <pavel_vozenilek@hotmail.com>
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@amazon.com> To: boost@lists.boost.org
No, but just because the standard libraries
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
scr*wed up 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.
Hi Frederik! I realized there is no reason to implement the comparison operators - functions std::equal() and std::lexicographical_compare() do the job. std::vector<int> v; v.push_back(1); v.push_back(2); v.push_back(3); std::deque<short> d; d.push_back(1); d.push_back(2); d.push_back(3); std::lexicographical_compare(v.begin(), v.end(), d.begin(), d.end()); std::equal(v.begin(), v.end(), d.begin()); Jan --- Fredrik Blomqvist <fredrik_blomqvist@home.se> wrote:
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@home.se> 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@amazon.com> To: boost@lists.boost.org
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@lists.boost.org From: "Pavel Vozenilek" <pavel_vozenilek@hotmail.com>
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@amazon.com> To: boost@lists.boost.org
No, but just because the standard libraries
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
scr*wed up 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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Send instant messages to your online friends http://uk.messenger.yahoo.com
"Jan Gaspar" wrote:
I realized there is no reason to implement the comparison operators - functions std::equal() and std::lexicographical_compare() do the job.
std::vector<int> v; v.push_back(1); v.push_back(2); v.push_back(3);
std::deque<short> d; d.push_back(1); d.push_back(2); d.push_back(3);
std::lexicographical_compare(v.begin(), v.end(), d.begin(), d.end());
std::equal(v.begin(), v.end(), d.begin());
Generic code may require operator ==(). /Pavel
participants (3)
-
Fredrik Blomqvist -
Jan Gaspar -
Pavel Vozenilek