Boost logo

Boost :

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-04-20 15:49:58


From: "Dill, John" <john-dill_at_[hidden]>
> "Rob Stewart" <stewart_at_[hidden]> wrote in message news:<200404201905.i3KJ55e08992_at_[hidden]>...
> > From: "Dill, John" <john-dill_at_[hidden]>
> > >
> > > I am wondering about the use-case of numeric_cast in this sample.
> > >
> > > unsigned char uchar_max = std::numeric_limits<unsigned char>::max();
> > > char schar_value = 0;
> > >
> > > try {
> > > schar_value = boost::numeric_cast<char>( uchar_max );
> > > }
> > > catch ( boost::bad_numeric_cast )
> > > { std::cout << "Overflow occurred..." << std::endl; }
> > >
> > > When I execute this sample, I don't get the exception. What's
> > > the background on this behavior? I'm using gcc 3.3.1.
> >
> > Your char is unsigned.
>
> I'd like to know why conceptually the exception isn't thrown.

As I said, in too few words, is that your "char" is unsigned, so
"char" and "unsigned char" are essentially the same type.
Technically, they are distinct types (for overloading purposes,
for example), but they are both unsigned and the same size, so:

   assert(std::numeric_limits<char>::max()
      == std::numeric_limits<unsigned char>::max());

on your system.

> Why is it beneficial to have unsigned T to signed T overflows
> not be detected? It is not just char, but short, int, and long
> as well.

Now that's another story. Changing "unsigned char" to
"unsigned" and "char" to "int" should cause an exception. If
that's not happening, I don't understand since
std::numeric_limits<unsigned>::max() is greater than
std::numeric_limits<int>::max().

> If this was the intended behavior, then what is the reasoning
> behind it?

What you describe isn't the intended behavior other than the char
problem.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;

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