Thread overview
Operators shl_r, shr_r, ushr_r
Aug 21, 2002
Walter
Aug 21, 2002
Pavel Minayev
Aug 21, 2002
Walter
Aug 21, 2002
Martin M. Pedersen
August 21, 2002
These are there so you can overload:

    5 << a

but really, should this be allowable? The right operand of a shift is always an integral value. Yes, I know that disallowing this will preclude an iostream-style use of << and >>, but I'll go out on a limb and say that << and >> should not be used for that.


August 21, 2002
On Wed, 21 Aug 2002 13:34:30 -0700 "Walter" <walter@digitalmars.com> wrote:

> These are there so you can overload:
> 
>     5 << a
> 
> but really, should this be allowable? The right operand of a shift is always

Hm, why not? It might turn out to have some better uses than C++-like streaming...
August 21, 2002
"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374900584580903@news.digitalmars.com...
> On Wed, 21 Aug 2002 13:34:30 -0700 "Walter" <walter@digitalmars.com>
wrote:
> > These are there so you can overload:
> >     5 << a
> > but really, should this be allowable? The right operand of a shift is
always
> Hm, why not? It might turn out to have some better uses than C++-like streaming...

The C++ iostreams is, to me, a good illustration of why overloading of arithmetic operators should only be used to implement user-defined arithmetic types. In the spirit of add() being commutative and cmp() being usable for <, <=, > and >=, it makes sense to disallow overloading of the right operand of a shift.

BTW, it does make some sort of sense to overload ~ for stream operations, after all, one could think of it as concatenating a series of strings into a stream.


August 21, 2002
Hi,

"Walter" <walter@digitalmars.com> wrote in message news:ak0tnt$ntf$1@digitaldaemon.com...
> These are there so you can overload:
>     5 << a
> but really, should this be allowable? The right operand of a shift is
always
> an integral value.

I think it should. It would allow a BigNum class to implement the same sematics as for the primitive integrals.

Regards,
Martin M. Pedersen