• Ben Cohen <bc skygate.co.uk> Nov 15 2001
• "Pavel Minayev" <evilone omen.ru> Nov 15 2001
• "Walter" <walter digitalmars.com> Nov 15 2001

I noticed that you describe the following for Shift Expressions in the
Spec:

  It's illegal to shift by more bits than the size of the quantity being
  shifted:

     int c;
     c << 33;        error


This is one way to avoid ambiguity when shifting by large values -- such a
shift isn't specified by the C standard and problems can occur if this
happens.

I find that problems with shifting usually occur when the shift value is a
variable which happens to exceed the width of the integer type (rather
than a constant as here).  If this happens, will an error be produced or
will it be ignored as in C?  (If you don't produce an error, then this
doesn't prevent the problem.)

I suggest that it would be more useful if you made it legal to shift by
more bits than the size of the quantity being shifted, but that in this
case the result will be defined as zero; I think this is the most
intuitive behaviour. It solves the problem by giving well-defined
behaviour, and I think that it is less likely to cause problems when the
shift accidentally gets too big or small.

(Shifting by a constant out of the range should probably produce a
compiler warning or error.)


Note that in C, a negative shift isn't defined either.  I would expect 
"a << -4" and "a >> 4" to be equivalent, but they are not necessarily
(e.g., on Intel).  What is D's behaviour here?  I would suggest that you
make these two examples equivalent.  (The alternative would be to produce
an error.)


I know that this will add runtime overhead, but producing an error would
add at least as much (and in any case it might be possible to optimise
away some of the cases).


If you use >> on an unsigned integer, is it a signed or unsigned
operation?

"Ben Cohen" <bc skygate.co.uk> wrote in message
news:9t0d0s$fu5$1 digitaldaemon.com...

 Note that in C, a negative shift isn't defined either.  I would expect
 "a << -4" and "a >> 4" to be equivalent, but they are not necessarily
 (e.g., on Intel).  What is D's behaviour here?  I would suggest that you
 make these two examples equivalent.  (The alternative would be to produce
 an error.)

 I know that this will add runtime overhead, but producing an error would
 add at least as much (and in any case it might be possible to optimise
 away some of the cases).


Wouldn't it add the support code that'd slow everything down even in
release version (since behaviour of << on negative values should
stay the same)? Bit shift is a fast and effective operation as is,
one opcode, why complicate it at cost of speed?

Wouldn't it be better to throw an exception in debug version,
and ignore everything (thus producing undefined result) in release
one - like it is proposed in the specs?

"Pavel Minayev" <evilone omen.ru> wrote in message
news:9t144c$1gc7$1 digitaldaemon.com...
 Wouldn't it add the support code that'd slow everything down even in
 release version (since behaviour of << on negative values should
 stay the same)? Bit shift is a fast and effective operation as is,
 one opcode, why complicate it at cost of speed?

 Wouldn't it be better to throw an exception in debug version,
 and ignore everything (thus producing undefined result) in release
 one - like it is proposed in the specs?


That is the intent.

The trouble is that the shift instructions on the CPUs give undefined
results for out of range arguments. To specify behavior means adding check
code, which is unacceptable in most released apps.