Re: We do not use C++ exceptions
On Jan 23, 5:19 am, Seungbeom Kim <musip...@bawi.org> wrote:
There have been lots and lots of discussion about this, and I feel
I'm opening that can of worms again, but... an unsigned parameter
doesn't prevent you from passing a negative value. Unsigned in C or
C++ is not "restrictive" in any sense; it just provides an alternate
"view" or "interpretation" of the underlying data and operations.
the valid range for signed
bang! ,-----------------------. bang!
3-bit signed: ~~~~~~~~~~~ -4 -3 -2 -1 0 +1 +2 +3 ~~~~~~~~~~~
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-
3-bit unsigned: 0 +1 +2 +3 0 +1 +2 +3 0 +1 +2 +3 0 +1 +2 +3
Signed means a finite strip on which you'll be doomed if you walk
past the ends, and unsigned means that the ends are put together
so that the strip forms a ring from which you can never fall off.
Hi Seungbeom,
This true. However, the goal of using unsigned versus signed is not to
prevent a signed value from being passed to a function expecting
unsigned.
The goal of using unsigned is to enter a new realm of thinking, where
all values that are inherently non-negative use unsigned. As it turns
out, by far, the majority of quantities in a program are naturally non-
negative. This mindset requires that the programmer do two things:
1. define parameters for inherently non-negative quantities to be
unsigned
2. define normal global and stack variables for inherently non-
negative values to be unsigned
So for example:
void foo (unsigned int);
int main ()
{
int x = -1;
foo (unsigned int); // 2^32 - 1 passed on 32-bit 2's comp machine
return 0;
}
I would never, ever, define x to be int. I must repeat: If I had to
write a 1,000,000 program, there would be no place in it, not one,
were you would catch me doing that, because I am just as predisposed
to choose unsigned int for an inherently non-negative quantity as
someone else is to choose int for that same quantity.
It requires a change in mindset to be consistent. My contention is
that not only is it possible to change the mindset and be consistent,
but the mental relief gained is far greater than the mental relief
gained by adding ASSERTs. The code looks better, and the components
actually work together better because they need not be prepared to
defending themselves from code that is fundamentally defective. By
contrast, there are some cases when a programmer might deliberately
allow a malformed value to enter his system, while remaing acutely
aware of the potential for an exception and is ready to catch it:
struct IP_Address
{
IP_Address (const char *); // throws BAD_ARGUMENT
} ;
try
{
IP_Address addr ("127.0.0.$");
}
catch (...)
{
// no big deal, I knew this could happen.
}
I guess the fundamental premise is that I control my code. I control
my system. These signed/unsigned problems never occur in my world
because I make sure they don't. All I see are a huge number of
unsigned entities all working well together.
The mental relief gained is immeasurable.
Q: Yeah...but what happens when the steam starts to rust the inside of
the engine?
A: Who said I was using a ~steam~ engine?
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]