From: davlet_panech (davlet_panech_at_[hidden])
Date: 2002-02-28 12:51:22
--- In boost_at_y..., Iain.Hanson_at_u... wrote:
> Author: davlet.panech (davlet_panech_at_y...) at unix,mime
> Date: 27/02/02 20:23
> - I think it would make sense to provide conversion to an
> "native" type (such as sockaddr)
> Why? As I said in my previous posting, I can't see any good reason
> doing this. And I have no desire to encourage mixed mode
> which would be very type unsafe. I don't see the point in a user
> a safe C++ address class to use with C socket api.
I think if we are providing a constructor that takes a sockaddr, we
might as well provide the inverse of that.
> >Also from your explanations I take it that your socket library is
> >modelled after BSD sockets. I think it would be reasonable to at
> >least try designing a system that be implemented without BSD
> >sockets. For example I might want to plug in an NT named pipe
> >"protocol" (which does not use WinSock).
> BSD sockets are a very strong influence on my thinking. As is XTI
> WinSock. I am also very aware that ACE has a general purpose IPC
> abstraction. However, the requirements state ( and I agree with
> ) that we should not go done that path. The reason, as I see it is
> that it could easily distract and compromise the production of the
> best possible sockets library
That's OK, I just think that this 1st abstraction layer (aka BSD
socket wrapper) shouldn't be hard-wired into the upper layers. IMHO
it's not that hard to do (we just need to make sure that our upper
layers are parametrized properly); yet it will allow us to use the
upper layers with non-socket-based networking.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk