Proposal: More flexible comparisons

[Juha Nieminen]

[...] You already can do

#define is ^
#define in Interval
...
if (4 is in (1, 10))
...

Preprocessor is not always your enemy.

Except that this wreaks havoc with code like this
std::istream& operator<<(std::istream& is, const T& o);
which isn't really uncommon.

Preprocessor macros messing up things is a relatively common problem.
For example, some versions of the C++ standard library implementation in
MSVC defined min() and max() as macros. This naturally caused havoc
anywhere you wanted to use those names, such as:

namespace
{
MyType min(MyType a, MyType b) { return ...; }
}

I once used an enumerated constant named NO_ERROR (inside a class) in
a library I made. Someone reported that this caused problems with some
version of Borland C++ because some library in that compiler defined
that name as a preprocessor macro.

 

[Ioannis Vranos]

There can't be any solution for this, since the


a< b< c< d


expression is currently evaluated from left to right (as usual) and it is equivalent to:

((a<b)<c)<d


which is no the expected normal notion.


If we introduce any notion that does the mathematical meaning, even this someone else suggested:


x E [1, 4]

or something similar like


x= [1,4]

x=[1,4)


e.t.c.


there will be confusion with the current evaluation of

1<x<=4


which currently is evaluated to (1<x)<=4.



However although controversial, I think the committee can force a fix on the issue and break the incorrect
notion when more than one comparison operators are present, to the correct mathematical meaning, as they did
break the notion of the largest built-in signed/unsigned integral types, with the introduction of the
unnecessary long long/unsigned long long integral types.






--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net

 

[Juha Nieminen]

But then identifiers in upper case are commonly used
for macros, so if you introduce one, you know you run
the risk of it being trampled over.
I find the habit to make constants all upper case odd,
and the only explanation I see for their existence is
that they are a left-over from the times when constants
really where macros. Get rid of that habit and have
less problems.

But it's a good example of a compiler breaking perfectly standard C++
code because of macros and their naming.

If it had either not used a macro, or used a name reserved for the
compiler (ie. starting with an underscore), the problem would not have
happened.