Boost logo

Boost :

From: Bjorn.Karlsson_at_[hidden]
Date: 2003-01-16 02:56:57


> From: Thorsten Ottosen [mailto:nesotto_at_[hidden]]
> > What would the advantage be over using boost::numeric_cast
> directly, and
> > thus explicitly?
>
> you would't have to worry about if you forgot a numeric_cast
> somewhere in
> your code
> or if you compiled on a platform with different ranges for
> built-ins which
> suddenly
> could make conversion problems appear.

That you don't have to worry is only true to a small extent - you still need
to worry, by protecting the code *somwhere* with a try/catch block. This is
also true for numeric_cast, but then it's straightforward to grok the code
when reading it. Obviously, the (potential) problems are always there as
soon as one starts mixing signed/unsigned types, and when assigning to a
potentially smaller type; they must always be checked regardless.
 
> that depends on what the "problem" is. I would say that an
> _undetected_
> false conversion
> is the biggest problem.

Agreed!
 
> >Doing it "manually", and acknowledging the potential problem by
> > using numeric_cast is (in addition to ensuring correct behavior)
> > self-documenting, a property that I think is rather important.
>
> by using a wrapper, you also acknowledge a potential problem.

Yes, and when writing code like this: safe_numeric<unsigned char> t=u;, a
reader can understand that - the code has documented itself. But I don't see
an advantage over writing unsigned char t=numeric_cast<unsigned char>(u); in
fact, the resemblance with a cast operator makes numeric_cast especially
intuitive. On the other hand, using typedefs such as "Char", would convey
nothing to the casual reader.
 
> I might also be beneficial when you are chaning a variable
> from one type to
> another; the change
> might cause conversion problems some different place in the
> code and/or
> require numeric_cast
> to be inserted. By using wrappers this would be detected.

True, but the price of this detection is using wrappers everywhere, which
defeats the purpose, IMO; how should a maintainer know which parts of the
code contains potential conversion issues when *all* of the code is implying
that is the case?
 
Bjorn


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk