Why multiplication not allowed?

[Joona I Palaste]

<big snip (good examples BTW)>

No, it could not be an area. For two reasons:
1. Where is a guarante that Main Street and El Casino Real are
perpendicular? What if they are parallel? Or even in two different towns, or
even countries?
2. Even if they were perpendicular, you would need a range on each side, so
perhaps "123 to 234 Main Street times 89 to 98 El Camino Real", which boils
down to multiplication of integers ;-)

The upshot is, Ben was right.

If Main Street and El Camino Real (not "El Casino Real") are not
parallel (they don't need to be perpendicular, just not parallel),
it's easy to multiply those locations.
Draw a line crossing 123 Main Street, perpendicular to El Camino Real.
Draw a line crossing 89 El Camino Real, perpendicular to Main Street.
The product of those addresses is the intersection point of those two
lines.

 

[Joona I Palaste]

If Main Street and El Camino Real (not "El Casino Real") are not
parallel (they don't need to be perpendicular, just not parallel),
it's easy to multiply those locations.
Draw a line crossing 123 Main Street, perpendicular to El Camino Real.
Draw a line crossing 89 El Camino Real, perpendicular to Main Street.
The product of those addresses is the intersection point of those two
lines.

No, that's not right, after all. There are two correct ways to draw
those lines.
1) Draw a line crossing 123 Main Street, parallel to El Camino Real.
Draw a line crossing 89 El Camino Real, parallel to Main Street.
2) Draw a line crossing 123 Main Street, perpendicular to Main Street.
Draw a line crossing 89 El Camino Real, perpendicular to El Camino Real.
The way I used above would put the intersection point in the wrong
place. If Main Street and El Camino Real were perpendicular, it would
*always* put the intersection point at the intersection point of the
streets themselves, regardless of the addresses.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"I said 'play as you've never played before', not 'play as IF you've never
played before'!"
- Andy Capp

 

[Christopher Benson-Manica]

Is this a valid declaration of bit-field members?

Nope... It's quite wrong, and I am justifiably embarassed to have
written it ;(

 

[Default User]

I always use spaces around *all* binary (or ternary) operators.
For clarity.

So,
i = -1;
a = m * n + 4;
etc.

But I appreciate that it's just a matter of style.

I usually do that too, except when the operator is used as an array
index:


j = i + 1; /* here I do */

a = array[i+1]; /* here I don't */


Why? I don't know exactly, compactness I suspose. It just "looks right"
in the context.



Brian Rodenborn

 

[Old Wolf]

char *rcopy, *q, *r;

foobar(rcopy + q - r);

I was disappointed when gcc rejected my construction like this, depending
on how I parenthesized it. It seems like it shouldn't be hard to support.

The portability and overflow problems of your idea can be highlighted
by explicitly writing what you are proposing:

(char *)( (uint)rcopy + (uint)q - (uint)r )

 

[Kevin Goodsell]

But I appreciate that it's just a matter of style.

I usually do that too, except when the operator is used as an array
index:


j = i + 1; /* here I do */

a = array[i+1]; /* here I don't */


Why? I don't know exactly, compactness I suspose. It just "looks right"
in the context.

I usually use spaces, but sometimes it seems more natural to leave them
out. One case where I often leave out spaces is when I'm using two
binary operators, in which case I'll have the one with higher precedence
closer to it's operands (which reflects the notion of the operator
"binding more tightly):

a*b + c

But I don't have any hard rules - I do whatever feels right or (in my
opinion) makes the code look cleaner.

-Kevin

 

[Peter Pichler]

(previous poster's name snipped by Old Wolf)

support.

The portability and overflow problems of your idea can be highlighted
by explicitly writing what you are proposing:

(char *)( (uint)rcopy + (uint)q - (uint)r )

Are you trying to say that the two examples are equivalent? Because they
are certainly not, yours being downright wrong.

The first example will be expressed more clearly as
foobar(rcopy + (q - r));
but the poster, whoever he or she was, presumably knew that already.
The parentheses around (q - r) are necessary, because + and - associate
left to right, so
foobar(rcopy + q - r);
parses as
foobar((rcopy + q) - r);
which is a constraint violation (adding two pointers).

Peter Pichler

 

[Arthur J. O'Dwyer]

[Joona wrote:]

1) Draw a line crossing 123 Main Street, parallel to El Camino Real.
Draw a line crossing 89 El Camino Real, parallel to Main Street.

[Find those lines' point of intersection.]

2) Draw a line crossing 123 Main Street, perpendicular to Main Street.
Draw a line crossing 89 El Camino Real, perpendicular to El Camino Real.

[Find those lines' point of intersection.]

Neither of those operations behaves anything like real multiplication
[by which I mean either * over the real numbers, or real-life
multiplication; take your pick]. There's no 1 and no 0; each number
has several different numbers by which you can multiply it to get the
same number back; and so forth.
It's an interesting and probably useful operation, but I don't see
any way to map it onto "multiplication" in the usual sense.

[Oh, and almost-on-topic, it's worth noting that in most computer
architectures, Main Street and El Camino Real *are* parallel...]

-Arthur