Doing this today I'd just have a std::function parameter and have callers pass in a lambda. I may use a third party std::function that doesn't have the weird copy semantics though
This paper is about the idea that eventually became std::function.
Callbacks in C++ using template functors (1994)
31–40 of 51 posts
Re: Callbacks in C++ using template functors (1994)
#32Re: Callbacks in C++ using template functors (1994)
#33Earlier quoted context omitted.
>ugly mess That may be the case, but there are plenty of examples of elegant implementations. JUCE, for instance: #include class MyComponent { public: void doAsyncOperation(std::function callback) { // Simulate async work juce::MessageManager::callAsync([callback]() { callback(42); // Call the functor with result }); } }; // Usage MyComponent comp; comp.doAsyncOperation([](int result) { juce::Logger::writeToLog("Call…
Well, that definitely doesn't look "clean and readable" to me for whatever that's worth.
Too many []’s and ::’s for your eyes?
Re: Callbacks in C++ using template functors (1994)
#34Earlier quoted context omitted.
and yet client code can be incredibly simpler nowadays thanks to all these features. I can write this simple struct: struct Person { std::string name; my_complicated_date_type date_of_birth; }; and get serialization, network interop, logging, automated UI generation, hashing, type-safe IDs, etc. without having to write an additional line of code. Twenty years ago you had to write 2000 lines of additional boilerplate…
You would have added some codegen, should be possible to write a codegen framework from scratch in 2000 lines even. Arguably the result would have been easier to read and maintain and not as slow to compile.
Or you might have used table based data structures, like TeX and the lunar lander did.
You do the best you can, today, with what you have, and then you ship it and get on to the next challenge. Same now as it always was.
Re: Callbacks in C++ using template functors (1994)
#35Earlier 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.
I didn't want to use the functional part of C++, then one day my colleague with a twisted sense of humour checked in fun.hpp with his own implementation of FP.
Boom.
Now you are not only using the functional part of C++, but also in a nonstandard way! Merci Gilles. :)
Re: Callbacks in C++ using template functors (1994)
#36Red flags for me when I see nonstandard functors in a c++ codebase (esp if the "glue" is in a setup function independent of the objects): (i) Have they thought about the relative lifetimes of the sender and receiver? (ii) Is the callback a "critical section" where certain side-effects have undefined behavior? (iii) Does the functors store debugging info that .natvis can use? (iv) Is it reeeeeeeally that bad to just i…
The only "standard" in 1994 was the C++ARM book (filled a similar role to the K&R C book) that served as basis for the ongoing standardization process, to be done in 1998.
Re: Callbacks in C++ using template functors (1994)
#37Earlier quoted context omitted.
Well, that definitely doesn't look "clean and readable" to me for whatever that's worth.
Too many []’s and ::’s for your eyes?
The first thing it seems to do is arbitrary textual inclusion, so that's already a big mess with unknowable consequences.
Then we've got a "member function" where magically if we specify a function while midway through specifying a data structure the function is somehow treated as though it were part of that data structure - but of course it is actually just sugar. I know this confuses real learners.
And sure, the lambda syntax is awful but that's sort of par for the course by the time you reach it.
Re: Callbacks in C++ using template functors (1994)
#38Earlier quoted context omitted.
and yet client code can be incredibly simpler nowadays thanks to all these features. I can write this simple struct: struct Person { std::string name; my_complicated_date_type date_of_birth; }; and get serialization, network interop, logging, automated UI generation, hashing, type-safe IDs, etc. without having to write an additional line of code. Twenty years ago you had to write 2000 lines of additional boilerplate…
As some not into modern c++, how would you get all functionality? Is there any guide or documentation yout could point to?. It is fascinating if all that could be done with just the struct defenition.
The actual feature comes in C++26 (static reflection) but there are polyfills that allow to do it today (boost.pfr, https://github.com/qlibs/reflect) ; concepts are also a great help: https://cnrs.hal.science/hal-04090584/file/icmc2022template....
Re: Callbacks in C++ using template functors (1994)
#39Earlier quoted context omitted.
and yet client code can be incredibly simpler nowadays thanks to all these features. I can write this simple struct: struct Person { std::string name; my_complicated_date_type date_of_birth; }; and get serialization, network interop, logging, automated UI generation, hashing, type-safe IDs, etc. without having to write an additional line of code. Twenty years ago you had to write 2000 lines of additional boilerplate…
You would have added some codegen, should be possible to write a codegen framework from scratch in 2000 lines even. Arguably the result would have been easier to read and maintain and not as slow to compile.
> Arguably the result would have been easier to read and maintain and not as slow to compile.
having been through I don't know how many codegen frameworks I thoroughly disagree, those are a complete pain to maintain as soon as you want to support mac / windows (esp. MSVC) / linux / wasm and various brands of cross-compiling. Everything that can be done in the target language, should.
Re: Callbacks in C++ using template functors (1994)
#40Earlier quoted context omitted.
You would have added some codegen, should be possible to write a codegen framework from scratch in 2000 lines even. Arguably the result would have been easier to read and maintain and not as slow to compile.
> Arguably the result would have been easier to read and maintain and not as slow to compile. having been through I don't know how many codegen frameworks I thoroughly disagree, those are a complete pain to maintain as soon as you want to support mac / windows (esp. MSVC) / linux / wasm and various brands of cross-compiling. Everything that can be done in the target language, should.
What is the issue with codegen for multiple platforms? Why not just emit regular C or C++ code (and data) -- preferably well abstracted from the underlying OS?
Or is your concern about integration into the build system of any prebuild-events or similar logic that need to be run in addition to compiling and linking? This integration may require separate efforts for each platform. But such support is very useful for a bunch of different things in most non-trivial projects, such that it's better to pay for that effort early, rather than develop workarounds to avoid it in my experience.