Unsigned types are DANGEROUS??

[James Kanze]

On 13/03/2011 20:57, Johannes Schaub (litb) wrote:

Eschewing unsigned integral types when programming in C++ is
irrational at worst; n00bish at best as the std::size_t C++
horse bolted long ago.

I'd suggest you read _Programming Principles and Practice Using
C++_. The author, a certian Bjarne Stroustrup, carefully avoids
all use of unsigned integrals. And I would hardly consider him
irrational or n00bish. (But of course, for you, anyone who
doesn't agree with Leigh is irrational or n00bish or a troll.
I'm not sure that I'd consider that attitude a sign of
maturity.)

 

[Paul]

Bullshit. The concept of a value which is never negative is not
orthogonal to "numerical stuff"; unsigned integral types are not just for
bitwise operations: std::size_t is not normally used in bitwise operations
but it is nevertheless an unsigned integral type.

It's not bullshit, it's a valid opinion that many people agree with.
Your concept of a value which is never negative is not necessarily the same
as everyone elses, for example you think an array can never be negative but
it can be.

double* arr = new double[3];
++arr;
arr is the name/identifier that is used to access the array object.
It's perfectly acceptable to offset the pointer to access the array with
non-zero based indexing. Many algorithms and mathematical functions benefit
from this type of functionality.
You attempt to say the C++ standards disallows this is an attempt to twist
the wording to support your own argument.

If you cannot understand the benefits of non-based array indexing, then I
suggest you are a complete idiot because I'm pretty sure you unreasonably
trying to twist things to suit your argument. And if you really do think an
array cannot be non-zero based then you are a complete idiot.

 

[Noah Roberts]

It's not bullshit, it's a valid opinion that many people agree with.
Your concept of a value which is never negative is not necessarily the
same as everyone elses, for example you think an array can never be
negative but it can be.

double* arr = new double[3];
++arr;
arr is the name/identifier that is used to access the array object.
It's perfectly acceptable to offset the pointer to access the array with
non-zero based indexing. Many algorithms and mathematical functions
benefit from this type of functionality.
You attempt to say the C++ standards disallows this is an attempt to
twist the wording to support your own argument.

If you cannot understand the benefits of non-based array indexing, then
I suggest you are a complete idiot because I'm pretty sure you
unreasonably trying to twist things to suit your argument. And if you
really do think an array cannot be non-zero based then you are a
complete idiot.

You guys are going to continue arguing in circles so long as you aren't
both agreeing to what terms mean. Most people here are hopefully using
the terms as defined by the standard, or are explicitly explaining that
this is not the case. Some people may not exactly know what the
standard terms are, and that's OK, but continuing to insist everyone use
the incorrect terminology when the difference has been pointed out to
you is pretty obtuse.

A pointer is not an array, even if that pointer points at an element IN
an array. There _is_ a difference and Leah has already explained this
to you. Although you might argue that non-technically, one could
suppose that they are the same thing (I would strongly disagree) the
simple fact is that as far as the technical definitions go the two
cannot be equated.

This blatant disregard for technical correctness seem especially
humorous given
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/853fcff0bfd290a2

 

[MikeP]

I used to be a big fan of unsigned , and I thought it was best used
for loop counters , array indexes etc. But my opinions have changed
and I now think signed are better. I think I understand the pros and
cons for each technique.

Ditto for me, but just the opposite.

But I think if a program needs an unsigned integer larger than 2^16
its for a very specific use.

You have to consider all cases: 8,- 16-, 32-, 64-bit widths. Towards the
right, not so important, towards the left, more important (to have
unsigned).

Normally numbers of that magnitute are
represented with doubles. I think most of these cases would be worthy
of a UDT, which is why I was thinking of using unsigned 16's to
construct a large user-defined integer type. I know its a massive
pain and would be much simpler if there was an unsigned integer, but
do it once and its re-useable.

It's not just about getting more range, it's about getting the
appropriate range most efficiently. If you have to jump to the next width
because there are no unsigned ints, that is inelegant (doubles the
storage space).

I agree that Java would be better with unsigned bytes and integers,
but i also respect their reasons for omitting them.

Well if it was to "dumb down", then they accomplished that. I think they
OVER-simplified at the expense of the expressibility of the language.
(.02).

It's a much
simpler language than C++ and each have their pros and cons.

It's true they are different environments, but in this case, the
elimination of unsigned ints was a faux paus IMO. (.02).

It's
just another level IMO: asm -> C++ -> Java.

Not really: Java is in a VM and not close to the hardware (funny, because
it started out as a language for embedded devices!) so assembly and C++
fit together but Java does not belong in the same category.

 

[MikeP]

And one of our resident trolls pipes up...

There are arguments for both sides. Overall, the arguments
against using unsigned for arithmetic values seems to prevail:
at least with most of the C++ experts. But of course, as a
resident troll, Leigh rather likes the idea of categorizing
the opinions of Stroustrup (and Kernighan and Richie in C) as
"plain idiocy".

I think what preference someone has on this issue indicates if they are
more of the language-lawyer type or the application domain type. The
former is apt to choose signed for a loop counter whereas the latter is
apt to choose unsigned.

 

[MikeP]

On Mar 13, 2:07 am, "Alf P. Steinbach /Usenet" <alf.p.steinbach
(e-mail address removed)> wrote:

[..,]

Not in the sense that you're apparently asking about, that is,
there is not anything broken about e.g 'unsigned' itself. But
as part of a willy-nilly broken type hodge-podge inherited
from C, yes, it's broken. That's because implicit conversions
that lose information are all over the place.

I think that's the best explination I've seen to date. It's not
unsigned per se which is broken, it's the whole way integral
types interact (and implicitly convert) which is broken. (This
is why most of the real experts, starting with Stroustrup, use
int unless really forced to do otherwise.)

By "real experts" you of course mean "language lawyers".

 

[MikeP]

I'd suggest you read _Programming Principles and Practice Using
C++_. The author, a certian Bjarne Stroustrup, carefully avoids
all use of unsigned integrals.

How long is the passage where he opines thusly? A sentence? A paragraph?
A page? A chapter? Can you give the page number(s) please? As I was not
convinced by this thread or the links in it to change my style, I would
like to see if I find his reasoning any more compelling. (Your current
line of reasoning seems like "appeal to authority", BTW).

 

[MikeP]

They've exagerated the problems, greatly IMHO.

"Understatement of the year"! Everyone seems to be advertising their pet
examples as to why it should be one way or the other instead of doing a
wholistic examination of the issue.

But in general,
most (but not all) C++ experts do only use unsigned types when
they need the modula arithmetic (e.g. hash codes), or when they
will be using bitwise operators.

But when they graduate from being C++ experts and into the realm of
application domain coding, will they still do the same? (I couldn't
resist!).

For various reasons, the
unsigned types in C/C++ are slightly broken, and don't work well
in usual contexts.

A list of ALL the cases would be good to create. Everyone seems to have
their pet example, so why not put them and more in one place for once and
for all. What a better place to do that then this ng!

Signed/Unsigned Issues

1. Loop counters.
2. Sizes.
3. Indices.
..
..
..
N.


etc.

Creating a comprehensive list should be a breeze in this group.

 

[Paul]

On Mar 13, 2:07 am, "Alf P. Steinbach /Usenet" <alf.p.steinbach
(e-mail address removed)> wrote:

[..,]

Not in the sense that you're apparently asking about, that is,
there is not anything broken about e.g 'unsigned' itself. But
as part of a willy-nilly broken type hodge-podge inherited
from C, yes, it's broken. That's because implicit conversions
that lose information are all over the place.

I think that's the best explination I've seen to date. It's not
unsigned per se which is broken, it's the whole way integral
types interact (and implicitly convert) which is broken. (This
is why most of the real experts, starting with Stroustrup, use
int unless really forced to do otherwise.)

By "real experts" you of course mean "language lawyers".

But what he says make sense.
Why introduce conversions if they are unnecessary?

 

[Paul]

It's not bullshit, it's a valid opinion that many people agree with.
Your concept of a value which is never negative is not necessarily the
same as everyone elses, for example you think an array can never be
negative but it can be.

double* arr = new double[3];
++arr;
arr is the name/identifier that is used to access the array object.
It's perfectly acceptable to offset the pointer to access the array with
non-zero based indexing. Many algorithms and mathematical functions
benefit from this type of functionality.
You attempt to say the C++ standards disallows this is an attempt to
twist the wording to support your own argument.

If you cannot understand the benefits of non-based array indexing, then
I suggest you are a complete idiot because I'm pretty sure you
unreasonably trying to twist things to suit your argument. And if you
really do think an array cannot be non-zero based then you are a
complete idiot.

You guys are going to continue arguing in circles so long as you aren't
both agreeing to what terms mean. Most people here are hopefully using
the terms as defined by the standard, or are explicitly explaining that
this is not the case. Some people may not exactly know what the standard
terms are, and that's OK, but continuing to insist everyone use the
incorrect terminology when the difference has been pointed out to you is
pretty obtuse.

A pointer is not an array, even if that pointer points at an element IN an
array. There _is_ a difference and Leah has already explained this to
you. Although you might argue that non-technically, one could suppose
that they are the same thing (I would strongly disagree) the simple fact
is that as far as the technical definitions go the two cannot be equated.

An array identifier *is* a pointer. This is not communacative: a pointer is
not necessarrily an array identifier, and I never suggested this.

Obviously you share Leighs programming concepts and aslo his ability to
twist words to support a lost argument.

 

[Paul]

On 14/03/2011 19:30, Alf P. Steinbach /Usenet wrote:
* MikeP, on 14.03.2011 18:49:
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?

Well that's a relief. Now that I've read the thread posts and the
links
to other threads, I see I have not been doing anything wrong by
preferring unsigned where it seems natural to do so. The biggie points
(for me) are:

1. C++ conversion rules are at the core of the problem.

Yes, right.

Another core issue is monkey-see-monkey-do habits & ideas, that is,
habits & ideas that are not founded in real understanding but are just
mindlessly adopted from some other context where they *are* meaningful.

I.e., that what's meaningful in e.g. Pascal (guaranteed range checking,
advantage) isn't meaningful in C++ (guaranteed lack of range checking,
disadvantage of adopting Pascal habits & ideas).


2.Mixing signed/unsigned inadvertently is not that big of a problem
given
that most compilers emit a warning upon such.

This is, however, wrong.

Particularly so since the Google coder's note speaks of "arithmetical
places".

Compilers generally warn about comparisions between signed and
unsigned,
but can't warn you of equally-or-more dangerous arithmetic constructs.


3. Using signed where unsigned is a better fit, loses semantic value.

Yes, right.

And it's even worse: using signed where unsigned is a better fit
(namely
for bit-level operations), can easily yield Undefined Behavor.

And vice versa, using unsigned where signed is a better fit (namely for
numerical stuff) loses semantic value and can far too easily introduce
bugs.

Bullshit. The concept of a value which is never negative is not
orthogonal to "numerical stuff"; unsigned integral types are not just
for bitwise operations: std::size_t is not normally used in bitwise
operations but it is nevertheless an unsigned integral type.

It's not bullshit, it's a valid opinion that many people agree with.
Your concept of a value which is never negative is not necessarily the
same as everyone elses, for example you think an array can never be
negative but it can be.

double* arr = new double[3];
++arr;
arr is the name/identifier that is used to access the array object.
It's perfectly acceptable to offset the pointer to access the array with
non-zero based indexing. Many algorithms and mathematical functions
benefit from this type of functionality.
You attempt to say the C++ standards disallows this is an attempt to
twist the wording to support your own argument.

If you cannot understand the benefits of non-based array indexing, then
I suggest you are a complete idiot because I'm pretty sure you
unreasonably trying to twist things to suit your argument. And if you
really do think an array cannot be non-zero based then you are a
complete idiot.

Keep up: we have already come to the conclusion that negative C++ array
indices are UB; C++ array indexing and pointer arithmetic *within* an
array are not necessarily semantically identical as a pointer to an array
element is not equivalent to an array unless it is pointing to the first
array element and as evidenced by the behaviour exhibited by various
versions of g++.

From the C++ standard:
"The expression E1[E2] is identical (by definition) to *((E1)+(E2))."

Give up , you've failed.

 

[Noah Roberts]

An array identifier *is* a pointer.

This is false.

int x[] = {1,2,3};

^^ x is an identifier, it identifies an array, but x is not a pointer.
Not much more to say there; it simply is not so. The type of x is
int[3], not int*.

What your misconception is probably based upon is the way that arrays
*convert to* pointers implicitly.

void f(int* y);
f(x); // legal. **y** is a pointer to the first element in x.

This does not mean that x itself is a pointer and it in fact is not.
For example, in 32 bit implementations:

sizeof(x) == 12 (probably)
sizeof(y) == 4 (probably)

There are other important, practical consequences of this difference.

Obviously you share Leighs programming concepts and aslo his ability to
twist words to support a lost argument.

Refer to the standard of the language you are talking about. C++ simply
does not work the way you think it does.

 

[Paul]

"Understatement of the year"! Everyone seems to be advertising their pet
examples as to why it should be one way or the other instead of doing a
wholistic examination of the issue.


But when they graduate from being C++ experts and into the realm of
application domain coding, will they still do the same? (I couldn't
resist!).


A list of ALL the cases would be good to create. Everyone seems to have
their pet example, so why not put them and more in one place for once and
for all. What a better place to do that then this ng!

Signed/Unsigned Issues

1. Loop counters.

Your reason for this? This is usually given as a reason why unsigned are bad
ref:
http://eli.thegreenplace.net/2010/06/11/the-perils-of-unsigned-iteration-in-cc/

2. Sizes.

A constant size or a size that could be modified by arithmetic? I don't see
any advantage of unsigned in any case, I see a disadvantage in the latter.

3. Indices.

Indices can be negative, unless a container class has defined it otherwise.
What advantage comes with using unsigned for indices?

The language default for integer literals is signed, so if you code
arr[1];
The expression is implicitly converted to *((arr pointer)+(integer with
value of 1)).
If this is the case doesn't it seem better to stick to the same type as the
languages default?

 

[Paul]

An array identifier *is* a pointer.

This is false.

int x[] = {1,2,3};

^^ x is an identifier, it identifies an array, but x is not a pointer. Not
much more to say there; it simply is not so. The type of x is int[3], not
int*.

You are confused between an array and an array-type.
int* p_x = new int[32];
An array identifier is a pointer.

What your misconception is probably based upon is the way that arrays
*convert to* pointers implicitly.

"The expression E1[E2] is identical (by definition) to *((E1)+(E2))."
It can't be any clearer.

void f(int* y);
f(x); // legal. **y** is a pointer to the first element in x.

This does not mean that x itself is a pointer and it in fact is not. For
example, in 32 bit implementations:

sizeof(x) == 12 (probably)
sizeof(y) == 4 (probably)

Type info is carried around with arrays , as you've just demonstrated,
arrays are passed around as pointers.
So nothing new there.

There are other important, practical consequences of this difference.

I don't know what you define an "important practical consequence" to be but
you obviously think you have shown one.

Refer to the standard of the language you are talking about. C++ simply
does not work the way you think it does.

It doesn't? oh glad you told me then

 

[Paul]

Type info *****ISN'T***** carried around with arrays , as you've just
demonstrated, arrays are passed around as pointers.
So nothing new there.

 

[MikeP]

On Mar 13, 2:07 am, "Alf P. Steinbach /Usenet" <alf.p.steinbach
(e-mail address removed)> wrote:

[..,]
Not in the sense that you're apparently asking about, that is,
there is not anything broken about e.g 'unsigned' itself. But
as part of a willy-nilly broken type hodge-podge inherited
from C, yes, it's broken. That's because implicit conversions
that lose information are all over the place.

I think that's the best explination I've seen to date. It's not
unsigned per se which is broken, it's the whole way integral
types interact (and implicitly convert) which is broken. (This
is why most of the real experts, starting with Stroustrup, use
int unless really forced to do otherwise.)

By "real experts" you of course mean "language lawyers".

But what he says make sense.

Now I KNOW you're not trying or about to try to convince me to change my
programming style to the way YOU prefer it. Are you? I see no compelling
reason to change it having read the pertinent threads. Change languages
eventually? Maybe. But programming style? Nah. I'm more apt to wrap the
primitive types to get nicer semantics than I am to just grin and bear
the language's shortcomings.

"Who said it" surely does not affect how I evaluate technical
information. I assess it for its technical merit and how it applies to my
projects. "Who says it" never factors into the process (OK, maybe a
little bit, but I'm more likely to keep an eye out for who is "in the
box" saying something and who is "out of the box" so I know how much salt
to use with the information, rather than anything else). Qualification
via name-dropping raises a red flag to me.

 

[MikeP]

"Understatement of the year"! Everyone seems to be advertising their
pet examples as to why it should be one way or the other instead of
doing a wholistic examination of the issue.


But when they graduate from being C++ experts and into the realm of
application domain coding, will they still do the same? (I couldn't
resist!).


A list of ALL the cases would be good to create. Everyone seems to
have their pet example, so why not put them and more in one place
for once and for all. What a better place to do that then this ng!

Signed/Unsigned Issues

1. Loop counters.

Your reason for this? This is usually given as a reason why unsigned
are bad ref:
http://eli.thegreenplace.net/2010/06/11/the-perils-of-unsigned-iteration-in-cc/

2. Sizes.

A constant size or a size that could be modified by arithmetic? I
don't see any advantage of unsigned in any case, I see a disadvantage
in the latter.

3. Indices.

Indices can be negative, unless a container class has defined it
otherwise. What advantage comes with using unsigned for indices?

The language default for integer literals is signed, so if you code
arr[1];
The expression is implicitly converted to *((arr pointer)+(integer
with value of 1)).
If this is the case doesn't it seem better to stick to the same type
as the languages default?

Well that's a start. Now about 200 more posts from a number of people and
we'd have a start to something workable. A thousand tidbits spread all
over the internet do not make a comprehensive or objective document. Or
maybe you want to compose one? And maybe Leigh can compose another one
and still another can combine the two. Back-n-forth banter is
unproductive.

There is the option to avoid "brain-damaged" language constructs
altogether, which no one has brought up. Of course if that is not
practical, then maybe the language is based upon weak foundation and
transition should be the goal. Something's gotta give.

 

[Paul]

On 14/03/2011 23:26, Paul wrote:

On 14/03/2011 19:30, Alf P. Steinbach /Usenet wrote:
* MikeP, on 14.03.2011 18:49:
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?

Well that's a relief. Now that I've read the thread posts and the
links
to other threads, I see I have not been doing anything wrong by
preferring unsigned where it seems natural to do so. The biggie
points
(for me) are:

1. C++ conversion rules are at the core of the problem.

Yes, right.

Another core issue is monkey-see-monkey-do habits & ideas, that is,
habits & ideas that are not founded in real understanding but are
just
mindlessly adopted from some other context where they *are*
meaningful.

I.e., that what's meaningful in e.g. Pascal (guaranteed range
checking,
advantage) isn't meaningful in C++ (guaranteed lack of range
checking,
disadvantage of adopting Pascal habits & ideas).


2.Mixing signed/unsigned inadvertently is not that big of a problem
given
that most compilers emit a warning upon such.

This is, however, wrong.

Particularly so since the Google coder's note speaks of "arithmetical
places".

Compilers generally warn about comparisions between signed and
unsigned,
but can't warn you of equally-or-more dangerous arithmetic
constructs.


3. Using signed where unsigned is a better fit, loses semantic
value.

Yes, right.

And it's even worse: using signed where unsigned is a better fit
(namely
for bit-level operations), can easily yield Undefined Behavor.

And vice versa, using unsigned where signed is a better fit (namely
for
numerical stuff) loses semantic value and can far too easily
introduce
bugs.

Bullshit. The concept of a value which is never negative is not
orthogonal to "numerical stuff"; unsigned integral types are not just
for bitwise operations: std::size_t is not normally used in bitwise
operations but it is nevertheless an unsigned integral type.

It's not bullshit, it's a valid opinion that many people agree with.
Your concept of a value which is never negative is not necessarily the
same as everyone elses, for example you think an array can never be
negative but it can be.

double* arr = new double[3];
++arr;
arr is the name/identifier that is used to access the array object.
It's perfectly acceptable to offset the pointer to access the array
with
non-zero based indexing. Many algorithms and mathematical functions
benefit from this type of functionality.
You attempt to say the C++ standards disallows this is an attempt to
twist the wording to support your own argument.

If you cannot understand the benefits of non-based array indexing, then
I suggest you are a complete idiot because I'm pretty sure you
unreasonably trying to twist things to suit your argument. And if you
really do think an array cannot be non-zero based then you are a
complete idiot.


Keep up: we have already come to the conclusion that negative C++
array indices are UB; C++ array indexing and pointer arithmetic
*within* an array are not necessarily semantically identical as a
pointer to an array element is not equivalent to an array unless it is
pointing to the first array element and as evidenced by the behaviour
exhibited by various versions of g++.

From the C++ standard:
"The expression E1[E2] is identical (by definition) to *((E1)+(E2))."

Give up , you've failed.

From the C++ standard:

"if E1 is an array and E2 an integer, then E1[E2] refers to the E2-th
member of E1"

I've failed? Obviously not. You've failed? Of course.

You obviously seem to think that says something other than it does. It has
already been proved by others that your quote is inaccurrate. Yes you failed
go back to bed.


"I will post this quote just to prove leigh is wrong, it doens't actually
support my argument but I will act as if it does because everyone is as
thick as leigh".

 

[Paul]

I notice you did not respond to this. I wonder if you have a reason why you
think unsigned is better in loop counter, or you just like it better.

Nor to this. I cannot help notice you give no reasoning, I wonder why this
is.

3. Indices.

Indices can be negative, unless a container class has defined it
otherwise. What advantage comes with using unsigned for indices?

The language default for integer literals is signed, so if you code
arr[1];
The expression is implicitly converted to *((arr pointer)+(integer
with value of 1)).
If this is the case doesn't it seem better to stick to the same type
as the languages default?

Again you have not responded to this either, do you actually have any
*reasons* for prefferring unsinged integers in these specific cases, other
than you just like them better?

Well that's a start. Now about 200 more posts from a number of people and
we'd have a start to something workable. A thousand tidbits spread all
over the internet do not make a comprehensive or objective document. Or
maybe you want to compose one? And maybe Leigh can compose another one and
still another can combine the two. Back-n-forth banter is unproductive.

There is the option to avoid "brain-damaged" language constructs
altogether, which no one has brought up.

What is a brain-damaged language construct? lol
I don't know what you mean by this, do you think it is brain-dead to use
array indices other than zero-based?

Of course if that is not practical, then maybe the language is based upon
weak foundation and transition should be the goal. Something's gotta give.

Yes it seems no language is perfect.

 

[Paul]

On 15/03/2011 00:49, Paul wrote:

On 14/03/2011 23:26, Paul wrote:

On 14/03/2011 19:30, Alf P. Steinbach /Usenet wrote:
* MikeP, on 14.03.2011 18:49:
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?

Well that's a relief. Now that I've read the thread posts and the
links
to other threads, I see I have not been doing anything wrong by
preferring unsigned where it seems natural to do so. The biggie
points
(for me) are:

1. C++ conversion rules are at the core of the problem.

Yes, right.

Another core issue is monkey-see-monkey-do habits & ideas, that is,
habits & ideas that are not founded in real understanding but are
just
mindlessly adopted from some other context where they *are*
meaningful.

I.e., that what's meaningful in e.g. Pascal (guaranteed range
checking,
advantage) isn't meaningful in C++ (guaranteed lack of range
checking,
disadvantage of adopting Pascal habits & ideas).


2.Mixing signed/unsigned inadvertently is not that big of a
problem
given
that most compilers emit a warning upon such.

This is, however, wrong.

Particularly so since the Google coder's note speaks of
"arithmetical
places".

Compilers generally warn about comparisions between signed and
unsigned,
but can't warn you of equally-or-more dangerous arithmetic
constructs.


3. Using signed where unsigned is a better fit, loses semantic
value.

Yes, right.

And it's even worse: using signed where unsigned is a better fit
(namely
for bit-level operations), can easily yield Undefined Behavor.

And vice versa, using unsigned where signed is a better fit (namely
for
numerical stuff) loses semantic value and can far too easily
introduce
bugs.

Bullshit. The concept of a value which is never negative is not
orthogonal to "numerical stuff"; unsigned integral types are not
just
for bitwise operations: std::size_t is not normally used in bitwise
operations but it is nevertheless an unsigned integral type.

It's not bullshit, it's a valid opinion that many people agree with.
Your concept of a value which is never negative is not necessarily
the
same as everyone elses, for example you think an array can never be
negative but it can be.

double* arr = new double[3];
++arr;
arr is the name/identifier that is used to access the array object.
It's perfectly acceptable to offset the pointer to access the array
with
non-zero based indexing. Many algorithms and mathematical functions
benefit from this type of functionality.
You attempt to say the C++ standards disallows this is an attempt to
twist the wording to support your own argument.

If you cannot understand the benefits of non-based array indexing,
then
I suggest you are a complete idiot because I'm pretty sure you
unreasonably trying to twist things to suit your argument. And if you
really do think an array cannot be non-zero based then you are a
complete idiot.


Keep up: we have already come to the conclusion that negative C++
array indices are UB; C++ array indexing and pointer arithmetic
*within* an array are not necessarily semantically identical as a
pointer to an array element is not equivalent to an array unless it is
pointing to the first array element and as evidenced by the behaviour
exhibited by various versions of g++.

From the C++ standard:
"The expression E1[E2] is identical (by definition) to *((E1)+(E2))."

Give up , you've failed.


From the C++ standard:

"if E1 is an array and E2 an integer, then E1[E2] refers to the E2-th
member of E1"

I've failed? Obviously not. You've failed? Of course.

You obviously seem to think that says something other than it does. It
has already been proved by others that your quote is inaccurrate. Yes
you failed go back to bed.

What has been proven by others exactly? How can a verbatim quote be
inaccurate? It is either a quote or it isn't. Fool.

Others agree with me that negative C++ array indices are UB.

I think you mean "other" singular. If he thinks this then he is also wrong ,
it's not UB to offset a pointer to an array:
"The expression E1[E2] is identical (by definition) to *((E1)+(E2))."
The C++ standard defines array indexing as pointer offsetting. I guess the
C++ standard itself is producing UB in your mind. Get a grip you idiot.