Keith Thompson wrote On 08/10/06 18:54,:
I was insufficiently precise.
C doesn't have user-defined operator overloading. Like many
languages, it overloads the predefined operators on its own predefined
types.
Ah. Okay, but C does support a very limited form of
user-defined overloading for some operators. For example,
the user can apply the () operator to function pointer
types not listed in the Standard.
In other words, "I know what you mean, and you know
what you mean, but we're both having a hard time expressing
it exactly." ;-)
If this "qfloat" were part of the C language, presumably there would
be language-defined overloaded operators for it, just as there are for
any other language-defined floating-point type. But it isn't; it's an
extension implemented by a certain compiler that jacob keeps trying to
advertise here.
From the dribs and drabs of information he's trumpeted
so often, I think Jacob has probably done his "qfloat" in the
form of a Standard-conforming extension, that is, something
that doesn't interfere with a conforming program. I don't
know the specifics of his choices, but if I were going to
add such an extension I'd add a `_qfloat' keyword (in the
implementation's name space), and maybe a <qfloat.h> header
that (among other things) did `typedef _qfloat qfloat;'.
Assuming that qfloat is really _qfloat behind the scenes,
I think the extended compiler is within its rights to define
how this extended type responds to various operators. That
is, "implementor-defined operator overloading" seems legal,
if applied to implementor-defined extended types. The
situation with mixed types is a little murkier because of the
Standard's enumeration of promotion rules; I'm not sure that
_qfloat q = 6;
q *= 7;
.... would be a legal way to obtain forty-two, because the
Standard describes all the possible promotions of the int
operand 7, and none of them leads to a _qfloat value. But
there may be a loophole somewhere I haven't spotted.
Hmmm... I wonder what his _qfloat constants look like.
It seems to me that a diagnostic is required for 3.14Q0 or
suchlike, even if the compiler also recognizes it as a
highly-precise poor approximation to pi. Maybe the compiler
needs to reject such constructs until <qfloat.h> provides
the magic `#pragma enable_qfloat'. I suppose such a #pragma
would also offer a way out of the promtion pickle. In fact,
maybe #pragma could take care of the whole business: turning
`qfloat' from an identifier to a keyword (doing away with
the need for `_qfloat'), enabling the recognition of constants,
augmenting the conversion rules, everything.