jacob navia <jacob@jacob.remcomp.frwrites:
Raghu a :
>I need your help on how to redefine teh function of arithmetic
>operators in
>C.
>for example : if there is an equation c = a/b;
[snip]
>>
I am afraid to start a new flame war here, but if you accept
to use *non-standard* C, the lcc-win32 compiler allows you to
do operator overloading without leaving the framework of C.

course this is an extension, but it is compatible with the
standard. No new keywords are used.

In what sense is this "without leaving the framework of C"?

You don't really *need* operator overloading; anything you can do with
it, you can do without it (with ordinary function calls).

Some languages support operator overloading: C++, Ada, the extended
C-like language supported by lcc-win32, and others. Standard C itself
does not. (And of course lcc-win32, as the name implies, is limited
to 32-bit Windows systems; see comp.compilers.lcc for more
information.)

Note that a conforming implementation may have extensions (including
additional library functions), provided they do not alter the behavior
of any strictly conforming program, so lcc-win32 may still qualify as
a C compiler.

jacob navia wrote
(in article <438c2df2$0$29185$8fcfb975@news.wanadoo.fr>):

I am afraid to start a new flame war here,

Actually, you seem to revel in it.

but if you accept to use *non-standard* C,
(thereby leaving the 'framework of C')

the lcc-win32 compiler allows you to
do operator overloading without leaving the framework of C.

Incorrect. You are using extensions so non-standard that they
NLY work on a single compiler, for a single operating system.

Even the folks that use gcc extensions are far better off than
that, nevermind the PSIX crowd, which has it golden in
comparison.

but it is compatible with the standard.

No, it isn't. Try compiling it on a compiler from anyone else.
So much for that theory.

Tue, 29 Nov 2005 11:31:19 +0100, jacob navia
<jacob@jacob.remcomp.frwrote in comp.lang.c:

Raghu a :
Hello all,

I need your help on how to redefine teh function of arithmetic operators in
C.

for example : if there is an equation c = a/b;

i want to execute my own algorithm for division operator.
I am compelled to use the native C , instead of calling functions or using
macros for doing arithmetic operations.
I mean i was compelled not to use c =MYDIV(a,b) or somewthing like that.

This i needeed to simulate floating point unit of MPC5554 on PC.In MPC the
way the rounding , overflow,errors dealt is different from those used in P4
or AMD.

so i need to simulate the floating point arithmetic of MPC5554 , when i want
to simualte the code designed for it.
I hope i could able express my question clearly.

Your help and advice is sought after at the earliest.

Thanks and Best Regards
Raghu.
>
>
>
I am afraid to start a new flame war here, but if you accept
to use *non-standard* C, the lcc-win32 compiler allows you to
do operator overloading without leaving the framework of C.

course this is an extension, but it is compatible with the standard.
No new keywords are used.

http://www.cs.virinia.edu/~lcc-win32

Jacob, as much as I admire lcc-win32, I was not aware that you had a
cross compiler that output PowerPC executables.

jacob navia <jacob@jacob.remcomp.frwrites:
Keith Thompson a :
>You don't really *need* operator overloading; anything you can do
>with
>it, you can do without it (with ordinary function calls).
>
This is of course true.

It is just a matter of measure.

Consider this:
qfloat a;
qfloat q = (sqrt(a+1)/sqrt(a-1))*(cos(a+1)/cos(a-1));

compared with:

tmp1 = qadd(a,1);
tmp2 = sqrtq(tmp1);
tmp3 = qsub(a,1);
tmp4 = sqrt(tmp3);
tmp5 = qdiv(tmp1,tmp3);
tmp6 = cosq(tmp1);
tmp7 = cosq(tmp3);
tmp8 = qdiv(tmp6,tmp7);
result = qmul(tmp8,tmp5);

This does the *same* stuff but which expression would
you prefer?

I prefer the one that's valid C, and that I can use on systems other
than Win32.

In the context of this newsgroup (now listen carefully), *C does not
support operator overloading*. Conversely, a language that does
support operator overloading is not C. I've used languages that do
support operator overloading, and I've found it useful when used
carefully -- but those languages have their own newsgroups, as does
the lcc compiler.

And jacob, please don't send me e-mail copies of Usenet followups.

In article <438C47D8.5020905@jacob.remcomp.frjacob navia <jacob@jacob.remcomp.frwrites:

Consider this:
qfloat a;
qfloat q = (sqrt(a+1)/sqrt(a-1))*(cos(a+1)/cos(a-1));

compared with:

tmp1 = qadd(a,1);
tmp2 = sqrtq(tmp1);
tmp3 = qsub(a,1);
tmp4 = sqrt(tmp3);
tmp5 = qdiv(tmp1,tmp3);
tmp6 = cosq(tmp1);
tmp7 = cosq(tmp3);
tmp8 = qdiv(tmp6,tmp7);
result = qmul(tmp8,tmp5);

This does the *same* stuff but which expression would
you prefer?

This is obviously a distortion of what is possible, how many of those
tmp's do you really need?
aplus1 = qadd(a, 1);
asub1 = qsub(a, 1);
result = qmul(qdiv(qsqrt(aplus1),qsqrt(asub1)),
qdiv(qcos(aplus1),qcos(asub1)));
which has the added advantage that it is correct.

Does your compiler calculate a+1 and a-1 only once? I have no idea, and
cannot check. I have no access to a win32 machine.

Dik T. Winter wrote:

In article <438C47D8.5020905@jacob.remcomp.frjacob navia <jacob@jacob.remcomp.frwrites:

Consider this:
qfloat a;
qfloat q = (sqrt(a+1)/sqrt(a-1))*(cos(a+1)/cos(a-1));

compared with:

tmp1 = qadd(a,1);
tmp2 = sqrtq(tmp1);
tmp3 = qsub(a,1);
tmp4 = sqrt(tmp3);
tmp5 = qdiv(tmp1,tmp3);
tmp6 = cosq(tmp1);
tmp7 = cosq(tmp3);
tmp8 = qdiv(tmp6,tmp7);
result = qmul(tmp8,tmp5);

This does the *same* stuff but which expression would
you prefer?

This is obviously a distortion of what is possible, how many of those
tmp's do you really need?
aplus1 = qadd(a, 1);
asub1 = qsub(a, 1);
result = qmul(qdiv(qsqrt(aplus1),qsqrt(asub1)),
qdiv(qcos(aplus1),qcos(asub1)));
which has the added advantage that it is correct.

Does your compiler calculate a+1 and a-1 only once? I have no idea, and
cannot check. I have no access to a win32 machine.

It's very old-fashioned of me, I know, but I cringe at
code that calculates a product or quotient of square roots.

spine-tinglers include products and quotients of
power functions and exponentials, sums of logarithms, and
trig functions applied to arctangents. All such expressions
ought to be simplified unless there's a *very* good reason
not to, usually having to do with extraordinary care about
precision: sqrt(x)/sqrt(y) need not equal sqrt(x/y) exactly.
But if that sort of thing is a problem, the code needs an
extensive comment to explain why the expression should not
be simplified; the default behavior should be to simplify
such things, always.