3 ms·
My problem with it is the fact that it inserts itself in my otherwise standard-conformant C++ code; right in the middle of class declarations. If I decide I wan
by RotsiserMho 10y ago
My problem with it is the fact that it inserts itself in my otherwise standard-conformant C++ code; right in the middle of class declarations. If I decide I want to use another GUI framework I'd have to refactor that code. Most other build steps occur before or after compilation and are far less intrusive. In short, it's too tightly-coupled to application code.
- dkersten 10y agoYou mean stuff like the "signal" and "slot" declarations in the class definition? Wouldn't these types of classes be tied to the GUI framework anyway due to the inherited classes, implemented virtual functions, widget classes referenced and so forth? In my experience (having used Qt, GTK, FOX, FLTK and wxWidgets over the years), different GUI frameworks are significantly different in their APIs and how they work, to the point where I think changing existing code from any of these to any other is a very difficult job, with or without moc.
- joezydeco 10y agoIf I decide I want to use another GUI framework I'd have to refactor that code. If you're already developing in Qt, what do you think the probability of that is? Personally MOC is worth the price of admission just to have signals transparently marshaled and queued across threads. It makes life incredibly easy.