Boost logo

Boost :

From: davlet_panech (davlet_panech_at_[hidden])
Date: 2002-02-27 15:23:12

--- In boost_at_y..., Iain.Hanson_at_u... wrote:
> The following is the interface for a unicast address in psudo
> I'm not that enamoured by the names of the mutator and
> methods so if anyone has better suggestions they would be
welcome. I'd
> appreciate comments, is this interface complete ? is it too
fat? etc.
> class address
> {
> public:
> // none of the following ctors need marshalling address ( );
> // sockaddr_in or in6
> address ( protocol_address_representation & Address );
> address ( address & Rhs );
> address & operator= ( address & Rhs );
> // the following two need marshalling
> address ( const char * Address , port_type Port = any_port );
> explicit address ( const std::string & Address ,
> port_type Port = any_port );
> // mutators
> reset ( const char * Address , port_type Port );
> reset_address ( const char * Address );
> reset_port ( port_type Port );
> // accessors
> const char * c_str ( ) const;
> const port_type port ( )
> };

I have a few suggestions:
- You missed the const modifiers in a few places
- 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)
- I think it would make sense to provide conversion to an unspecified
"native" type (such as sockaddr)
- We also need a few special pre-deined IP addresses (like loopback).

With these things in mind here is my take on it:

class inet_address {
  typedef uint16_t port_type;
  static const port_type any_port = 0;

  // could be `sockaddr'
  typedef IMPL_DEFINED native_type;


  // Dotted-decimal IP addres + port:
  // 111.222.333.123:80 or
  // 111.222.333.123 <-- assume ANY port
  inet_address( const char *full_addr );
  inet_address( const std::string &full_addr );

  inet_address( const std::string &ip_addr, port_type port );
  inet_address( const native_type & );

  // Special predefined addresses
  static inet_address loopback( port_type port = any_port );
  static inet_address any( port_type port = any_port );

  // These accept the dotted-decimal notation + port
  // or hostname + port, in which case they use the
  // more generic name resolution service:
  // 111.222.333.123:80
  // <-- assume ANY port
  static inet_address primary( const std::string &full_addr );
  static inet_address primary( const std::string &ip_addr,
     port_type port );

  std::string str() const;

  std::string ip_addr() const;
  void ip_addr( const std::string & );

  port_type port() const;
  void port( port_type );

  const native_type &native() const;

  // Return non-zero if address is valid
  operator const void *() const;

  // (Copy & assignment)
  // (Relation operators)
  // (Destructor)

  // ...

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

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

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

Your thoughts?

> plus ostream and istream operators
> /ikh
> 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
> does not accept liability for any errors or omissions in the
> 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
> related financial instruments.

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