Boost logo

Boost :

From: Sylvain Pion (pion_at_[hidden])
Date: 2002-09-06 19:04:35

On Fri, Sep 06, 2002 at 11:33:25PM +0200, Gabriel Dos Reis wrote:
> | Given the high similarity with std::complex, consistency with std::complex
> | is a serious option, right ?
> Wrong.

But your following argument is not againt inconsistency, you just argue that
std::complex is buggy. Which is not the same thing at all.

> Several people have proposed to add a std::less<complex<> >.
> (I certainly would like to see something similar ge into the the next
> version of C++).

OK, it's a proposal, it's your view, and some people share it, that's fine.
Anybody can make a proposal and discuss.
But is it (has it been ?) debated in some WGs ?
What are the chances, and of which resolution, in the next revision ?

That's the real question that I'd like to see solved before we decide if the
same arguments also apply to boost::interval. I have not seen these arguments
myself behind your claims of "past mistakes". How do I differentiate that
from your own opinions ?

interval is not standard and can evolve anyway, especially since the option of
no default policy, can be trivially made backward compatible with a possible
future addition of a default. So since this issue is not clearly fixed at all,
the safe side is definitely not to provide any default for now.

> | Agreed, but you may perfectly want to have a non-standard class with the same
> If you have a non-standard class, then it is not std:complex<>,
> therefore, there is no issue about std::less<std::complex<> >.

Yep, but I assumed std::less and opertor< were supposed to have the same
meaning (otherwise it's confusing, see Guillaume's argument for 2 different
classes). operator< has global consequences, whereas std::less has far less.

> | > Don't over-abstract. Or you'll get where we're with std::complex<> --
> | > a perfect example of standard over-abstraction.
> |
> | It seems that we agree that interval and complex are really equivalent beasts
> | on this topic.
> | So all boils down to the fact that you think the standard is wrong for
> | complex, and you would like to push your view on boost::interval.
> No.
> All I'm saying is that the over-abstraction put in std::complex<> is
> NOT an example to reproduce; it is an example to avoid. Let's not
> repeat the mistake.

It's your view that it's a mistake.
Does everybody obviously shares this view ?
Personnaly, I don't really feel that std::complex is overly over-abstracted,
but I'm used to abstraction as you noted.
I must admit that I miss the key arguments behind this claim.
The lack of std::less specialization cannot really be that, right ?

> | May I mention that I therefore have the majority of the standard commitee
> | on my side ? :)
> How did you make the count?

Simply because IF (I don't know) the issue has been discussed before rejection
(I just look at the standard which tells me there's no such order, so I
conclude it has been rejected if the issue has been considered), then I
presume it is the consequence of a vote (any reasonnable comitee has a voting
procedure, right ? :), whose majority decided for the rejection.
Am I wrong ?
Or has the issue not been debated at all, or postponed or whatever ?

> | More seriously, I do not know what have been the discussions of the standard
> | commitee (you surely know better) about this question, if there has been any.
> | But may I suggest that you _first_ try to get the std::complex "fixed" with
> | the standard working groups.
> As you might probably know, I can't speak for the committee. But I
> can point out mistakes made in the past and argue against reproducing
> them. With your reasoning, any new library should follow all
> imaginable mistakes made in the standard, and correct them only *after*
> the standard issued a TC. IMHO, that is a nonsensical approach to
> library design especially when we know of the mistakes and we know we
> would have done better had we debatted of the issues much deeply.

I want to be sure that we are really in a position where "we know of the
mistakes". That's why I don't want only your opinion on this, but a consensus
of the commitee to confirm that. Otherwise, it remains just your own view.

So to recap :
you suggest specializing std::less<boost::interval<>> to be the lexicographic
order. It either means that std::less will have a different meaning than
operator<, or it means that operator< has a useless arithmetical sense.
(I assume from the other threads that it's important to have both std::less
and operator< keep the same meaning.)

I do not find these options satisfactory at all.

Or are you ready to have std::less have a different meaning than operator< ?
( I don't really have an opinion on this one. )
Or let operator< have no arithmetic sense ?
( I do have a strong opinion against this one. )


Boost list run by bdawes at, gregod at, cpdaniel at, john at