NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/std/cplus/1551

Internet Message Format | 1992-11-12 | 3.5 KB

Xref: sparky comp.std.c++:1551 comp.lang.c++:16158
Newsgroups: comp.std.c++,comp.lang.c++
Path: sparky!uunet!sun-barr!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!darwin.sura.net!Sirius.dfn.de!Urmel.Informatik.RWTH-Aachen.DE!kaa!dak
From: [e-mail] (David Kastrup)
Subject: PROPOSAL: Allow static member operators
Message-ID: <dak.721580710@kaa>
Summary: Proposal to remove nonstatic restriction for member operators
Keywords: static operator
Sender: [e-mail] (Newsfiles Owner)
Nntp-Posting-Host: kaa
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Date: 12 Nov 92 15:05:10 GMT
Lines: 62

I have already proposed this to Dr. Stroustrup, but received a nolo volens
because of possible confusion of users. I do not agree with his point
of view.

I do not know why operators should only be nonstatic member functions.
They would be handy especially in the case of fake classes or
angels (Thomas von Aquin argued that since angels lack physical manifestation,
they are not a manifestation of a principle, but the principle itself,
and so every angel as a mere spiritual being has its own, unique class).

One use of angels are function templates with nontype arguments. Since
the usual function templates do not support nontype arguments, one has
to implement them using angels. And the most natural choice for an
angel to behave as a function is operator(), which is there exactly
for that purpose. (In ARM, the use of angels for this purpose is
suggested, however with a non-operator syntax).
example:
template <some template arguments> class example {
    static operator()(parameters) { ... };
};

example <actual template arguments> instant;

After that you can call
instant(actual parameters);

The implementation of static operators would be strictly analogous to
other static member functions: they would be passed no this-pointer, thus
receiving no information of their first operand apart from its type
(because they would not have been called was the type wrong). And in
the special case of angels, there would be no more information to pass
anyway.

Another choice for angels would be, say in complex arithmetic, a special
angel called i, or maybe complexi because i is so common. Then you
could provide conversion to complex, but also special multiplication
operators making multiplication with complexi much more efficient than
the usual complex multiplication.

So implementation of special constants in special number classes is an
obvious argument for angels with operator syntax.

To talk about physical manifestations (the "this" pointer) of angels is
obviously senseless, therefore they should only have static member
functions. It is ugly to have to use nonstatic operators, especially
as most compilers could implement static operators by simply leaving
out the operator specific test for prohibiting static.

Dr Stroustrup argued that you could use nonstatic operators to the
same effect, and that the compiler might optimize the "this" away.
But the  same argument would obviate static member functions, and
they seem to have enough importance to include them in C++.

Another suggestion was using constructors for a similar syntax for
function calls of angels. But this is a hack, is much more
difficult to keep track of, mixes function call semantics (clearly
provided by operator()) with copying of objects and temporary
instantiation. In short, it is far more dangerous.

So let's hear it for static operators. If static member functions have
a purpose, and overloadable operators have, then obviously the combination
will also have a purpose.