Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-05-04 07:11:25

Vicente BOTET wrote:
> De : "Stewart, Robert"
[repeat several times!]
>
> > > > > template
> > > > > Target convert_to(Source const& s, Target const& t);
> > > > >
> > > > > template
> > > > > Target& assign_to(Target& t, Source const& s);
> > > > >
> > > > > template
> > > > > struct default_value
> > > > > {
> > > > > T apply() { return T(); }
> > > > > };
> > > > >
> > > > > This meta-function will be used instead of declaring a
> > > > > defaulted variable in the string conversion function.
> > > > >
> > > > > T v(default_value::apply());
> > > >
> > > > None of those options work for types without a default
> > > > constructor *and* without a sentinel value.
> > >
> > > Why? For me the 3 options work.
> >
> > Consider conversion to int, where all values are allowed:
> >
> > int const fallback(/* what to use here? */);
> > int const t(convert_to("some string", fallback));
> > if (t == fallback)
> > {
> > // is this because the conversion failed or because
> > // of the second parameter?
> > }
>
> Note that in this case, if conversion fails an exception is
> thrown.

Ah, sorry.  I stated the use case you didn't address incompletely and didn't realize you meant for such a call to convert_to() to throw an exception.  In Vladimir's library, adding the fallback argument implied non-throwing behavior and I assumed the same here.

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.

> > > assign_to is the functional for of operator= (assign). This
> > > operator can accept any type on its lhs, making a
> > > conversion. I think the name assign_to respect this schema.
> >
> > I'm not arguing why you have the function, I'm just telling
> > you that I don't find the name to be good.
>
> Would you have a better name?

Not presently.  I need to think about it more, but first...

> > I also don't thing assignment for conversions is appropriate.
>
> Well, this is part of the language, I'm quite sure the C++
> standard and Boost uses this kind of assignations. As a generic
> function emulating extrinsic assignation you should I must
> follows the standard mechanism conventions. It is up to the
> user to overload or not this function which by default relies
> on the operator=.

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.

> > Hmmm. Those codes aren't extensible. Do they really describe
> > the sorts of errors likely to occur during such conversions?
> > If the codes don't cover everything, then they won't work.
> > You'd need a different list, though a similar design would
> > work.
>
> error_code is extensible because error_category is. You just
> need to define a specific category and use it to instantiate
> your error codes, isn't it?

Yeah, I forgot about the error categories.

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