|
Boost : |
From: Hamish Mackenzie (boost_at_[hidden])
Date: 2002-02-28 10:34:46
On Thu, 2002-02-28 at 13:32, Iain.Hanson_at_[hidden] wrote:
> As I posted previously, This is more the job of a resolver class and could
> also be layered on top of this address class as a resolvable_address.
Sorry, I missed that one. How about calling them resolved_address and
address? I expect most people will want to work with unresolved
addresses.
Also I think they should be two different things not derived from one
another (if that is what you meant by "on top of"). Constructing an
unresolved address should not mean resolving it.
You could resolve the address something like
address unresolved;
resolved_address resolved;
address_info_list list( resolver.resolve( unresolved ) );
if( list.size() == 1 )
{
resolved = (*list.begin()).resolved_addr();
}
Short hand for this could be
resolved = unresolved.resolve_single( resolver );
(The resolver argument could have a default to make it even easier)
This function would have to throw if list.size() != 1.
However, I think most high level functions should actualy accept
address_info and address_info_list as they would contain the information
required to call socket.
Another possibility would be to have three classes resolved_address,
unresolved_address and address. Where address is something like
class address
{
bool is_resolved_;
resolved_address resolved_;
unresolved_address unresolved_;
public:
...
};
Hamish
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk