Saturday, February 27, 2021

Digest for comp.lang.c++@googlegroups.com - 7 updates in 4 topics

Mint User <mint@aio3.org>: Feb 27 08:12PM

<https://www.usnews.com/education/learn-c-guide>
<https://www.usnews.com/education/learn-c-guide>
<https://www.usnews.com/education/learn-c-guide>
Brian Wood <woodbrian77@gmail.com>: Feb 27 11:41AM -0800

On Saturday, February 20, 2021 at 9:58:56 AM UTC-6, Tim Rentsch wrote:
> than one element matches
 
> I had fun with this exercise (and it didn't go as quickly as I
> was expecting). I hope some people here find it fun too.
 
That's great. Now I wish that my wish list items would
not be forgotten for a year or two.
 
 
Brian
Marcel Mueller <news.5.maazl@spamgourmet.org>: Feb 27 07:00AM +0100

Given a type T has a memory alignment alignof(T) and a base class B.
B will in general not have the same alignment as T. But B cannot appear
at arbitrary locations, only every alignof(T).
 
For some low level programming I need the alignment offset of B within a
given type T. Something like
offsetof(T, B) % alignof(T)
 
Of course the old offsetof macro will not work this way. But is there a
way to extract this offset, preferably as constexpr?
 
I know that there are limitations when B is a virtual base of T. The
offset is no longer defined in this case.
 
 
Marcel
James Kuyper <jameskuyper@alumni.caltech.edu>: Feb 27 09:21AM -0500

On 2/27/21 1:00 AM, Marcel Mueller wrote:
> way to extract this offset, preferably as constexpr?
 
> I know that there are limitations when B is a virtual base of T. The
> offset is no longer defined in this case.
 
"Use of the offsetof macro with a type other than a standard-layout
class (11.2) is conditionally-supported. ... The result of applying the
offsetof macro to a static data member or a function member is
undefined." (17.2.4p1)
 
As a general rule, if there is in fact a constant offset from the
beginning of a given class instance to a given member of that object,
the behavior of offsetof() will be well-defined, and the implementation
will support the use of offsetof() for obtaining that offset. To put it
the other way around, if use of offsetof() has undefined behavior or is
not supported, then the distance between those two things might not be
constant. Therefore, if you can't use offsetof(), it's unlikely that
there will be any workaround.
Siri Cruise <chine.bleu@yahoo.com>: Feb 26 03:26PM -0800

In article <tSd_H.261436$Wue5.69200@fx13.ams4>,
> functions
> contain branching logic.
 
> (0) Only pure functions may not modify mutable state.
 
goldbach = \n.[
goldbachsum(n, 2, 2) -> goldbach(n+2);
true -> halt
]
goldbachsum = \n,r,s. [
r>=n -> false;
not prime(r, 2) -> goldbachsum(n, r+1, 2);
not prime(s, 2) -> goldbachsum(n, r, s+1);
r+s>n -> goldbachsum(n, r+1, 2);
r+s<n -> goldbachsum(n, r, s+1);
r+s=n -> true;
]
prime = \n,r.[
r*r>n -> true;
n mod r=0 -> false;
true -> prime(n, r+1)
]
 
Prove goldbach(2) halts or never halts and you win a Hero of the
Mathematics badge.
 
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed
Kaz Kylheku <563-365-8930@kylheku.com>: Feb 27 01:58AM

> Simulate(P, P);
> }
 
> Does everyone agree?
 
If Simulate(P, P) replaces P(P), and the simulation is a faithful
replica of the processor, then nothing has changed.
 
You have previosuly written about a scheme in which Simulate
contains provisions for monitoring the execution. An outer Simulate has
instruction stream information from all inner Simulate calls and is able
to impose the rule that the simulation will only go to some fixed number
of levels, like 3. Let's call that N.
 
Firstly, what that does is change H_Hat: H_Hat is no longer infinitely
recursive, because Simulate detects an internal halting condition and
stops.
 
Secondly, the different recursion levels of H_Hat are not equivalent
to each other.
 
The outer-most H_Hat goes to N levels of recursion/simulation nesting.
 
The next lower nesting, though ostensibly executing the same logic,
only has N-1 remaining levels available to it before it will be
terminated.
 
The one after that N-2.
 
A function that terminates after U nestings is not the same function
as a similar one which terminates after V nestings, for U != V.
 
We must treat each H_Hat invocation at every nesting level i as a
different function H_Hat_i.
 
--
TXR Programming Language: http://nongnu.org/txr
Cygna: Cygwin Native Application Library: http://kylheku.com/cygnal
Jeff Barnett <jbb@notatt.com>: Feb 26 09:32PM -0700

On 2/26/2021 12:53 PM, olcott wrote:
>   Simulate(P, P);
> }
 
> Does everyone agree?
 
You took off all of this time to come up with this. Remember when you
were pooping in the Lisp group without a clue of what you were talking
about or knowledge of any modern Lisp? Disgraceful! Consider a function
which accesses a variable bound outside its scope - there are many
variations here and this is why you should have learned some Lisp
instead of just pooping. Then the above is incorrect. Of course you have
something different in mind but are making a pig of terminology. Above
you say "software" function and that is what I'm talking about. If you
mean "mathematical" function, well do you remember the definition of a
mathematical function? In this case, you are correct but that has little
or nothing to do with software. I suggest another hiatus for you but
make it longer this time. Much longer.
--
Jeff Barnett
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)