Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!taumet!steve
From: steve@taumet.com (Stephen Clamage)
Newsgroups: comp.lang.c++
Subject: Re: Overloaded operator dot?
Message-ID: <648@taumet.com>
Date: 3 Apr 91 23:54:45 GMT
References: <11152@jarthur.Claremont.EDU> <1991Mar11.061204.6023@mathcs.sjsu.edu> <4607@lupine.NCD.COM> <1991Mar25.154128.4138@world.std.com> <71622@microsoft.UUCP>
Organization: Taumetric Corporation, San Diego
Lines: 42

jimad@microsoft.UUCP (Jim ADCOCK) writes:

>I claim one of those guiding principles ought to be that whenever we
>have a chance to 1) change the definition to make the language more orthogonal, 
>removing a special case "wart" WITHOUT negatively impacting existing
>code, verses 2) leaving the language the same, arguing the change is not
>worth the effort, that we should "almost always" make that effort.

Aha!  A hidden argument for 'operator dot'.  Nice try, but I see through it!

>Another second guiding principle ought to be:  The ANSI-C++ spec specifies
>*language* not *implementation.*

There was never any question that the spec must refer to language and not
to any specific implementation.  However, any language feature, and the
resulting totality of the language, must be implementable with current
technology with reasonable efficiency; it must not force all users to
pay a high price for a feature which they do not use.  Thus, we will
not see type 'int' required to represent all integers, but only those
in an implementation-defined set.

>And "my" third guiding principle would be, the ANSI-C++ specification
>either calls out *one* behavior for a compiler regards a particular 
>feature, or leaves *all* interpretation of that feature "implementation
>dependent" BUT DOES NOT specify two contradictory *implementations*
>either of which [but no other] is acceptible.

Consider the right-shift operator in ANSI C.  It has one of two specified
behaviors: it may, but need not, sign-extend signed integers.  It was left
with this choice because on some systems it was considered too onerous to
require sign extension.  By your criterion, >> would be extremely expensive
on some systems, or else would be left entirely up to the implementation --
a conforming implementation could just return 0 for any >> operation.
Is this what you had in mind?  Remember that the standardization effort
is cooperative, and many diverse ideas and requirements must be
reconciled.

The "0, 1, infinity" criterion is often a good guiding principle, but
does have its limitations when it collides with the real world.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com