Monday, December 31, 2018

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

Richard Damon <Richard@Damon-Family.org>: Dec 31 04:43PM -0500

On 12/31/18 4:34 PM, Keith Thompson wrote:
 
> Oh, there's a CAlive newsgroup?
 
> Wouldn't that be a better place to discuss CAlive than comp.lang.c *and*
> comp.lang.c++?
 
It isn't a 'real' NNTP newsgroup, just one of the pseudo newsgroups on,
if I remember right, googlegroups (so accessible on web through it as if
it was a newsgroup, but doesn't leave google).
Richard Damon <Richard@Damon-Family.org>: Dec 31 04:57PM -0500

On 12/31/18 4:05 PM, Bart wrote:
 
> Try and take out the member select part of the 10 or 12 examples in your
> syntax; you can't just remove the ".m", because most of them don't use it.
 
> C syntax has always been a mess that way. Your additions make it worse.
 
your syntax isn't that different than C in my view.
 
In C *p, in your p^
Both get you 'the object pointed to by p), to which you can add more
indirection of member selection.
 
C adds a 'shortcut' of p->m as the syntax sugar for (*p).m
 
Perhaps having the indirect operation being postfix instead of prefix
cleans up some issue with syntax, getting rid of some needs of parenthesis.
 
For C, with the need of the parenthesis, the shortcut seems useful, and
having 2 notations doesn't seem that bad.
 
Rick's multitude of options seems much less useful, and I suspect he is
going to run into parsing issues with his grammar.
 
...
 
>> equivalent value that can be used.
 
> Say again? I expected you to say that _x means *x, some syntactic sugar.
> You mean that _x means '*(unsigned char)x'?
 
I think Rick means that _x is like (uintptr_t)x
Bart <bc@freeuk.com>: Dec 31 10:33PM

On 31/12/2018 21:57, Richard Damon wrote:
 
> C adds a 'shortcut' of p->m as the syntax sugar for (*p).m
 
> Perhaps having the indirect operation being postfix instead of prefix
> cleans up some issue with syntax, getting rid of some needs of parenthesis.
 
That is the crucial part. It means pointers to arrays in C would have
been more popular if accesses could be written A^[i] ('*' wouldn't work)
instead of (*A)[i].
 
Pointers to struct members could be written consistently as P^.m instead
of either (*P).m or P->m, while adding or removing an indirection is
just adding or removing ^, instead of having to add or remove (*) or to
transform between -> and (*) or between -> and . or between (*) and .
 
And calls via function pointers could be consistently written F^(x)
instead of (*F)(x) or via the confusing F(x).
 
> having 2 notations doesn't seem that bad.
 
> Rick's multitude of options seems much less useful, and I suspect he is
> going to run into parsing issues with his grammar.
 
Almost certainly.
 
--
bart
Keith Thompson <kst-u@mib.org>: Dec 31 03:20PM -0800


> It isn't a 'real' NNTP newsgroup, just one of the pseudo newsgroups on,
> if I remember right, googlegroups (so accessible on web through it as if
> it was a newsgroup, but doesn't leave google).
 
My point stands.
 
--
Keith Thompson (The_Other_Keith) kst@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
rbowman <bowman@montana.com>: Dec 31 12:06PM -0700

On 12/30/2018 09:43 PM, Ralf Goertz wrote:
> Really? Fraktur was not taught at my time in German schools, I had to
> learn it on my own and I only did it because we had some old books I
> wanted to read.
 
The US schools hadn't quite caught up in the early '60s. The copies of
'Emil und die Detektive' we had might have been pre-war. Our teachers
were in their '50s so they were definitely pre-war.
 
In college the focus was on technical literature and that was all in
Roman type. The assumption for engineering students was a lot of
literature would be published in German. The reality, for better or
worse, was German engineers and scientists learned English.
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.

No comments: