Re: [boost] [system][filesystem v3] Questionabout error_codearguments

Subject: Re: [boost] [system][filesystem v3] Questionabout error_codearguments
From: Peter Foelsche (peter_foelsche_at_[hidden])
Date: 2009-10-26 20:16:28

"David Bergman" <David.Bergman_at_[hidden]> wrote in message 
news:080E88A6-D02B-4AAD-B2FC-B9E6A8E97F5C_at_bergmangupta.com...

> Agreed. I am a huge proponent of using exception handling instead of 
> error codes (virtually everywhere), but considering that ASIO is one  of 
> the best, and most cleverly, designed C++ libraries ever made (up  there 
> with Boost.Graph and Boost.MPL), one should be a tad careful  before 
> bantering like that. The likelihood of one's being a better C++- using 
> designer than Christopher is not that high, statistically  speaking...

I've a lot of respect for some parts of the boost library -- e.g. mpl.
I learned a lot from using the mpl.
I also learned a lot from boost::variant and boost::any.

Did you actually read my posts?
He designed a socket library, which is full of protocols
(Protocol is my word for a class-design,
which requires that methods of an object be called in a particular order.).
He also does not understand the usefulness of exception handling in larger 
software projects.

>> I suspect you have a point you would like to make about
>> the interface. If you keep the personal attacks out of the
>> statement you will be more clearly heard.
>
> If I were Christopher, I would kindly ask for instances in the ASIO 
> library where exception handling would help readability, performance  or 
> any other aspect. I think there might be such cases, but that would  be 
> like whining about a pimple on Halle Berry's face.

I think in 1996 I designed some classes to wrap UNIXs socket and io calls.
There was a socket class calling socket() in the constructor and close() in 
the destructor
without any other methods.
This class does not need to be public, as it is useless for the enduser.
Then there are classes,
* which connect to a well known address (for usage as a client)
* and a class calling bind() and listen() to a wellknown local address (for 
usage as a server)
-- both classes are based on the socket class.

These classes have cast functions to cast into a int -- the filedescriptor.

Then there are implementation of some read-from-somewhere interface and some 
write-to-somewhere interface
-- reading from a filedescriptor and writing to a filedescriptor.
Such implementations of read-from-somewhere and write-to-somewhere can be 
combined to produce cached reading and writing.

Then there was another layer using the XDR libraries to deal with machine 
independence,
which was pretty complicated due to the crazy XDR interface (which UNIX API 
is not crazy?).

And I think I had to deal with various UNIX hacks, like e.g. connect() 
returning immediately.

The write-system call also had to be wrapped by setting/resetting the signal 
handler for SIGIO.

All of these functions threw on error -- a system error object.
This made debugging server-client systems much more easier than before,
since now people knew the system error and the method which failed
and maybe even the call-stack of the failed operation:

Cannot start postprocessor in client mode! Because of
Cannot connect to "hostname":portnumber! Because of
No such host! ("Hostname").

I was only dealing with TCP/IP and not UDP.