size_t

[Doug Mika]

I found this on a discussion group, and it said that the following will cause an infinite loop, but why?

for (size_t i = strlen (str) - 1; i >= 0; i--){
...
}

[Wouter van Ooijen]

Doug Mika schreef op 05-Jun-15 om 8:25 PM:

> I found this on a discussion group, and it said that the following will cause an infinite loop, but why?
>
> for (size_t i = strlen (str) - 1; i >= 0; i--){
> ...
> }
>

siez_t is likely to be (I dunno, it might even be required to be) an
unsigned type. An unsigned variable will always be >= 0.

Wouter

[Scott Lurndal]

size_t is an unsigned type, it can never be negative.

[Doug Mika]

But of course, for the loop to stop we need to fall below 0, which is not going to be possible with size_t as our data type...I should have looked at it closer.

[Mel]

size_t is unsigned...

--
Press any key to continue or any other to quit

[Jens Thoms Toerring]

Since size_t is an unsigned integer type (what type exactly
doesn't matter, the 'unsigned' bit is the important thing)
it will "wrap around if the value is 0 and you subtract 1
(or any other number), thus resulting in a value that is
still larger or equal to 0 (in the case of subtracting 1 the
result is the largest value that can be stored in a size_t).
So this is indeed an infinite loop (unless there's something
in the body of the loop that gets you out of it, of course).

Regards, Jens
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de

[Mr Flibble]

The solution is the arrow idiom but can you spot the arrow?

#include <iostream>
#include <string>

int main()
{
std::string str = "Hello, World!";
for (size_t i = str.size(); i--> 0;)
{
std::cout << str[i];
}
std::cout << std::endl;
}

/Flibble

[gwowen]

Ugh. Even:

for (size_t i = str.size(); i+1 > 0; --i)}

}

even better than that monstrosity. "Idioms" that arise to work around braindead design choices (e.g. an unsigned type as a decreasing index).

The real solution -- that results in actually readable code rather than reliance on an ugly "idiom" -- is simply use an unsigned type for decreasing index unless you can absolutely help it. 31 bits of indices are enough for anyone.

[Mel]

On Mon, 8 Jun 2015 05:52:49 -0700 (PDT), gwowen <gwo...@gmail.com>
wrote:

> On Friday, June 5, 2015 at 9:41:32 PM UTC+1, Mr Flibble wrote:
> > On 05/06/2015 19:25, Doug Mika wrote:
> > > I found this on a discussion group, and it said that the
following will cause an infinite loop, but why?
> > >
> > > for (size_t i = strlen (str) - 1; i >= 0; i--){
> > > ...
> > > }
> > >
> >
> > The solution is the arrow idiom but can you spot the arrow?
> >
> > #include <iostream>
> > #include <string>
> >
> > int main()
> > {
> > std::string str = "Hello, World!";
> > for (size_t i = str.size(); i--> 0;)
> > {
> > std::cout << str[i];
> > }
> > std::cout << std::endl;
> > }
> >
> > /Flibble


> Ugh. Even:


> for (size_t i = str.size(); i+1 > 0; --i)}


> }


> even better than that monstrosity. "Idioms" that arise to work
around braindead design choices (e.g. an unsigned type as a
decreasing index).

Nope, it is not better as indice have to be subtracted..

[David Brown]

Do you mean you need to write this?

for (size_t i = str.size(); i + 1 > 0; --i) {
std::cout << str[i - 1];
}

It's a little inconvenient, but IMHO it is still better than the "arrow
idiom". But for such code, I'd rather write:

size_t i = str.size();
while (i--) {
std::cout << str[i];
}

(Yes, I know that "--i" is more common in C++, and "i--" looks like C -
but it's find to use it when it makes sense.)

If I see a "for" loop that doesn't have all three sections (or even
worse, has multiple comma-separated sub-sections), I usually switch to a
while loop.

[gwowen]

On Monday, June 8, 2015 at 2:22:54 PM UTC+1, David Brown wrote:
> Do you mean you need to write this?
>
> for (size_t i = str.size(); i + 1 > 0; --i) {
> std::cout << str[i - 1];
> }

Actually, somewhere between the two...

Either
for (size_t i = str.size(); i > 0; --i) {

std::cout << str[i - 1];
}

or

for (size_t i = str.size()-1; i+1 > 0; --i) {
std::cout << str[i];

}



> It's a little inconvenient, but IMHO it is still better than the "arrow
> idiom".

I agree.

> size_t i = str.size();
> while (i--) {
> std::cout << str[i];
> }

That's better. I may even go for:
while (i) {
i -= 1;
std::cout << str[i];
}

but that's just personal preference. (I have a thing against testing ++i or i++ because although I know the difference, I have to consciously recall it, and that makes the code less readable. I assume YM does V.)

> If I see a "for" loop that doesn't have all three sections (or even
> worse, has multiple comma-separated sub-sections), I usually switch to a
> while loop.

Me too. I don't care for piling up multiple non-trivial termination/initialisation conditions inside the for(...), though I'm OK with relatively trivial things like

for(i = 0, a = &arr1, b=&arr2 ; i < 10 ; ++i, ++a, ++b)
{

}

[gwowen]

On Monday, June 8, 2015 at 4:21:14 PM UTC+1, Stefan Ram wrote:

> gwowen writes:
> >Ugh. Even:
> >for (size_t i = str.size(); i+1 > 0; --i)}
>

> #include <climits>
>
> And what is the value of i+1,
> when str.size() == SIZE_MAX?

If you ever manage to find a system on which one can generate a string with

str.size() == SIZE_MAX;

we can both find out. Disregarding address-space exhaustion (extremely likely,but I guess not totally theoretically impossible), the need store the terminating the null character for str.c_str() means you'd have an object of size SIZE_MAX + 1. So, NOT A THING.

So until then, its a total irrelevance to the act of programming; an "Angels on the head of a pin" question.

... shakes head sadly ...

[Mr Flibble]

On 08/06/2015 17:10, Stefan Ram wrote:
> Newsgroups: comp.lang.c++,comp.lang.c
>
> r...@zedat.fu-berlin.de (Stefan Ram) writes:

>> gwowen <gwo...@gmail.com> writes:
>>> Ugh. Even:
>>> for (size_t i = str.size(); i+1 > 0; --i)}

>> #include <climits>
>> And what is the value of i+1,
>> when str.size() == SIZE_MAX?
>

> . Maybe we can get rid of the addition by:
>
> for( size_t i = str.size() - 1; i !=( size_t )-1; --i )
>
> ?

Just use the arrow idiom as it works, has no horrible casts, doesn't
involve modulo arithmetic that you have to scratch your head to work out
what it is doing and is more efficient than gwowen's nonsense.

/Flibble

[Victor Bazarov]

On 6/8/2015 11:11 AM, gwowen wrote:
> On Monday, June 8, 2015 at 2:22:54 PM UTC+1, David Brown wrote:

>> [...]

>> size_t i = str.size();
>> while (i--) {
>> std::cout << str[i];
>> }
>
> That's better. I may even go for:
> while (i) {
> i -= 1;
> std::cout << str[i];
> }
>
> but that's just personal preference. (I have a thing against testing
++i or i++ because although I know the difference, I have to consciously
recall it, and that makes the code less readable. I assume YM does V.)

Idiosyncrasy? When I see

i -= 1;

instead of

--i;

I can only think, as an old lady puts it, "everybody has their own
cockroaches in their head". Consciously recall what about what? It's a
decrement, FCOL, and nothing else.

There is no difference between --i and i-- if that's _the entire_
statement, is there? Of course, there is no difference between those
and i-=1 , as well. Yet I've seen people define such a useful function:

void decrement(int & i) { --i; }

and I always wondered as to their motivation (or sanity, for that
matter). But don't let's go exploring those murky depths, please.

V
--
I do not respond to top-posted replies, please don't ask

[Victor Bazarov]

On 6/8/2015 12:10 PM, Stefan Ram wrote:
> Newsgroups: comp.lang.c++,comp.lang.c
>
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> gwowen <gwo...@gmail.com> writes:

>>> Ugh. Even:
>>> for (size_t i = str.size(); i+1 > 0; --i)}

>> #include <climits>
>> And what is the value of i+1,
>> when str.size() == SIZE_MAX?
>
> . Maybe we can get rid of the addition by:
>
> for( size_t i = str.size() - 1; i !=( size_t )-1; --i )
>
> ?
>

> Newsgroups: comp.lang.c++,comp.lang.c

Why, FCOL? str.size() is hardly valid C code... (yes, I know of the
possibility of having structure members that are pointers to functions)

[Mr Flibble]

On 08/06/2015 16:11, gwowen wrote:
> On Monday, June 8, 2015 at 2:22:54 PM UTC+1, David Brown wrote:
>> Do you mean you need to write this?
>>
>> for (size_t i = str.size(); i + 1 > 0; --i) {
>> std::cout << str[i - 1];
>> }
>
> Actually, somewhere between the two...
>
> Either
> for (size_t i = str.size(); i > 0; --i) {
> std::cout << str[i - 1];
> }
>
> or
>
> for (size_t i = str.size()-1; i+1 > 0; --i) {
> std::cout << str[i];
> }
>
>
>
>> It's a little inconvenient, but IMHO it is still better than the "arrow
>> idiom".

Nothing wrong with the arrow idiom.

>
> I agree.
>
>> size_t i = str.size();
>> while (i--) {
>> std::cout << str[i];
>> }
>
> That's better. I may even go for:
> while (i) {
> i -= 1;
> std::cout << str[i];
> }

What, needlessly increasing the scope of a loop counter is better? Don't
think so mate.

/Flibble

[Scott Lurndal]

gwowen <gwo...@gmail.com> writes:
>On Monday, June 8, 2015 at 2:22:54 PM UTC+1, David Brown wrote:
>> Do you mean you need to write this?
>>
>> for (size_t i = str.size(); i + 1 > 0; --i) {
>> std::cout << str[i - 1];
>> }
>
>Actually, somewhere between the two...
>
>Either
>for (size_t i = str.size(); i > 0; --i) {
> std::cout << str[i - 1];
>}

Or:
for (ssize_t i = str.size()-1; i >= 0; i--) {
std::cout << str[i];
}

[Richard]

[Please do not mail me a copy of your followup]

sl...@pacbell.net spake the secret code
<Damdx.1$dm...@fx17.iad> thusly:

>Or:
> for (ssize_t i = str.size()-1; i >= 0; i--) {
> std::cout << str[i];
> }

Did you mean size_t instead of ssize_t?

Because size_t is unsigned, this is an infinite loop.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[David Brown]

On 09/06/15 00:50, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> sl...@pacbell.net spake the secret code
> <Damdx.1$dm...@fx17.iad> thusly:
>
>> Or:
>> for (ssize_t i = str.size()-1; i >= 0; i--) {
>> std::cout << str[i];
>> }
>
> Did you mean size_t instead of ssize_t?
>
> Because size_t is unsigned, this is an infinite loop.
>

ssize_t is a signed version of size_t. It is not part of the C
standards, but is (I think) in posix.

[Scott Lurndal]

legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>sl...@pacbell.net spake the secret code
><Damdx.1$dm...@fx17.iad> thusly:
>
>>Or:
>> for (ssize_t i = str.size()-1; i >= 0; i--) {
>> std::cout << str[i];
>> }
>
>Did you mean size_t instead of ssize_t?
>
>Because size_t is unsigned, this is an infinite loop.

I meant "ssize_t" of course, since it is a signed type.

[Scott Lurndal]

It was added to POSIX/SUS to accomodate interfaces that returned
a negative value of one on error a quarter of a century ago.

Now the standard actually requires ssize_t to support the range
[-1, {SSIZE_MAX}], but in practice, no modern implementation
supports only a single negative value (this wording was added
due to one, no longer available, implementation when we added
ssize_t), and in any case, that constraint is sufficient for the
aforementioned loop.

The competent programmers at microsoft defined it as unsigned in Visual Studio 2010,
which may have put some people off using it (subsequently fixed).

[bartek]

On 05.06.2015 20:39, Doug Mika wrote:
> On Friday, June 5, 2015 at 1:33:30 PM UTC-5, Wouter van Ooijen wrote:
>> Doug Mika schreef op 05-Jun-15 om 8:25 PM:
>>> I found this on a discussion group, and it said that the following will cause an infinite loop, but why?
>>>
>>> for (size_t i = strlen (str) - 1; i >= 0; i--){
>>> ...
>>> }
>>>
>>
>> siez_t is likely to be (I dunno, it might even be required to be) an
>> unsigned type. An unsigned variable will always be >= 0.
>>
>> Wouter
>
> But of course, for the loop to stop we need to fall below 0,

Not nesesery

for (size_t i = strlen (str) - 1; i < strlen (str); i--){
...
}

;-)

bartekltg

[asetof...@gmail.com]

Mr Flibble wrote:"

The solution is the arrow idiom but can you spot the arrow?

#include <iostream>
#include <string>

int main()
{
std::string str = "Hello, World!";
for (size_t i = str.size(); i--> 0;)
{
std::cout << str[i];
}
std::cout << std::endl;
}"

int main()
{std::string str = "Hello, World!";

size_t i, j;
i=str.size();
if(i)
for( --i; ; --i)
{std::cout << str[i];
if(i==0) break;
}

[Richard]

[Please do not mail me a copy of your followup]

David Brown <david...@hesbynett.no> spake the secret code
<ml60ie$rc3$1...@dont-email.me> thusly:

>ssize_t is a signed version of size_t. It is not part of the C
>standards, but is (I think) in posix.

Well, this is a C++ newsgroup, not C. So please, stop posting C code.

Also, POSIX is not C and is not C++. POSIX is like Win32.

If I posted code that only worked in Win32, you can be sure some people
would complain about my code not being portable. The same goes for
POSIX.

[Scott Lurndal]

legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>David Brown <david...@hesbynett.no> spake the secret code
><ml60ie$rc3$1...@dont-email.me> thusly:
>
>>ssize_t is a signed version of size_t. It is not part of the C
>>standards, but is (I think) in posix.
>
>Well, this is a C++ newsgroup, not C. So please, stop posting C code.

You know, C is still a subset of C++; and it always will be, purists
like yourself notwithstanding.

[David Brown]

On 09/06/15 19:00, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> David Brown <david...@hesbynett.no> spake the secret code
> <ml60ie$rc3$1...@dont-email.me> thusly:
>
>> ssize_t is a signed version of size_t. It is not part of the C
>> standards, but is (I think) in posix.
>
> Well, this is a C++ newsgroup, not C. So please, stop posting C code.
>

Neither I nor anyone else has posted C here - it is all C++. Try asking
a C compiler to accept "str::count << str[i]".


I suppose I could have written "ssize_t is not part of the C++
standards", but C++ gets these sorts of thing from C.

> Also, POSIX is not C and is not C++. POSIX is like Win32.

No, POSIX is widely supported across a range of platforms, including
Windows - Win32 is just for Windows. And POSIX and POSIX headers can be
used with C++, even if they were originally made for C.

You are correct that POSIX is not C or C++ - that is, in fact, exactly
what I wrote. I don't see why you feel the need to repeat it.

>
> If I posted code that only worked in Win32, you can be sure some people
> would complain about my code not being portable. The same goes for
> POSIX.
>

Non-portable code can be relevant in this newsgroup - but should usually
be marked to show that depends on additional features. Perhaps Scott
didn't realise that ssize_t was not portable.

But rather than moan and complain about the use of non-standard types,
and rather than simply misunderstanding the post (as you did by
suggesting Scott meant "size_t" instead of "ssize_t"), you could do like
I did - just point out the facts to clarify the situation.

[Chris Vine]

On Tue, 09 Jun 2015 13:59:41 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:
> It was added to POSIX/SUS to accomodate interfaces that returned
> a negative value of one on error a quarter of a century ago.
>
> Now the standard actually requires ssize_t to support the range
> [-1, {SSIZE_MAX}], but in practice, no modern implementation
> supports only a single negative value (this wording was added
> due to one, no longer available, implementation when we added
> ssize_t), and in any case, that constraint is sufficient for the
> aforementioned loop.
>
> The competent programmers at microsoft defined it as unsigned in
> Visual Studio 2010, which may have put some people off using it
> (subsequently fixed).

ssize_t is poorly implemented in POSIX and has rightly not been
incorporated into either C or C++.

Take the most basic of POSIX functions, namely read(). It takes a
second count argument of type size_t, indicating the maximum number of
bytes that the read buffer can take, and returns a ssize_t type
representing (if positive) the number of bytes read or -1 in case of
error. Because std::size_t/SIZE_MAX is required by the C and C++
standards to be wide enough to take the maximum addressable size of an
object, this means that a call to read() with a count argument greater
than SSIZE_MAX and less than SIZE_MAX will result in an overrun
generating undefined behaviour (§4.7/3). So the typing actually
operates to reduce safety rather than increase it.

ssize_t should generally be avoided where not mandated as part of a
POSIX interface that a program is obliged to use.

Chris

[Richard]

[Please do not mail me a copy of your followup]

sl...@pacbell.net spake the secret code

<LyFdx.46275$Ly1....@fx14.iad> thusly:

>You know, C is still a subset of C++; and it always will be, purists
>like yourself notwithstanding.

Not really. nullptr is not a keyword in C, but it is a keyword in C++.

We're talking about POSIX, which is neither a part of the C standard nor
is it part of the C++ standard, so the whole idea of "C being a subset
of C++" is irrelevant.

[asetof...@gmail.com]

I wrote:"
int main()
{std::string str = "Hello, World!";
size_t i, j;
i=str.size();
if(i)
for( --i; ; --i)
{std::cout << str[i];
if(i==0) break;
}
"

#define R return
#define P printf
#define G(a,b) if(a) goto b

size_t i, j;
i=strlen(s); j=i;
G(i==-1, l3);
G(1, l2);
l1: --i; P("%c", s[i]);
l2: G(i, l1);
l3: R j;

[Lőrinczy Zsigmond]

On 2015.06.05. 20:25, Doug Mika wrote:
> I found this on a discussion group, and it said that the following will cause an infinite loop, but why?
>
> for (size_t i = strlen (str) - 1; i >= 0; i--){
> ...
> }

You've already got countless working and non-working code-snippets,
here is another:

for (size_t i= strlen(str)+1; --i;) {
process (str[i]);
}

[Scott Lurndal]

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
>On Tue, 09 Jun 2015 13:59:41 GMT
>sc...@slp53.sl.home (Scott Lurndal) wrote:
>> It was added to POSIX/SUS to accomodate interfaces that returned
>> a negative value of one on error a quarter of a century ago.

>>=20

>> Now the standard actually requires ssize_t to support the range
>> [-1, {SSIZE_MAX}], but in practice, no modern implementation
>> supports only a single negative value (this wording was added
>> due to one, no longer available, implementation when we added
>> ssize_t), and in any case, that constraint is sufficient for the
>> aforementioned loop.

>>=20

>> The competent programmers at microsoft defined it as unsigned in
>> Visual Studio 2010, which may have put some people off using it
>> (subsequently fixed).
>
>ssize_t is poorly implemented in POSIX and has rightly not been
>incorporated into either C or C++.
>
>Take the most basic of POSIX functions, namely read(). It takes a
>second count argument of type size_t, indicating the maximum number of
>bytes that the read buffer can take, and returns a ssize_t type
>representing (if positive) the number of bytes read or -1 in case of
>error. Because std::size_t/SIZE_MAX is required by the C and C++
>standards to be wide enough to take the maximum addressable size of an
>object, this means that a call to read() with a count argument greater
>than SSIZE_MAX and less than SIZE_MAX will result in an overrun

>generating undefined behaviour (=C2=A74.7/3). So the typing actually

>operates to reduce safety rather than increase it.
>
>ssize_t should generally be avoided where not mandated as part of a
>POSIX interface that a program is obliged to use.
>

The abstract type ssize_t was added long after the interfaces which
used it were defined (e.g. the read(2) system call return value was
defined as a 16-bit signed integer in V6 (late 70's)). When 32-bit
systems became prevalent, int was extended to 32-bits (not without
some painful work fixing broken apps). Meanwhile, X/Open, POSIX, etc.
needed to abstract the return type for read, write et. alia to allow
for future software portability[*], and because legacy software needed
to see -1 as a return code from read on error, an abstract type
(ssize_t) was defined.

ssize_t "This is intended to be a signed analog of size_t. The
wording is such that an implementation may either choose
to use a longer type or simply to use the signed version
of the type that underlies size_t. All functions that
return ssize_t {read() and write()} describe as
'implementation defined' the result of an input exceeding
{SSIZE_MAX}. It is recognized that some implementations
might have 'int' that are smaller than size_t. A portable
application would be constrained to not perform I/O in
pieces larger than {SSIZE_MAX}, but a portable application
using extensions would be able to use the full range if
the implementation provided an extended range, while still
having a single type-compatible interface."
[P1003.4/D14.1 May 1993]

This has been well-known for a quarter century.

Given {SSIZE_MAX} on modern 64-bit systems, restricting I/O to
{SSIZE_MAX} doesn't seem to be a limiting constraint.

Without changing 20+ years of legacy unix code, there was no other
solution. You can bitch about it all you want, but it is what it is.

[*] http://www.unix.org/version2/whatsnew/lfs20mar.html

[Scott Lurndal]

legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>sl...@pacbell.net spake the secret code
><LyFdx.46275$Ly1....@fx14.iad> thusly:
>
>>You know, C is still a subset of C++; and it always will be, purists
>>like yourself notwithstanding.
>
>Not really. nullptr is not a keyword in C, but it is a keyword in C++.

Not in the dialect of C++ that I'm required to use. I work in the real
world, not some academic or personal paradise. NULL works in C++11 too.

scott

[Richard]

[Please do not mail me a copy of your followup]

=?UTF-8?B?TMWRcmluY3p5IFpzaWdtb25k?= <nos...@for.me> spake the secret code
<ml8acf$qfa$1...@speranza.aioe.org> thusly:

Also wrong (and please stop using C string functions, they are nothing
but a source of trouble):

#include <iostream>
#include <string>

int main()
{

std::string s("foo");

for (std::size_t i = s.length()+1; --i;) {
std::cout << "i: " << i << ", '" << s[i] << "'\n";
}
return 0;
}

output:

i: 3, '\000'
i: 2, 'o'
i: 1, 'o'

[Richard]

[Please do not mail me a copy of your followup]

sl...@pacbell.net spake the secret code

<RsYdx.88355$L81....@fx30.iad> thusly:

>legaliz...@mail.xmission.com (Richard) writes:
>>[Please do not mail me a copy of your followup]
>>
>>sl...@pacbell.net spake the secret code
>><LyFdx.46275$Ly1....@fx14.iad> thusly:
>>
>>>You know, C is still a subset of C++; and it always will be, purists
>>>like yourself notwithstanding.
>>
>>Not really. nullptr is not a keyword in C, but it is a keyword in C++.
>
>Not in the dialect of C++ that I'm required to use.

That's your problem, not mine. The addition of the keyword nullptr to
the language is certainly not some academic pedantry.

>NULL works in C++11 too.

Except for where it doesn't and then you *need* nullptr. It wasn't a
gratuitous addition to the language, it really is necessary.

I *think* this is the video where Stephan T. Lavavej explains this:
<http://channel9.msdn.com/Shows/Going+Deep/Stephan-T-Lavavej-Everything-you-ever-wanted-to-know-about-nullptr>

[Lőrinczy Zsigmond]

Thank you for testing it,
you are right, we still have to subtract one
which makes it in-elegant:

for (size_t i= strlen(str)+1; --i;) {

process (str[i-1]);
}

[Scott Lurndal]

legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>sl...@pacbell.net spake the secret code
><RsYdx.88355$L81....@fx30.iad> thusly:
>
>>legaliz...@mail.xmission.com (Richard) writes:
>>>[Please do not mail me a copy of your followup]
>>>
>>>sl...@pacbell.net spake the secret code
>>><LyFdx.46275$Ly1....@fx14.iad> thusly:
>>>
>>>>You know, C is still a subset of C++; and it always will be, purists
>>>>like yourself notwithstanding.
>>>
>>>Not really. nullptr is not a keyword in C, but it is a keyword in C++.
>>
>>Not in the dialect of C++ that I'm required to use.
>
>That's your problem, not mine.

To be perfectly frank, I _don't_ see it as a problem. You do.

You keep harping on "C" as if it were some evil. Only in your
mind is that actually the case. The real world, where programmers
get paid for writing production code, doesn't care a fig about
purity of C++. Maintainability, Reliability[*], yes. Purity forgetaboutit.

>The addition of the keyword nullptr to
>the language is certainly not some academic pedantry.

Nonetheless, C++ has existed for a quarter of a century without it.

[*] Neither of these _require_ pure C++. It may make reliability
slightly better (although at the expense of maintainability).

[Richard]

[Please do not mail me a copy of your followup]

sl...@pacbell.net spake the secret code

<7OZdx.48366$_o7....@fx05.iad> thusly:

>You keep harping on "C" as if it were some evil.

C code in C++ code bases is the source of many AVOIDABLE bugs. This
has been demonstrated to me personally many times by many teams since
the 1990s. It is the repeated advice of Bjarne Stroustrup, the creator
of C++. Just ask around, this isn't just me saying this stuff. This
advice has been deployed in the C++ community for about 20 years, yet
still people keep writing error-prone C code as if it is "OK".

You, of course, can continue to write whatever code you want. But you
do so by intentionally avoiding the general advice of the community and
the advice of the designer of the language.

>Only in your
>mind is that actually the case.

Incorrect.

>The real world, where programmers
>get paid for writing production code, doesn't care a fig about
>purity of C++. Maintainability, Reliability[*], yes. Purity forgetaboutit.

Please show me a post where I have stated anything about "purity".

Maintainability and reliability are directly related to using C++ for
its strengths and avoiding C-isms. This is pretty standard industry
wide consensus everywhere I look: books, conferences, real world
practitioners, attendees at my user group meeting, and even language
detractors. (They show me C style code shoved into a class and say
"see! this is why C++ is error prone!", not realizing that they are
criticizing C and not C++.)

I personally have trained teams for the past 20 years to use C++
mechanisms over C mechanisms and entire categories of bugs disappear
from our code once we stop using C style coding. C style coding *is*
a source of bugs in a C++ code base.

>>The addition of the keyword nullptr to
>>the language is certainly not some academic pedantry.
>
>Nonetheless, C++ has existed for a quarter of a century without it.

Using this sort of logic, you could argue that the entire artifice of
the modern technological world is unnecessary because human beings
existed for millenia without it.

[Ian Collins]

So do I, a real (embedded) world where C++11 is specified in our coding
standard.

> NULL works in C++11 too.

nullptr is there for good reasons.

--
Ian Collins

[Chris Vine]

On Wed, 10 Jun 2015 15:10:44 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
[snip]

I agree with what you say, and particularly that it is unlikely to be an
issue with 64 bit systems at least for the moment, but nonetheless POSIX
interfaces using ssize_t as a return value remain poorly implemented. A
function which returns ssize_t and which takes a size argument
specifying a maximum to which the return value relates should take the
size argument by the same type as the return value or by a type of
smaller range. POSIX does the opposite.

In this respect, POSIX fails to comply with all modern security advice,
the interfaces are broken, ssize_t has not been and never will be
incorporated into C or C++, and ssize_t should (in my opinion, maybe not
yours) be avoided where it is not required in your code by virtue of
the POSIX interfaces it may happen to use.

This mammoth thread just stems from a misunderstanding by the OP that
size_t is unsigned.

Another point you could make and which I would concede is that the same
problems arise with char arrays because ptrdiff_t is signed, but at
least ptrdiff_t does work safely with arrays with element sizes larger
than 1.

Chris

[Christopher Pisz]

On 6/10/2015 11:57 AM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> sl...@pacbell.net spake the secret code
> <7OZdx.48366$_o7....@fx05.iad> thusly:
>
>> You keep harping on "C" as if it were some evil.
>
> C code in C++ code bases is the source of many AVOIDABLE bugs. This
> has been demonstrated to me personally many times by many teams since
> the 1990s. It is the repeated advice of Bjarne Stroustrup, the creator
> of C++. Just ask around, this isn't just me saying this stuff. This
> advice has been deployed in the C++ community for about 20 years, yet
> still people keep writing error-prone C code as if it is "OK".
>
> You, of course, can continue to write whatever code you want. But you
> do so by intentionally avoiding the general advice of the community and
> the advice of the designer of the language.
>
>> Only in your
>> mind is that actually the case.
>
> Incorrect.

My mind too.
...and at least 80 other C++ programmers, I've worked with, that were
worth a poopy.

>> The real world, where programmers
>> get paid for writing production code, doesn't care a fig about
>> purity of C++. Maintainability, Reliability[*], yes. Purity forgetaboutit.
>
> Please show me a post where I have stated anything about "purity".
>
> Maintainability and reliability are directly related to using C++ for
> its strengths and avoiding C-isms. This is pretty standard industry
> wide consensus everywhere I look: books, conferences, real world
> practitioners, attendees at my user group meeting, and even language
> detractors. (They show me C style code shoved into a class and say
> "see! this is why C++ is error prone!", not realizing that they are
> criticizing C and not C++.)
>
> I personally have trained teams for the past 20 years to use C++
> mechanisms over C mechanisms and entire categories of bugs disappear
> from our code once we stop using C style coding. C style coding *is*
> a source of bugs in a C++ code base.
>
>>> The addition of the keyword nullptr to
>>> the language is certainly not some academic pedantry.
>>
>> Nonetheless, C++ has existed for a quarter of a century without it.
>
> Using this sort of logic, you could argue that the entire artifice of
> the modern technological world is unnecessary because human beings
> existed for millenia without it.
>

+1 to everything Richard said.


--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---