From: Christopher Currie (christopher_at_[hidden])
Date: 2003-10-30 14:04:17
Jessie Hernandez wrote:
> Well, I just finished uploading a new version of my "socketstream"
> classes (which has been renamed to be in "boost::net"). It is in the
> Yahoo files section under the "socketstream" folder
> (net-20031024-1.tar.gz ).
>
> I'd like to get feedback on the current state of the library and see
> what can be improved (I'm mostly interested in the design aspect).
> Forgive me for not providing example programs up front, but I hope to
> add this soon (for now, the test.cpp file provides a few samples).
> Thanks.
I've finally had a chance to sit and look at this, sorry for the delayed
response. My impression is very good, you've obviously put a lot of work
into this. Keep at it!
I'm somewhat concerned about the ErrorPolicy parameter in your
framework. I'm glad to see that you've put in a method of reporting
errors other than throwing exceptions around, because there are
instances where I cannot affort the stack unwinding for something as
common as "connection_refused".
But your current implementation has two drawbacks:
1. I'm unable to pass information to my policy on construction.
You create the policy object internally to your socket, using a default
constructor. However, I might want a policy object holds a function
pointer, so that my policy can call back to objects of my own. I might
want that to be a different object for each of my sockets, but as it
stands I have no control.
To correct this, your socket constructors would need a parameter to pass
in a copy-constructable policy object; or if you want to allow
non-copyable policies, a pointer to such an object (maybe even an
auto_ptr to allow the socket to take ownership).
2. I'm unable to change the existing policy at run-time.
Having the policy as a template paramter means that my policy is fixed
for a given instance of an object. If cirumstances change, in order to
change my policy I'm forced to create a new socket instance, which
effectively means closing and reopening my connection just so I can
change the way errors are reported.
Having a function that would allow me to replace the existing policy
would help. But this only allows me to replace it with a policy of the
same type, since the type is enforced by the template. If I want a
drastically different policy, I either need to have a single policy type
that enforces multiple policies, or the socket would need to accept
pointers to the policy type, so I could implement a policy inheritance
hierarchy, which would then eliminate much of the advantages of having
the policy be a template in the first place.
Is this over the top? Possibly. But for these reasons, I'm not sold on
the idea of using a template to enforce policy in this case. Most
likely, there are two main error handling scenarios; throwing an
exception, or returning (or setting) an error code.
Exceptions are seen as being more OO-like, but they have performance
penalties that are unacceptable in some situations. Ultimately, we might
be best off implementing some variation of the iostreams model: define a
collection of error codes, and the user is able to set an exception mask
to determine which errors generate exceptions.
Although I haven't had a lot of time to analyze it, things look good so
far otherwise, so keep up the good work.
Christopher