Dave Abrahams wrote:
"Deferred Callable Object" http://www.boost.org/doc/libs/1_49_0/libs/fusion/doc/html/fusion/functional/... Sorry, I don't follow any of this. When you say "functors," what do you mean? You're the boost guy; I think the ontology in fusion is more than enough.
Perhaps it's abuse of the term, but I use "functor" to mean callable, usually copyable object (including function pointer).
That word has a formal meaning in computer science that is probably not what you mean, and an informal meaning in C++ (just another word for "function object") that doesn't /seem/ to be what you mean. http://en.wikipedia.org/wiki/Functor "For functors as a synonym of 'function objects'"
I think we're talking about the same thing. Would you perfer I use "function object"?
Consider this big monster object with this interface. It's not movable/copyable (maybe it has its own threads). I think you'd find something like this acceptable.
struct monster : noncopyable{ typedef signal<void ()>::slot_type slot;
connection subscribeA(slot); connection subscribeB(slot); connection subscribeC(slot); ... };
It's got threads, io_service, mutexes, signal2, containers, sockets, etc inside it that don't like being moved/copied and don't need to be. What would you do Dave?
I wouldn't write a monster in the first place. You believe in OOP encapsulation (separation of problems), right? I think if you had this kind of problem, you'd also try to hide the details behind some minimal interface. I can understand you proposing a better interface.
I can't imagine you saying "C++ programmers shouldn't do network programming". So imagine a good C++ programmer like has yucky details to encapsulate: * networking protocol * TCP sockets - to multiple servers * UDP/multicast sockets - which should join/leave when needed * containers for subscriptions - say B's have ids * unsubscribe - optionally lazy * threads - single or pool of threads All the users care about is subscribing and getting updates. What should the interface look like? Was I that far off? Did I try to hide too much?
Would you prefer to put all of monster's guts in a shared_ptr-ed pimple so monster can be copied?
This is an honest question. I may be a couple steps behind on best practices of C++. I'd probably give the user of monster an object he can't move/copy. Is that generally bad? Do you think all objects be copy/movable?
I think it's 99.9% reasonable to make all objects movable, and maybe 75% reasonable to make all objects copyable. You can do either or both of these, the difference is a matter of degree: just how uncompromising do you have to be to build a world that makes sense? A good candidate for the 25% is any object that is supposed to represent and external resource. Example: a TCP session with some other process. It makes sense to have a non-copyable object which exclusively owns that session whose deconstructor logs out and disconnects. You can copy the fd. You could connect a second time. You probably can not tell the server on the other side to copy all the state from associated with one session to another.
Here's the 0.1% case I tend to have, but maybe you think it's bad form. If an object has members which are needed for synchronization with a private thread, it can't be moved. Say I've got an class that has a private member mutex and thread it uses. I can't safely just move the mutex. A move constructor would have to * tell the worker thread to go park itself and wait for instructions from some temporary synchronization object * wait until it's parked * move the inards of my object including mutexes * tell the thread to continue using the new location That seems hard and error prone. So I'd never implement it unless there was a need. It might be done easliy by smart_ptr<> pimple but that costs something too. It's also something a user of an object can do. Let the user decide how ownership should work. Anyway such a pimple type though private would still be a 0.1% type. Here's a nice example: boost::asio::io_service isn't movable. Should it be? I wouldn't call asio legacy code. To me it appears to be the latest style of interface. Chris