Thursday, August 30, 2018

Digest for comp.lang.c++@googlegroups.com - 20 updates in 6 topics

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 30 09:17PM +0100

On 30/08/2018 12:57, Rick C. Hodgin wrote:
> 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.
 
What you call mocking I call satire. Satire is used to ridicule and shine
a light on that which is bad; what is bad in this case is your insistence
on posting off-topic religious posts to a technical newsgroup. If you
don't like the satire then stop with the posts but don't whine about it:
you reap what you sow.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 30 02:15PM -0700

On Thursday, August 30, 2018 at 4:17:49 PM UTC-4, Mr Flibble wrote:
> ...you reap what you sow.
 
So will you, Leigh. I sow seeds of Jesus Christ in the lives
of people around me. Jesus taught we would be mocked, ridiculed,
hated, even killed. It won't stop His love for you and your
soul in action within us.
 
I wear your attacks as badges of honor. Feel free to "satire"
me as you feel is appropriate ... you will only be heaping on
eternal blessing after eternal blessing:
 

https://www.biblegateway.com/passage/?search=Matthew+5%3A11-12&version=KJV
 
11 Blessed are ye, when men shall revile you, and
persecute you, and shall say all manner of evil
against you falsely, for my sake.
 
12 Rejoice, and be exceeding glad: for great is your
reward in heaven: for so persecuted they the prophets
which were before you.
 
Heavenly rewards never abate. They are like the wood in the
burning bush, in use fully, but not consumed.
 
--
Rick C. Hodgin
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Aug 30 03:38PM -0700

On 8/23/2018 9:31 AM, Rick C. Hodgin wrote:
> The rapture will happen soon; the last ones didn't happen because reasons.
 
What happens in the rapture? Will you just drop dead, or disappear?
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Aug 30 03:40PM -0700

On 8/30/2018 4:57 AM, Rick C. Hodgin wrote:
>> 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.
 
Rick C. Hodgin Enterprises?
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 30 09:14PM +0100


> I think you're missing the point that no one is going to bother to use a
> sorting library where they have to do most of the work. It rather defeats
> the point of using a library in the first place.
 
You obviously didn't re-read my article with your brain engaged like I
suggested. What do you mean by "most of the work"? All the user has to do
is write a swapper which is trivial.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
Vir Campestris <vir.campestris@invalid.invalid>: Aug 30 09:37PM +0100

On 29/08/2018 07:14, David Brown wrote:
> 4 clocks per instruction means an IPC of 0.25, not "around 2/3".
 
Brainfart. The thing was IIRC clocked at 4MHz, and so the memory cycle
time was ~1MHz..
 
Sorry. Next time I'll look it up, not rely on decades old memory.
(Except my manuals are in store until next month.)
 
Andy
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 30 09:12PM +0100

On 30/08/2018 06:46, Alf P. Steinbach wrote:
 
> Some variant of this is presumably how `std::sort` is implemented in ~all
> implementations, since it needs to have guaranteed worst case O(n log n),
> and also, at the same time, needs to be quick about it. :)
 
Yes my intrusive_sort uses introsort so it has same complexity guarantees
as std::sort.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
"Öö Tiib" <ootiib@hot.ee>: Aug 30 01:35PM -0700

On Monday, 27 August 2018 16:46:12 UTC+3, Mr Flibble wrote:
 
> intrusive_sort has the same complexity guarantees as std::sort.
 
> https://github.com/i42output/neolib/blob/master/include/neolib/intrusive_sort.hpp
 
Nice. Doing that with std::sort is tricky because it does move
the elements instead of swapping those.
boltar@cylonHQ.com: Aug 30 01:59PM

On Thu, 30 Aug 2018 15:05:05 +0200
>> 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.
 
Compiler writers need to accept the reality that C/C++ coders mix and match
C and C++ code in the same source. If its valid in C99 then a C++ compiler
should compile it especially if it does so in another mode already. Plus as
you say gcc is perfectly happy to compile some other C99 syntax. C99 has
been out 19 years, it really shouldn't be considered something new or exotic
any more.
"Öö Tiib" <ootiib@hot.ee>: Aug 30 01:05PM -0700

On Thursday, 30 August 2018 14:24:48 UTC+3, James Kuyper wrote:
 
> >> 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.
 
Thanks.
 
> 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.
 
My low knowledge is because I avoid using VLAs even in C. Also I would
continue avoiding if those were added to C++. But ... I would not protest
either if others desire such a feature.
 
My reason is that existence of automatic storage limits and breaking
those is undefined behavior that C++ standard avoids addressing.
Automatic storage is faster but usually more limited resource than
dynamic storage. Also there is std::bad_alloc that makes exceeding
dynamic storage limits possible to handle. VLA would add another
unknown factor to risk of breaking automatic storage limits. That
makes std::vector safer buffer of dynamic dimensions. When the
reason of VLA usage is performance then usually there are safer
ways to improve it.
 
May be I just haven't met a problem for what VLA is best tool.
For example OP problem. In C++ I would expect something like:
 
std::cout << a.submatrix(4, 3, 5, 4);
 
Instead of:
 
num = 10;
print((int(*)[num])(&a[4][3]), 5, 4);
David Brown <david.brown@hesbynett.no>: Aug 30 10:14PM +0200

>> not valid C++, so there is nothing absurd about it.
 
> Compiler writers need to accept the reality that C/C++ coders mix and match
> C and C++ code in the same source.
 
They do, sometimes. But such programmers write in a common subset of
versions of C and C++ (say, C99 and C++11) - and VLAs are not in that
common subset. They might, in some cases, write in the common subset of
gcc-C and gcc-C++ versions (like gnu11 and gnu++14) - that could include
some uses of VLAs. Equally, they could use a common set matching a
different specific compiler.
 
> If its valid in C99 then a C++ compiler
> should compile it especially if it does so in another mode already.
 
You could equally well say that if it is valid C++11, then a C11
compiler should handle it in C since the compiler can already handle it
in C++. That would be nonsense just the same.
 
C is not a subset of C++. It is /close/ to a subset, but not an exact one.
 
> you say gcc is perfectly happy to compile some other C99 syntax. C99 has
> been out 19 years, it really shouldn't be considered something new or exotic
> any more.
 
If people had really wanted this particular form of VLAs in their C++
code, I am sure the gcc team would have allowed it as an extension. If
you feel strongly that it is a feature you would like to see in C++
modes of gcc, then the way forward is to file a bug in gcc asking for
the missing feature. If other people agree with you, and it is as
simple to support as you think, then maybe it will get added. It is
certainly a more likely way to get the feature than posts here!
woodbrian77@gmail.com: Aug 30 08:06AM -0700

On Monday, April 3, 2017 at 8:14:46 AM UTC-5, Chris Vine wrote:
> circumstances in which a file descriptor is spuriously reported as
> ready. Thus it may be safer to use O_NONBLOCK on sockets that should
> not block."
 
I've got Linux 4.14 and my docs for select() have the above text,
but the docs for poll() don't. I'm not sure why this doesn't get
fixed and not sure if this problem is confined to select() or also
affects poll().
 
> are doing asynchronous i/o you must cater for EAGAIN and EWOULDBLOCK so
> it doesn't really matter if very occasionally select() gives you
> one more EAGAIN than you were expecting.
 
In one of my programs I was able to stop using poll() as there's
only one socket involved. I'm still using poll(), though, in
this program:
https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc
 
so would like to know if I should take some defensive
measures related to this. FreeBSD seems to be free of
these problems.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
woodbrian77@gmail.com: Aug 30 08:26AM -0700

> but the docs for poll() don't. I'm not sure why this doesn't get
> fixed and not sure if this problem is confined to select() or also
> affects poll().
 
I was looking at docs in the "3P" section on poll() -- I guess
the 'P' may stand for Posix. When I checked poll() in another
section, there's a note referring you to select() spurious bugs.
So I guess this is still a problem for poll().
Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 30 04:49PM

>> affects poll().
 
> I was looking at docs in the "3P" section on poll() -- I guess
> the 'P' may stand for Posix.
 
Yes, and I think the man page states so clearly. Another hint is that
it's written in Legalese.
 
> When I checked poll() in another
> section, there's a note referring you to select() spurious bugs.
> So I guess this is still a problem for poll().
 
Yes, and also for epoll(7). The problem/feature is in the kernel code
that's underlying for all these functions.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 30 01:35PM

On Thu, 2018-08-30, Fraser Ross wrote:
 
> 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.
 
Let's assume the range is [2, 6), i.e. [2, 3, 4, 5].
Then it should copy 5, 4, 3, 2, i.e.
 
starting from 5 = 6-1 = last-1
proceeding to 2 = first
 
Looks correct to me.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Fraser Ross <fraser.ross8ATbtinternet.com@com>: Aug 30 03:01PM +0100

On 30/08/2018 14:35, Jorgen Grahn wrote:
> proceeding to 2 = first
 
> Looks correct to me.
 
> /Jorgen
 
In C++ an end iterator points one past the last element. The algorithm
descriptions would be better understood if the convention was stuck to.
 
Fraser.
Fraser Ross <fraser.ross8ATbtinternet.com@com>: Aug 30 03:02PM +0100

On 30/08/2018 14:35, Jorgen Grahn wrote:
> proceeding to 2 = first
 
> Looks correct to me.
 
> /Jorgen
 
In C++ an end iterator points one past the last element. The algorithm
descriptions would be better understood if the convention was stuck to.
 
Fraser.
jameskuyper@alumni.caltech.edu: Aug 30 07:22AM -0700

On Thursday, August 30, 2018 at 10:01:20 AM UTC-4, Fraser Ross wrote:
 
> > /Jorgen
 
> In C++ an end iterator points one past the last element. The algorithm
> descriptions would be better understood if the convention was stuck to.
 
True - but that description describes which objects get copied. No
attempt is supposed to be made to copy the object that the end iterator
refers to, since such an attempt would have undefined behavior.
Fraser Ross <fraser.ross8ATbtinternet.com@com>: Aug 30 03:45PM +0100


> True - but that description describes which objects get copied. No
> attempt is supposed to be made to copy the object that the end iterator
> refers to, since such an attempt would have undefined behavior.
 
It refers to the range of iterators and specific iterators of that range
so I disagree. The wording is done identically to that for copy where
they correctly use the C++ end iterator convention.
 
Fraser.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 30 02:45PM

On Thu, 2018-08-30, Fraser Ross wrote:
 
>> /Jorgen
 
> In C++ an end iterator points one past the last element. The algorithm
> descriptions would be better understood if the convention was stuck to.
 
I think the difference is this: when I read "... proceeding to first"
I don't interpret that in in a "normal" context, as if we've left the
iterator terminology at that point. It didn't occur to me until now that
it could be interpreted differently.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)