Subject: Re: [boost] [review] string convert
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-05-04 09:29:21
Vicente BOTET wrote:
> De : "Stewart, Robert"
> > Vicente BOTET wrote:
> > > De : "Stewart, Robert"
> > What your three options don't address, then, is indicating
> > conversion failure, without an exception, for a type with
> > neither a default constructor nor a usable sentinel value.
> > That was the purpose of Vladimir's result type: it could be
> > queried for success and for the value.
> Please, check the post around May 03, 2011; 10:09pm that
> includes a file with the complete post without angle brackets
> issues. There you will find all the cases.
I thought you were proposing those three options as the solution. I now understand that you still meant for an error_code overload or a no_throw overload to be the means to determine whether conversion fails without relying on fallback values.
The latter involves returning a pair<value, bool> which I dislike. boost::optional would be better as it supports safe-bool and a more meaningful get() for extracting the value (versus .second and .first for your pair).
If there's truly value in using an error_code, that interface is good because it affords the ability to provide more specific diagnostics. Otherwise, I'd prefer the optional interface with nothrow or even a "try" variant to avoid the argument.
> > I haven't looked at the design of your library, but
> > presumably these assignment operators are on a conversion
> > type. Your conversion type's state is being set from
> > another type in the various assignment operators, which is
> > the normal sense of assignment, but your purpose of doing so
> > is simply to provide the source value in order to extract it
> > subsequently as the target type. That seems an abuse of
> > assignment.
> If you have a class C1 you can define the following operator
> C1& operator=(C2 const& rhs);
> As I understand this, we are converting a C2 to a C1 via an
A constructor with such an argument is, certainly, a converting constructor. While I don't think of assignment in the same terms, it is not much of a stretch to consider it similar. Nevertheless, the assignments in your case are to a converter, not to the target type, which I still contend is abusing assignment.
> The assign_to function is a way do it extrinsically, i.e.
> outside any of the classes C1, C2.
> C1& assign_to(C1 & lhs, C2 const& rhs);
> We can say assign_to is to C1& operator=(C1&,C2const&) as
> boost::swap(C&lhs,C&rhs) is to C::swap(C& rhs).
Your assignment operators are not on the target type, but on a converting proxy. Using assign_to() implies that the operation is lhs = rhs, but that's incorrect. The operation is, instead, lhs = f(rhs), where f() applies some transformation to rhs to produce lhs. Hence, "assign_to" is the wrong name.
Rob Stewart robert.stewart_at_[hidden]
Software Engineer using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP http://www.sig.com
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk