«

* Rui Maciel:
> 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

Never happened to me; I wrote "seldom" just to be conservative.


> and support for that feature already exists.

Sorry, no, full support for such an array does not exist in C++. You're
generally into UB land if you subtract pointers that point into that array.


> So, why should anyone want to take it away?

The question doesn't seem to make sense. Who's taking what away from you?


> What is there to be gained?

By what?

I'm not sure that I understand what you mean or indeed that you yourself
understand what you mean, but it feels vaguely like someone arguing that one
should generally prefer gas lamps to electrical lighting because there's a cabin
that few if anyone has actually used and that's already being demolished, where
the electricity would be slightly less cheap if it was ever used.

Regardless of whether one thought that the person understood "gas lamp" and
"electricity" one would suspect a person making such an argument to be trolling.


Cheers & hth.,

- Alf

Ian Collins wrote:
> On 04/17/10 12:26 PM, Bo Persson wrote:
>> Leigh Johnston wrote:
>>> "Leigh Johnston"<> wrote in message
>>> news:-...
>>>>
>>>>
>>>> "Alf P. Steinbach"<> wrote in message
>>>> news:hqarar$385$...
>>>>> 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.

You have to do it anyway.

So, with unsigned ints I can allocate a 3GB byte array. What if I
needed a 5 GB array?

Hardly worth designing a programming language around. Some of us now
believe the C++ committee made a mistake in std::vector::size_type.
And I believe there are committee members that agree.



Bo Persson

On 04/15/10 08:41 PM, DaveB wrote:
> The Java designers didn't think there was any need to have unsigned
> integers. Probably because they handle the errors well and don't leave as
> much room for undefined behavior?

Now this thread has played its self out, it might be interesting to
consider where the protagonist's views on the subject originated.

I started my programming career as a hardware engineer in a team where
we programmed all our own hardware. The company's software developers
were all "application types" who didn't understand hardware. In that
world of registers and buses, just about everything is a bag of bits, so
using unsigned types is the natural way of things. I still enjoy
embedded programming and writing drivers, so I guess I'm stuck in the
use unsigned types mindset.

I bet most of those who dislike signed types are in the "application
types who didn't understand hardware" category.

--
Ian Collins

On 2010-04-17, Ian Collins <ian-> wrote:
> On 04/15/10 08:41 PM, DaveB wrote:
>> The Java designers didn't think there was any need to have unsigned
>> integers. Probably because they handle the errors well and don't leave as
>> much room for undefined behavior?
>
> Now this thread has played its self out, it might be interesting to
> consider where the protagonist's views on the subject originated.
>
> I started my programming career as a hardware engineer in a team where
> we programmed all our own hardware. The company's software developers
> were all "application types" who didn't understand hardware. In that
> world of registers and buses, just about everything is a bag of bits, so
> using unsigned types is the natural way of things. I still enjoy
> embedded programming and writing drivers, so I guess I'm stuck in the
> use unsigned types mindset.
>
> I bet most of those who dislike signed types are in the "application
> types who didn't understand hardware" category.
>

I have this mentality as well when working with binary
network protocols, when signed integers must be encoded
in a specific way (big-endian two's complement, hardly
an esoteric encoding, but even so.). Everything is just
bits on a wire, and it's counter-intuitive to read bits
as negative numbers.

Right now I'm doing embedded development and the same
idea applies.

However, when I'm doing mathematical programming, and
I'm using C for some reason (either for speed or to do
numerical analysis with fewer abstractions to think
though) (otherwise Lisp or Python are far nicer to work
with), I use signed types for numbers, because in math,
numbers are signed.

So perhaps there are people who unilaterally fall into the
"application" or "hardware" categories, but I think that
most people switch freely depending on the problem domain.

--
Andrew Poelstra
http://www.wpsoftware.net/andrew

Ian Collins wrote:
> On 04/15/10 08:41 PM, DaveB wrote:
>> The Java designers didn't think there was any need to have unsigned
>> integers. Probably because they handle the errors well and don't
>> leave as much room for undefined behavior?
>
> Now this thread has played its self out, it might be interesting to
> consider where the protagonist's views on the subject originated.
>
> I started my programming career as a hardware engineer in a team
> where we programmed all our own hardware. The company's software
> developers were all "application types" who didn't understand
> hardware. In that world of registers and buses, just about
> everything is a bag of bits, so using unsigned types is the natural
> way of things. I still enjoy embedded programming and writing
> drivers, so I guess I'm stuck in the use unsigned types mindset.
>
> I bet most of those who dislike signed types are in the "application
> types who didn't understand hardware" category.

Unsigned type are good on this level. The problem in the C family is
that the type is called 'unsigned int' and not 'word'.

Nobody would consider 'word' as good type for vector indexing.


Bo Persson

DaveB wrote:

>
> "Leigh Johnston" <> wrote in message
> news: ...
>> 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?

The lack of unsigned integers in Java makes writing hash functions very
difficult so they are necessary.