Re: sockets Interface for address class

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
> 
> 
>      
[snip]
> 
> - I think it would make sense to provide conversion to an 
unspecified 
> "native" type (such as sockaddr)
> 
> Why? As I said in my previous posting, I can't see any good reason 
for 
> doing this. And I have no desire to encourage mixed mode 
programming 
> which would be very type unsafe. I don't see the point in a user 
building 
> 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.

[snip]
>      
> >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 
and 
> WinSock. I am also very aware that ACE has a general purpose IPC 
> abstraction. However, the requirements state ( and I agree with 
them 
> ) 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. 

Thanks,
D.P.