«

MikeP wrote:

> If you investigate the tcmalloc code (by Google), you will find the
> following warning:
>
> // NOTE: unsigned types are DANGEROUS in loops and other arithmetical
> // places. Use the signed types unless your variable represents a bit
> // pattern (eg a hash value) or you really need the extra bit. Do NOT
> // use 'unsigned' to express "this value should always be positive";
> // use assertions for this.
>
> Is it just their idiom? What's the problem with using unsigned ints in
> loops (it seems natural to do so)? Are C++ unsigned ints "broken"
> somehow?

Exactly. They are soooo right. It's a anti-pattern that the Standard library
uses unsigned integral types for "only-positive" entities.

http://stackoverflow.com/questions/3...f-declaring-a-
variable-as-unsigned/3729815#3729815

"Leigh Johnston" <> wrote in message
news:Y8udnZW5hNEZs-...
> On 13/03/2011 20:43, Paul wrote:
>>
>> "Leigh Johnston" <> wrote in message
>> newssednU44m-tvgODQnZ2dnUVZ8g-...
>>> On 13/03/2011 19:29, Alf P. Steinbach /Usenet wrote:
>>>> * William Ahern, on 13.03.2011 03:01:
>>>>
>>>> "If you stick to (unsigned int) or wider, then you're fine" is
>>>> generally
>>>> false. Use hammer for nails, screwdriver for screws. In short, use the
>>>> right tool for the job, or at least don't use a clearly inappropriate
>>>> tool: don't use signed types for bitlevel stuff, and don't use unsigned
>>>> types for numerical stuff.
>>>>
>>>
>>> Bullshit. Using unsigned integral types to represent values that are
>>> never negative is perfectly fine. std::size_t ensures that the C++
>>> horse has already bolted as far as trying to avoid them is concerned.
>>>
>>>>
>>>>> unsigned types can be safer because everything about the
>>>>> arithmetic is well defined, including over- and underflows which occur
>>>>> modulo 2^N; as opposed to signed, where those scenarios are undefined.
>>>>
>>>> The well-definedness of operations that you're talking about is this:
>>>> that the language *guarantees* that range errors for unsigned types
>>>> will
>>>> not be caught.
>>>>
>>>> A guarantee that errors won't be caught does not mean "safer".
>>>>
>>>> That's plain idiocy, sorry.
>>>
>>> Plain idiocy is eschewing the unsigned integral types in C++. Perhaps
>>> you would prefer being a Java programmer? Java has less types to "play
>>> with" which perhaps would suit you better if you cannot cope with
>>> C++'s richer set of types.
>>>
>> As Java, like C++, supports UDT's I don't think it's correct to say that
>> C++ suports a richer set of types.
>> class anyTypeYouLike{};
>
> This is a troll. If is obvious I am referring to the set of built-in
> types. A user defined type is often composed of one or more built-in
> types.
>
>>
>> There is a reason Java doesn't bother with a built in unsigned numeric
>> type.
>> I think the people who created Java know more about programming than you
>> do and it is not a case of Java being inadequete. This is just your
>> misguided interpretation in an attempt to reinforce your idea that
>> std::size_t is the only type people should use in many circumstances.
>> You obviously think std:size_t is the best thing since sliced bread and
>> this is the way forward in C++ and, as per usual, your opinion is wrong.
>
> C++'s std::size_t comes from C's size_t. It is the way forward because it
> is also the way backward.
>
>>
>> The message you replied to ALf said to use the correct tool for the job,
>> which seems like a reasonable opinion. You replied saying this was
>> bullshit and implied Alf had said something about never using unsigned,
>> your post looks like a deliberate attempt to start a flare.
>> You also make the point of saying using unsigned for values that are
>> never negative is fine, but how do you know it is never going to be
>> negative? Your idea of never negative is different from others', you
>> think array indexes cannot be negative, but most other people know they
>> can be.
>>
>
> If array indexes can be negative then please explain why
> std::array::size_type will be std::size_t and not std:trdiff_t.
>

Just because that particular array type cannot have a negative index doesn't
mean this applies to all arrays.
Array indexes *can* be negative see:
http://www.boost.org/doc/libs/1_46_1.../doc/user.html

"Leigh Johnston" <> wrote in message
news:NqqdnfazidZk--...
> On 14/03/2011 00:09, Paul wrote:
>>
>> "Leigh Johnston" <> wrote in message
>> news:Y8udnZW5hNEZs-...
>>> On 13/03/2011 20:43, Paul wrote:
>>>>
>>>> "Leigh Johnston" <> wrote in message
>>>> newssednU44m-tvgODQnZ2dnUVZ8g-...
>>>>> On 13/03/2011 19:29, Alf P. Steinbach /Usenet wrote:
>>>>>> * William Ahern, on 13.03.2011 03:01:
>>>>>>
>>>>>> "If you stick to (unsigned int) or wider, then you're fine" is
>>>>>> generally
>>>>>> false. Use hammer for nails, screwdriver for screws. In short, use
>>>>>> the
>>>>>> right tool for the job, or at least don't use a clearly inappropriate
>>>>>> tool: don't use signed types for bitlevel stuff, and don't use
>>>>>> unsigned
>>>>>> types for numerical stuff.
>>>>>>
>>>>>
>>>>> Bullshit. Using unsigned integral types to represent values that are
>>>>> never negative is perfectly fine. std::size_t ensures that the C++
>>>>> horse has already bolted as far as trying to avoid them is concerned.
>>>>>
>>>>>>
>>>>>>> unsigned types can be safer because everything about the
>>>>>>> arithmetic is well defined, including over- and underflows which
>>>>>>> occur
>>>>>>> modulo 2^N; as opposed to signed, where those scenarios are
>>>>>>> undefined.
>>>>>>
>>>>>> The well-definedness of operations that you're talking about is this:
>>>>>> that the language *guarantees* that range errors for unsigned types
>>>>>> will
>>>>>> not be caught.
>>>>>>
>>>>>> A guarantee that errors won't be caught does not mean "safer".
>>>>>>
>>>>>> That's plain idiocy, sorry.
>>>>>
>>>>> Plain idiocy is eschewing the unsigned integral types in C++. Perhaps
>>>>> you would prefer being a Java programmer? Java has less types to "play
>>>>> with" which perhaps would suit you better if you cannot cope with
>>>>> C++'s richer set of types.
>>>>>
>>>> As Java, like C++, supports UDT's I don't think it's correct to say
>>>> that
>>>> C++ suports a richer set of types.
>>>> class anyTypeYouLike{};
>>>
>>> This is a troll. If is obvious I am referring to the set of built-in
>>> types. A user defined type is often composed of one or more built-in
>>> types.
>>>
>>>>
>>>> There is a reason Java doesn't bother with a built in unsigned numeric
>>>> type.
>>>> I think the people who created Java know more about programming than
>>>> you
>>>> do and it is not a case of Java being inadequete. This is just your
>>>> misguided interpretation in an attempt to reinforce your idea that
>>>> std::size_t is the only type people should use in many circumstances.
>>>> You obviously think std:size_t is the best thing since sliced bread and
>>>> this is the way forward in C++ and, as per usual, your opinion is
>>>> wrong.
>>>
>>> C++'s std::size_t comes from C's size_t. It is the way forward because
>>> it is also the way backward.
>>>
>>>>
>>>> The message you replied to ALf said to use the correct tool for the
>>>> job,
>>>> which seems like a reasonable opinion. You replied saying this was
>>>> bullshit and implied Alf had said something about never using unsigned,
>>>> your post looks like a deliberate attempt to start a flare.
>>>> You also make the point of saying using unsigned for values that are
>>>> never negative is fine, but how do you know it is never going to be
>>>> negative? Your idea of never negative is different from others', you
>>>> think array indexes cannot be negative, but most other people know they
>>>> can be.
>>>>
>>>
>>> If array indexes can be negative then please explain why
>>> std::array::size_type will be std::size_t and not std:trdiff_t.
>>>
>>
>> Just because that particular array type cannot have a negative index
>> doesn't mean this applies to all arrays.
>> Array indexes *can* be negative see:
>> http://www.boost.org/doc/libs/1_46_1.../doc/user.html
>>
>
> From n3242:
>
> "if E1 is an array and E2 an integer, then E1[E2] refers to the E2-th
> member of E1"
>
> E2 cannot be negative if the above rule is not to be broken.
>
The above says E2 is an integer not an unsigned integer.

Also:
int arr[5] = {0};
arr[4] =5; /*The 5th element not the 4th*/
arr[0] = 1; /*The 1st elelment, not the 0th*/
int*p_arr = &arr;
++p_arr;
p_arr[-1] = 1; /*The 1st element, not the -1st*/
p_arr[0] = 2; /*The 2nd element, not the 0th*/


I don't know what medicine you are on but it doesn't seem to be working. An
array can have a negative index, accept you're wrong, forget about size_t,
revisit your doctor and move on.

"Leigh Johnston" <> wrote in message
news: ...
> On 14/03/2011 01:41, Paul wrote:
>>
>> "Leigh Johnston" <> wrote in message
>> news:NqqdnfazidZk--...
>>> On 14/03/2011 00:09, Paul wrote:
>>>>
>>>> "Leigh Johnston" <> wrote in message
>>>> news:Y8udnZW5hNEZs-...
>>>>> On 13/03/2011 20:43, Paul wrote:
>>>>>>
>>>>>> "Leigh Johnston" <> wrote in message
>>>>>> newssednU44m-tvgODQnZ2dnUVZ8g-...
>>>>>>> On 13/03/2011 19:29, Alf P. Steinbach /Usenet wrote:
>>>>>>>> * William Ahern, on 13.03.2011 03:01:
>>>>>>>>
>>>>>>>> "If you stick to (unsigned int) or wider, then you're fine" is
>>>>>>>> generally
>>>>>>>> false. Use hammer for nails, screwdriver for screws. In short,
>>>>>>>> use the
>>>>>>>> right tool for the job, or at least don't use a clearly
>>>>>>>> inappropriate
>>>>>>>> tool: don't use signed types for bitlevel stuff, and don't use
>>>>>>>> unsigned
>>>>>>>> types for numerical stuff.
>>>>>>>>
>>>>>>>
>>>>>>> Bullshit. Using unsigned integral types to represent values that are
>>>>>>> never negative is perfectly fine. std::size_t ensures that the C++
>>>>>>> horse has already bolted as far as trying to avoid them is
>>>>>>> concerned.
>>>>>>>
>>>>>>>>
>>>>>>>>> unsigned types can be safer because everything about the
>>>>>>>>> arithmetic is well defined, including over- and underflows which
>>>>>>>>> occur
>>>>>>>>> modulo 2^N; as opposed to signed, where those scenarios are
>>>>>>>>> undefined.
>>>>>>>>
>>>>>>>> The well-definedness of operations that you're talking about is
>>>>>>>> this:
>>>>>>>> that the language *guarantees* that range errors for unsigned types
>>>>>>>> will
>>>>>>>> not be caught.
>>>>>>>>
>>>>>>>> A guarantee that errors won't be caught does not mean "safer".
>>>>>>>>
>>>>>>>> That's plain idiocy, sorry.
>>>>>>>
>>>>>>> Plain idiocy is eschewing the unsigned integral types in C++.
>>>>>>> Perhaps
>>>>>>> you would prefer being a Java programmer? Java has less types to
>>>>>>> "play
>>>>>>> with" which perhaps would suit you better if you cannot cope with
>>>>>>> C++'s richer set of types.
>>>>>>>
>>>>>> As Java, like C++, supports UDT's I don't think it's correct to say
>>>>>> that
>>>>>> C++ suports a richer set of types.
>>>>>> class anyTypeYouLike{};
>>>>>
>>>>> This is a troll. If is obvious I am referring to the set of built-in
>>>>> types. A user defined type is often composed of one or more built-in
>>>>> types.
>>>>>
>>>>>>
>>>>>> There is a reason Java doesn't bother with a built in unsigned
>>>>>> numeric
>>>>>> type.
>>>>>> I think the people who created Java know more about programming
>>>>>> than you
>>>>>> do and it is not a case of Java being inadequete. This is just your
>>>>>> misguided interpretation in an attempt to reinforce your idea that
>>>>>> std::size_t is the only type people should use in many circumstances.
>>>>>> You obviously think std:size_t is the best thing since sliced bread
>>>>>> and
>>>>>> this is the way forward in C++ and, as per usual, your opinion is
>>>>>> wrong.
>>>>>
>>>>> C++'s std::size_t comes from C's size_t. It is the way forward because
>>>>> it is also the way backward.
>>>>>
>>>>>>
>>>>>> The message you replied to ALf said to use the correct tool for the
>>>>>> job,
>>>>>> which seems like a reasonable opinion. You replied saying this was
>>>>>> bullshit and implied Alf had said something about never using
>>>>>> unsigned,
>>>>>> your post looks like a deliberate attempt to start a flare.
>>>>>> You also make the point of saying using unsigned for values that are
>>>>>> never negative is fine, but how do you know it is never going to be
>>>>>> negative? Your idea of never negative is different from others', you
>>>>>> think array indexes cannot be negative, but most other people know
>>>>>> they
>>>>>> can be.
>>>>>>
>>>>>
>>>>> If array indexes can be negative then please explain why
>>>>> std::array::size_type will be std::size_t and not std:trdiff_t.
>>>>>
>>>>
>>>> Just because that particular array type cannot have a negative index
>>>> doesn't mean this applies to all arrays.
>>>> Array indexes *can* be negative see:
>>>> http://www.boost.org/doc/libs/1_46_1.../doc/user.html
>>>>
>>>
>>> From n3242:
>>>
>>> "if E1 is an array and E2 an integer, then E1[E2] refers to the E2-th
>>> member of E1"
>>>
>>> E2 cannot be negative if the above rule is not to be broken.
>>>
>> The above says E2 is an integer not an unsigned integer.
>>
>> Also:
>> int arr[5] = {0};
>> arr[4] =5; /*The 5th element not the 4th*/
>> arr[0] = 1; /*The 1st elelment, not the 0th*/
>> int*p_arr = &arr;
>> ++p_arr;
>> p_arr[-1] = 1; /*The 1st element, not the -1st*/
>> p_arr[0] = 2; /*The 2nd element, not the 0th*/
>>
>
> In C++ an array index can't be negative; p_arr above is not an array it is
> a pointer. Obviously "E2-th" is zero-based not one-based. The fact that
> Boost provides an array-like container which accepts negative indices is
> mostly irrelevant; my primary concern is C++ not Boost; again:
>
An array is always accessed via a pointer thats just how it works.


> From n3242:
>
> "if E1 is an array and E2 an integer, then E1[E2] refers to the E2-th
> member of E1"
>
> if E2 is negative then E1[E2] cannot possibly refer to a member of E1.
>
From common sense:

int arr[16]={0};
arr[0]=0; /*1st element not 0th element*/


I don't give a **** about your stupid misinterpretations from the ISO
documents you ****in idiot, learn to accpet when you are wrong.

>>
>> I don't know what medicine you are on but it doesn't seem to be working.
>> An array can have a negative index, accept you're wrong, forget about
>> size_t, revisit your doctor and move on.
>>
>
> You are the one who is wrong and refuse to accept what is correct.
>
> std::size_t.
>
Oh yes try to start a flare with no reasonable arguement as usual, well I
had enough of idiots like you see if I care , anyone with a brain can see
you are the one who is wrong.

"Leigh Johnston" <> wrote in message
news: ...
> On 14/03/2011 11:48, Leigh Johnston wrote:
>> On 14/03/2011 01:41, Paul wrote:
>>>
>>> "Leigh Johnston" <> wrote in message
>>> news:NqqdnfazidZk--...
>>>> On 14/03/2011 00:09, Paul wrote:
>>>>>
>>>>> "Leigh Johnston" <> wrote in message
>>>>> news:Y8udnZW5hNEZs-...
>>>>>> On 13/03/2011 20:43, Paul wrote:
>>>>>>>
>>>>>>> "Leigh Johnston" <> wrote in message
>>>>>>> newssednU44m-tvgODQnZ2dnUVZ8g-...
>>>>>>>> On 13/03/2011 19:29, Alf P. Steinbach /Usenet wrote:
>>>>>>>>> * William Ahern, on 13.03.2011 03:01:
>>>>>>>>>
>>>>>>>>> "If you stick to (unsigned int) or wider, then you're fine" is
>>>>>>>>> generally
>>>>>>>>> false. Use hammer for nails, screwdriver for screws. In short,
>>>>>>>>> use the
>>>>>>>>> right tool for the job, or at least don't use a clearly
>>>>>>>>> inappropriate
>>>>>>>>> tool: don't use signed types for bitlevel stuff, and don't use
>>>>>>>>> unsigned
>>>>>>>>> types for numerical stuff.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Bullshit. Using unsigned integral types to represent values that
>>>>>>>> are
>>>>>>>> never negative is perfectly fine. std::size_t ensures that the C++
>>>>>>>> horse has already bolted as far as trying to avoid them is
>>>>>>>> concerned.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> unsigned types can be safer because everything about the
>>>>>>>>>> arithmetic is well defined, including over- and underflows which
>>>>>>>>>> occur
>>>>>>>>>> modulo 2^N; as opposed to signed, where those scenarios are
>>>>>>>>>> undefined.
>>>>>>>>>
>>>>>>>>> The well-definedness of operations that you're talking about is
>>>>>>>>> this:
>>>>>>>>> that the language *guarantees* that range errors for unsigned
>>>>>>>>> types
>>>>>>>>> will
>>>>>>>>> not be caught.
>>>>>>>>>
>>>>>>>>> A guarantee that errors won't be caught does not mean "safer".
>>>>>>>>>
>>>>>>>>> That's plain idiocy, sorry.
>>>>>>>>
>>>>>>>> Plain idiocy is eschewing the unsigned integral types in C++.
>>>>>>>> Perhaps
>>>>>>>> you would prefer being a Java programmer? Java has less types to
>>>>>>>> "play
>>>>>>>> with" which perhaps would suit you better if you cannot cope with
>>>>>>>> C++'s richer set of types.
>>>>>>>>
>>>>>>> As Java, like C++, supports UDT's I don't think it's correct to say
>>>>>>> that
>>>>>>> C++ suports a richer set of types.
>>>>>>> class anyTypeYouLike{};
>>>>>>
>>>>>> This is a troll. If is obvious I am referring to the set of built-in
>>>>>> types. A user defined type is often composed of one or more built-in
>>>>>> types.
>>>>>>
>>>>>>>
>>>>>>> There is a reason Java doesn't bother with a built in unsigned
>>>>>>> numeric
>>>>>>> type.
>>>>>>> I think the people who created Java know more about programming
>>>>>>> than you
>>>>>>> do and it is not a case of Java being inadequete. This is just your
>>>>>>> misguided interpretation in an attempt to reinforce your idea that
>>>>>>> std::size_t is the only type people should use in many
>>>>>>> circumstances.
>>>>>>> You obviously think std:size_t is the best thing since sliced bread
>>>>>>> and
>>>>>>> this is the way forward in C++ and, as per usual, your opinion is
>>>>>>> wrong.
>>>>>>
>>>>>> C++'s std::size_t comes from C's size_t. It is the way forward
>>>>>> because
>>>>>> it is also the way backward.
>>>>>>
>>>>>>>
>>>>>>> The message you replied to ALf said to use the correct tool for the
>>>>>>> job,
>>>>>>> which seems like a reasonable opinion. You replied saying this was
>>>>>>> bullshit and implied Alf had said something about never using
>>>>>>> unsigned,
>>>>>>> your post looks like a deliberate attempt to start a flare.
>>>>>>> You also make the point of saying using unsigned for values that are
>>>>>>> never negative is fine, but how do you know it is never going to be
>>>>>>> negative? Your idea of never negative is different from others', you
>>>>>>> think array indexes cannot be negative, but most other people know
>>>>>>> they
>>>>>>> can be.
>>>>>>>
>>>>>>
>>>>>> If array indexes can be negative then please explain why
>>>>>> std::array::size_type will be std::size_t and not std:trdiff_t.
>>>>>>
>>>>>
>>>>> Just because that particular array type cannot have a negative index
>>>>> doesn't mean this applies to all arrays.
>>>>> Array indexes *can* be negative see:
>>>>> http://www.boost.org/doc/libs/1_46_1.../doc/user.html
>>>>>
>>>>
>>>> From n3242:
>>>>
>>>> "if E1 is an array and E2 an integer, then E1[E2] refers to the E2-th
>>>> member of E1"
>>>>
>>>> E2 cannot be negative if the above rule is not to be broken.
>>>>
>>> The above says E2 is an integer not an unsigned integer.
>>>
>>> Also:
>>> int arr[5] = {0};
>>> arr[4] =5; /*The 5th element not the 4th*/
>>> arr[0] = 1; /*The 1st elelment, not the 0th*/
>>> int*p_arr = &arr;
>>> ++p_arr;
>>> p_arr[-1] = 1; /*The 1st element, not the -1st*/
>>> p_arr[0] = 2; /*The 2nd element, not the 0th*/
>>>
>>
>> In C++ an array index can't be negative; p_arr above is not an array it
>> is a pointer. Obviously "E2-th" is zero-based not one-based. The fact
>> that Boost provides an array-like container which accepts negative
>> indices is mostly irrelevant; my primary concern is C++ not Boost; again:
>>
>> From n3242:
>>
>> "if E1 is an array and E2 an integer, then E1[E2] refers to the E2-th
>> member of E1"
>>
>> if E2 is negative then E1[E2] cannot possibly refer to a member of E1.
>>
>
> Also from n1336:
>
> "if E1 is an array object (equivalently, a pointer to the initial element
> of an array object) and E2 is an integer, E1[E2] designates the E2-th
> element of E1 (counting from zero)."
>
> This more closely matches my thinking on this subject; a sub-array
> reference that allows you to give a negative array index on most
> implementations is not an array object.
>
> /Leigh

idiot.

"Leigh Johnston" <> wrote in message
news:3JidnSj5NITxm-...
> On 14/03/2011 12:06, Paul wrote:
>>
>> "Leigh Johnston" <> wrote in message
>> news: ...
>>> On 14/03/2011 01:41, Paul wrote:
>>>>
>>>> "Leigh Johnston" <> wrote in message
>>>> news:NqqdnfazidZk--...
>>>>> On 14/03/2011 00:09, Paul wrote:
>>>>>>
>>>>>> "Leigh Johnston" <> wrote in message
>>>>>> news:Y8udnZW5hNEZs-...
>>>>>>> On 13/03/2011 20:43, Paul wrote:
>>>>>>>>
>>>>>>>> "Leigh Johnston" <> wrote in message
>>>>>>>> newssednU44m-tvgODQnZ2dnUVZ8g-...
>>>>>>>>> On 13/03/2011 19:29, Alf P. Steinbach /Usenet wrote:
>>>>>>>>>> * William Ahern, on 13.03.2011 03:01:
>>>>>>>>>>
>>>>>>>>>> "If you stick to (unsigned int) or wider, then you're fine" is
>>>>>>>>>> generally
>>>>>>>>>> false. Use hammer for nails, screwdriver for screws. In short,
>>>>>>>>>> use the
>>>>>>>>>> right tool for the job, or at least don't use a clearly
>>>>>>>>>> inappropriate
>>>>>>>>>> tool: don't use signed types for bitlevel stuff, and don't use
>>>>>>>>>> unsigned
>>>>>>>>>> types for numerical stuff.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Bullshit. Using unsigned integral types to represent values that
>>>>>>>>> are
>>>>>>>>> never negative is perfectly fine. std::size_t ensures that the C++
>>>>>>>>> horse has already bolted as far as trying to avoid them is
>>>>>>>>> concerned.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> unsigned types can be safer because everything about the
>>>>>>>>>>> arithmetic is well defined, including over- and underflows which
>>>>>>>>>>> occur
>>>>>>>>>>> modulo 2^N; as opposed to signed, where those scenarios are
>>>>>>>>>>> undefined.
>>>>>>>>>>
>>>>>>>>>> The well-definedness of operations that you're talking about is
>>>>>>>>>> this:
>>>>>>>>>> that the language *guarantees* that range errors for unsigned
>>>>>>>>>> types
>>>>>>>>>> will
>>>>>>>>>> not be caught.
>>>>>>>>>>
>>>>>>>>>> A guarantee that errors won't be caught does not mean "safer".
>>>>>>>>>>
>>>>>>>>>> That's plain idiocy, sorry.
>>>>>>>>>
>>>>>>>>> Plain idiocy is eschewing the unsigned integral types in C++.
>>>>>>>>> Perhaps
>>>>>>>>> you would prefer being a Java programmer? Java has less types to
>>>>>>>>> "play
>>>>>>>>> with" which perhaps would suit you better if you cannot cope with
>>>>>>>>> C++'s richer set of types.
>>>>>>>>>
>>>>>>>> As Java, like C++, supports UDT's I don't think it's correct to say
>>>>>>>> that
>>>>>>>> C++ suports a richer set of types.
>>>>>>>> class anyTypeYouLike{};
>>>>>>>
>>>>>>> This is a troll. If is obvious I am referring to the set of built-in
>>>>>>> types. A user defined type is often composed of one or more built-in
>>>>>>> types.
>>>>>>>
>>>>>>>>
>>>>>>>> There is a reason Java doesn't bother with a built in unsigned
>>>>>>>> numeric
>>>>>>>> type.
>>>>>>>> I think the people who created Java know more about programming
>>>>>>>> than you
>>>>>>>> do and it is not a case of Java being inadequete. This is just your
>>>>>>>> misguided interpretation in an attempt to reinforce your idea that
>>>>>>>> std::size_t is the only type people should use in many
>>>>>>>> circumstances.
>>>>>>>> You obviously think std:size_t is the best thing since sliced bread
>>>>>>>> and
>>>>>>>> this is the way forward in C++ and, as per usual, your opinion is
>>>>>>>> wrong.
>>>>>>>
>>>>>>> C++'s std::size_t comes from C's size_t. It is the way forward
>>>>>>> because
>>>>>>> it is also the way backward.
>>>>>>>
>>>>>>>>
>>>>>>>> The message you replied to ALf said to use the correct tool for the
>>>>>>>> job,
>>>>>>>> which seems like a reasonable opinion. You replied saying this was
>>>>>>>> bullshit and implied Alf had said something about never using
>>>>>>>> unsigned,
>>>>>>>> your post looks like a deliberate attempt to start a flare.
>>>>>>>> You also make the point of saying using unsigned for values that
>>>>>>>> are
>>>>>>>> never negative is fine, but how do you know it is never going to be
>>>>>>>> negative? Your idea of never negative is different from others',
>>>>>>>> you
>>>>>>>> think array indexes cannot be negative, but most other people know
>>>>>>>> they
>>>>>>>> can be.
>>>>>>>>
>>>>>>>
>>>>>>> If array indexes can be negative then please explain why
>>>>>>> std::array::size_type will be std::size_t and not std:trdiff_t.
>>>>>>>
>>>>>>
>>>>>> Just because that particular array type cannot have a negative index
>>>>>> doesn't mean this applies to all arrays.
>>>>>> Array indexes *can* be negative see:
>>>>>> http://www.boost.org/doc/libs/1_46_1.../doc/user.html
>>>>>>
>>>>>
>>>>> From n3242:
>>>>>
>>>>> "if E1 is an array and E2 an integer, then E1[E2] refers to the E2-th
>>>>> member of E1"
>>>>>
>>>>> E2 cannot be negative if the above rule is not to be broken.
>>>>>
>>>> The above says E2 is an integer not an unsigned integer.
>>>>
>>>> Also:
>>>> int arr[5] = {0};
>>>> arr[4] =5; /*The 5th element not the 4th*/
>>>> arr[0] = 1; /*The 1st elelment, not the 0th*/
>>>> int*p_arr = &arr;
>>>> ++p_arr;
>>>> p_arr[-1] = 1; /*The 1st element, not the -1st*/
>>>> p_arr[0] = 2; /*The 2nd element, not the 0th*/
>>>>
>>>
>>> In C++ an array index can't be negative; p_arr above is not an array
>>> it is a pointer. Obviously "E2-th" is zero-based not one-based. The
>>> fact that Boost provides an array-like container which accepts
>>> negative indices is mostly irrelevant; my primary concern is C++ not
>>> Boost; again:
>>>
>> An array is always accessed via a pointer thats just how it works.
>>
>>
>>> From n3242:
>>>
>>> "if E1 is an array and E2 an integer, then E1[E2] refers to the E2-th
>>> member of E1"
>>>
>>> if E2 is negative then E1[E2] cannot possibly refer to a member of E1.
>>>
>> From common sense:
>>
>> int arr[16]={0};
>> arr[0]=0; /*1st element not 0th element*/
>>
>>
>> I don't give a **** about your stupid misinterpretations from the ISO
>> documents you ****in idiot, learn to accpet when you are wrong.
>
> *My* misinterpretations? lulz. I don't think so; the standards are quite
> clear; from n1336:
>
> "if E1 is an array object (equivalently, a pointer to the initial element
> of an array object) and E2 is an integer, E1[E2] designates the E2-th
> element of E1 (counting from zero)."
>
> This more closely matches my thinking on this subject; a sub-array
> reference that allows you to give a negative array index on most
> implementations is not an array object.
>
> You are the ****ing idiot.
>
>>
>>>>
>>>> I don't know what medicine you are on but it doesn't seem to be
>>>> working.
>>>> An array can have a negative index, accept you're wrong, forget about
>>>> size_t, revisit your doctor and move on.
>>>>
>>>
>>> You are the one who is wrong and refuse to accept what is correct.
>>>
>>> std::size_t.
>>>
>> Oh yes try to start a flare with no reasonable arguement as usual, well
>> I had enough of idiots like you see if I care , anyone with a brain can
>> see you are the one who is wrong.
>>
>
> As I said above it is you who is the idiot; it is you who is wrong.
>
> Using negative array indices is poor practice at best.
>
> /Leigh

idiot

On 14 Mrz., 14:13, Leigh Johnston wrote:
>
> Obviously one can do the following:
>
> int main()
> {
> * * * * int n[2][2] = { { 11, 12 }, { 21, 22} };
> * * * * std::cout << n[1][-1]; // outputs "12"
> }
> [...]
> so IMO it is an open question as to whether the above code is UB.

Yes, I think this is a bit of a gray area. Avoid it if you can. If I
recall correctly, pointer arithmetic is restricted to stay inside some
array (including "one element past the end"). Here, n is an array of
arrays. n[1] selects the second array and the additional [-1] steps
out of that 2nd array. If I recall correctly, James Kanze talked about
a possible debugging implementation which would augment pointers to
store additional information to enable runtime checking of index-out-
of-bounds conditions w.r.t. pointer arithmetic and op[]. IIRC, he
claimed this implementation to be conforming. But it would obviously
"break" your example.

On 14 mar, 15:20, SG <s.gesem...@gmail.com> wrote:
> On 14 Mrz., 14:13, Leigh Johnston wrote:
>
>
>
> > Obviously one can do the following:
>
> > * int main()
> > * {
> > * * * * int n[2][2] = { { 11, 12 }, { 21, 22} };
> > * * * * std::cout << n[1][-1]; // outputs "12"
> > * }
> > [...]
> > so IMO it is an open question as to whether the above code is UB.
>
> Yes, I think this is a bit of a gray area. Avoid it if you can. If I
> recall correctly, pointer arithmetic is restricted to stay inside some
> array (including "one element past the end"). Here, n is an array of
> arrays. n[1] selects the second array and the additional [-1] steps
> out of that 2nd array. If I recall correctly, James Kanze talked about
> a possible debugging implementation which would augment pointers to
> store additional information to enable runtime checking of index-out-
> of-bounds conditions w.r.t. pointer arithmetic and op[]. IIRC, he
> claimed this implementation to be conforming. But it would obviously
> "break" your example.

An implementation storing data before or after each array would be
problematic indeed.

It would also break n[1][1] == (&n[0][0])[3] which would be
surprising.
I could not find a guarantee of continuity of the layout in the
standard to back up that claim and, to my untrained eye, it carefully
steps around the issue.

By the way, Leigh Johnson didn't quote the full phrase :
"/Because of the conversion rules that apply to +,/ if E1 is an array
and E2 an integer, then E1[E2] refers to the E2-th member of E1".

The C99 standard phrases it a bit differently:
"Because of the conversion rules that apply to the binary + operator,
if E1 is an array object (equivalently, a pointer to the initial
element of an array object) and E2 is an integer, E1[E2] designates
the E2-th element of E1 (counting from zero)."

The counting from zero is surprising because arrays are however zero-
based but not if you consider that when referencing a sub-object (a
sub-array), you would no longer be zero-based regarding the underlying
object..

Which tends to hint that E1 is however converted into a pointer and no
special treatment is performed because E1 is of array type. In this
case, I expect normal pointer arithmetic applies and a negative
integral part of the subscript operator is acceptable provided you
stay within the underlying object.

--
Michael

On 14 mar, 15:23, Leigh Johnston <le...@i42.co.uk> wrote:
> On 14/03/2011 13:13, Leigh Johnston wrote:
>
>
>
> > On 14/03/2011 12:10, Leigh Johnston wrote:
> >> On 14/03/2011 11:48, Leigh Johnston wrote:
> >>> On 14/03/2011 01:41, Paul wrote:
>
> >>>> "Leigh Johnston" <le...@i42.co.uk> wrote in message
> >>>>news:NqqdnfazidZk--...
> >>>>> On 14/03/2011 00:09, Paul wrote:
>
> >>>>>> "Leigh Johnston" <le...@i42.co.uk> wrote in message
> >>>>>>news:Y8udnZW5hNEZs-...
> >>>>>>> On 13/03/2011 20:43, Paul wrote:
>
> >>>>>>>> "Leigh Johnston" <le...@i42.co.uk> wrote in message
> >>>>>>>>newssednU44m-tvgODQnZ2dnUVZ8g-...
> >>>>>>>>> On 13/03/2011 19:29, Alf P. Steinbach /Usenet wrote:
> >>>>>>>>>> * William Ahern, on 13.03.2011 03:01:
>
> >>>>>>>>>> "If you stick to (unsigned int) or wider, then you're fine" is
> >>>>>>>>>> generally
> >>>>>>>>>> false. Use hammer for nails, screwdriver for screws. In short,
> >>>>>>>>>> use the
> >>>>>>>>>> right tool for the job, or at least don't use a clearly
> >>>>>>>>>> inappropriate
> >>>>>>>>>> tool: don't use signed types for bitlevel stuff, and don't use
> >>>>>>>>>> unsigned
> >>>>>>>>>> types for numerical stuff.
>
> >>>>>>>>> Bullshit. Using unsigned integral types to represent values that
> >>>>>>>>> are
> >>>>>>>>> never negative is perfectly fine. std::size_t ensures that the C++
> >>>>>>>>> horse has already bolted as far as trying to avoid them is
> >>>>>>>>> concerned.
>
> >>>>>>>>>>> unsigned types can be safer because everything about the
> >>>>>>>>>>> arithmetic is well defined, including over- and underflows which
> >>>>>>>>>>> occur
> >>>>>>>>>>> modulo 2^N; as opposed to signed, where those scenarios are
> >>>>>>>>>>> undefined.
>
> >>>>>>>>>> The well-definedness of operations that you're talking about is
> >>>>>>>>>> this:
> >>>>>>>>>> that the language *guarantees* that range errors for unsigned
> >>>>>>>>>> types
> >>>>>>>>>> will
> >>>>>>>>>> not be caught.
>
> >>>>>>>>>> A guarantee that errors won't be caught does not mean "safer".
>
> >>>>>>>>>> That's plain idiocy, sorry.
>
> >>>>>>>>> Plain idiocy is eschewing the unsigned integral types in C++.
> >>>>>>>>> Perhaps
> >>>>>>>>> you would prefer being a Java programmer? Java has less types to
> >>>>>>>>> "play
> >>>>>>>>> with" which perhaps would suit you better if you cannot cope with
> >>>>>>>>> C++'s richer set of types.
>
> >>>>>>>> As Java, like C++, supports UDT's I don't think it's correct to say
> >>>>>>>> that
> >>>>>>>> C++ suports a richer set of types.
> >>>>>>>> class anyTypeYouLike{};
>
> >>>>>>> This is a troll. If is obvious I am referring to the set of built-in
> >>>>>>> types. A user defined type is often composed of one or more built-in
> >>>>>>> types.
>
> >>>>>>>> There is a reason Java doesn't bother with a built in unsigned
> >>>>>>>> numeric
> >>>>>>>> type.
> >>>>>>>> I think the people who created Java know more about programming
> >>>>>>>> than you
> >>>>>>>> do and it is not a case of Java being inadequete. This is just your
> >>>>>>>> misguided interpretation in an attempt to reinforce your idea that
> >>>>>>>> std::size_t is the only type people should use in many
> >>>>>>>> circumstances.
> >>>>>>>> You obviously think std:size_t is the best thing since sliced bread
> >>>>>>>> and
> >>>>>>>> this is the way forward in C++ and, as per usual, your opinion is
> >>>>>>>> wrong.
>
> >>>>>>> C++'s std::size_t comes from C's size_t. It is the way forward
> >>>>>>> because
> >>>>>>> it is also the way backward.
>
> >>>>>>>> The message you replied to ALf said to use the correct tool for the
> >>>>>>>> job,
> >>>>>>>> which seems like a reasonable opinion. You replied saying this was
> >>>>>>>> bullshit and implied Alf had said something about never using
> >>>>>>>> unsigned,
> >>>>>>>> your post looks like a deliberate attempt to start a flare.
> >>>>>>>> You also make the point of saying using unsigned for values that
> >>>>>>>> are
> >>>>>>>> never negative is fine, but how do you know it is never going to be
> >>>>>>>> negative? Your idea of never negative is different from others',
> >>>>>>>> you
> >>>>>>>> think array indexes cannot be negative, but most other people know
> >>>>>>>> they
> >>>>>>>> can be.
>
> >>>>>>> If array indexes can be negative then please explain why
> >>>>>>> std::array::size_type will be std::size_t and not std:trdiff_t.
>
> >>>>>> Just because that particular array type cannot have a negative index
> >>>>>> doesn't mean this applies to all arrays.
> >>>>>> Array indexes *can* be negative see:
> >>>>>>http://www.boost.org/doc/libs/1_46_1.../doc/user.html
>
> >>>>> From n3242:
>
> >>>>> "if E1 is an array and E2 an integer, then E1[E2] refers to the E2-th
> >>>>> member of E1"
>
> >>>>> E2 cannot be negative if the above rule is not to be broken.
>
> >>>> The above says E2 is an integer not an unsigned integer.
>
> >>>> Also:
> >>>> int arr[5] = {0};
> >>>> arr[4] =5; /*The 5th element not the 4th*/
> >>>> arr[0] = 1; /*The 1st elelment, not the 0th*/
> >>>> int*p_arr = &arr;
> >>>> ++p_arr;
> >>>> p_arr[-1] = 1; /*The 1st element, not the -1st*/
> >>>> p_arr[0] = 2; /*The 2nd element, not the 0th*/
>
> >>> In C++ an array index can't be negative; p_arr above is not an array it
> >>> is a pointer. Obviously "E2-th" is zero-based not one-based. The fact
> >>> that Boost provides an array-like container which accepts negative
> >>> indices is mostly irrelevant; my primary concern is C++ not Boost;
> >>> again:
>
> >>> From n3242:
>
> >>> "if E1 is an array and E2 an integer, then E1[E2] refers to the E2-th
> >>> member of E1"
>
> >>> if E2 is negative then E1[E2] cannot possibly refer to a member of E1.
>
> >> Also from n1336:
>
> >> "if E1 is an array object (equivalently, a pointer to the initial
> >> element of an array object) and E2 is an integer, E1[E2] designates the
> >> E2-th element of E1 (counting from zero)."
>
> >> This more closely matches my thinking on this subject; a sub-array
> >> reference that allows you to give a negative array index on most
> >> implementations is not an array object.
>
> > Obviously one can do the following:
>
> > int main()
> > {
> > int n[2][2] = { { 11, 12 }, { 21, 22} };
> > std::cout << n[1][-1]; // outputs "12"
> > }
>
> > This should work on most implementations (Comeau warns with "subscript
> > out of range"); however I think it does run contra to the following:
>
> > "if E1 is an array and E2 an integer, then E1[E2] refers to the E2-th
> > member of E1"
>
> > as n[1][-1] is not a member of n[1]; it is a member of n[0].
>
> > so IMO it is an open question as to whether the above code is UB.
>
> Interestingly g++ v4.1.2 (codepad.org) does not output "12"; this of
> course either strengthens my position that using negative array indices
> may be UB or that g++ is buggy; either way using negative array indices
> is still poor practice.

It may be a bug or related to codepad.

The offset is right :
int main()
{
int n[2][2] = { { 11, 12 }, { 21, 22} };
std::cout << &n[0][0] <<" "<<&n[1][0]; // outputs 0xbf6c1960
0xbf6c1968
}


--
Michael

On 14 Mrz., 16:03, Michael Doubez wrote:
> On 14 mar, 15:20, SG wrote:
>
> > Yes, I think this is a bit of a gray area. Avoid it if you can. If I
> > recall correctly, pointer arithmetic is restricted to stay inside some
> > array (including "one element past the end"). Here, n is an array of
> > arrays. n[1] selects the second array and the additional [-1] steps
> > out of that 2nd array. If I recall correctly, James Kanze talked about
> > a possible debugging implementation which would augment pointers to
> > store additional information to enable runtime checking of index-out-
> > of-bounds conditions w.r.t. pointer arithmetic and op[]. IIRC, he
> > claimed this implementation to be conforming. But it would obviously
> > "break" your example.
>
> An implementation storing data before or after each array would be
> problematic indeed.
> It would also break n[1][1] == (&n[0][0])[3] which would be
> surprising.

I think you misunderstood. I was talking about the possibility of an
implementation that makes raw pointers more intelligent for debugging
purposes. Imagine a "raw pointer" that not only stores the adress but
also a range of possibly valid "indices". A built-in version of

struct raw_pointer {
char* address;
ptrdiff_t begin_idx, end_idx;
};

so-to-speak where an array-to-pointer decay in a case like

void foo(int * r) {
r += 9; // <-- runtime check fails, program aborts
}

void bar() {
int arr[5];
int* p = arr;
int* q = p+1;
foo(p);
}

would make p store the address of the first element along with 0 and 5
as an index pair and q the adress of the second array element with an
index pair -1 and 4.

Now, I'm not aware of any such implementation and I'm not claiming
this to be a good idea. But IIRC James Kanze hinted at something like
this and claimed it to be conforming to the C++ ISO standard.

> I could not find a guarantee of continuity of the layout in the
> standard to back up that claim and, to my untrained eye, it carefully
> steps around the issue.

Well, it would surprize me if sizeof(T[N])==N*sizeof(T) was not
satisfied. But I am not aware of any such guarantee, either.

> [...]
> Which tends to hint that E1 is however converted into a pointer and no
> special treatment is performed because E1 is of array type. In this
> case, I expect normal pointer arithmetic applies and a negative
> integral part of the subscript operator is acceptable provided you
> stay within the underlying object.

As I said, IIRC James Kanze claimed this to be "formally U.B.".

Cheers!
SG