Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Callbacks in C++ using template functors (1994)

tutok.sk

Post reply on HN
Print view View original

11–20 of 51 posts

Re: Callbacks in C++ using template functors (1994)

#11

Post by asveikau »

drnick1 wrote: post #3

C++ was so much cleaner in the 90s, when it was still essentially "C with classes," which is how I like to use the language. Modern standards have turned it into an ugly mess.

I dunno, I skimmed the article's 31 year old code examples and immediately thought they would be shorter and simpler in c++11 or later.

But it's important to see the 1994 (and 1998) view of the world to understand how modern c++ features work. Because they start from that worldview and start adding convenient stuff. If you don't understand how c++ used to work, you may be confused with why c++ lambdas look so weird.

Re: Callbacks in C++ using template functors (1994)

#12

Post by tcbawo »

mwkaufma wrote: post #10
tcbawo wrote: post #6

Earlier quoted context omitted.

Can you elaborate on your third point? What would a class need to do to affect debugging info? Regarding your fourth point, sometimes an architecture can be vastly simplified if the source of information can abstracted away. For example, invoking a callback from a TCP client, batch replay service, unit test, etc. Sometimes object oriented design gets in the way. To your first point, I think RAII and architecture prim…

>> Can you elaborate on your third point? What would a class need to do to affect debugging info? Common implementations are a function pointer + void* pair, which in most debuggers just show you two opaque addresses. Better to include a info block -- at least in debug builds -- with polymorphic type pointers that can actually deduce the type and show you all the fields of the receiver. >> sometimes an architecture c…

> most debuggers just show you two opaque addresses

This has not been my experience. But I haven't needed to deal with RTTI disabled.

By RAII, I mean using destructors to unregister a callback. This covers 99.9% of use cases. Generally callback registration is not where you really want type erasure anyways.

Re: Callbacks in C++ using template functors (1994)

#13

Post by dang »

Related. Others?

Callbacks in C++ using template functors (1994) - https://news.ycombinator.com/item?id=18650902 - Dec 2018 (50 comments)

Callbacks in C++ using template functors – Rich Hickey (1994) - https://news.ycombinator.com/item?id=12401400 - Aug 2016 (1 comment)

Callbacks in C++ using template functors (1994) - https://news.ycombinator.com/item?id=10410864 - Oct 2015 (2 comments)

Re: Callbacks in C++ using template functors (1994)

#14

Post by mwkaufma »

tcbawo wrote: post #12
mwkaufma wrote: post #10

Earlier quoted context omitted.

>> Can you elaborate on your third point? What would a class need to do to affect debugging info? Common implementations are a function pointer + void* pair, which in most debuggers just show you two opaque addresses. Better to include a info block -- at least in debug builds -- with polymorphic type pointers that can actually deduce the type and show you all the fields of the receiver. >> sometimes an architecture c…

> most debuggers just show you two opaque addresses This has not been my experience. But I haven't needed to deal with RTTI disabled. By RAII, I mean using destructors to unregister a callback. This covers 99.9% of use cases. Generally callback registration is not where you really want type erasure anyways.

>> By RAII, I mean using destructors to unregister a callback.

_Whose_ destructor, if not the receiving-type? Is there a third "binding" object, because then you have three potentially-unrelated lifetimes.

>> Generally callback registration is not where you really want type erasure anyways.

I'm responding to the article: "Some mechanisms for doing callbacks require a modification to, or derivation of, the caller or callee types. The fact that an object is connected to another object in a particular application often has nothing to do with its type. As we'll see below, mechanisms that are type intrusive can reduce the flexibility and increase the complexity of application code. "

Re: Callbacks in C++ using template functors (1994)

#15

Post by tcbawo »

mwkaufma wrote: post #14
tcbawo wrote: post #12

Earlier quoted context omitted.

> most debuggers just show you two opaque addresses This has not been my experience. But I haven't needed to deal with RTTI disabled. By RAII, I mean using destructors to unregister a callback. This covers 99.9% of use cases. Generally callback registration is not where you really want type erasure anyways.

>> By RAII, I mean using destructors to unregister a callback. _Whose_ destructor, if not the receiving-type? Is there a third "binding" object, because then you have three potentially-unrelated lifetimes. >> Generally callback registration is not where you really want type erasure anyways. I'm responding to the article: "Some mechanisms for doing callbacks require a modification to, or derivation of, the caller or c…

> Whose_ destructor, if not the receiving-type

The receiving type should control the lifetime of any callbacks to itself that it gives away. The destructor is the best place to ensure this gets properly cleaned up.

Like anything, custom callbacks can be used well or misused. Design is a matter of expertise and taste bordering on an art form. Connecting framework implementation and business logic can be done cleanly or clumsily. I am skeptical of an argument that callbacks have a code smell prima facie.

Re: Callbacks in C++ using template functors (1994)

#16

Post by mwkaufma »

tcbawo wrote: post #15
mwkaufma wrote: post #14

Earlier quoted context omitted.

>> By RAII, I mean using destructors to unregister a callback. _Whose_ destructor, if not the receiving-type? Is there a third "binding" object, because then you have three potentially-unrelated lifetimes. >> Generally callback registration is not where you really want type erasure anyways. I'm responding to the article: "Some mechanisms for doing callbacks require a modification to, or derivation of, the caller or c…

> Whose_ destructor, if not the receiving-type The receiving type should control the lifetime of any callbacks to itself that it gives away. The destructor is the best place to ensure this gets properly cleaned up. Like anything, custom callbacks can be used well or misused. Design is a matter of expertise and taste bordering on an art form. Connecting framework implementation and business logic can be done cleanly o…

I don't disagree, but the article does. RH describes an architecture where setup functions create callbacks, independent of the receiving type. If I were to steelman him, it would be something like this: "in a pedantic MVC system, model objects don't depend on view objects by design, and therefore should not be aware that their methods are used as 'click callbacks'"

Re: Callbacks in C++ using template functors (1994)

#18

Post by eschaton »

adzm wrote: post #17
drnick1 wrote: post #3

C++ was so much cleaner in the 90s, when it was still essentially "C with classes," which is how I like to use the language. Modern standards have turned it into an ugly mess.

You can just use the parts you want though; that's part of its appeal.

This is a thing C++ advocates say that tells me they’ve never really tried to do it and share that codebase with others or integrate with other codebases.

You generally don’t get to pick what parts other people want to use, which means that in the end you still have to deal with the entirety of the language.

Re: Callbacks in C++ using template functors (1994)

#19

Post by spacechild1 »

drnick1 wrote: post #3

C++ was so much cleaner in the 90s, when it was still essentially "C with classes," which is how I like to use the language. Modern standards have turned it into an ugly mess.

No member function templates, no variadic templates, no std::function, no lambdas, etc. That's certainly not the kind of C++ I would want to write...

Re: Callbacks in C++ using template functors (1994)

#20

Post by codr7 »

eschaton wrote: post #18
adzm wrote: post #17

Earlier quoted context omitted.

You can just use the parts you want though; that's part of its appeal.

This is a thing C++ advocates say that tells me they’ve never really tried to do it and share that codebase with others or integrate with other codebases. You generally don’t get to pick what parts other people want to use, which means that in the end you still have to deal with the entirety of the language.

Exactly, it doesn't work very well in practice.

Even when working alone, the complexity gradually creeps up on you.

Because it's all made to work together, start pulling anywhere and before you know it you're using another feature, and another, and so on.

And many features interact in exotic and hard to predict ways, so hard that entire careers have been spent on trying and failing to master the language.

Post reply on HN