> Qt started long before C++11, as I'm sure you know, and lambdas weren't available for the 10 years prior.
Of course. That's also the reason we have UTF-16 and a Qt reimplementation of the standard library: the project's age and need for backward compatibility.
moc for C++98 didn't offer closures, so you still had to write a separate function and then call connect() to link the signal with the new slot function. Even in C++98, moc could have instead just allowed you to use a version of std::function, written for C++98 (I wrote such a container, as did boost.) So instead you'd have: button.onClick(&MyClass::clickEvent, &myClassObject); which for at least 98% of GUI programming, would cover the same use case as connect(button, SIGNAL(pressed()), &myClassObject, SLOT(clickEvent())); but without the need for preprocessing; and without the downside of run-time type checking of the signal and slot names.
...
I definitely don't doubt you that you have use cases that moc makes significantly easier. But in my case, I really don't. And I've written a dozen simple to moderately complex UI applications. So, I would be appreciative if in my simple case, I didn't have to use moc at all.
One thing I do like, that is possible with a fancier std::function class, but is still kind of clunky with pure C++, is the way you can bind a slot that has less parameters than a function ordinarily takes. It's a nice way to offer additional information, but not require you to have an exactly matching callback signature. Great for binding multiple signals to the same generic slot that handles all cases at once (eg "synchronize()" called whenever you change a setting.)
> You only need to run headers of QObjects through MOC, although that is most of them if you are using Qt, obviously.
Yeah, I wrote a recursive wildcard search function in GNU make to find all files that matched "%.moc.hpp", and then ran moc against all of the results. It's not a huge burden, but it's still kind of annoying. It interferes when you just want to write a small utility class and have your interface and implementation in the same file. You have to deal with knowing what moc is called (moc on most platforms, moc-qt4 on Debian). You can't distribute pre-parsed moc files because they are extremely version-dependent.
> I tend to prefer qmake over make
I prefer GNU make over qmake, bsdmake et al. qmake is great if you like it, but not if you're already happy with your build environment, use lots of specific features from your build tool, and don't want to change it just to make using Qt easier.
Of course. That's also the reason we have UTF-16 and a Qt reimplementation of the standard library: the project's age and need for backward compatibility.
moc for C++98 didn't offer closures, so you still had to write a separate function and then call connect() to link the signal with the new slot function. Even in C++98, moc could have instead just allowed you to use a version of std::function, written for C++98 (I wrote such a container, as did boost.) So instead you'd have: button.onClick(&MyClass::clickEvent, &myClassObject); which for at least 98% of GUI programming, would cover the same use case as connect(button, SIGNAL(pressed()), &myClassObject, SLOT(clickEvent())); but without the need for preprocessing; and without the downside of run-time type checking of the signal and slot names.
...
I definitely don't doubt you that you have use cases that moc makes significantly easier. But in my case, I really don't. And I've written a dozen simple to moderately complex UI applications. So, I would be appreciative if in my simple case, I didn't have to use moc at all.
One thing I do like, that is possible with a fancier std::function class, but is still kind of clunky with pure C++, is the way you can bind a slot that has less parameters than a function ordinarily takes. It's a nice way to offer additional information, but not require you to have an exactly matching callback signature. Great for binding multiple signals to the same generic slot that handles all cases at once (eg "synchronize()" called whenever you change a setting.)
> You only need to run headers of QObjects through MOC, although that is most of them if you are using Qt, obviously.
Yeah, I wrote a recursive wildcard search function in GNU make to find all files that matched "%.moc.hpp", and then ran moc against all of the results. It's not a huge burden, but it's still kind of annoying. It interferes when you just want to write a small utility class and have your interface and implementation in the same file. You have to deal with knowing what moc is called (moc on most platforms, moc-qt4 on Debian). You can't distribute pre-parsed moc files because they are extremely version-dependent.
> I tend to prefer qmake over make
I prefer GNU make over qmake, bsdmake et al. qmake is great if you like it, but not if you're already happy with your build environment, use lots of specific features from your build tool, and don't want to change it just to make using Qt easier.