Lots of good feedback, thank you!
On Sat, Aug 10, 2013 at 6:55 PM, Rob Stewart
named_pipe_object is an odd name. Why "object"?
For consistency with the interprocess library. For instance creating a shared memory object you write:
shared_memory_object shm; I actually don't like it either,
Construction with char const * attaches to an existing pipe, while with a std::string it creates a pipe? That's horrible. Those ctors should have the same behavior. Use an enumerated type argument to distinguish on behavior from the other or use the Named Constructor Idiom.
Thanks for the catch, but that's really just a "typo" of me editing one piece of documentation and not the other. They will definitely have the same behaviour.
"some" in read_some() and write_some() is not helpful.
This again was for consistency with the Boost.Asio convertion of differentiating reads/writes that will block until the size is full, vs the more low level construct of write-what-you-can/read-what-is-available. How does read_some() know the size of the supplied buffer? You need a size
argument (or buffer type discussed separately).
I definitely favour the buffer type instead of size argument. It looks like Boost.Asio already has a buffer typehttp://think-async.com/Asio/asio-1.4.8/doc/asio/reference/buffer.htmlthat can be used to wrap builtin arrays, std::vector or boost::array. It seems useful enough that it would be worth the coupling to use it. Also, it seems like this functionality wants to live halfway between Asio and Interprocess :) I don't think named_pipe_server is needed. One creates or connects to a
named pipe. A single class can handle both aspects, through different constructors.
I disagree, and here's why. With a named pipe you can either act as a server, and be prepared to accept multiple incoming connections or you can be a client and connect to a "server." With a separate "server" object this is fairly natural I think: named_pipe_server pipeserv("pipename"); for (;;) { named_pipe cli_conn = pipeserv.accept(); // Do stuff with the new client } Whereas if you had to use named_pipe for everything there's the potential for changing the name, and thus creating a completely new pipe (instead of another connection on it). There is definitely another use-case for a one-to-one connection. That would be a good candidate for an alternate factory function on named_pipe, but I think the separate server object is still useful. Also, here's the new version with your all's feedback incorporated. -- Geoff Nothing is ever easy.