Thursday, August 30, 2018

Digest for comp.lang.c++@googlegroups.com - 25 updates in 8 topics

Fraser Ross <fraser.ross8ATbtinternet.com@com>: Aug 30 01:12PM +0100

In the standard it says "Copies elements in the range [first, last) into
the range [result - (last-first), result) starting from last - 1 and
proceeding to first."
 
I think it should say proceeding to first - 1. first - 1 would refer to
the iterator one past the end. The same mistake is made with
move_backward. There is also inconsistency with fonts and boldness for
these expressions.
 
Fraser.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 30 03:30PM +0200

On 30.08.2018 14:12, Fraser Ross wrote:
> the iterator one past the end.  The same mistake is made with
> move_backward.  There is also inconsistency with fonts and boldness for
> these expressions.
 
The author (Richard?) must have meant the inclusive "to". We could avoid
most of these implicit appeals to common sense by making that appeal
explicit: "to first, or thereabouts, whatever". One reason I like that
idea very much is that while it would work nicely for programmers it
could and hopefully would give the Language Lawyers™ the fits.
 
Cheers!,
 
- Alf
jerry.jeremiah@gmail.com: Aug 29 07:13PM -0700

Hello all,
 
I am curious If the code presented below causes UB in C++. I know the original question was about C but I am specifically asking about C++.
 
Thanks very much.
 
Jerry
 
https://stackoverflow.com/a/34626013/2193968
 
#include <stdio.h>

int num;

void print( int a[][num], int row, int col )
{
int i, j;
for(i = 0; i < row; i++)
{
for(j = 0; j < col; j++)
printf("%3d ", a[i][j]);
printf("\n");
}
}


int main()
{
int a[10][10];
int i, j;

for(i = 0; i < 10; i++)
for(j = 0; j < 10; j++)
a[i][j] = i*10+j;

num = 10;
print(a, 10, 10);

printf("\n\n");

print((int(*)[num])(&a[4][3]), 5, 4);

return 0;
}
"Öö Tiib" <ootiib@hot.ee>: Aug 29 08:07PM -0700

> the original question was about C but I am specifically asking about C++.
 
> Thanks very much.
 
> Jerry
 
It is hard to tell because presented code should not compile as C++.
 
 
> #include <stdio.h>
 
> int num;
 
> void print( int a[][num], int row, int col )
 
That does not make sense in C++. Array dimension must be constant
expression not uninitialized int num. Is that really allowed in C?
 
James Kuyper <jameskuyper@alumni.caltech.edu>: Aug 30 12:09AM -0400

On 08/29/2018 11:07 PM, Öö Tiib wrote:
 
>> void print( int a[][num], int row, int col )
 
> That does not make sense in C++. Array dimension must be constant
> expression not uninitialized int num. Is that really allowed in C?
 
Yes, it is. It's called a variable length array. It was added in C99.
Sam <sam@email-scan.com>: Aug 30 07:01AM -0400

James Kuyper writes:
 
 
> > That does not make sense in C++. Array dimension must be constant
> > expression not uninitialized int num. Is that really allowed in C?
 
> Yes, it is. It's called a variable length array. It was added in C99.
 
Ok, but this is C++, and not C.
 
No self-respecting C++ compiler would accept this code.
boltar@cylonHQ.com: Aug 30 11:16AM

On Thu, 30 Aug 2018 07:01:12 -0400
 
>> Yes, it is. It's called a variable length array. It was added in C99.
 
>Ok, but this is C++, and not C.
 
>No self-respecting C++ compiler would accept this code.
 
Clang seems happy with it but not g++, which is absurd since gcc compiles
it without a problem in C mode.
 
Its unfortunate syntax like this which would be useful on a daily basis isn't
included in the C++ standard whereas the standards committee are quite happy
to constantly chuck in obscure irrelevant nonsense (eg user literals) or
reinventing the wheel (eg using aliases instead of typedef) that 99% of coders
will never use.
James Kuyper <jameskuyper@alumni.caltech.edu>: Aug 30 07:24AM -0400

On 08/30/2018 07:01 AM, Sam wrote:
>>> expression not uninitialized int num. Is that really allowed in C?
 
>> Yes, it is. It's called a variable length array. It was added in C99.
 
> Ok, but this is C++, and not C.
 
Öö asked explicitly about C, so I answered about C.
 
> No self-respecting C++ compiler would accept this code.
 
Perhaps - I suppose that depends upon how they go about respecting
themselves. However, a fully standard conforming implementation of C++
is allowed to accept it, after issuing the required diagnostic. C++ code
could use a container class to achieve the same practical effect, and in
many ways that would be a better solution - but VLAs provide a
conceptually simpler way to do it, and I have seen people express a
desire to add them to C++, even if only as an implementation-specific
extension.
David Brown <david.brown@hesbynett.no>: Aug 30 03:05PM +0200


>> No self-respecting C++ compiler would accept this code.
 
> Clang seems happy with it but not g++, which is absurd since gcc compiles
> it without a problem in C mode.
 
gcc compiles C in C mode, and C++ in C++ mode. The code is valid C but
not valid C++, so there is nothing absurd about it.
 
Now, it's fine for a C++ compiler to support VLA's as an extension. gcc
certainly supports some VLA syntax in (non-pedantic) C++ modes - you can
have a local variable that is a VLA, for example. But it looks like
this particular VLA usage is not allowed by gcc in C++ modes - while
clang supports it.
 
> to constantly chuck in obscure irrelevant nonsense (eg user literals) or
> reinventing the wheel (eg using aliases instead of typedef) that 99% of coders
> will never use.
 
I can't imagine any significant use for this particular syntax -
certainly not "on a daily basis". I've used VLA's sometimes in C, as
local variables - they can be a convenient way of making a buffer. The
same usage could apply to C++ (as supported by gcc, as a C++ extension)
as an alternative to having a vector.
 
I would not object to VLA's in C++ - but I can't see it as such a big issue.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 30 01:42AM +0100

On 23/08/2018 17:31, Rick C. Hodgin wrote:
> The rapture will happen soon; the last ones didn't happen because reasons.
 
Please watch this important video about the Rapture which is coming soon
(not like the other raptures):
 
https://www.youtube.com/watch?v=42UCpOzTbNU
 
--
 
Thank you,
Rick C. Hodgin
boltar@cylonHQ.com: Aug 30 09:20AM

On Thu, 30 Aug 2018 01:42:55 +0100
 
>Please watch this important video about the Rapture which is coming soon
>(not like the other raptures):
 
>https://www.youtube.com/watch?v=42UCpOzTbNU
 
Mate, give it rest, no one gives a shit about your medieval beliefs and it
should have been clear by now to anyone with any social intelligence that
you've made yourself a figure of fun on here. Take it to a more appropriate
group.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 30 04:57AM -0700

> should have been clear by now to anyone with any social intelligence that
> you've made yourself a figure of fun on here. Take it to a more appropriate
> group.
 
I didn't write the posts on this thread. Look at the headers.
They are from a mocker making fun of me (Leigh Johnston, aka Mr.
Flibble). He, like you, thinks my teaching posts about Jesus
Christ are a waste of time and something to be mocked. He posts
these mocking posts pretending to be me.
 
I would simply ask this: after the rapture, remember these posts.
You can still be saved in what's coming. Don't take the mark
required to buy or sell, and ask Jesus to forgive your sin and
save you. He will, but what you'll go through during that time
will be much, much harder. You can read about the additional
difficulties in the New Testament, specifically in the book of
Revelation, as that's the only book with things left to be fulfilled
during that post-rapture age.
 
--
Rick C. Hodgin
boltar@cylonHQ.com: Aug 30 12:23PM

On Thu, 30 Aug 2018 04:57:02 -0700 (PDT)
>Flibble). He, like you, thinks my teaching posts about Jesus
>Christ are a waste of time and something to be mocked. He posts
>these mocking posts pretending to be me.
 
It doesn't really matter, the point still stands.
 
>I would simply ask this: after the rapture, remember these posts.
 
People have been predicting the imminent end of the world since time
immemorial. Your prediction will turn out to be just as deluded as all the
others. Reality doesn't care what it says in your religious storybook.
scott@slp53.sl.home (Scott Lurndal): Aug 29 08:48PM

ram@zedat.fu-berlin.de (Stefan Ram) writes:
 
[snip mingw complaints]
 
 
> And when do we get valgrind under Windows?
 
It's available for Windows 10, just install WSL and the
ubuntu distro.
David Brown <david.brown@hesbynett.no>: Aug 30 09:04AM +0200

On 29/08/18 22:16, Stefan Ram wrote:
 
> (Of course, I /am/ grateful to the creators of MinGW that
> something like this is available for Windows at all.)
 
> And when do we get valgrind under Windows?
 
Just to be clear here - are you using gcc from the old
<http://mingw.org/> site, or are you using the much newer and more
powerful <http://mingw-w64.org/doku.php> version?
 
(It is entirely believable that this too has limitations. In
particular, the address sanitizers and leak detection work by fancy
games with virtual memory settings - these techniques may simply not
have equivalents in Windows.)
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 30 11:55AM +0200

On 29.08.2018 22:16, Stefan Ram wrote:
 
> . But with MinGW, a random number generating algorithm
> initialized in this way always seems to produce the same
> sequence (AFAIK).
 
Oh look.
 
<url:
https://github.com/alf-p-steinbach/Wrapped-stdlib/blob/master/source/fix/gcc_random_device.hpp>
 
-------------------------------------------------------------------------
#pragma once // Source encoding: utf-8 with BOM ∩
// #include <stdlib/fix/gcc_random_device.hpp>
 
#ifndef STDLIB_NO_FIX_OF_RANDOM_DEVICE
# ifdef __GNUC__
# undef _GLIBCXX_USE_RANDOM_TR1
# define _GLIBCXX_USE_RANDOM_TR1
# endif
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)