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

41–50 of 51 posts

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

#41

Post by ux266478 »

jcelerier wrote: post #24
codr7 wrote: post #21

Earlier quoted context omitted.

And then they introduced coke at committee meetings, the crazy shit they've been coming up with lately shows absolutely zero understanding of the complexity issue.

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…

Now instead you have 25,000 lines of code that you literally cannot debug.

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

#42

Post by MomsAVoxell »

tialaramex wrote: post #37
MomsAVoxell wrote: post #33

Earlier quoted context omitted.

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 la…

>The first thing it seems to do is arbitrary textual inclusion, so that's already a big mess with unknowable consequences.

I'm not seeing this - can you clarify?

>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.

Humor me, show me where this "member function" is?

I honestly feel like we're not reading the same code .. but maybe that's your point.

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

#43

Post by tialaramex »

MomsAVoxell wrote: post #42
tialaramex wrote: post #37

Earlier quoted context omitted.

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 la…

>The first thing it seems to do is arbitrary textual inclusion, so that's already a big mess with unknowable consequences. I'm not seeing this - can you clarify? >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…

> I'm not seeing this - can you clarify?

#include is a C pre-processor feature which just pastes in whatever the contents of the specified file are. Did you not know that's what it does ?

> Humor me, show me where this "member function" is?

That doAsyncOperation is a member function. Unlike member variables, which are part of the actual data structure we're defining, the member functions are the peculiar syntax for methods in C++, the function won't actually live inside the data structure, we're not making any sort of function pointer or reference - it's just written here because presumably Bjarne couldn't think of anywhere better to put it.

I guess it's possible you didn't understand that, it does seem like a fair number of undergrads think this will be how it works when shown C++ which isn't great news.

> I honestly feel like we're not reading the same code .. but maybe that's your point.

I'm reading the code you wrote in https://news.ycombinator.com/item?id=45484503 and frankly the response just makes me think C++ programmers don't understand C++ either.

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

#44

Post by mwkaufma »

pjmlp wrote: post #36
mwkaufma wrote: post #5

Red 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.

Apologies, I didn't mean "standard" as in the C++ language standard, but standard as in provided-by-your-app-framework's-foundation-library.

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

#45

Post by jcelerier »

jstimpfle wrote: post #40
jcelerier wrote: post #39

Earlier quoted context omitted.

> 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…

> preferably well abstracted from the underlying OS?

you can't do that as soon as you start thinking about embedding non-code resources in your binaries, etc. #embed / std::embed is finally solving this though. You also usually have to think a lot about linking, symbol visibility & various other compiler-specific attributes in such files if you're doing non-trivial work.

> 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.

Exactly, and my experience is that it is always not worth it. For example I ported all my Qt code so that it doesn't use moc (external code generator) and uses instead verdigris (same thing with slightly more complex macros but no need for anything else than a c++ compiler for building my code) and that instantly solved so many problems it's not even funny - something that required maintenance multiple times a year (pretty much every time you want to use some new C++ feature and the code generator does not know yet how to parse a source file that contains this feature - I have issues open on the Qt bug tracker that are now well into their first decade) had its operational cost fall to 0. And moc is by far one of the most well-developed code generators I've had to use, so many others just fail on anything other than the "happiest path".

The only vaguely tolerable experience I had was using CMake as a code generator as cmake works portably-enough on the platforms it supports (though there are oddities to take care of between MSYS2 CMake and MinGW CMake and MSVC CMake) but then there's a lot of people who will absolutely never ever want to touch this (https://github.com/ossia/score/blob/master/cmake/GenerateLic...) or this (https://github.com/ossia/score/blob/master/cmake/ScoreFuncti...) with a ten foot pole. If I could replace all this today with normal C++ code I absolutely would in a heartbeat, it would be an undebatable improvement even if it took three times as many LoC / tokens / cyclomatic complexity / whatever measure you want to use.

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

#46

Post by jstimpfle »

jcelerier wrote: post #45
jstimpfle wrote: post #40

Earlier quoted context omitted.

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…

> preferably well abstracted from the underlying OS? you can't do that as soon as you start thinking about embedding non-code resources in your binaries, etc. #embed / std::embed is finally solving this though. You also usually have to think a lot about linking, symbol visibility & various other compiler-specific attributes in such files if you're doing non-trivial work. > Or is your concern about integration into th…

What does codegen have to do with Qt or CMake (I don't use either)? I was only thinking about generating .[ch]{,pp} files with very simple code in them, and compiling them.

I'd recommend checking out e.g. https://github.com/EpicGamesExt/raddebugger . They are doing a lot of codegen. The codebase is very self-sufficient. Currently works only on Windows x64 but coming to Linux soon it sounds like. (And the reason why not yet isn't codegen)

About embedding non-code resources, yes there are platform dependent solutions to file embedding that you'd have to support separately, but you can also ship an executable with separate asset files. With bigger assets that's probably the way to go. You can of course also opt to encode a file as C code (char data) but it's not very efficient.

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

#47

Post by codr7 »

jcelerier wrote: post #24
codr7 wrote: post #21

Earlier quoted context omitted.

And then they introduced coke at committee meetings, the crazy shit they've been coming up with lately shows absolutely zero understanding of the complexity issue.

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…

Simpler to write maybe, reading it and following all the threads to figure out what the code is doing, not so much.

The problem with C++ is that you end up having to take most of its features into account, one way or the other, and it quickly gets complicated; at least that's my experience and the experience of many others.

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

#48

Post by MomsAVoxell »

tialaramex wrote: post #43
MomsAVoxell wrote: post #42

Earlier quoted context omitted.

>The first thing it seems to do is arbitrary textual inclusion, so that's already a big mess with unknowable consequences. I'm not seeing this - can you clarify? >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…

> I'm not seeing this - can you clarify? #include is a C pre-processor feature which just pastes in whatever the contents of the specified file are. Did you not know that's what it does ? > Humor me, show me where this "member function" is? That doAsyncOperation is a member function. Unlike member variables, which are part of the actual data structure we're defining, the member functions are the peculiar syntax for m…

>#include is a C pre-processor feature which just pastes in whatever the contents of the specified file are. Did you not know that's what it does ?

LOL, I’ve been writing professional C and C++ code for 40 years, so yes indeed I know perfectly well what it does, I just couldn’t fathom your description as being a valid complaint. I mean, seriously?

“Data structure”. No, it’s a class.

Since this class is about encapsulating behavior, managing state, or providing an interface it’s better described as a code module.

Since you cannot make this distinction and seem more inclined to argue from the position of someone who can’t/won’t write C++ code, I’ll just leave you to your misery and state that I disagree with your whining, completely. Please don’t ever write any C++.

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

#49

Post by tialaramex »

MomsAVoxell wrote: post #48
tialaramex wrote: post #43

Earlier quoted context omitted.

> I'm not seeing this - can you clarify? #include is a C pre-processor feature which just pastes in whatever the contents of the specified file are. Did you not know that's what it does ? > Humor me, show me where this "member function" is? That doAsyncOperation is a member function. Unlike member variables, which are part of the actual data structure we're defining, the member functions are the peculiar syntax for m…

>#include is a C pre-processor feature which just pastes in whatever the contents of the specified file are. Did you not know that's what it does ? LOL, I’ve been writing professional C and C++ code for 40 years, so yes indeed I know perfectly well what it does, I just couldn’t fathom your description as being a valid complaint. I mean, seriously? “Data structure”. No, it’s a class. Since this class is about encapsul…

> “Data structure”. No, it’s a class.

Although it inherits from C several kinds of user defined type, C++ chooses to neuter all of them so that in practice any real user defined type "is a class". One of the many cringey Herb Sutter (IIRC) stunts at CppCon was singing "all you need is class" to the tune of the Beatles' "All you need is love".

But crucially here what we're talking about is the choice to define the concrete data structure inline with the definition of a class as "member variables" and to also mix in these "member functions" which aren't part of that data structure. That's an unnecessarily confusing way to do this.

Unlike "member function", your "code module" is not in fact part of C++ nomenclature. You're of course welcome to invent your own terminology to explain what's going on but it does obviously undercut the claim that this is "clean and readable" if you had to invent your own terms to even talk about it.

I do agree with you that writing C++ is a bad idea.

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

#50

Post by MomsAVoxell »

tialaramex wrote: post #49
MomsAVoxell wrote: post #48

Earlier quoted context omitted.

>#include is a C pre-processor feature which just pastes in whatever the contents of the specified file are. Did you not know that's what it does ? LOL, I’ve been writing professional C and C++ code for 40 years, so yes indeed I know perfectly well what it does, I just couldn’t fathom your description as being a valid complaint. I mean, seriously? “Data structure”. No, it’s a class. Since this class is about encapsul…

> “Data structure”. No, it’s a class. Although it inherits from C several kinds of user defined type, C++ chooses to neuter all of them so that in practice any real user defined type "is a class". One of the many cringey Herb Sutter (IIRC) stunts at CppCon was singing "all you need is class" to the tune of the Beatles' "All you need is love". But crucially here what we're talking about is the choice to define the con…

“Code module” is a generic phrase used in many programming languages, not just C++.

Your pedantry over what is an extremely useful and highly productive language, for which there is ample evidence of actual utility, belies a feeble attempt to justify what I believe is your fundamental failure to have actually shipped products in any language, whatsoever. Not just C++. I doubt you ship anything at all, given your proclivity for tripping over your lack of understanding.

Which languages have you used to ship real products to your users?

Post reply on HN