23 Jun
2025
23 Jun
'25
1:29 p.m.
Overloading bit shifting operators to implement stream
I/O was a repellent choice
Without commenting on this judgement, I can tell how the convention
came about in a casual conversation.
I was perhaps the earliest serious experimenter with C++ overloading,
for a constructive solid geometry package in which arithmetic
operators were overloaded for matrices and vectors, and boolean
operators were overloaded for union and intersection of geometric
objects. I've forgotten how object subtraction (e.g. to drill a hole)
was represented. Sadly, the symbol vocabulary for overloading was
fixed, which meant that two vector products (dot and cross) vied for
one operator. Joe Condon put me onto an interesting analog of quotient
and remainder in 3D. The quotient. of two vectors, q=a/b is the ratio
of the projection of a onto b to b and the remainder r=a%b is the
component of a perpendicular to b, The usual quotient-remainder
formula holds::a = q*b + r.
Once, while discussing some detail of overloading, Bjarne remarked
that he'd like to find an attractive notation for stream IO, which
printf certainly is not. << and >> immediately popped into my mind.
They've been in the language ever since.
Equally casually, there was no discussion about the set of operator
symbols, so C++ did not come up with a convention for symbol syntax,
such as that of Haskell.
Doug
23 Jun
23 Jun
9:01 p.m.
New subject: C with Improvements :-)
Hi Doug,
At 2025-06-23T09:29:42-0400, Douglas McIlroy wrote:
Thanks for throwing considerable light on what prompted my heat.
I think your point about the overloadable symbol vocabulary being fixed
is a salient one, and puts a burden on overloading from a language
design and readability perspective that might not be sustainable.
However, I may be biased...while I'm accepting of function overloading,
I've never seen an implementation of operator overloading that pleased
me. I tell myself it's because I just haven't met the right language
yet, and that once I do I can thus claim an objective stance, but maybe
I'm just personally allergic to operator overloading. I already think
it's a bad idea to have "/" represent both integer and floating-point
division, and just within the past week we fixed a groff bug--that I
introduced--arising from the ambiguity.[1] (You guessed it--Ada doesn't
do this.)
If I were doing what Warren's done and devising my own riff on C, then
apart from stealing shamelessly from Ada, I'd use keywords for all
integer math operations: "add", "sub", "mul",
"div", "mod" (and maybe
Ada's "rem", too). To any C jockeys inclined to whine, I'd point out
that these are strongly reminiscent of the assembly language mnemonics
into which the operations will translate anyway, which _should_
harmonize with their mantra that they program "close to the metal".
That would reserve the arithmetic operator symbols for floating-point
operations, which is good because it's familiar from handheld
calculators (or, to update my superannuated notions, calculator apps
on handheld phones).
Your story about needing to assign distinct operators to two different
sorts of "product" is, I think, a strong one against operator
overloading. When programming we must cope with sundry varieties of
mathematical structures. I remember being intrigued when I learned that
the inner product (dot product) generalizes to a wide variety of
spaces[2] but the cross product does not. The cross product is
meaningful only in a 3-space. (Maybe one with an orthonormal basis to
boot; I haven't thought about this stuff in 10+ years.)
It seems that a lot of what we call "mathematical maturity" amounts to
awareness that much of what we were taught to assume as true in primary
or secondary school, or even most of an undergraduate program outside
the math department, was a fib.[3]
In that sense, we have Bolyai and Lobachevsky, and later Gödel, among
other celebrated thinkers, to thank for maturing us.
Overloading
bit shifting operators to implement stream I/O was a
repellent choice
Without commenting on this judgement, I can tell how the convention
came about in a casual conversation.
I was perhaps the earliest serious experimenter with C++ overloading,
for a constructive solid geometry package in which arithmetic
operators were overloaded for matrices and vectors, and boolean
operators were overloaded for union and intersection of geometric
objects. I've forgotten how object subtraction (e.g. to drill a hole)
was represented. Sadly, the symbol vocabulary for overloading was
fixed, which meant that two vector products (dot and cross) vied for
one operator. Joe Condon put me onto an interesting analog of quotient
and remainder in 3D. The quotient. of two vectors, q=a/b is the ratio
of the projection of a onto b to b and the remainder r=a%b is the
component of a perpendicular to b, The usual quotient-remainder
formula holds::a = q*b + r. Once, while discussing some detail of overloading,
Bjarne remarked
that he'd like to find an attractive notation for stream IO, which
printf certainly is not. << and >> immediately popped into my mind.
They've been in the language ever since.
Oh, no! I have you to blame? :-O
Almost anything looks better than printf (anything but Fortran's
"FORMAT"), and that may have been unfortunate.
Equally casually, there was no discussion about the
set of operator
symbols, so C++ did not come up with a convention for symbol syntax,
such as that of Haskell.
I won't claim expertise with Haskell (I've yet to use it in anger), but
what exposure I've had to it suggests a carefully thought out language.
Our profession seems reluctant to accept new languages with that
property. We prefer JavaScript and PHP. :-|
Regards,
Branden
[1] https://lists.gnu.org/archive/html/groff-commit/2025-06/msg00110.html
[2] "inner product spaces", natch ;-)
[3] One reason I'm so enthusiastic about linear algebra as a subject--I
think we should teach it to everyone, not even joking--is that
delivers a lot of benefit to one's critical thinking even as its
prerequisites are modest; all you really need is introductory
algebra and none of its weirder topics. With that small
armamentarium you can start learning how to reason about huge
classes of problems, and to do so in a "mature" way: that is, no
longer accepting models that are handed down on stone tablets, but
devising one's own, explicitly articulating one's assumptions,
seeing what properties result, and comparing them critically to the
phenomenon under study. You start with easy things like, "did I
select the correct number of (independent) variables to model this
problem?", and it gets more fun from there.
Recognizing when a problem _can't_ be modeled in a linear space is a
benefit that can't be overstated. But only familiarity with linear
algebra can equip you to make that judgment.
24 Jun
24 Jun
12:07 p.m.
New subject: C with Improvements :-)
On Mon, Jun 23, 2025 at 9:36 AM Douglas McIlroy
<douglas.mcilroy(a)dartmouth.edu> wrote:
Thank you for this interesting historical note, Doug.
Personally, I've never found the `<<` or `>>` syntax troubling when
using C++ IO streams, and the type safety is a notable improvement
over printf/scanf et al.
What I _do_ find troubling is that the stream itself is a stateful,
mutable object, so to perform any sort of non-trivial formatting, one
has to inject special control messages into the stream using the same
syntax; these do compose (usually), but they're persistent, are overly
verbose, and cumbersome to use in practice. Here, the concision of
printf's "little language" of formatting verbs is superior, and far
more readable.
It seems obvious in retrospect that C++ would have been better off if
augmented with a small hierarchy of "formatting objects" that encoded
the various formatting directives, exposing a printf-like language, as
a constructor argument, along with the datum. The stream would consume
these for the purposes of formatting that specific datum, but then
discard them, as opposed to holding onto whatever state they induced.
Google eventually did something like this, which kinda-sorta made it
out in the `absl::StrFormat` library, but it took far too long (and
Google, for many years, explicitly forbade using iostreams in C++ code
for dubious reasons).
More recent languages have introduced happy mediums. I personally like
the way that Rust handles this; `println!` is a macro, and interprets
the format string at compile time, ensuring whatever it specifies
matches its arguments vis types, visibility, safety, etc. But at the
call site, it resembles the concision of printf via a small formatting
language.
- Dan C.
Overloading
bit shifting operators to implement stream I/O was a repellent choice
Without commenting on this judgement, I can tell how the convention
came about in a casual conversation. I was perhaps the earliest serious experimenter with
C++ overloading,
for a constructive solid geometry package in which arithmetic
operators were overloaded for matrices and vectors, and boolean
operators were overloaded for union and intersection of geometric
objects. I've forgotten how object subtraction (e.g. to drill a hole)
was represented. Sadly, the symbol vocabulary for overloading was
fixed, which meant that two vector products (dot and cross) vied for
one operator. Joe Condon put me onto an interesting analog of quotient
and remainder in 3D. The quotient. of two vectors, q=a/b is the ratio
of the projection of a onto b to b and the remainder r=a%b is the
component of a perpendicular to b, The usual quotient-remainder
formula holds::a = q*b + r.
Once, while discussing some detail of overloading, Bjarne remarked
that he'd like to find an attractive notation for stream IO, which
printf certainly is not. << and >> immediately popped into my mind.
They've been in the language ever since.
Equally casually, there was no discussion about the set of operator
symbols, so C++ did not come up with a convention for symbol syntax,
such as that of Haskell.
Doug
12
days inactive
13
days old
2 comments
3 participants
participants (3)
-
Dan Cross -
Douglas McIlroy -
G. Branden Robinson