Bob Jones wrote:
"Don" <[email protected]> wrote in message
news:[email protected]...
bearophile wrote:
Don:
In Pascal too (and OCaML, but the situation is different) they are
separated. I think here having two operators is better,
Why?
You are intelligent and expert so you must know my answer, so I fear
yours is a trick question :-)
No, it's not a trick question. You've used Python extensively, I haven't.
Two operators allow to reduce the need for casts (and
rounding/truncation), and are more explicit, allowing the code to express
its meaning better to people that come after the original programmer.
OK. I'm trying to get most of the benefits without needing an extra
operator.
Having made the switch from Delphi to C++ a few years ago I ran into this
alot. I dislike that I have to litter my arithmetic expresions with casts in
order to get the division operator to do what I want it to. And I suspect
all of those who are used to having seperate intdiv & fltdiv operators will
agree.
Your arithmetic expressions would only become "littered with casts" if
you regularly use integer division inside floating-point expressions.
Personally, I cannot recall *ever* having intentionally used integer
division inside a floating point expression. (I've seen inadvertent uses
of it, plenty of times).
So using cast(int) to mean "actualy I did intend the integer division inside
the following expression" instead of it's usual "convert this to" makes an
ugly situation even more so imo.
Well, it's really a bizarre situation. It's a very strange thing to be
doing.
The fact that adding a specific intdiv operator would not only avoid more
casting, but remove the the need for casting in a lot of existing cases
I bet there are negligible cases where casting is required.
should count pretty well against the "no more operator/keywords" argument.
Imo it should count enough to override it.
But i guess cheap&ugly is more likely to make it in than
expensive&expresive&ellegant.
