>ugly mess
That may be the case, but there are plenty of examples of elegant implementations.
JUCE, for instance:
#include <juce_core/juce_core.h>
class MyComponent {
public:
void doAsyncOperation(std::function<void(int)> 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("Callback received with: " + juce::String(result));
});
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.
>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.
> 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.
>#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++.
> “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.