Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk