Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Are unsigned integers necessary?

Reply
Thread Tools

Are unsigned integers necessary?

 
 
Öö Tiib
Guest
Posts: n/a
 
      04-16-2010
On 17 apr, 01:43, Ian Collins <(E-Mail Removed)> wrote:
> On 04/17/10 10:38 AM, Alf P. Steinbach wrote:
>
>
>
> > * Ian Collins:
> >> On 04/17/10 12:00 AM, DaveB wrote:
> >>> "Leigh Johnston"<(E-Mail Removed)> wrote in message
> >>>news:ZLadnVpFLpup3VXWnZ2dnUVZ8mydnZ2d@giganews. com...
> >>>> Yes.

>
> >>> That there is Java and that it does not have them indicates NO. The
> >>> question, then, becomes about what the tradeoffs are. Maybe in a VM
> >>> environment the elimination of unsigned integers is easier to accept?

>
> >> Try allocating >2GB of memory on a 32 bit system without unsigned
> >> integers.

>
> > At the application level code that concerns only 1 case, namely a >2GB
> > array of bytes.

>
> > It seldom happens, and can be dealt with if it does happen.

>
> Efficiently and transparently?
>
> --
> Ian Collins


char (* a)[50000] = new char[50000][50000];
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      04-16-2010
On 04/17/10 10:55 AM, Öö Tiib wrote:
> On 17 apr, 01:43, Ian Collins<(E-Mail Removed)> wrote:
>> On 04/17/10 10:38 AM, Alf P. Steinbach wrote:
>>
>>
>>
>>> * Ian Collins:
>>>> On 04/17/10 12:00 AM, DaveB wrote:
>>>>> "Leigh Johnston"<(E-Mail Removed)> wrote in message
>>>>> news:(E-Mail Removed) ...
>>>>>> Yes.

>>
>>>>> That there is Java and that it does not have them indicates NO. The
>>>>> question, then, becomes about what the tradeoffs are. Maybe in a VM
>>>>> environment the elimination of unsigned integers is easier to accept?

>>
>>>> Try allocating>2GB of memory on a 32 bit system without unsigned
>>>> integers.

>>
>>> At the application level code that concerns only 1 case, namely a>2GB
>>> array of bytes.

>>
>>> It seldom happens, and can be dealt with if it does happen.

>>
>> Efficiently and transparently?

>
> char (* a)[50000] = new char[50000][50000];


That's neither transparent, nor elegant!

--
Ian Collins
 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      04-16-2010
* Ian Collins:
> On 04/17/10 10:38 AM, Alf P. Steinbach wrote:
>> * Ian Collins:
>>> On 04/17/10 12:00 AM, DaveB wrote:
>>>> "Leigh Johnston"<(E-Mail Removed)> wrote in message
>>>> news:(E-Mail Removed) ...
>>>>> Yes.
>>>>
>>>> That there is Java and that it does not have them indicates NO. The
>>>> question, then, becomes about what the tradeoffs are. Maybe in a VM
>>>> environment the elimination of unsigned integers is easier to accept?
>>>
>>> Try allocating >2GB of memory on a 32 bit system without unsigned
>>> integers.

>>
>> At the application level code that concerns only 1 case, namely a >2GB
>> array of bytes.
>>
>> It seldom happens, and can be dealt with if it does happen.

>
> Efficiently and transparently?


Depends to some degree on what you mean. First note that there can only be 1
such array of bytes at any time (in any given process). So it's a special case,
used for some special purpose.

If we're talking about a convention of not mixing signed/unsigned, then it's no
big deal: you know about this special 1 array, and you have no need to obtain
its size in your own code. You just make sure to store an end-pointer at the
time when you allocate the array (at that point using unsigned size), and access
the array elements via pointers or pointer based local part indexing instead of
all-over-the-array numerical indexing. That's that.

That might sound like if you need to be extra careful with this array just
because of the adoption of a convention of not mixing signed/unsigned.

But you need to be extra careful anyway, since that array *is* a special case no
matter how it's handled.

For given p1 and p2 pointing to bytes of that array, evaluating p2-p1 is
potentially Undefined Behavior (via §5.7/5) since the result is of signed
ptrdiff_t type.

That is, that special array is a special handle-with-extreme-care case no matter
how you handle it, including if you use unsigned types for indexing and size; it
can be handled efficiently, but not transparently as if it was any other array.

Summing up, if the signed ptrdiff_t is sufficient for handling some array
without UB, then (master of tautologies demonstrates his mastery) ptrdiff_t is
sufficient for handling that array without UB, and otherwise it isn't.


Cheers & hth.,

- Alf
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      04-16-2010
On 04/17/10 11:19 AM, Alf P. Steinbach wrote:
> * Ian Collins:
>> On 04/17/10 10:38 AM, Alf P. Steinbach wrote:
>>> * Ian Collins:
>>>> On 04/17/10 12:00 AM, DaveB wrote:
>>>>> "Leigh Johnston"<(E-Mail Removed)> wrote in message
>>>>> news:(E-Mail Removed) ...
>>>>>> Yes.
>>>>>
>>>>> That there is Java and that it does not have them indicates NO. The
>>>>> question, then, becomes about what the tradeoffs are. Maybe in a VM
>>>>> environment the elimination of unsigned integers is easier to accept?
>>>>
>>>> Try allocating >2GB of memory on a 32 bit system without unsigned
>>>> integers.
>>>
>>> At the application level code that concerns only 1 case, namely a >2GB
>>> array of bytes.
>>>
>>> It seldom happens, and can be dealt with if it does happen.

>>
>> Efficiently and transparently?

>
> Depends to some degree on what you mean. First note that there can only
> be 1 such array of bytes at any time (in any given process). So it's a
> special case, used for some special purpose.
>
> If we're talking about a convention of not mixing signed/unsigned, then
> it's no big deal: you know about this special 1 array, and you have no
> need to obtain its size in your own code. You just make sure to store an
> end-pointer at the time when you allocate the array (at that point using
> unsigned size), and access the array elements via pointers or pointer
> based local part indexing instead of all-over-the-array numerical
> indexing. That's that.
>
> That might sound like if you need to be extra careful with this array
> just because of the adoption of a convention of not mixing signed/unsigned.
>
> But you need to be extra careful anyway, since that array *is* a special
> case no matter how it's handled.
>
> For given p1 and p2 pointing to bytes of that array, evaluating p2-p1 is
> potentially Undefined Behavior (via §5.7/5) since the result is of
> signed ptrdiff_t type.
>
> That is, that special array is a special handle-with-extreme-care case
> no matter how you handle it, including if you use unsigned types for
> indexing and size; it can be handled efficiently, but not transparently
> as if it was any other array.
>
> Summing up, if the signed ptrdiff_t is sufficient for handling some
> array without UB, then (master of tautologies demonstrates his mastery)
> ptrdiff_t is sufficient for handling that array without UB, and
> otherwise it isn't.


Alf, you should consider politics as a change of career!

Was that a yes or a no?

--
Ian Collins
 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      04-16-2010
On 17 apr, 02:26, Ian Collins <(E-Mail Removed)> wrote:
> On 04/17/10 11:19 AM, Alf P. Steinbach wrote:
>
>
>
> > * Ian Collins:
> >> On 04/17/10 10:38 AM, Alf P. Steinbach wrote:
> >>> * Ian Collins:
> >>>> On 04/17/10 12:00 AM, DaveB wrote:
> >>>>> "Leigh Johnston"<(E-Mail Removed)> wrote in message
> >>>>>news:ZLadnVpFLpup3VXWnZ2dnUVZ8mydnZ2d@giganew s.com...
> >>>>>> Yes.

>
> >>>>> That there is Java and that it does not have them indicates NO. The
> >>>>> question, then, becomes about what the tradeoffs are. Maybe in a VM
> >>>>> environment the elimination of unsigned integers is easier to accept?

>
> >>>> Try allocating >2GB of memory on a 32 bit system without unsigned
> >>>> integers.

>
> >>> At the application level code that concerns only 1 case, namely a >2GB
> >>> array of bytes.

>
> >>> It seldom happens, and can be dealt with if it does happen.

>
> >> Efficiently and transparently?

>
> > Depends to some degree on what you mean. First note that there can only
> > be 1 such array of bytes at any time (in any given process). So it's a
> > special case, used for some special purpose.

>
> > If we're talking about a convention of not mixing signed/unsigned, then
> > it's no big deal: you know about this special 1 array, and you have no
> > need to obtain its size in your own code. You just make sure to store an
> > end-pointer at the time when you allocate the array (at that point using
> > unsigned size), and access the array elements via pointers or pointer
> > based local part indexing instead of all-over-the-array numerical
> > indexing. That's that.

>
> > That might sound like if you need to be extra careful with this array
> > just because of the adoption of a convention of not mixing signed/unsigned.

>
> > But you need to be extra careful anyway, since that array *is* a special
> > case no matter how it's handled.

>
> > For given p1 and p2 pointing to bytes of that array, evaluating p2-p1 is
> > potentially Undefined Behavior (via §5.7/5) since the result is of
> > signed ptrdiff_t type.

>
> > That is, that special array is a special handle-with-extreme-care case
> > no matter how you handle it, including if you use unsigned types for
> > indexing and size; it can be handled efficiently, but not transparently
> > as if it was any other array.

>
> > Summing up, if the signed ptrdiff_t is sufficient for handling some
> > array without UB, then (master of tautologies demonstrates his mastery)
> > ptrdiff_t is sufficient for handling that array without UB, and
> > otherwise it isn't.

>
> Alf, you should consider politics as a change of career!
>
> Was that a yes or a no?
>
> --
> Ian Collins


Possibly the correct answer is that it is implementation-defined.
Maximum size of one object is implementation defined. Suggested (with
non-binding to conformance suggestion) was at least 0x40000 bytes at
2003.
 
Reply With Quote
 
Bo Persson
Guest
Posts: n/a
 
      04-17-2010
Leigh Johnston wrote:
> "Leigh Johnston" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>>
>>
>> "Alf P. Steinbach" <(E-Mail Removed)> wrote in message
>> news:hqarar$385$(E-Mail Removed)-september.org...
>>> Summing up, if the signed ptrdiff_t is sufficient for handling
>>> some array without UB, then (master of tautologies demonstrates
>>> his mastery) ptrdiff_t is sufficient for handling that array
>>> without UB, and otherwise it isn't.
>>>

>>
>> Using ptrdiff_t for an array *index* is retarded. Array indexes
>> are always positive. For the unusual case of an array >2GB on a
>> 32-bit platform std::size_t works as an index. For the
>> non-unusual case case of any sized array on any platform
>> std::size_t also works as an index. Conclusion? Use std::size_t
>> for an index. Use std:trdiff_t for pointer arithmetic within an
>> array. /Leigh

>
> N.B. said signed pointer arithmetic can only address the range that
> ptrdiff_t provides. This is less of an issue on 64-bit platforms
> which typically have much less memory than a 64-bit address might
> imply.


Right, so we can argue that having a single array using more that half
the available virtual address space is an anomaly. Attempts to solve
the problem includes 1) using unsigned integers for indexing, or 2)
changing the size of the address space.

Here 2) is the proper solution, and 1) is a cure that is just as bad
as the disease.


Bo Persson


 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      04-17-2010
On 04/17/10 12:26 PM, Bo Persson wrote:
> Leigh Johnston wrote:
>> "Leigh Johnston"<(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>>
>>>
>>> "Alf P. Steinbach"<(E-Mail Removed)> wrote in message
>>> news:hqarar$385$(E-Mail Removed)-september.org...
>>>> Summing up, if the signed ptrdiff_t is sufficient for handling
>>>> some array without UB, then (master of tautologies demonstrates
>>>> his mastery) ptrdiff_t is sufficient for handling that array
>>>> without UB, and otherwise it isn't.
>>>>
>>>
>>> Using ptrdiff_t for an array *index* is retarded. Array indexes
>>> are always positive. For the unusual case of an array>2GB on a
>>> 32-bit platform std::size_t works as an index. For the
>>> non-unusual case case of any sized array on any platform
>>> std::size_t also works as an index. Conclusion? Use std::size_t
>>> for an index. Use std:trdiff_t for pointer arithmetic within an
>>> array. /Leigh

>>
>> N.B. said signed pointer arithmetic can only address the range that
>> ptrdiff_t provides. This is less of an issue on 64-bit platforms
>> which typically have much less memory than a 64-bit address might
>> imply.

>
> Right, so we can argue that having a single array using more that half
> the available virtual address space is an anomaly. Attempts to solve
> the problem includes 1) using unsigned integers for indexing, or 2)
> changing the size of the address space.
>
> Here 2) is the proper solution, and 1) is a cure that is just as bad
> as the disease.


But what if you don't or can't do 2? 1 should still be an option and
that requires unsigned integers.

--
Ian Collins
 
Reply With Quote
 
Rui Maciel
Guest
Posts: n/a
 
      04-17-2010
Alf P. Steinbach wrote:

> At the application level code that concerns only 1 case, namely a >2GB
> array of bytes.
>
> It seldom happens, and can be dealt with if it does happen.


But it does happen and support for that feature already exists. So, why should anyone want to
take it away? What is there to be gained?


Rui Maciel
 
Reply With Quote
 
DaveB
Guest
Posts: n/a
 
      04-17-2010
Pete Becker wrote:
> DaveB wrote:
>> "Pete Becker" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed) ...
>>> DaveB wrote:
>>>> "Leigh Johnston" <(E-Mail Removed)> wrote in message
>>>> news:(E-Mail Removed) ...
>>>>> Yes.
>>>> That there is Java and that it does not have them indicates NO. The
>>>> question, then, becomes about what the tradeoffs are. Maybe in a VM
>>>> environment the elimination of unsigned integers is easier to
>>>> accept?
>>> Try implementing semi-numerical algorithms (e.g. unbounded precision
>>> integer math) without unsigned types. You end up masking after every
>>> operation, and if you forget once you get bugs that are hard to
>>> locate.

>>
>> So that piece of info seems to point to the java designers making
>> things conceptually simpler for the newbie at the expense of the
>> engineer-level developer. Good info. Keep it coming.
>>

>
> Don't get me started. Java was designed for beginners.


So you opine, and maybe you know, but I don't know whether you know or
not, so I'll assume that you are just opining. I think it was an attempt
mostly to create a C++-like language devoid of C++ idiosynchracies, to
some extent. I think the "making it easy for newbies" was down the list
of requirements, but I AM just opining.

> That was
> especially evident in the early versions of the Java library, which
> was designed in ways that beginners would love but experienced
> programmers would find limiting.


Like ALL libraries, the first implementation is never the last, for
things have to evolve. Building a lot of complexity or features into the
first release is bound to be a bit on the "lame" side, by design.

> I firmly believe that that was
> because the library was designed by beginners, so it had many
> beginners' mistakes. And certainly in some areas that hasn't
> improved; take a look at the specification for
> java.util.SimpleTimeZone -- it's far from simple, and should have
> been split into several subclasses.


How is the library today though? Pretty comprehensive with hundreds of
classes right? Is it better designed now too? All the major things seem
to be there and that's more than anyone can say about C++: GUI, threads,
DB... Of course to compare the 2 languages, one has to only compare from
a mile-high perspective because C++ is a systems-level programming
language and Java is not.


 
Reply With Quote
 
DaveB
Guest
Posts: n/a
 
      04-17-2010
Ian Collins wrote:
> On 04/17/10 12:00 AM, DaveB wrote:
>> "Leigh Johnston"<(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed) ...
>>> Yes.

>>
>> That there is Java and that it does not have them indicates NO. The
>> question, then, becomes about what the tradeoffs are. Maybe in a VM
>> environment the elimination of unsigned integers is easier to accept?

>
> Try allocating >2GB of memory on a 32 bit system without unsigned
> integers.


Or using 8-bit ASCII.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
(int) -> (unsigned) -> (int) or (unsigned) -> (int) -> (unsigned):I'll loose something? pozz C Programming 12 03-20-2011 11:32 PM
casting unsigned integers techie C++ 4 10-13-2006 06:01 PM
comparing signed and unsigned integers Joe Van Dyk C Programming 3 06-25-2006 09:11 PM
Adding and multiplying two unsigned integers Edith Gross C++ 5 05-01-2005 04:48 PM
8-bit unsigned integers in Java jeff Java 2 03-07-2004 06:10 PM



Advertisments