Boost logo

Boost :

From: Maxim Shemanarev (mcseem_at_[hidden])
Date: 2002-08-21 22:30:33


> If the committee is seriously considering ways to handle stuff, how about
> dealing with the two results returned by almost every integer divide
> instruction... quotient and remainder.

Right. That's another thing. But in this case if you write x=a/b; y=a%b; a
compiler at least *can try* to optimize this. In case of x*a/b it cannot
because it's not allowed to! The question is really not a technical one. We
really don't have a choice even if we were the ANSI committee.

Suppose, it's resolved, i.e. an experssion x*a/b works as I want. I honestly
don't think there're lots of code will be affected, moreover, I believe that
there's nothind serious will go wrong. If something will it means it was
*written* wrong, at least not in a professional manner. Still if I were the
committee I wouldn't take the responsibility to change these things
because... I just would be afraid to. We live in the real world. So. The
only possibility is to add thing but not change the existing ones even when
they look stupid.

There's another thing. Actually there's no way to make the expression
y=x*a/b work as I proposed (i.e. using 64-bit for x*a). That's because it's
not clear what to do with more complex expressions, like y=x*a*b*c*d/e;
Really, what? As soon as x*a is computed we will have to deal with the rest
of the expression in 64 bits, but we rally don't need to! There's no choice.
So, let it be as it is! But I (and we) really need some sort of a new syntax
for simple constructions like y=x*a/b. The syntax with a separate variable
as the intermediate result is also not appropriate because there's also not
clear for the compiler. Suppose we have code like:
longest_long t=x*a;
blah_blah=blah_blah_function(blah_blah_blah);
int final_result = t/b;
I don't think we could rely on any optimizer in this case. So, the only
possibility is to add a new syntax construction or at least a standardized
function. And ideally it would be great this operation to be overloadable. I
can imagine what the committee would say about it :-)
They would say something like "let's play a game: you won't tell us what to
do and we won't tell you where you should go to" :-)

But still, the issue exists.

McSeem


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk