Re: [boost] [asio] some stuff about ipv4::address

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2006-01-04 10:21:50

Christopher Kohlhoff wrote:
> Hi Yuval,
> 
> --- Yuval Ronen <ronen_yuval_at_[hidden]> wrote:
> 
>>What I dislike is the string-accepting contructor and the
>>to_string() method. My personal taste is that textual
>>conversions (and the ip::address class is a very good
>>candidate for this) should be made through the standard
>>ostream/istream operators. This has the usual advantages of
>>using an idiom. It also provides standard means to detect
>>parsing error using the ios_base::fail bit. The ip::address
>>currently has the only option of throwing in the
>>string-accepting contructor, however, this is not intuitive,
>>IMHO (and not documented). String conversions can be easily
>>performed using boost::lexical_cast.
> 
> 
> I think the current string conversion functions are convenient
> and natural, and I see them not being coupled to iostreams as a
> feature :)
> 
> However I take your point about non-throwing parsing, so I will
> add both input and output iostream operations for the address
> class (and the endpoint classes too).

But if you do supply the I/O operators, then you don't really need the 
string operations because you get those for free using lexical_cast, 
don't you? Wouldn't you want to save writing code that is already 
present in lexical_cast?

>>Another thing is the plethora of assingment operators.
>>Wouldn't a single copy-assignment be enough?
> 
> 
> For the current implementation, probably yes. But I don't want
> the interface to assume that the implementation will always be
> so cheap as to not worry about extra temporaries.

I don't think there is any such assumption in what I said. You should be 
saying to the user: "you can assign an ip::address from X, Y, and Z", 
and that's all he needs to know. There's a difference between this and 
"there is an assignment operator from X, Y and Z". The latter is less 
flexible than the former, and for no good reason. Stating the former 
allows you to include or disclude these assignment operators as you see 
fit, without changing the user's interface.

But this is really a minor issue...