Boost logo

Boost :

From: Iain.Hanson_at_[hidden]
Date: 2002-02-28 08:22:59


Author: davlet.panech (davlet_panech_at_[hidden]) at unix,mime
Date: 27/02/02 20:23

>I have a few suggestions:
>- You missed the const modifiers in a few places

Thanks. I've fixed that and will post it to the files in socket2/address.html
which also has the GenVoca grammer in it. Whilst reviewing the interface for
const correctness I realised that port_type should be passed be reference and
not by value as OSI has arbitary size transport selectors and there is no
guarantee that other protocols in the future will stick to a selector compatible
with built in types.

>- I think operations involving strings should use std::string, not
>char arrays (except perhaps the non-explicit constructor, so that
>implicit conversions from string literals are possible)

There is no need for an address class to store the string it is
constructed with as this would greatly increase its size. It just
marshalls the string into an address_representation. Conversation
back to human readable form is typically for logging and therefore
the cost of converting from representation to presentation form is
negligable in comparrison to the run time overhead of I/O so its
not worth storing the string.

- 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.

- We also need a few special pre-deined IP addresses (like loopback).

These would go in a protocol traits class. For IPv4 the default is but
in fact any 127 /8 is a legal loopback address. For IPv6 it is just a single
value of 0:1

[ snip ]
>I also considered using a separate IP address class (I was thinking
>about supporting "raw" IP sockets), which would incorporate the name
>resolution services; in this case all `IP address' parameters in the
>above class would be of type `ip_address' instead of `std::string'.

see below.
>Actually, I think the representation of addresses is the least of
>our problems when designing a socket library. The way I see it, we
>should concentrate on things like protocol, blocking policies, and
>the actual socket abstractions first, since it is not obvious how to
>design these things. How do we implement non-blocking operations?
>Asynchronous events (like disconnect indications)? What about error

It is the 1st abstraction we need when building a socket library and
much of the core of the library is dependant on it. Hopefully, from
little acorns, a great oak tree will grow ;-).
>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

BTW the terminology I use on the whole tends to be BSD because that
is what most people understand. My preference is for OSI terminology
which is much cleaner, has better abstractions, and is more exact
IMO. I don't, on the whole, use it here because I suspect I would end
up talking to myself ;-).


Visit our website at

This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.

Boost list run by bdawes at, gregod at, cpdaniel at, john at