Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Looking for "User-defined operators for fun and profit"

190 views
Skip to first unread message

Vicente J. Botet Escriba

unread,
Feb 1, 2014, 12:52:36 AM2/1/14
to std-pr...@isocpp.org
Hi,

has someone a pointer to "B. Stroustrup: "User-defined operators for fun
and profit," Overload April, 1998"?

Thanks in advance,
Vicente

P.S. Goggling didn't give any satisfactory results for me.

Daniel Krügler

unread,
Feb 1, 2014, 4:55:21 AM2/1/14
to std-pr...@isocpp.org
2014-02-01 Vicente J. Botet Escriba <vicent...@wanadoo.fr>:
> Hi,
>
> has someone a pointer to "B. Stroustrup: "User-defined operators for fun and
> profit," Overload April, 1998"?

I'm don't believe that this article really exists, because

http://accu.org/var/uploads/journals/overload25.pdf

which contains the famous "whitespace overloading" article has been
written in April 1998 ;-)

- Daniel

>
> Thanks in advance,
> Vicente
>
> P.S. Goggling didn't give any satisfactory results for me.
>
> --
>
> --- You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

Vicente J. Botet Escriba

unread,
Feb 1, 2014, 8:19:50 AM2/1/14
to std-pr...@isocpp.org
Le 01/02/14 10:55, Daniel Krügler a écrit :
2014-02-01 Vicente J. Botet Escriba <vicent...@wanadoo.fr>:
Hi,

has someone a pointer to "B. Stroustrup: "User-defined operators for fun and
profit," Overload April, 1998"?
I'm don't believe that this article really exists, because

http://accu.org/var/uploads/journals/overload25.pdf

which contains the famous "whitespace overloading" article has been
written in April 1998 ;-)

I've got the reference from just this paper:

"The facilities for defining new operators, such as :::, <>, pow , and abs are described in a companion
paper [B. Stroustrup: "User-defined operators for fun and profit," Overload April, 1998].
Basically, this mechanism builds on experience from Algol68 and ML to allow the programmer to assign
useful - and often conventional - meaning to expressions such as
double d = z pow 2 + abs y;
and
if (z <> ns:::2) // …
This facility is conceptually simple, type safe, conventional, and very simple to implement."
Bjarne, maybe you remember if the named paper is available.

Best,
Vicente

Ville Voutilainen

unread,
Feb 1, 2014, 8:47:01 AM2/1/14
to std-pr...@isocpp.org
On 1 February 2014 15:19, Vicente J. Botet Escriba
<vicent...@wanadoo.fr> wrote:
> I've got the reference from just this paper:
>
> "The facilities for defining new operators, such as :::, <>, pow , and abs
> are described in a companion
> paper [B. Stroustrup: "User-defined operators for fun and profit," Overload
> April, 1998].
> Basically, this mechanism builds on experience from Algol68 and ML to allow
> the programmer to assign
> useful - and often conventional - meaning to expressions such as
> double d = z pow 2 + abs y;
> and
> if (z <> ns:::2) // ...
> This facility is conceptually simple, type safe, conventional, and very
> simple to implement."
>
> Bjarne, maybe you remember if the named paper is available.


"This paper outlines the proposal for
generalizing the overloading rules for
Standard C++ that is expected to become part
of the next revision of the standard. The focus
is on general ideas rather than technical
details (which can be found in AT&T Labs
Technical Report no. 42, April 1,1998)."

No. 42, published on April 1st, the year is insignificant. It's an April Fools'
joke.

Daniel Krügler

unread,
Feb 1, 2014, 8:49:08 AM2/1/14
to std-pr...@isocpp.org
2014-02-01 Vicente J. Botet Escriba <vicent...@wanadoo.fr>:
> Le 01/02/14 10:55, Daniel Krügler a écrit :
>
> 2014-02-01 Vicente J. Botet Escriba <vicent...@wanadoo.fr>:
>
> Hi,
>
> has someone a pointer to "B. Stroustrup: "User-defined operators for fun and
> profit," Overload April, 1998"?
>
> I'm don't believe that this article really exists, because
>
> http://accu.org/var/uploads/journals/overload25.pdf
>
> which contains the famous "whitespace overloading" article has been
> written in April 1998 ;-)
>
>
> I've got the reference from just this paper:
>
> "The facilities for defining new operators, such as :::, <>, pow , and abs
> are described in a companion
> paper [B. Stroustrup: "User-defined operators for fun and profit," Overload
> April, 1998].

Yes, I'm aware of this and this is the reason why I think that it is
just part of the joke.

- Daniel

pot...@gmail.com

unread,
Feb 1, 2014, 9:58:06 AM2/1/14
to std-pr...@isocpp.org
On Feb 1, 2014, at 9:49 PM, Daniel Krügler <daniel....@gmail.com> wrote:

Yes, I'm aware of this and this is the reason why I think that it is
just part of the joke.

So it comes full circle…

I just read N3553, and I don’t see a mention of motivation for using punctuation mentioned — it seems taken for granted. Moreover the proposed :=: is right-associative, such that a sequence of swap operations implements a rotation. Right associativity implies rightward-by-one rotation (and evaluation to the initially rightmost value stored in the leftmost object), which is nice, but a bit arbitrary and sure to confuse many. Also, a rename would force migration of all preexisting code using the name swap.

Did I miss something in the paper? I feel crazy that there was already a long discussion and nobody mentioned this.

As for non-contextually defining swap over primitive values, which don’t benefit from ADL, could the solution be to introduce an artificial namespace association for them? That is, to fix ADL, not work around it?

But speaking of :::, shouldn’t that have a special tokenizing rule for symmetry with <::? (The scope specifier has no postfix meaning, so three colons must invariably be ill-formed, with the user’s intent presumably being to form : ::.)

Ex:

case 5:::namespace_func();
      ~~~
(a<b?3:::qu::al::ified)
      ~~~

Daniel Krügler

unread,
Feb 1, 2014, 10:18:34 AM2/1/14
to std-pr...@isocpp.org
2014-02-01 <pot...@gmail.com>:
>
> On Feb 1, 2014, at 9:49 PM, Daniel Krügler <daniel....@gmail.com>
> wrote:
>
> Yes, I'm aware of this and this is the reason why I think that it is
> just part of the joke.
>
>
> So it comes full circle...
>
> I just read N3553, and I don't see a mention of motivation for using
> punctuation mentioned -- it seems taken for granted. Moreover the proposed
> :=: is right-associative, such that a sequence of swap operations implements
> a rotation. Right associativity implies rightward-by-one rotation (and
> evaluation to the initially rightmost value stored in the leftmost object),
> which is nice, but a bit arbitrary and sure to confuse many. Also, a rename
> would force migration of all preexisting code using the name swap.

N3553 was discussed during the Bristol meeting by the Evolution group.
I didn't participate during that discussion but from the wiki notes
the discussion ended with the following:

"Daveed: does it really solve them? The operator will still be found by ADL.

Matt: maybe, since this would use an intrinsic in place of the general
std::swap template.

Bjarne: But swap() isn't going away because of backward compatibility,
so now we'll have swap() and operator:=:. "Probably a good idea if we
had a time machine". Introducing a new operator, it has to be really
central and helpful. If it got us out of our swap problem it might be
good enough, but it isn't. Libraries aren't going to stop calling swap
and if they did then all the specialized swap functions people have
written wouldn't get invoked. Problems are real, but the benefits it
would have (i.e. what problem it would actually solve) aren't
sufficiently explained. Too likely that swap and :=: would coexist
indefinitely and that all the problems of swap would persist.

General agreement that this is a real problem but that it's not clear
why this would solve them. We will not proceed with this. "

So, yes, there were several problems of the proposal mentioned, albeit
I couldn't find your point.

- Daniel

David Krauss

unread,
Feb 1, 2014, 10:23:41 AM2/1/14
to std-pr...@isocpp.org


On Saturday, February 1, 2014 11:18:34 PM UTC+8, Daniel Krügler wrote:
So, yes, there were several problems of the proposal mentioned, albeit
I couldn't find your point.

That discussion is close enough to being exactly my point, thanks :)

The associativity/rotating bit is tangential.

As for triple colon, not sure what to do with that. Perhaps implement it in my own C++ implementation and issue a warning to remain compliant :P

Evgeny Panasyuk

unread,
Feb 2, 2014, 6:41:45 AM2/2/14
to std-pr...@isocpp.org
1 Feb 2014 г., 18:58:06 UTC+4 David Krauss:

I just read N3553, and I don’t see a mention of motivation for using punctuation mentioned — it seems taken for granted. Moreover the proposed :=: is right-associative, such that a sequence of swap operations implements a rotation. Right associativity implies rightward-by-one rotation (and evaluation to the initially rightmost value stored in the leftmost object), which is nice, but a bit arbitrary and sure to confuse many.

Rotation expressed by chain of infix swaps has inherent performance issue.

Usually swap between two values logically involves 3 copy/move assignments.
Rotation of N values using infix swap v1 :=: v2 :=: ... :=: vN would require (N-1)*3 assignments.

But using variadic function it becomes: cycle(v1,v2,...,vN) with N+1 assignments. (refer http://www.stepanovpapers.com/notes.pdf)

Vicente J. Botet Escriba

unread,
Feb 2, 2014, 8:32:37 AM2/2/14
to std-pr...@isocpp.org
Le 01/02/14 14:47, Ville Voutilainen a écrit :
:(

Vicente

P.S. To those that have added some comments related to the swap
operator. Please continue it on another thread.

Billy O'Neal

unread,
Feb 3, 2014, 11:53:15 AM2/3/14
to std-proposals
True, but the swap is likely to be inlined and the redundant load optimized out. (It may even make sense to explicitly allow implementations to make such an optimization; similar to how copy elision is allowed today)

--
 
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

t
Reply all
Reply to author
Forward
0 new messages