Use != rather than < in for loops ?

[lovecreatesbea...]

In C++ Primer 4th, sec 3.3.2, it states that C++ programmers use !=
rather than < in a for loop.

The following small snippet erases punctuations in a string. It works
well with < used in the for loop but it breaks when != is used instead.

#include <string>
#include <iostream>
#include <exception>
#include <cctype>
using namespace std;

int main(){
string s = "hello, world!";//s: i18n
//for (string::size_t ype sz = 0; sz < s.size(); ++sz){
/*works with < */
for (string::size_t ype sz = 0; sz != s.size(); ++sz){
/*doesn't work with != */
try{
if (ispunct(s.at(s z))){
s.erase(sz, 1);
}
}catch(exceptio n &e){
cout << e.what() << endl;
}
}
cout << s << endl;
}

[Daniel T.]

Julián Albo <JU********@ter ra.eswrote:

Daniel T. wrote:

There is no char '\xFF' in ASCII (which is what ispunct(int) and family
are designed to handle.)

Are you saying that C++ is only intended to machines with ascii compatible
charsets?

I'm saying that the is... functions in <cctypeare intended to be used
only on characters that can be represented using 7 bits. i.e., if
assert( ch & 0x7F == ch || ch == EOF ) fails, then the result returned
by ispunct and family on 'ch' is undefined. As such a cast to unsigned
char is meaningless. Again, I could be wrong on this, but that is my
understanding. If you know of an authoritative source that says the cast
is necessary, I'd love to see it.

There are a separate set of is... functions defined in <localthat can
be used for characters that are represented using more than 7 bits, and
a cast is never needed for any of those.

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

Daniel T. wrote:

I'm saying that the is... functions in <cctypeare intended to be used
only on characters that can be represented using 7 bits. i.e., if

Do you know of an authoritative source that says that? All I have readed is
that the int argument must be EOF or the value of an unsigned char.

--
Salu2

[Daniel T.]

Julián Albo <JU********@ter ra.eswrote:

Daniel T. wrote:

I'm saying that the is... functions in <cctypeare intended to be
used only on characters that can be represented using 7 bits.
i.e., if

Do you know of an authoritative source that says that?

I don't have much in the way of authoritative sources. I was hoping
someone who had the standard could tell us one way or the other.

I did find, "In the C locale or in a locale where character type
information is not defined, characters are classified according to the
rules of the ASCII 7-bit coded character set." (Found at
http://www.mksxserver.com/docs/man3/ispunct.3.asp,
http://www-zeuthen.desy.de/apewww/AP.../ctype_8h.html,
http://ou800doc.caldera.com/en/man/h.../ctype.3C.html et al.)

I have to admit, I know very little about the locale system and fully
expect that those who ask about using ispunct here have not called
setlocale() (a function which is not even mentioned in TC++PL AFAICT.)

TC++PL does make a comment that passing a signed char into the cctype
functions can be problematic but it gives no details.

According to
http://www.dinkumware.com/manuals/?m...age=ctype.html the
only standard (i.e., not-implementation defined) characters that ispunct
will return true for are within the ascii character set. Passing a non
7-bit ASCII character to ispunct seems to be, at best, implementation
spicific.

[Clark S. Cox III]

Daniel T. wrote:

Julián Albo <JU********@ter ra.eswrote:

>Daniel T. wrote:

>>I'm saying that the is... functions in <cctypeare intended to be
used only on characters that can be represented using 7 bits.
i.e., if

Do you know of an authoritative source that says that?

I don't have much in the way of authoritative sources. I was hoping
someone who had the standard could tell us one way or the other.

I did find, "In the C locale or in a locale where character type
information is not defined, characters are classified according to the
rules of the ASCII 7-bit coded character set." (Found at
http://www.mksxserver.com/docs/man3/ispunct.3.asp,
http://www-zeuthen.desy.de/apewww/AP.../ctype_8h.html,
http://ou800doc.caldera.com/en/man/h.../ctype.3C.html et al.)

Those are manpages, specific to particular platforms.

I have to admit, I know very little about the locale system and fully
expect that those who ask about using ispunct here have not called
setlocale() (a function which is not even mentioned in TC++PL AFAICT.)

TC++PL does make a comment that passing a signed char into the cctype
functions can be problematic but it gives no details.

According to
http://www.dinkumware.com/manuals/?m...age=ctype.html the
only standard (i.e., not-implementation defined) characters that ispunct
will return true for are within the ascii character set. Passing a non
7-bit ASCII character to ispunct seems to be, at best, implementation
spicific.

Yes, those characters are all in the ASCII standard, but that doesn't
mean that they have to be represented by the equivalent ASCII values.
here is nothing preventing a conforming C++ implementation on a platform
that uses EBCDIC for instance (which is an 8-bit encoding).
--
Clark S. Cox III
cl*******@gmail .com

[Andrew Koenig]

"Tr0n" <ol*********@ho tmail.comwrote in message
news:eo******** **@aioe.org...

I suppose it really depends on what it is used for - but I still think <
is less error-prone than a != (as any value can be != - while you're
limiting a range using <) .

No -- it's more error-prone, not less, because it makes it easier for errors
to escape undetected.

>In other words, if you use < for index comparisons, you make it easier to
verify that the loop doesn't do anything undefined, but harder to verify
that the loop produces the correct result.

What "correct" result are you after?
The last point in the loop?
.. Surely the data effected by the code inside the loop proves if it is
"correct" or not - and not the result of an incrementing index?

If you wanted the last point using "i != N" then you're after N... Why not
just USE N?

Here is a concrete example of what I'm talking about.

Suppose I want to write a loop that calls f(n) for every value of (integer)
n such that n>=0 and n<N.

Then I might write a loop with an invariant such as

I have called f(n) for every value of n such that n >= 0 and n < i

and initially establish the invariant by writing

i = 0;

This initialization of i establishes the invariant because there are no
values of n that are both >= 0 and < i.

The loop itself might look like this

while (i != N) { /* or i < N */
// increase i while maintaining the invariant
f(i);
++i;
}

Now, suppose we want to prove that this loop does what we intend.
Regardless of whether the loop condition is i != N or i < N, we have to
prove that the loop terminates.

If the condition is i != N, we can't prove that the loop terminates unless
we prove that N >= 0, a fact that you are claiming argues that i < N is
superior.

However, if the condition is i < N, that complicates the second part of the
proof. Because in that case, when the loop does terminate, we do not know
that i == n, which means that instead of proving the original requirement:

we have called f(n) for every value of (integer) n such that n >= 0 and
n < N

we have instead proved

we have called f(n) for every value of (integer) n such that n >= 0 and
n < i, where i is an unknown value >= n

In other words, in exchange for simplifying the proof of termination, we
have complicated the proof of correctness.

I would much rather simplify the proof of correctness, because if for some
reason the program doesn't terminate, we'll surely know about it. In other
words, I'd rather have a program that goes into an infinite loop than one
that quietly produces the wrong answer.

>Personally, I would rather write my programs in a way that makes it
easier to prove correctness.

.. I really don't like that.
Reminds me of all these buffer over-run errors where something unexpected
means CONSTANT bug-fixing.

I have no idea what you're talking about here.

It also reminds me of a current position I have at work, using an un-named
application (I don't think it's my place to name-names) which produced an
endless loop because of some incorrect data.. It took them 3 days to track
this down on a production environment (the data was incorrect for 2 weeks
over the xmas and only produced errors after people started again: adding
to the difficulty).

I actually support the previous posters' paragraph which states "limiting
value N", and "if it is incorrect to execute the loop body if.. i is
greater than N".

I just thought I'd post my thoughts on this, because I'd prefer my code to
do what I program - rather than produce a program which may do 'other
things'.

Exactly. And to be confident that your code does what you program, you
should make it as easy as possible to prove that it does what you intend.

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

Daniel T. wrote:

I did find, "In the C locale or in a locale where character type
information is not defined, characters are classified according to the
rules of the ASCII 7-bit coded character set." (Found at
http://www.mksxserver.com/docs/man3/ispunct.3.asp,
http://www-zeuthen.desy.de/apewww/AP.../ctype_8h.html,
http://ou800doc.caldera.com/en/man/h.../ctype.3C.html et al.)

Those looks like the documentation of an implementation, non a standard
description. And is highly likely that all those implementations are
intended for machines with ascii-compatible character set.

But even in that case, the locale can be not 'C' and can not work as 'C' in
this regard.

I have to admit, I know very little about the locale system and fully
expect that those who ask about using ispunct here have not called
setlocale()

Very nice for your part to ignore all people in the world that use languages
with more characters than the ascii set.

TC++PL does make a comment that passing a signed char into the cctype
functions can be problematic but it gives no details.

A good indication that you should not do it if without a good reason, IMO.

Passing a non 7-bit ASCII character to ispunct seems to be, at best,
implementation spicific.

But passing it as unsigned char, the result will always be the intended by
the user who knows about his locale. Passing it as signed char, maybe not.
An unnecessary risk for no other benefit than avoid to write a few chars in
the source.

--
Salu2

[Daniel T.]

Julián Albo <JU********@ter ra.eswrote:

Daniel T. wrote:

I did find, "In the C locale or in a locale where character type
information is not defined, characters are classified according to the
rules of the ASCII 7-bit coded character set." (Found at
http://www.mksxserver.com/docs/man3/ispunct.3.asp,
http://www-zeuthen.desy.de/apewww/AP.../ctype_8h.html,
http://ou800doc.caldera.com/en/man/h.../ctype.3C.html et al.)

Those looks like the documentation of an implementation, non a standard
description.

Which is why I have been asking someone to look it up in the standard.
TC++PL says that implementation documentation is the authoritative
source.

But even in that case, the locale can be not 'C' and can not work as 'C' in
this regard.

Odd, the documentation I can find for setlocale says that the default
local is "C", "A minimal environment for C-language translation"

I have to admit, I know very little about the locale system and fully
expect that those who ask about using ispunct here have not called
setlocale()

Very nice for your part to ignore all people in the world that use languages
with more characters than the ascii set.

Please, no need to be combative. If one wants to handle languages with
more characters than the ascii set, one is probably better off using
some form of unicode which means all of the functions in cctype are
useless.

I've said more than once that I'm not sure of the correct answer here.
I'm asking what it is. You seem to be sure of the correct answer, but
you haven't produced any authoritative source to back your answer up.

TC++PL does make a comment that passing a signed char into the cctype
functions can be problematic but it gives no details.

A good indication that you should not do it if without a good reason, IMO.

But I'd like to understand the details. Do you know of any source that
explains them? TC++PL says, "discussion of [local conversion between
codesets] is beyond the scope of this book. Please consult your
implementation' s documentation." Well, I did that above for several
implementations . Is this something that is purely implementation defined?

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

Daniel T. wrote:

>Those looks like the documentation of an implementation, non a standard
description.

Which is why I have been asking someone to look it up in the standard.
TC++PL says that implementation documentation is the authoritative
source.

The standard says nothing about the working of the C-inherited functions,
other than some minor variants, and refering to the appropriate C-standard
document.

Please, no need to be combative. If one wants to handle languages with
more characters than the ascii set, one is probably better off using
some form of unicode which means all of the functions in cctype are
useless.

Probably today is a better approach, but there are still a lot of programs
that use 8-bit national charsets. And in may cases a program can be quickly
adapted with a change of locale and rewriting it with unicode support is
not an option. And even using uft-8 encoded unicode some locales can
correctly support several of the is... functions.

>A good indication that you should not do it if without a good reason,
IMO.

But I'd like to understand the details. Do you know of any source that
explains them?

I think the base point is clear: ispunct and family takes and int and
expects it contains the EOF value or the int value of an unsigned char,
passing it a plain char does not grant this expectation. You can check the
man page of some unix system, they are usually less ascii-centric than
other sources, see for example:

http://www.die.net/doc/linux/man/man3/ispunct.3.html

Or refer to the C-standard documents. I don't have it at hand.

And, as others have pointed, the fact that some documents talks about
character presents in the ascii charset, does not necessarily mean that the
ascii encoding is used.

TC++PL says, "discussion of [local conversion between
codesets] is beyond the scope of this book. Please consult your
implementation' s documentation." Well, I did that above for several
implementations . Is this something that is purely implementation defined?

I think this quote refers to more elaborated things than character
classification functions. Chapter and point?

--
Salu2

[Daniel T.]

Julián Albo <JU********@ter ra.eswrote:

Daniel T. wrote:

I think the base point is clear: ispunct and family takes and int and
expects it contains the EOF value or the int value of an unsigned char,
passing it a plain char does not grant this expectation.

Unfortunately, I don't have the C standard either.

>

TC++PL says, "discussion of [local conversion between
codesets] is beyond the scope of this book. Please consult your
implementation' s documentation." Well, I did that above for several
implementations . Is this something that is purely implementation defined?

I think this quote refers to more elaborated things than character
classification functions. Chapter and point?

Section 21.7, the last paragraph.

It seems though, that you are right in that if the programer has any
reason to expect that the 8th bit will be on for any character, he
should cast to unsigned char before passing the char to the cctype
functions.

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

Daniel T. wrote:

TC++PL says, "discussion of [local conversion between
codesets] is beyond the scope of this book. Please consult your
implementation' s documentation." Well, I did that above for several
implementations . Is this something that is purely implementation
defined?

I think this quote refers to more elaborated things than character
classificati on functions. Chapter and point?

Section 21.7, the last paragraph.

This paragraph looks confusing to me (I have a edition in Spanish, but I
think the translation is very good, and the paragraph you quoted confirms
it). Maybe it means "consult (the C++ standard or more specialized books
and) your implementation' s documentation".

--
Salu2