"Ken Hagan" <K.Hagan@thermoteknix.co.uk> writes:

> "Jack Klein" <jackklein@spamcop.net> wrote...
> >
> > The real problem is not so much that size_t is an unsigned integer
> > type, but the rules of promotion for unsigned types.  I am not the
> > only one who thinks that the "value preserving" choice for value
> > promotions in C89/C90 was unfortunate.
>
> I'm not sure I agree with the phrase "value preserving".
>
> Consider the following code (all integers)
>
>     a = (b*c)/d;
>
> What I would call a "value preserving" language would ignore the size
> and (un)signed-ness of the variables on the right hand side. It would
> take their values and generate whatever code was needed to get the
> mathematically correct answer assuming they were integers of unlimited
> range. It would then perform whatever truncation was needed to squeeze
> the answer into a.
>
> Clearly this forces compilers to deal with arbitrarily wide computations
> and the assignment to "a" is possibly value-destroying. However, I think
> the above proposal has fewer gotchas than the present arrangement.

I'd do something similar, but which avoids the arbitrary wide
computations:

Define a "compiler number range". All calculations are done in that
compiler number range; if any computation goes outside, results are
undefined. All integral types can store subranges of that CNR, but not
all subranges of the CNR need to be covered by any type (i.e. there
may be subranges where no type can store all numbers of that
subrange). Especially there need not be a type which covers the full
CNR. On assignment, the number (which is in the CNR) must fit into the
assigned-to type, otherwise the result is undefined.

Of course, a compiler would be required to document which CNR it uses.

> Also,
> a compiler can see that many expressions need only be evaluated at
> reduced precision since they are assigned to narrow result variables
> anyway. For example,
>
>     int a,b,c; /*...*/ a = b+c;
>
> A compiler need not widen b+c, since we truncate it immediately.
> Programmers who actually want wrap-around in sub-expressions (rather
> than only at assignments) can just introduce a temporary.

Or can add an explicit cast:

   a = int(b*c)+d;

Of course, in my model this would be pointless, since either it would
have no effect, or it would cause undefined behaviour. It could,
however, be an optimization aid for the compiler.

But wraparound could be done just using the modulo operator:

  unsigned char c;
  c = ((expression) % (UCHAR_MAX+1) + (UCHAR_MAX+1)) % (UCHAR_MAX+1);

(This double-modulo is necessary since % may give negative results)

To allow this even with the longest unsigned type, the CNR would have
to have a maximum of at least twice the maximum number of that type.

Alternatively a "positive modulo" operator %% giving only positive
results could be invented, then there would only be a need to have one
number above, to allow

  unsigned long l; // assuming unsigned long is the longest type
  c = (expression) %% (ULONG_MAX+1)

>
> Of course, another use for extended precision would be to calculate the
> number of lines of existing code that my proposal would break. :)

Well, mine would probably break even more code ;-)



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow <francis.glassborow@ntlworld.com> writes:

> The real trouble with unsigned is that programmers have to very careful
> that they do not mix unsigned with signed. Mostly mixtures work because
> unsigned is a modular type, but now and again it causes a disaster.

This is often caught by the compiler (if you heed the warnings). The
*real* trouble is when you start doing arithmetic with unsigneds. This
can - and eventually will - lead to a disaster without type mixing.

--
Oleg Goldshmidt | ogoldshmidt@NOSPAM.computer.org
If it aint't broken it hasn't got enough features yet.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 1 May 2002 21:57:05 GMT, jpotter@falcon.lhup.edu (John Potter)
wrote:

>
>On 29 Apr 2002 22:41:31 GMT, rhairgroveNoSpam@Pleasebigfoot.com (Bob
>Hairgrove) wrote:
>
>> As to arithmetic, can you give an example where it would be wise (or
>> even necessary) to mix signed and unsigned values?
>
>Neither wise nor necessary, but common.
>   vector<C> v;
>   ...
>   for (int x = 0; x != v.size(); ++ x)
>
>I'm sure that you always write
>   for (vector<C>::size_type u = 0; u != v.size(); ++ u)
>and
>   v.begin() + x
>but never
>   v.begin() + u
>

No, actually I would do this instead:

   vector<C> v;
   for (vector<C>::iterator it = v.begin(); it != v.end(); ++it)


Bob Hairgrove
rhairgroveNoSpam@Pleasebigfoot.com



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Geoff Field wrote:
>
> "Sungbom Kim" <musiphil@bawi.org> wrote in message
> news:3CC7DB8F.52E75D62@bawi.org...
> > I often find it somewhat "flawed" that the standard requires the data
> > type representing sizes of objects to be an unsigned integral type.
> >
> > They are just arithmetic quantities, like 'number of people'; no one
> > would recommend using unsigned numbers for those kind of quantities.
>
> Why not?  Can one have *negative* numbers of people, or negative sizes?
> To my mind, unsigned integral types are the most natural model of a
> count of anything "real" - be it people, bytes or bits.

You can negative values for the difference in between two different
numbers of people, or in the difference of two sizes. And, thanks to the
use of size_t, those negative values won't actually come out negative
unless you pay careful attention. Sure, you should always pay careful
attention; but it's bad design to create a system where there are,
unnecessarily, too many different things one has to pay attention to at
the same time.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Jack Klein" <jackklein@spamcop.net> wrote...
>
> The real problem is not so much that size_t is an unsigned integer
> type, but the rules of promotion for unsigned types.  I am not the
> only one who thinks that the "value preserving" choice for value
> promotions in C89/C90 was unfortunate.

I'm not sure I agree with the phrase "value preserving".

Consider the following code (all integers)

    a = (b*c)/d;

What I would call a "value preserving" language would ignore the size
and (un)signed-ness of the variables on the right hand side. It would
take their values and generate whatever code was needed to get the
mathematically correct answer assuming they were integers of unlimited
range. It would then perform whatever truncation was needed to squeeze
the answer into a.

Clearly this forces compilers to deal with arbitrarily wide computations
and the assignment to "a" is possibly value-destroying. However, I think
the above proposal has fewer gotchas than the present arrangement. Also,
a compiler can see that many expressions need only be evaluated at
reduced precision since they are assigned to narrow result variables
anyway. For example,

    int a,b,c; /*...*/ a = b+c;

A compiler need not widen b+c, since we truncate it immediately.
Programmers who actually want wrap-around in sub-expressions (rather
than only at assignments) can just introduce a temporary.

Of course, another use for extended precision would be to calculate the
number of lines of existing code that my proposal would break. :)




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1020129034.890475@cswreg.cos.agilent.com>, Geoff Field
<geofffield@hotmail.com> writes
>> They are just arithmetic quantities, like 'number of people'; no one
>> would recommend using unsigned numbers for those kind of quantities.
>
>Why not?  Can one have *negative* numbers of people, or negative sizes?
>To my mind, unsigned integral types are the most natural model of a
>count of anything "real" - be it people, bytes or bits.

Sure, they are fine for counting. However in a world where only unsigned
values were used (before mathematicians invented negative numbers)
subtracting a larger number from a smaller one 'failed', it did not
generate a ridiculously large answer. Trying to use a negative value for
an unsigned type should raise an exception.

>
>Apart from that, unsigned types on most platforms have an extra bit
>available for counting before going to the next size up.  This may not
>matter in the hosted world, but for us embedded folks it usually means
>adding lots of overhead to drag in another library or set of routines to
>handle the bigger data type.

But in the world of embedded coding there are many other restraints.
Anyone who jumps into that world without doing some form of conversion
course (if only careful study in private) will write poor code. The
requirements of embedded coding are special and should not be imposed on
everyone. I have no problem with unsigned integer types per se. I have a
big problem with being forced to use them or to use casts to remove
them.

I think size_t is wrongly specified, and I think time_t and clock_t are
underspecified (if you use either of those in arithmetic you have the
problem that they may be any arithmetic type.)


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1e27bd36.0205010847.3c667d35@posting.google.com>, Radoslav
Getov <rgetov@ultraheap.com> writes
>IMO the main problems with unsigned are:
>
>   1) The result of some operations (e.g. a-b) is "non-intuitive";
>   2) Mixed (signed/unsigned) expressions are 'unsigned';

Well not always:

unsigned short int usi = 5;
int i = -20;

What is the type of ( i-usi), and what is the value?

>   3) A false sense of 'safety' (guaranteed non-negativeness and a wider range)
>
>These, in combination with the fact that 'int' is traditionally "the type
>to use" in C, quite often cause troubles.
>
>BTW can you imagine the existense of "unsigned double"? I've seen many
>language extension proposals in these groups but not this one. Noone
>needs it! The (signed) double seems to be good enough. Having unsigned one
>(with 1 bit better accuracy, guaranteed non-negativeness, strange
>mixed expressions results) would cause just a confusion. The same way as
>does unsigned int, short, etc.
>
>Long ago 1 bit (in numbers' representations range) might have been
>important; that's not the case anymore. While unsigned is here to
>stay for compatibility reasons, fhere is no need to use it in the
>contemporary programs. I think it's very unfortunate that
>size_t happens to be unsigned and that STL (a relativelly contemporary
>creation) uses size_t and not int almost exclusivelly.

And the real irony of size_t is that there is also ptrdiff_t. Think
about it. Either the latter has to be a larger type than that used for
size_t or size_t must be limited to half its range (in any program that
uses ptrdiff_t)

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

gsakrejda@hotmail.com (Grzegorz Sakrejda) writes:

|>  Francis Glassborow <francis.glassborow@ntlworld.com> wrote in
|>  <t26KU6Avhtz8EwnZ@robinton.demon.co.uk>:

|>  >I would argue (on odd days of the month) that it only makes sense
|>  >to have an unsigned type if underflow raises an exception.

|>   And on even days i would wonder why C++ doesn't have more of low
|>   level functions that are easy to implement across different
|>   assembly languages /processors and encapsulate common
|>   functionality found in this processors.
|>   I mean something like :
|>     bool carry()  - if previous operation sets carry bit
|>     bool borrow() - the same more or less.

The problem with these is that at the hardware level, the flag
contains the result of the last operation. And there is no way to
rigorously specify which is the last operation preceding the call.

On the other hand, I could very well imagine something like:

    template< typename T >    //  Must be basic integral type...
    std::pair< T, bool >
    addWithCarray( T op1, T op2, bool carry = 0 )
    {
        //  Some compiler magic needed here...
    }

The result is the sum of op1, op2 and the carry, with the carry in the
second element of the pair.

--
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Erik Max Francis schrieb:
> I'm not sure what you mean by "no one," since that's exactly what
> unsigned quantities are good for.  How can you have a negative number of
> people?

never heard of this professor of mathematics with 300 students in
the auditorium?  when 400 left he says "now if 100 come in, the
auditorium is empty"...
:-)

 robert

--
Robert Klemme
software engineer
--------------------------------------------------------------------------------
myview technologies GmbH & Co. KG
Lindberghring 1 ~ 33142 B   ren ~ Germany
Fon: +49-2955-7433-20 Fax: +49-2955-7433-99
--------------------------------------------------------------------------------



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze <kanze@alex.gabi-soft.de> writes:

> gsakrejda@hotmail.com (Grzegorz Sakrejda) writes:
[asking for carry, borrow]
> The problem with these is that at the hardware level, the flag
> contains the result of the last operation.

More, at hardware level, there may be no carry flag.  Or a set of
them.

> And there is no way to rigorously specify which is the last
> operation preceding the call.
>
> On the other hand, I could very well imagine something like:
>
>     template< typename T >    //  Must be basic integral type...
>     std::pair< T, bool >
>     addWithCarray( T op1, T op2, bool carry = 0 )
>     {
>         //  Some compiler magic needed here...
>     }
>
> The result is the sum of op1, op2 and the carry, with the carry in
> the second element of the pair.

This is possible for unsigned types, but the specification for signed
one would be messy.

--
Jean-Marc

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

marg64@yahoo.com (Vahan Margaryan) wrote
> The logic that 'unsigned quantities should always be represented by
> unsigned types' is, IMO, wrong. Saying 'I had -3 guests' is illogical,
> but saying 'john was seated -3 guests to the right of mary' may make
> perfect sense in a programming context. A quantity that counts guests
> is unsigned, a quantity that offsets guests is signed. In a sense,
> that's what negative numbers were invented for. I don't want to mix
> unsigned guest counts with signed guest offsets, because I feel that
> will lead to bugs. That's why to me, only signed guests are welcome...

Maybe what you're really saying, is that the difference between
two unsigneds is signed?

Of course, that would cause problems too:
    unsigned int a = MAX_UINT;
    unsigned int b = 2;
    signed   int c = a - b; // Overflow

Maybe (if we ignore compatibility issues) the best way to handle
this would be to have two different subtract operators?

There is precedent for something (vaguely) similar in other languages.
For instance, Visual Basic has two division operators (one for floats,
the other for integer).

        a-b; // Returns unsigned result
        a@b; // Returns   signed result

I'm using @ as a placeholder here; the actual punctuation wouldn't
be important, but finding an available operator would be problematic.
Maybe we could overload ~ (tilde) this way -- just as + and - are
both unary and binary operators, ~ would be too. Otherwise we might
have to invent a new two-character token, such as !- .



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow <francis.glassborow@ntlworld.com> writes:

|>  And the real irony of size_t is that there is also
|>  ptrdiff_t. Think about it. Either the latter has to be a larger
|>  type than that used for size_t or size_t must be limited to half
|>  its range (in any program that uses ptrdiff_t)

Or the result of taking the difference between two pointers isn't
always defined.

Guess which solution was adopted in C (and continued in C++).

--
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique oriente objet/
                     Beratung in objektorientierter Datenverarbeitung
Ziegelhttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 3 May 2002 18:52:58 GMT, Allan W <Allan_W@my-dejanews.com> wrote:
 >  marg64@yahoo.com (Vahan Margaryan) wrote
 > > The logic that 'unsigned quantities should always be represented by
 > > unsigned types' is, IMO, wrong. Saying 'I had -3 guests' is illogical,
 > > but saying 'john was seated -3 guests to the right of mary' may make
 > > perfect sense in a programming context. A quantity that counts guests
 > > is unsigned, a quantity that offsets guests is signed. In a sense,
 > > that's what negative numbers were invented for. I don't want to mix
 > > unsigned guest counts with signed guest offsets, because I feel that
 > > will lead to bugs. That's why to me, only signed guests are welcome...
 >
 >  Maybe what you're really saying, is that the difference between
 >  two unsigneds is signed?
 >
 >  Of course, that would cause problems too:
 >      unsigned int a = MAX_UINT;
 >      unsigned int b = 2;
 >      signed   int c = a - b; // Overflow

You've got almost the same issue with signed integers:

    signed int a = MAX_INT;
    signed int b = -2;
    signed int c = a - b;   // overflow

The basic problem is that a difference type always needs twice the range
of the type whose difference is taken to be able to hold all possible
differences. This is true regardless of whether the latter type is
signed or unsigned.

-- Niklas Matthies
--
Pain is inevitable. Suffering is optional.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Vahan Margaryan wrote:

 > The logic that 'unsigned quantities should always be represented by
 > unsigned types' is, IMO, wrong. Saying 'I had -3 guests' is illogical,
 > but saying 'john was seated -3 guests to the right of mary' may make
 > perfect sense in a programming context. A quantity that counts guests
 > is unsigned, a quantity that offsets guests is signed. In a sense,
 > that's what negative numbers were invented for. I don't want to mix
 > unsigned guest counts with signed guest offsets, because I feel that
 > will lead to bugs. That's why to me, only signed guests are welcome...


    You are conflating several things which should not be conflated.  One
inappropriate conflation is conflating a unit of measure (guest) with the
quantity being measured (attendence) and again a unit of measure (chair) with
vector being measured (order-at-table).  Further you are conflating two
quantities being measured (attendence versus order-at-table) which is causing
your inappropriate desire to intermix negative-nonnegative integers with
nonnegative-only integers.  Quite honestly, the defect is in your thinking about
your design's model-of-reality, not in the existence/application of unsigned
integers into the solution-space.  (Furthermore as an aside, focusing an entire
model of reality solely on "guests" instead of "people" or "attendees" begets a
model of reality in which it is either impossible or awkward to describe the
hosts of the party, how many hosts were in attendence, and where the hosts were
seated.)

    If I were to ask "How many guests attended the party?", your desire to
intermix these separate quantities as negative-nonnegative/signed integers
implies that I should be able to expect (and meaningfully process) answers in
reply such as "7 guests in attendence plus 3 guests to the right of Mary" and "7
guests in attendence plus -2 guests to the right of Mary" where Mary is
obviously some basis for order-at-table vector within a system of coordinates
and somehow this order-at-table vector is somehow meaningful outside of its
coordinate system---i.e., meaningful in the absolute magnitude of guests in
attendence.  The absolute magnitude of guests in attendence in fundamentally
separate from a vector in an order-at-table coordinate system because the
one-dimensional one-directional nonnegative-only attendence ever-increasing
linear axis (without wrapping around) is fundamentally separate from the
one-dimensional two-directional negative-nonnegative order-at-table cyclical
axis where left of Mary eventually wraps back around to right of Mary.

    If I were to ask "Where is Fred to sit?", your desire to intermix these
separate quantities as negative-nonnegative/signed integers implies that I
should be able to expect (and meaningfully process) answers in reply such as "5
guests in attendence plus 2 guests to the right of Mary" and "5 guests in
attendence plus -1 guests to the right of Mary".  Again, this sets off so many
levels of red flags in the human brain that something is seriously
wrong/imagined/contrived/insane/incoherent within the model of reality.  If such
statements are incoherent in natural language, software designs should also
firmly avoid purporting such bizarre models of imagination as desirable models
of reality.

    If 3 people (a magnitude) are currently in attendence and two more people (a
magnitude) arrive, your desire to intermix these separate quantities as
negative-nonnegative/signed integers successfully implies that normal everyday
garden-variety arithmetic applies: 3 guests plus 2 guests equals 5 guests now in
attendence (still a magnitude).
    But if Fred sits -1 chairs to the right of Mary (a vector) whereas Bob sits 1
chair to the right of Mary (a vector), your desire to intermix these separate
quantities as negative-nonnegative/signed integers (applied naively) would
incorrectly answer questions such as "How many chairs/dining-table-positions are
there from Fred to  Bob, inclusive?" with incorrect arithmetic such as
    -1 guests (inappropriately treating vector as magnitude) plus 1 guest
(inappropriately treating vector as magnitude)
    = -1 guests + 1 guests
    = zero guests (an incorrectly-calculated magnitude).
Instead one must realize that each order-at-table is a vector whose  magnitude
(absolute value) must be taken to answer such questions:
    the number of chairs from Fred inclusively to Mary exclusively (the magnitude
of a vector) plus Bob's chair-offset from Mary (a magnitude of a vector) plus
Mary's chair (a magnitude)
    = the number of chairs in the set [Fred,Mary) plus the number of chairs in
the set [Bob,Mary) plus Mary's chair
    = |-1| + |1| + 1
    = 1 + 1 + 1
    = 3
which is the correct magnitude in answer to the question referring to vectors.
    Once again there is a drastic difference between the guests-in-attendence
quantity versus the order-at-table quantity.  In this case the difference isn't
arguably over in the English Department or Philosophy Department, but firmly in
the Mathematics Department: guests-in-attendence quantities use garden-variety
elementary-school natural-number arithmetic whereas order-at-table quantities
use an arithmetic of directed-vectors.  There is a fundamental
difference-in-type between guests-in-attendence and order-at-table.  Software
designs should overtly represent that obvious difference-in-type, not merely
with 1) overt admission of signed versus unsigned integers, but with 2) overt
admission of the frame-of-reference/coordinate-system as well as 3) overt
admission of units of measure as well as 4) overt admission of arithmetic system
to be used within that frame-of-reference as well as 5) overt admission of
conversion-system/arithmetic-system between frames-of-reference/coordinate-systems.

    The fallacy within "I want to intermix quantities measured in
negative-positive integers with quantities measured in nonnegative-only
integers" claims typically have less to do with the signedness and a whole lot
more to do with inappropriately intermixing numeric-only quantities which
measure drastically different non-intermixable concepts/types/classes (e.g., a
natural number of people in attendence versus a vector of seats in a
dining-table-layout cyclic coordinate system).  Throughout modern software
design, I strongly advocate an application of the KISS principle:
    1) keep classes, objects, and quantities firmly grounded in reality,
    2) describe classes, objects, and quantities as they are factually
expressed/observed in reality,
    3) describe classes, objects, and quantities in ways which read cleanly in a
natural language such as English.

    There is the time-honored example in software design:
    The farmer can milk the cow.
    The cow can demilk itself.
    The milk can decowify itself.

    The further one goes out on the limb so to speak with one's contrived
nonreality-based thinking, the more troubles one has in bailing out the
ever-burgeoning surreality.  This is seen since time began in the software
industry in that aging software designs eventually get to a point that they can
no longer be bailed out due to incongruence of their flawed model-of-reality to
the ever-more-intricate problems at hand in reality.  Moral of the story: do not
mix quantities in one's software model-of-reality which are not meant to be
mixed in reality and do not mix classes/objects/quantities/relationships in
one's software model-of-reality in ways which are not expressable/observable in
reality.  This moral of making software designs comply with the
how-to-model-reality makes it very rare to even contemplate intermixing
negative-nonnegative integers with nonnegative-only integers and then when their
worlds do touch, they are likely to touch in ways which are quite appropriate &
compatible without defect and without conflict between the signed versus
unsigned/modulus arithmetic systems.

    I highly encourage everyone to realize that the modeling of reality in
software, especially object-oriented/pattern-based software, is highly dependent
on the objectivist (i.e., object-oriented) philosophy of Ayn Rand whose writings
drive home this point of remaining firmly based in a repeatable (i.e.,
reusable), knowable, expressable, observable reality instead of highly-contrived
thinking.  The highly-contrived thinking is based more on an
inventive/projective imagination than on an receptive cognition of
expressable/observable reality.  This applies not only to the narrower topic of
unsigned versus signed integers, but throughout all
object-oriented/type-parameterized software design & architecture as well.

    As such, the presence of unsigned integers and an unsigned size_t is a
wonderful aspect of C's & C++'s ability to model reality.  I strongly affirm the
other pro-unsigned postings along these threads.  I also successfully use
unsigned integers throughout my designs without defect.  Any problem with
intermixing negative-nonnegative/signed integers with nonnegative-only/unsigned
integers is a problem with the design's overly-contrived model of imagination,
not with the semantics of unsigned and not with the presence of unsigned.

    A POINT OF ORDER: I suspect that replies to this posting will be more on the
philosophical underpinnings and less on the appropriateness of unsigned and an
unsigned size_t in standard C++ & C, so please guard against
purely-philosophical off-topic postings to comp.std.c++.  I have tried to use a
certain line of reasoning to defend & advocate unsigned and an unsigned size_t
in standard C and C++ and in software-design models of reality expressed in
standard C & C++.  Thus I consider this posting firmly on-topic for comp.std.c++.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Jack Klein <jackklein@spamcop.net> wrote in message news:<de3scu4ufuc516pgfghcb2gdcak86sjkrc@4ax.com>...
>
> Can you have a negative number of people, or an object containing a
> negative number of bytes?
>

I believe you may need to manipulate negative number of people or
bytes. Please see Francis Glassborow's reply to Geoff Field in this
thread and/or my previous post on this thread.

I have joined a project using unsigned in those 'logically unsigned'
places, and it often turned out - after a bug was painfully found -
that yet another 'logically' unsigned had to be signed instead. The
practice of using signed wherever possible has never caused me any
trouble.

-Vahan



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <RPfz8.11$Vo2.244@paloalto-snr1.gtei.net>, Barry Margolin
<barmar@genuity.net> writes
>Why not?  You can't have objects with negative size, just as you can't have
>a class in school with a negative number of students.  Unsigned types are
>appropriate for variables that can only hold non-negative values.

I would argue (on odd days of the month) that it only makes sense to
have an unsigned type if underflow raises an exception.

The real trouble with unsigned is that programmers have to very careful
that they do not mix unsigned with signed. Mostly mixtures work because
unsigned is a modular type, but now and again it causes a disaster.

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

P.J. Plauger wrote:
[snip]

>  In fairness, I have to confess that I'm the person who
> proposed the introduction of size_t as an unsigned type into Standard
> C.


   I have long wondered why Standard C (and thus Standard C++) express
positive-number integers via size_t instead of unsigned.  It appears that the
forum in which to conveniently bring up this educational question has arrived:

P.J. Plauger, why did you introduce size_t instead of using unsigned directly in
the C (and thus C++) standards?

> And I also fought hard for the VP rules over UP ones. So I'm
> doubtless biased in this area.
>
> P.J. Plauger
> Dinkumware, Ltd.
> http://www.dinkumware.com



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3ccd96e9.5974430@news.ch.kpnqwest.net>,
Bob Hairgrove <rhairgroveNoSpam@Pleasebigfoot.com> wrote:

>I believe it has more to do with the appropriateness of the domain ...

>For example, would it be logical to say: "We had -3 guests at our
>house last night"; or: "We need -1.5 liters of milk".

>Such quantites don't make any sense.

But they occur all the time, not in conversation, but in calculation.
How much milk do we need?  5 liters.  How much do we have?  3.5
liters.  So we will have -1.5 liters of milk if we try to carry
out this recipe.

>As to arithmetic, can you give an example where it would be wise (or
>even necessary) to mix signed and unsigned values?

The obvious one that trips me up constantly is that the difference
between two quantities may be negative, even if the quantities
are obligatorily positive.  Say you have two indexes into an array,
and you want to know the distance between them--that needs to be
signed.  Or you want to know how much more milk I have than you have;
the answer will be negative if, in fact, you have more milk.  Avoiding
this takes ugly special-case code.

There is nothing in my current program that would encourage me to
use unsigned at all, were it not for the fact that the STL does and
I need to conform to that at many points.  I hate this; it is a
constant source of small annoying mistakes, and occasional big ones
(where I used unsigned to conform with the STL and then used the
number in a way not appropriate for an unsigned).

My principle is that if I'm so close to the limit of a type that I
would want to use unsigned to make it bigger, I need a bigger type
anyway.  My vote for things to add to C++0x would be long long and
some kind of enormous double, so I wouldn't be spending my life coding
logarithmic work-arounds for too-small types.

Mary Kuhner mkkuhner@gs.washington.edu



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

musiphil@bawi.org (Sungbom Kim) wrote (abridged):
> I often find it somewhat "flawed" that the standard requires the data
> type representing sizes of objects to be an unsigned integral type.

I agree with your sentiments.


> As Stroustrup mentioned in TC++PL 4.4, usage of unsigned integer types
> for that kind of situation is discouraged.

This is rather a special case, though. On some machines, using a signed
integer would halve the maximum object size. That would be unacceptable.

For example, on a 16-bit machine we might have a single array 36000 chars
long (taking up more than half the addressable memory). So size_t needs to
be a 16-bit quantity capable of representing 36000.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>On 29 Apr 02 13:02:17 GMT, Sungbom Kim <musiphil@bawi.org> wrote:
>
>>I often find it somewhat "flawed" that the standard requires the data
>>type representing sizes of objects to be an unsigned integral type.

>I believe it has more to do with the appropriateness of the domain ...

That may have been the motivation, but it confuses type and value.  It's
analogous to the OO chestnut of deriving Square from Rectangle: what
matters is not the values, but the operations.  Yes, all array index
values (for example) are nonnegative, just as the instantaneous shape of
any Square is also that of some Rectangle.  But the operations you want
to perform on array indices are those of ordinary (i.e. signed)
arithmetic, not the modulo or bitwise operations proper to unsigned
quantities.

>For example, would it be logical to say: "We had -3 guests at our
>house last night"; or: "We need -1.5 liters of milk".

I suspect it would be easier to provide an interpretation under which
"We had -3 guests at our house last night" might reasonably be true than
a situation in which the 32-bit unsigned equivalent "We had 4294967293
guests at our house last night" might reasonably be true :-).  More
seriously, negative needs are perfectly 'logical': they are just
normally _called_ surpluses.

>As to arithmetic, can you give an example where it would be wise (or
>even necessary) to mix signed and unsigned values?
>
>Bob Hairgrove

It's never wise, but the widespread use of the unsigned size_t in the
standard often makes it necessary to use the result of ordinary
arithmetic as an unsigned value, or (more insidiously) to use an
unsigned value as a parameter to an expression intended to be evaluated
by ordinary arithmetic.  It isn't even self-consistent: if you want to
specify a width for an output stream large enough to hold a given string
without overflow you need to convert a stringsize (unsigned) to a
streamsize (signed).

Best wishes,
Matthew Collett

--
The word "reality" is generally used with the intention of evoking sentiment.
                                                          -- Arthur Eddington

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Sungbom Kim" <musiphil@bawi.org> wrote in message
news:3CC7DB8F.52E75D62@bawi.org...
> I often find it somewhat "flawed" that the standard requires the data
> type representing sizes of objects to be an unsigned integral type.
>
> They are just arithmetic quantities, like 'number of people'; no one
> would recommend using unsigned numbers for those kind of quantities.

Why not?  Can one have *negative* numbers of people, or negative sizes?
To my mind, unsigned integral types are the most natural model of a
count of anything "real" - be it people, bytes or bits.

Apart from that, unsigned types on most platforms have an extra bit
available for counting before going to the next size up.  This may not
matter in the hosted world, but for us embedded folks it usually means
adding lots of overhead to drag in another library or set of routines to
handle the bigger data type.

> They have semantics of neither modular arithmetics nor bit arrays.
> As Stroustrup mentioned in TC++PL 4.4, usage of unsigned integer types
> for that kind of situation is discouraged. It also causes many problems
> in arithmetics mixed with signed integers.

Whenever one mixes data types, there's the potential for problems,
whether the mixing is of size or sign or anything else.  Engage brain
before starting to code.

> I know that it is from C and that it's too late to change anything,

There are already some C-isms that have been modified for C++,
but the main problem is that the C++ standard has already been
written (albeit late and in a vastly different form to the original vision
of it).

> but I just want to hear what others have to say.

My take it that it's "horses for courses".  Of course, my background
is low-end embedded systems where *signed* data types can cause
more problems (and code size issues) than unsigned.  Also, I've seen
different libraries used to handle operations with different data sizes.

Geoff

--
Geoff Field,    Professional geek, amateur stage-levelling gauge.
Spamtraps: geofffield@hotmail.com, gcfield@bigmailbox.net, or
geoff_field@great-atuin.co.uk; Real Email: gcfield at optusnet dot com dot
au
My band's web page: http://www.geocities.com/southernarea/




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 29 Apr 02 13:02:17 GMT, Sungbom Kim <musiphil@bawi.org> wrote in
comp.lang.c++.moderated:

> I often find it somewhat "flawed" that the standard requires the data
> type representing sizes of objects to be an unsigned integral type.
>
> They are just arithmetic quantities, like 'number of people'; no one
> would recommend using unsigned numbers for those kind of quantities.
> They have semantics of neither modular arithmetics nor bit arrays.
> As Stroustrup mentioned in TC++PL 4.4, usage of unsigned integer types
> for that kind of situation is discouraged. It also causes many problems
> in arithmetics mixed with signed integers.
>
> I know that it is from C and that it's too late to change anything,
> but I just want to hear what others have to say.

Can you have a negative number of people, or an object containing a
negative number of bytes?

The real problem is not so much that size_t is an unsigned integer
type, but the rules of promotion for unsigned types.  I am not the
only one who thinks that the "value preserving" choice for value
promotions in C89/C90 was unfortunate.

--
Jack Klein
Home: http://JK-Technology.Com



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 29 Apr 2002 22:41:31 GMT, rhairgroveNoSpam@Pleasebigfoot.com (Bob
Hairgrove) wrote:

> As to arithmetic, can you give an example where it would be wise (or
> even necessary) to mix signed and unsigned values?

Neither wise nor necessary, but common.
   vector<C> v;
   ...
   for (int x = 0; x != v.size(); ++ x)
I'm sure that you always write
   for (vector<C>::size_type u = 0; u != v.size(); ++ u)
and
   v.begin() + x
but never
   v.begin() + u

John



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1020271625 14114 127.0.0.1 (1 May 2002 16:47:05 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: 1 May 2002 16:47:05 GMT
Content-Length: 1765
ReSent-Date: Wed, 1 May 2002 09:56:57 -0700 (PDT)
ReSent-From: Steve Clamage <clamage@eng.sun.com>
ReSent-To:  <c++-submit@netlab.cs.rpi.edu>
ReSent-Subject: Re: Unsignedness of size_t
ReSent-Message-ID: <Pine.SOL.4.33.0205010956570.10978@taumet>

rhairgroveNoSpam@Pleasebigfoot.com (Bob Hairgrove) wrote in message
news:<3ccd96e9.5974430@news.ch.kpnqwest.net>...

[snip]

> I believe it has more to do with the appropriateness of the domain ...
>
>
> For example, would it be logical to say: "We had -3 guests at our
> house last night"; or: "We need -1.5 liters of milk".
>
> Such quantites don't make any sense.
>
> As to arithmetic, can you give an example where it would be wise (or
> even necessary) to mix signed and unsigned values?

IMO the main problems with unsigned are:

   1) The result of some operations (e.g. a-b) is "non-intuitive";
   2) Mixed (signed/unsigned) expressions are 'unsigned';
   3) A false sense of 'safety' (guaranteed non-negativeness and a wider range)

These, in combination with the fact that 'int' is traditionally "the type
to use" in C, quite often cause troubles.

BTW can you imagine the existense of "unsigned double"? I've seen many
language extension proposals in these groups but not this one. Noone
needs it! The (signed) double seems to be good enough. Having unsigned one
(with 1 bit better accuracy, guaranteed non-negativeness, strange
mixed expressions results) would cause just a confusion. The same way as
does unsigned int, short, etc.

Long ago 1 bit (in numbers' representations range) might have been
important; that's not the case anymore. While unsigned is here to
stay for compatibility reasons, fhere is no need to use it in the
contemporary programs. I think it's very unfortunate that
size_t happens to be unsigned and that STL (a relativelly contemporary
creation) uses size_t and not int almost exclusivelly.

You can also find some good advice about using 'unsigned' in Lakos's book.


Radoslav Getov
www.ultraheap.com


[snip]



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Daniel Miller" <daniel.miller@tellabs.com> wrote in message
news:3CCEEEBF.5040000@tellabs.com...

> >  In fairness, I have to confess that I'm the person who
> > proposed the introduction of size_t as an unsigned type into Standard
>
>    I have long wondered why Standard C (and thus Standard C++) express
> positive-number integers via size_t instead of unsigned.  It appears that the
> forum in which to conveniently bring up this educational question has arrived:
>
> P.J. Plauger, why did you introduce size_t instead of using unsigned directly in
> the C (and thus C++) standards?

Because size_t is not necessarily unsigned int. It can be some other
unsigned type, and these days it often is.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1020285286 20743 127.0.0.1 (1 May 2002 20:34:46 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: 1 May 2002 20:34:46 GMT
Content-Length: 1943

"P.J. Plauger" <pjp@dinkumware.com> wrote in message news:<3ccd58e5$0$20934$4c41069e@reader1.ash.ops.us.uu.net>...
> Since the C Standard chose value-preserving promotion rules over
> unsigned-preserving, I have had few occasions where mixed arithmetic
> causes any real problems. The usual problem I see is busybody compilers
> that insist on warning that an operation *might* be dangerous -- the
> problem is that I have to add type casts to avoid customer complaints
> about warning messages.
>

Your answer seems to imply that you favor unsigned size_t because it
causes few bugs (rather than many). I believe there has been
'positive' rationale for this decision too, and the only positive
rationale I can see is that larger range for size_t is provided.

I have had numerous occasions where mixed comparisons caused bugs. I
know these could have been avoided by programmers, but then all bugs
could...

> You just did. In fairness, I have to confess that I'm the person who
> proposed the introduction of size_t as an unsigned type into Standard
> C. And I also fought hard for the VP rules over UP ones. So I'm
> doubtless biased in this area.

This is perhaps a matter of personal taste, but I would be more
comfortable with signed size_t. The smaller range of size_t has never
bothered me (I cast size_t's to ints, so it could have), whereas mixed
arithmetic bugs have.

The logic that 'unsigned quantities should always be represented by
unsigned types' is, IMO, wrong. Saying 'I had -3 guests' is illogical,
but saying 'john was seated -3 guests to the right of mary' may make
perfect sense in a programming context. A quantity that counts guests
is unsigned, a quantity that offsets guests is signed. In a sense,
that's what negative numbers were invented for. I don't want to mix
unsigned guest counts with signed guest offsets, because I feel that
will lead to bugs. That's why to me, only signed guests are welcome...

-Vahan



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote in
<t26KU6Avhtz8EwnZ@robinton.demon.co.uk>:

>I would argue (on odd days of the month) that it only makes sense to
>have an unsigned type if underflow raises an exception.
>
 And on even days i would wonder why C++ doesn't have more of
 low level functions that are easy to implement across different
 assembly languages /processors and encapsulate common functionality
 found in this processors.
 I mean something like :
   bool carry()  - if previous operation sets carry bit
   bool borrow() - the same more or less.
   struct multiply_result{ unsigned MSB; unsigned LSB; };
    multiply_result mult(unsigned one,onsigned two); //

    void setTimer(interrupt_type callback);

 grzegorz



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:kIroLmF3$S08EwtD@robinton.demon.co.uk...
>
> In article <1020129034.890475@cswreg.cos.agilent.com>, Geoff Field
> <geofffield@hotmail.com> writes
> >Why not?  Can one have *negative* numbers of people, or negative sizes?
> >To my mind, unsigned integral types are the most natural model of a
> >count of anything "real" - be it people, bytes or bits.
>
> Sure, they are fine for counting. However in a world where only unsigned
> values were used (before mathematicians invented negative numbers)
> subtracting a larger number from a smaller one 'failed', it did not
> generate a ridiculously large answer. Trying to use a negative value for
> an unsigned type should raise an exception.

True. Or, depending on the circumstances and the desired result, it
could return 0 (or an error code) and a warning message.  Or it could
just not do the subtraction in the first place - it largely depends on
what makes sense, and it *really* doesn't make sense to try to
subtract a large number of people from a small number of people
in most circumstances.

> >Apart from that, unsigned types on most platforms have an extra bit
> >available for counting before going to the next size up.  This may not
> >matter in the hosted world, but for us embedded folks it usually means
> >adding lots of overhead to drag in another library or set of routines to
> >handle the bigger data type.
>
> But in the world of embedded coding there are many other restraints.

Indeed.  These other restraints, of course, are not topical to either of
these
groups.

> Anyone who jumps into that world without doing some form of conversion
> course (if only careful study in private) will write poor code.

Many such actually migrate from hardware to software (as did I).  This in
itself can be a source of poor code, but I'd like to believe my style has
matured over the years.

> The
> requirements of embedded coding are special and should not be imposed on
> everyone.

Sometimes I think people *should* be required to do some small-system
embedded coding just to gain the different perspective.

> I have no problem with unsigned integer types per se. I have a
> big problem with being forced to use them or to use casts to remove
> them.

Fair enough.  If one is going to use them, one must be aware of the
issues and potential pitfalls.  Vahan Margrayan sounds like he/she
(sorry, my cultural background is too limited to tell me which) has
found this out the hard way - with someone else's bugs.

However,  Niklas Matthies points out that there are boundary cases
that can cause similar problems with signed types.  It's just that
one of the boundaries (0) is *much* more common with unsigned
types.

> I think size_t is wrongly specified, and I think time_t and clock_t are
> underspecified (if you use either of those in arithmetic you have the
> problem that they may be any arithmetic type.)

These are worthy topics for debate.  At the moment, this thread is
only about size_t.  However, what would you propose for clock_t and
time_t?

Geoff


--
Geoff Field,    Professional geek, amateur stage-levelling gauge.
Spamtraps: geofffield@hotmail.com, gcfield@bigmailbox.net, or
geoff_field@great-atuin.co.uk; Real Email: gcfield at optusnet dot com dot
au
My band's web page: http://www.geocities.com/southernarea/





      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan_W@my-dejanews.com (Allan W) wrote in message news:<23b84d65.0205021513.799537a4@posting.google.com>...
> marg64@yahoo.com (Vahan Margaryan) wrote

> Maybe what you're really saying, is that the difference between
> two unsigneds is signed?
>

Yes.

> There is precedent for something (vaguely) similar in other languages.
> For instance, Visual Basic has two division operators (one for floats,
> the other for integer).
>
>         a-b; // Returns unsigned result
>         a@b; // Returns   signed result
>

Frankly, I haven't had any experience with such semantics, so it's
hard for me to assess the utility and possible problems.

-Vahan



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1020652915.872448@cswreg.cos.agilent.com>, Geoff Field
<geofffield@hotmail.com> writes
>These are worthy topics for debate.  At the moment, this thread is only

>about size_t.  However, what would you propose for clock_t and time_t?

I think I would opt for double for clock_t and long double for time_t
but my point was that as it stands they can be any arithmetic type and
that includes both unsigned integer types and floating point types. As
each type has its own problems having such typedefs seems unreasonable
to me as the problems I will have to handle are implementation specific.



--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Since the size of an object can not be negative, why would you want a size
to be a signed integral type ?

"Sungbom Kim" <musiphil@bawi.org> wrote in message
news:3CC7DB8F.52E75D62@bawi.org...
> I often find it somewhat "flawed" that the standard requires the data
> type representing sizes of objects to be an unsigned integral type.
>
> They are just arithmetic quantities, like 'number of people'; no one
> would recommend using unsigned numbers for those kind of quantities.
> They have semantics of neither modular arithmetics nor bit arrays.
> As Stroustrup mentioned in TC++PL 4.4, usage of unsigned integer types
> for that kind of situation is discouraged. It also causes many problems
> in arithmetics mixed with signed integers.
>
> I know that it is from C and that it's too late to change anything,
> but I just want to hear what others have to say.




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3CC7DB8F.52E75D62@bawi.org>,
Sungbom Kim  <musiphil@bawi.org> wrote:
>I often find it somewhat "flawed" that the standard requires the data
>type representing sizes of objects to be an unsigned integral type.
>
>They are just arithmetic quantities, like 'number of people'; no one
>would recommend using unsigned numbers for those kind of quantities.

Why not?  You can't have objects with negative size, just as you can't have
a class in school with a negative number of students.  Unsigned types are
appropriate for variables that can only hold non-negative values.

Since the maximum value of an unsigned type is usually twice that of the
corresponding signed value, making size_t unsigned allows for larger
objects.  I suspect this was the main rationale for this choice, not the
modular arithmetic semantics.

--
Barry Margolin, barmar@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 29 Apr 02 13:02:17 GMT, Sungbom Kim <musiphil@bawi.org> wrote:

>I often find it somewhat "flawed" that the standard requires the data
>type representing sizes of objects to be an unsigned integral type.
>
>They are just arithmetic quantities, like 'number of people'; no one
>would recommend using unsigned numbers for those kind of quantities.
>They have semantics of neither modular arithmetics nor bit arrays.
>As Stroustrup mentioned in TC++PL 4.4, usage of unsigned integer types
>for that kind of situation is discouraged. It also causes many problems
>in arithmetics mixed with signed integers.
>
>I know that it is from C and that it's too late to change anything,
>but I just want to hear what others have to say.
>

I believe it has more to do with the appropriateness of the domain ...


For example, would it be logical to say: "We had -3 guests at our
house last night"; or: "We need -1.5 liters of milk".

Such quantites don't make any sense.

As to arithmetic, can you give an example where it would be wise (or
even necessary) to mix signed and unsigned values?


Bob Hairgrove
rhairgroveNoSpam@Pleasebigfoot.com



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Sungbom Kim" <musiphil@bawi.org> wrote in message
news:3CC7DB8F.52E75D62@bawi.org...

> I often find it somewhat "flawed" that the standard requires the data
> type representing sizes of objects to be an unsigned integral type.

I don't.

> They are just arithmetic quantities, like 'number of people'; no one
> would recommend using unsigned numbers for those kind of quantities.

Really? I would. And I usually do, in my own code.

> They have semantics of neither modular arithmetics nor bit arrays.
> As Stroustrup mentioned in TC++PL 4.4, usage of unsigned integer types
> for that kind of situation is discouraged.

By whom? Not by me.

>                                            It also causes many problems
> in arithmetics mixed with signed integers.

It is true that ``unsigned'' in C/C++ is really modulus arithmetic.
Since neither language has a non-negative type, unsigned is the closest
you can get. Indeed, I usually find it a better match than signed.

Since the C Standard chose value-preserving promotion rules over
unsigned-preserving, I have had few occasions where mixed arithmetic
causes any real problems. The usual problem I see is busybody compilers
that insist on warning that an operation *might* be dangerous -- the
problem is that I have to add type casts to avoid customer complaints
about warning messages.

Java chose to deep six all the unsigned types. As a result, I've had
to play ugly games in several places when writing the Java library.
When you need unsigned arithmetic, you really need it.

> I know that it is from C and that it's too late to change anything,
> but I just want to hear what others have to say.

You just did. In fairness, I have to confess that I'm the person who
proposed the introduction of size_t as an unsigned type into Standard
C. And I also fought hard for the VP rules over UP ones. So I'm
doubtless biased in this area.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Sungbom Kim wrote:

> I often find it somewhat "flawed" that the standard requires the data
> type representing sizes of objects to be an unsigned integral type.
>
> They are just arithmetic quantities, like 'number of people'; no one
> would recommend using unsigned numbers for those kind of quantities.

I'm not sure what you mean by "no one," since that's exactly what
unsigned quantities are good for.  How can you have a negative number of
people?

--
 Erik Max Francis / max@alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/  \ Life is one long process of getting tired.
\__/ Samuel Butler
    Interstelen / http://www.interstelen.com/
 A multiplayer, strategic, turn-based Web game on an interstellar scale.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I often find it somewhat "flawed" that the standard requires the data
type representing sizes of objects to be an unsigned integral type.

They are just arithmetic quantities, like 'number of people'; no one
would recommend using unsigned numbers for those kind of quantities.
They have semantics of neither modular arithmetics nor bit arrays.
As Stroustrup mentioned in TC++PL 4.4, usage of unsigned integer types
for that kind of situation is discouraged. It also causes many problems
in arithmetics mixed with signed integers.

I know that it is from C and that it's too late to change anything,
but I just want to hear what others have to say.

--
Sungbom Kim <musiphil@bawi.org>

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]