Boost logo

Boost :

From: Jan Gaspar (jano_gaspar_at_[hidden])
Date: 2005-04-28 11:03:21


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_at_[hidden]>
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_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.
> >>>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

Send instant messages to your online friends http://uk.messenger.yahoo.com


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk