Pavel Antokolsky aka Zigmar wrote:
- What is your evaluation of the design? In general - I liked it. It looks a bit complicated in some places, but I guess this is tradeoff played for its power. I've made several tests and found that library is easy enough to use, yet powerful enough to do what most people need for IPC communications.
One minor thing, I didn't particularly liked about design is that several method (for example shared_message_queue::receive) return values into variables passed by non-const reference. I don't like this approach - the resulting code is obscure because you can't see from that code, that variable is modified. I think of the the following approaches might result a better client code: 1) Return multiple values (i.e. by using std::pair, boost::tuple) 2) Modify parameters, but instead of passing by non-const reference - pass them by pointer. When pointer passed it immediately indicates that variable might be modified as opposite to non-const reference, which is a rare beast nowadays. If you think of foo(someVar) via foo(&someVar), the second hints about possibility of modifying someVar, while first one doesn't.
I have not had time to look into shmem yet, so my comment is only to the above text without looking at the code. 1) This is not always a good idea because of the cost of copying a returned object. Also when using templated functions the compiler can deduce the type from the argument instead of having to specify it explicitly. 2) No, No, No. I strive for pointer free code. A method that advertises a non-const reference tells you that it will modify the object. A const reference indicates that it will not. A function that takes a pointer tells me nothing. KevinH -- Kevin Heifner heifner @ ociweb.com http://heifner.blogspot.com Object Computing, Inc. (OCI) www.ociweb.com