Date: 2002-02-28 14:21:06
from my previous post.
>>This seems fine, as long as your resolver design allows for a >succint
>>syntax with the socket address class so that users aren't motivated
>to avoid deailing with hostnames -and- dotted decimal names out of
>>In other words,
>I have only roughly modeled the resolver, so far but yes, I would expect
>it to be at least that simple. I would probably prefer a free function
>that allowed getting the primary directly, such as:
>address Server_Address ( primary_address ( "www.boost.org" );
>maybe at layered on top of this there could be a resolvable_address.
What I meant by layered on top of would probably be containment and certainly
not inheritence. A resolverable_address would be constructable from DNS names
whereas the address class currently under discussion is only constructible from
dotted decimal strings such as "10.0.0.1"
A resolver class will need to deal with address_info and have iterators etc. but
thats getting ahead of myself.
______________________________ Reply Separator _________________________________
Subject: Re: [boost] sockets Interface for address class
Author: boost (boost_at_[hidden]) at unix,mime
Date: 28/02/02 15:34
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
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_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
Info: http://www.boost.org Send unsubscribe requests to: <mailto:boost-unsubscr
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Visit our website at http://www.ubswarburg.com
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk