Thursday, September 20, 2018

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

guinness.tony@gmail.com: Sep 20 02:13AM -0700

On Thursday, 20 September 2018 08:41:29 UTC+1, Christian Gollwitzer wrote:
> queue (ˈkjuː) which coincides up to the accent with the verb dequeue
> (diːˈkjuː according to the OED)
 
> Christian
 
Donald Knuth: The Art of Computer Programming, Vol. 1 (Fundamental Algorithms)
 
Section 2.2.1: Stacks, Queues, and Deques
 
"A deque ... has some properties in common with a deck of cards,
and it is pronounced the same way."
Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 20 02:59PM

On Wed, 2018-09-19, David Brown wrote:
> On 19/09/18 22:09, Jorgen Grahn wrote:
...
>> not for BASIC, C#, Ruby. Python: about fifty-fifty.
 
> Basic, ruby and python are all normal English words - how would you
> pronounce them other than as those words?
 
As if they were Swedish words. But you're right -- the English word
"basic" for example is so well known that noone would try to pronounce
it differently except for comic effect.
 
Python is different because there's a word "pyton" for the snakes, and
because Monty Python got local pronounciation back in the 70s.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Bart <bc@freeuk.com>: Sep 20 04:43PM +0100

On 20/09/2018 15:59, Jorgen Grahn wrote:
> it differently except for comic effect.
 
> Python is different because there's a word "pyton" for the snakes, and
> because Monty Python got local pronounciation back in the 70s.
 
That doesn't stop Americans pronouncing it as PyTHON.
 
 
--
bart
Paavo Helde <myfirstname@osa.pri.ee>: Sep 20 07:12PM +0300

On 20.09.2018 18:43, Bart wrote:
 
>> Python is different because there's a word "pyton" for the snakes, and
>> because Monty Python got local pronounciation back in the 70s.
 
> That doesn't stop Americans pronouncing it as PyTHON.
 
Sorry, this is not helpful, I still have no idea how Americans pronounce
it, or how they ought to pronounce it.
 
I'm constantly baffled why people are trying to clarify pronunciation of
a nonphonemic orthography by using the same nonphonemic orthography.
Maybe somebody could write down some variants of "Python" in IPA?
 
For example, "python" (as the snake) is in Estonian written "püüton" and
pronounced "py:ton".
David Brown <david.brown@hesbynett.no>: Sep 20 11:00AM +0200

On 20/09/18 10:38, Alf P. Steinbach wrote:
> cout << "In 1...7? " << !!(tag::math>> 1 < x < 7) << endl;
> cout << "In 4...7? " << !!(tag::math>> 4 < x < 7) << endl;
> }
 
I like the idea of the "tag::math>>" to indicate that you are changing
to a special type of expression mode. It is, IMHO, nicer than the
suggested "M(1) < M(x) < M(7)" or suchlike.
 
The principle could be used for other cases where you want to use
alternative semantics, like:
 
(saturating>> x + 1)
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 20 11:33AM +0200

On 20.09.2018 11:00, David Brown wrote:
 
> The principle could be used for other cases where you want to use
> alternative semantics, like:
 
> (saturating>> x + 1)
 
The operator precedence works out badly. The above would be parsed as
`saturating >> (x + 1)`. Might do `saturating*` instead, maybe.
 
The general idea is used by some (or some have claimed to use it) for
pseudo-operators like `a %exp% b`, which is parsed as `(a % exp) % b`.
 
 
Cheers!,
 
- Alf
Bo Persson <bop@gmb.dk>: Sep 20 12:13PM +0200

On 2018-09-19 21:22, Mr Flibble wrote:
 
>> That might work.
 
> Nobody is interested in this fucktarded idea of yours mate so give it a
> rest.
 
Some ARE actually.
 
See "Chaining Comparisons" (Sutter and Revzin)
 
https://wg21.link/p0893
 
 
Bo Persson
David Brown <david.brown@hesbynett.no>: Sep 20 08:21AM +0200

On 20/09/18 01:47, bitrex wrote:
> invoked. Given that it compiled and it does not appear to invoke any
> undefined behavior I know of then surely the compiler is not confused.
> It will do something, whatever it is.
 
Ah, you mean /your/ interpretation of it is ambiguous - not that the C
itself is ambiguous. Yes, I can appreciate that. There is nothing for
it but to learn the way C interprets this type of expression - and then,
like all sane C programmers, avoid writing it.
 
David Brown <david.brown@hesbynett.no>: Sep 20 12:43PM +0200

On 20/09/18 11:33, Alf P. Steinbach wrote:
 
>> (saturating>> x + 1)
 
> The operator precedence works out badly. The above would be parsed as
> `saturating >> (x + 1)`. Might do `saturating*` instead, maybe.
 
You are right. It's a pity - "saturating>>" had a nice look to it. It
would have to be "saturating*", "saturating%" or "saturating/" to have
the right precedence, and even then it would fail for increment and
decrement.
 
> The general idea is used by some (or some have claimed to use it) for
> pseudo-operators like `a %exp% b`, which is parsed as `(a % exp) % b`.
 
I can certainly claim to have made such pseudo-operators as examples and
seen that it all works out - but I haven't used them in actual code.
With utf identifiers you can then do:
 
#define ↑ %exp%
 
so that you can write "a ↑ b" for a power operator. But that only works
if your compiler is happy with utf identifiers, your editor is happy,
and you are happy with the serious restrictions on which operator
symbols are allowed as "letters" in C++.
Bart <bc@freeuk.com>: Sep 20 11:50AM +0100

[Posting separately to c.l.c and c.l.c++, newsreader not supporting
cross-posting.]
 
On 20/09/2018 11:13, Bo Persson wrote:
> Some ARE actually.
 
> See "Chaining Comparisons" (Sutter and Revzin)
 
> https://wg21.link/p0893
 
That link brings up the interesting point that in C and C++, == and !=
have a different precedence from <, <=, >= and >.
 
It would make for an odd grouping within such comparison chains.
 
I don't think I've ever considered that aspect, probably few have,
although many will know that C started off with a ridiculously large
number of precedences.
 
The rest of the document demonstrates the difficulties in implementing
such a feature in a language such as C++.
 
I couldn't help checking my implementation of chained operators, and it
was only 25 lines of code. (Although, not for C or C++, and taking the
simpler option of evaluating middle terms twice.)
 
--
bart
"Öö Tiib" <ootiib@hot.ee>: Sep 20 03:51AM -0700

On Thursday, 20 September 2018 12:00:48 UTC+3, David Brown wrote:
 
> The principle could be used for other cases where you want to use
> alternative semantics, like:
 
> (saturating>> x + 1)
 
May be I misunderstand but typically the custom numeric types are
converted from dirty data like "Num(x) + n". There x and n are
dirty data and so checks are made and exceptions thrown on
violations. Your alternative schema described above is confusing for
reasons of precedence. The operator% can be used instead of
operator>> but it can be still confusing.
David Brown <david.brown@hesbynett.no>: Sep 20 01:28PM +0200

On 20/09/18 12:51, Öö Tiib wrote:
> violations. Your alternative schema described above is confusing for
> reasons of precedence. The operator% can be used instead of
> operator>> but it can be still confusing.
 
Yes, you need something like % instead of >> for precedence. After
that, "confusing" is in the eye of the beholder. To me, something like
"Sat(x) + n" means "treat x as a saturating integer and add n to it",
while "saturating% x + n" means "calculate x + n using saturating
arithmetic".
 
But I have not tried either method in real code, so I have no experience
for judging what works best in practice.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 20 08:29AM -0400

On 9/20/2018 6:13 AM, Bo Persson wrote:
> See "Chaining Comparisons" (Sutter and Revzin)
> https://wg21.link/p0893
>     Bo Persson
 
+1 ... from April, 2018. Awesome.
 
--
Rick C. Hodgin
"Öö Tiib" <ootiib@hot.ee>: Sep 20 05:48AM -0700

On Thursday, 20 September 2018 14:29:10 UTC+3, David Brown wrote:
> arithmetic".
 
> But I have not tried either method in real code, so I have no experience
> for judging what works best in practice.
 
Sure it is always what people are used to, but lets try as thought
experiment. There is one of those two lines:
 
auto s1 = Saturating(x) + n;
auto s2 = saturating% x + n;
 
Lets imagine that next maintainer feels some uncertainty what is
going on. What does he do on either case? What is easier? Why?
Lets imagine that there are no much documentation.
Now lets imagine that we are asked to document the class Saturating
or the object saturating. What would you prefer? Why?
Richard Damon <Richard@Damon-Family.org>: Sep 20 06:31AM -0400

On 9/18/18 3:45 PM, Rick C. Hodgin wrote:
 
> It was originally unsigned for a reason.  Why migrate it to
> signed without a cast?
 
> I honestly consider this a fundamental flaw in C (and C++).
 
Decades ago the Standards Committee came across this issue, how should
unsigned values smaller than int, be handled, and there were strong
arguments on both sides, should the unsignedness be preserved or not.
Pre-Standard implementations existed with both decisions, so it was
going to be a quiet possibly breaking change to someone. It had enough
importance that it really couldn't be left to be unspecified or even
implementation defined, so after much heated arguments, they decided on
the current rule, over the objections of some of the members of the
community.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 20 08:22AM -0400

On 9/20/2018 6:31 AM, Richard Damon wrote:
> implementation defined, so after much heated arguments, they decided on
> the current rule, over the objections of some of the members of the
> community.
 
I've been trying to think of what the advantages would be with a
promotion to signed, and I'm not seeing it ... unless the operator
it's going to be working with is also signed. But in a straight-
forward unsigned to unsigned comparison, such as the one I had
which flagged this question in the first place ... I cannot see
it.
 
I would argue the C committee didn't do what they should've. They
should've modified the standard to allow unsigned promotion for
all unsigned values, and then only promote to signed when the op
on the other side requires it.
 
And I honestly can't think of a reason why that's not the only
logical choice. I'd be open to hearing some reasons.
 
--
Rick C. Hodgin
boltar@cylonHQ.com: Sep 20 08:47AM

On Thu, 20 Sep 2018 10:28:34 +1200
 
>> There are several Python implementations. Surely Jython, which is
>> Python run in a Java VM, is as sandboxed as Java?
 
>Oh no, not another language that eats all the RAM in one's machine...
 
I find the sudden resurgence in interest in VMs over the last 20 years or so
rather ironic given how a large chunk of the non emebedded computer industry
has settled upon a single CPU architecture from Intel. Yes, API differences
and all that but translation layers are hardly new. I wonder how much of the
worlds electricity generation is wasted on running VMs rather than raw
binaries.
David Brown <david.brown@hesbynett.no>: Sep 20 11:03AM +0200

> and all that but translation layers are hardly new. I wonder how much of the
> worlds electricity generation is wasted on running VMs rather than raw
> binaries.
 
The current trend is towards JIT compilation - logically, you are
running in a sandboxed VM, but code that requires a lot of processing
time ends up as native. The aim is to get the best of both worlds.
 
And the electricity wasted on VM's is peanuts compared to the
electricity wasted on bitcoins!
boltar@cylonHQ.com: Sep 20 09:24AM

On Thu, 20 Sep 2018 11:03:22 +0200
 
>The current trend is towards JIT compilation - logically, you are
>running in a sandboxed VM, but code that requires a lot of processing
>time ends up as native. The aim is to get the best of both worlds.
 
The problem with JIT is that there has to be some code running in the VM
timing various parts of the program and that in itself uses CPU cycles not to
mention the actual compilation itself.
 
The other problem is that you come up against a variation on the halting
problem - ie will this section always be compute bound or is it just a one
off? There's no way of knowing. Compiling it may end up taking longer than just
leaving it if next time it drops straight through.
 
>And the electricity wasted on VM's is peanuts compared to the
>electricity wasted on bitcoins!
 
True.
Ian Collins <ian-news@hotmail.com>: Sep 20 10:07PM +1200

> problem - ie will this section always be compute bound or is it just a one
> off? There's no way of knowing. Compiling it may end up taking longer than just
> leaving it if next time it drops straight through.
 
JIT compilation uses some form of hot-spot detection. At least it did
when I listened to Mike Ball from Sun (he who wrote the first Java JIT
compiler) describe it at an ACCU conference 20 odd years ago. Probably
not so good for one shot programs, but worth the effort for sever side
stuff.
 
--
Ian
boltar@cylonHQ.com: Sep 20 10:10AM

On Thu, 20 Sep 2018 22:07:14 +1200
>compiler) describe it at an ACCU conference 20 odd years ago. Probably
>not so good for one shot programs, but worth the effort for sever side
>stuff.
 
Yes, server side definately makes more sense. I've not used java for years
but I do remember the occasionally hang as the VM garbage collected and I
imagine JIT has a similar effect. Wonder if they've improved things or much
faster hardware renders it unnoticable now...
Ian Collins <ian-news@hotmail.com>: Sep 20 10:14PM +1200

> but I do remember the occasionally hang as the VM garbage collected and I
> imagine JIT has a similar effect. Wonder if they've improved things or much
> faster hardware renders it unnoticable now...
 
Well they have had 20 years :)
 
--
Ian.
Bart <bc@freeuk.com>: Sep 20 11:30AM +0100

On 20/09/2018 11:07, Ian Collins wrote:
 
> compiler) describe it at an ACCU conference 20 odd years ago.  Probably
> not so good for one shot programs, but worth the effort for sever side
> stuff.
 
Mike Ball or Mike Pall?
 
The latter created LuaJIT. It would be a funny coincidence.
 
--
bart
Ian Collins <ian-news@hotmail.com>: Sep 20 10:47PM +1200

On 20/09/18 22:30, Bart wrote:
>> stuff.
 
> Mike Ball or Mike Pall?
 
> The latter created LuaJIT. It would be a funny coincidence.
 
Mike Ball, he used to post here (or maybe the moderated group) long ago.
 
--
Ian
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 20 05:04AM -0400

On 09/20/2018 03:43 AM, David Brown wrote:
> In particular, there is a very small amount of evidence that there was a
> religious or philosophical teacher called "Jesus" in about the right
> time and place.
 
https://www.biblegateway.com/passage/?search=Matthew+16%3A4%2CLuke+11%3A29%2CLuke+11%3A30&version=NIV
 
4 A wicked and adulterous generation looks for a sign,
but none will be given it except the sign of Jonah."
==> Jesus then left them and went away.
 
David:
 

https://www.biblegateway.com/passage/?search=Romans+10%3A17-21&version=NIV
 
17 Consequently, faith comes from hearing the message,
and the message is heard through the word about Christ.
18 But I ask: Did they not hear? Of course they did:
"Their voice has gone out into all the earth, their
words to the ends of the world."
 
You won't find God in ungodly things. You won't come to faith
pursuing the world. You won't find truth when you're not look-
ing for it, because Jesus is truth and He has said:
 

https://www.biblegateway.com/passage/?search=Matthew+7%3A7-8&version=NIV
 
7 "Ask and it will be given to you; seek and you will
find; knock and the door will be opened to you.
8 For everyone who asks receives; the one who seeks finds;
and to the one who knocks, the door will be opened.
 
If you want to be saved, then ask Jesus to save you, ask God
to reveal Himself to you, ask Him to meet you where you are
and lead you to the place you should be.
 
It's not about taking your money. It's not about you joining a
particular church. It's about your sin, and God's forgiveness;
or your sin, and God's punishment for sin poured out unto you.
 
Jesus was manifest in this world to take away our sin. If there
was another way to do it, God would've given us that way. There
is none, because our sin is something contrary to truth (contrary
to God who is truth), and it cannot exist in His Kingdom founded
entirely upon truth, and righteousness, and holiness.
 
--
Rick C. Hodgin
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)