Sunday, February 28, 2021

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

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 28 11:39AM -0800

On 2/26/2021 10:00 PM, 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.
 
I have no idea if this will work for you, or if its even standard with
regard to the use of alignas for virtual base classes.
 
__________________________________
#include <iostream>
#include <cstdint>
#include <cassert>
 
 
#define ALIGN 128
 
 
struct alignas(ALIGN) base
{
int a;
char b;
long c;
 
base()
{
std::cout << "base::base() " << this << "\n";
}
 
virtual ~base()
{
std::cout << "base::~base() " << this << "\n";
}
 
std::uintptr_t base_this() { return (std::uintptr_t)this; }
};
 
 
struct alignas(ALIGN) foo : virtual public base
{
int d;
 
foo()
{
std::cout << "foo::foo() " << this << "\n";
 
std::uintptr_t dif = base_this() - (uintptr_t)this;
 
std::cout << "dif = " << dif << "\n";
 
assert(dif == ALIGN);
}
 
~foo()
{
std::cout << "foo::~foo() " << this << "\n";
}
};
 
int main()
{
{
foo f;
}
 
return 0;
}
 
__________________________________
 
 
I am getting:
 
base::base() 010FF680
foo::foo() 010FF600
dif = 128
foo::~foo() 010FF600
base::~base() 010FF680
 
 
dif should always equal the alignment. What do you get on your end?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 28 12:05PM -0800

On 2/28/2021 11:39 AM, Chris M. Thomasson wrote:
> foo::~foo() 010FF600
> base::~base() 010FF680
 
> dif should always equal the alignment. What do you get on your end?
 
My "rational" is that if we over align the the base class and the
derived class on a common alignment, then they should both share that
alignment.
olcott <NoOne@NoWhere.com>: Feb 28 01:08PM -0600

On 2/28/2021 11:20 AM, Mr Flibble wrote:
> Publish now please unless of course you only have snake oil, which seems
> to be the case.
 
> /Flibble
 
This instance of H_Hat() is proved to be decidable and all the code is
provided. This H_Hat() calls Simulate() that returns true whenever its
input halts.
 
 
int Simulate(u32 P, u32 I)
{
((void(*)(int))P)(I);
return 1;
}
 
 
// P has the machine address of H_Hat()
void H_Hat(u32 P)
{
u32 Input_Halts = Simulate(P, P);
if (Input_Halts)
HERE: goto HERE;
return;
}
 
 
_Simulate()
[00000478](01) 55 push ebp
[00000479](02) 8bec mov ebp,esp
[0000047b](03) 8b450c mov eax,[ebp+0c]
[0000047e](01) 50 push eax
[0000047f](03) ff5508 call dword [ebp+08]
[00000482](03) 83c404 add esp,+04
[00000485](05) b801000000 mov eax,00000001
[0000048a](01) 5d pop ebp
[0000048b](01) c3 ret
 
 
_H_Hat()
[00000858](01) 55 push ebp
[00000859](02) 8bec mov ebp,esp
[0000085b](01) 51 push ecx
[0000085c](03) 8b4508 mov eax,[ebp+08]
[0000085f](01) 50 push eax
[00000860](03) 8b4d08 mov ecx,[ebp+08]
[00000863](01) 51 push ecx
[00000864](05) e80ffcffff call 00000478
[00000869](03) 83c408 add esp,+08
[0000086c](03) 8945fc mov [ebp-04],eax
[0000086f](04) 837dfc00 cmp dword [ebp-04],+00
[00000873](02) 7402 jz 00000877
[00000875](02) ebfe jmp 00000875
[00000877](02) 8be5 mov esp,ebp
[00000879](01) 5d pop ebp
[0000087a](01) c3 ret
 
Because the execution trace shown below shows that H_Hat() invokes
Simulate() with the same data two times in sequence we can conclude that
H_Hat() is invoked in infinite recursion.
 
Push instructions have already pushed the value shown in their in the
third column. The two push instructions preceding the call to Simulate()
are its second and first parameters respectively.
 
Columns
(1) Machine address of instruction
(2) Machine address of top of stack
(3) Value of top of stack after instruction executed
(4) Number of bytes of machine code
(5) Machine language bytes
(6) Assembly language text
 
...[00000858][000111c5][000111d1](01) 55 push ebp
...[00000859][000111c5][000111d1](02) 8bec mov ebp,esp
...[0000085b][000111c1][00000000](01) 51 push ecx
...[0000085c][000111c1][00000000](03) 8b4508 mov eax,[ebp+08]
...[0000085f][000111bd][00000858](01) 50 push eax
...[00000860][000111bd][00000858](03) 8b4d08 mov ecx,[ebp+08]
...[00000863][000111b9][00000858](01) 51 push ecx
; Call Simulate(0x858, 0x858);
...[00000864][000111b5][00000869](05) e80ffcffff call 00000478
...[00000858][000111a5][000111b1](01) 55 push ebp
...[00000859][000111a5][000111b1](02) 8bec mov ebp,esp
...[0000085b][000111a1][00000858](01) 51 push ecx
...[0000085c][000111a1][00000858](03) 8b4508 mov eax,[ebp+08]
...[0000085f][0001119d][00000858](01) 50 push eax
...[00000860][0001119d][00000858](03) 8b4d08 mov ecx,[ebp+08]
...[00000863][00011199][00000858](01) 51 push ecx
; Call Simulate(0x858, 0x858);
...[00000864][00011195][00000869](05) e80ffcffff call 00000478
 
 
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
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:

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:

Friday, February 26, 2021

Digest for comp.lang.c++@googlegroups.com - 11 updates in 3 topics

olcott <NoOne@NoWhere.com>: Feb 26 01:53PM -0600

(1) We know that every software function invoked with the same data must
have the same execution trace.
 
(2) When a software function invokes itself this is recursive invocation.
 
(3) When the second recursive invocation of a software function calls
itself with the same data as the prior invocation then it must have the
same execution trace as the prior invocation.
 
(4) When the second recursive invocation of a software function calls
itself with the same data has no conditional branch instructions
inbetween these two invocations then this is a case of infinite recursion.
 
(5) When the recursive invocation is replaced with a call to a software
system that simulates the execution of the calling function with its
same data, then this is equivalent to a recursive invocation.
 
// P has address of H_Hat
void H_Hat(u32 P)
{
Simulate(P, P);
}
 
Does everyone agree?
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
Siri Cruise <chine.bleu@yahoo.com>: Feb 26 12:48PM -0800

In article <3LadneKdoK8jzKT9nZ2dnUU78T3NnZ2d@giganews.com>,
 
> Does everyone agree?
 
P = \a.P(succ(a))
P 0
 
 
> (1) We know that every software function invoked with the same data must
> have the same execution trace.
 
When does a recursion use the same data?
 
--
:-<> 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
Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Feb 26 09:37PM

On 26/02/2021 19:53, olcott wrote:
>   Simulate(P, P);
> }
 
> Does everyone agree?
 
No.
 
(-1) In general for an algorithm or program to perform useful work its functions
contain branching logic.
 
(0) Only pure functions may not modify mutable state.
 
...
 
(6) ???
 
(7) ???
 
(8) ???
 
...
 
(???) ???
 
...
 
/Flibble
 
--
😎
Bonita Montero <Bonita.Montero@gmail.com>: Feb 26 03:17PM +0100

Lambdas with no captures can be handled like ordinary functions and you
can get the address of the lambda as a normal function-pointer. AFAIK
there's no compiler which allows to specify a callig-convention on a
lambda. But with MSVC you can convert a lamda to a function-pointer of
any type, i.e. you can convert it to __cdecl, __fastcall or whatever
(they exist for x86 only, x64 has a consistent calling convention for
all calls). What MSVC does here is that it compiles the lambda multiple
times for each calling convention on demand.
 
Look here:
 
#include <iostream>
#include <string>
#include <iomanip>
#include <cstdint>
 
using namespace std;
 
void fastCall( void (__fastcall *pf)( string ) )
{
string str = "hello world";
cout << p << endl;
pf( str );
}
 
void cdeclCall( void (__cdecl *pf)( string ) )
{
string str = "hello world";
cout << p << endl;
pf( str );
}
 
int main()
{
auto lambda = []( string str )
{
cout << str << endl;
};
fastCall( lambda );
cdeclCall( lambda );
}
 
As you can see the addresses pf vary. You might think that the compiler
generates proxy-code and the string is copy-constructed with each proxy.
But I disassembled the lambda and found that the lambda is compiled
completely multiple times.
 
So are there any other compilers which have different calling conven-
tions and which do the same ?
David Brown <david.brown@hesbynett.no>: Feb 26 05:08PM +0100

On 26/02/2021 15:17, Bonita Montero wrote:
> (they exist for x86 only, x64 has a consistent calling convention for
> all calls). What MSVC does here is that it compiles the lambda multiple
> times for each calling convention on demand.
 
Calling conventions - especially the various ones supported by MSVC -
are very much implementation specific. On most platforms you have a
single ABI that all compilers adhere to, but not on 32-bit Windows. So
how different calling conventions are handled on Win32 will be entirely
up to the compiler.
 
Lambdas have internal linkage and are usually not "exported" in any way,
so compilers are free to use whatever calling conventions they want -
there is no need for any consistency, especially if the lambda is a leaf
function.
 
When you convert a lambda to a pointer-to-function, you are actually
using a conversion function template which is free to give different
results for different pointer types. (It can even give different
results for the same pointer types, although that would be less likely
in a real implementation.)
 
See the section on "ClosureType::operator ret(*)(params)()" :
 
<https://en.cppreference.com/w/cpp/language/lambda>
 
 
Of curiosity, what happens if you replace the lambda with a static function:
 
static auto lambda(string str) { cout << str << endl; }
 
?
Bonita Montero <Bonita.Montero@gmail.com>: Feb 26 05:21PM +0100

> Calling conventions - especially the various ones supported by MSVC -
> are very much implementation specific. On most platforms you have a
> single ABI that all compilers adhere to, ...
 
On Windows x64 there's no such thing as __cdecl, __fastcall, __stdcall
etc. anymore.
David Brown <david.brown@hesbynett.no>: Feb 26 05:41PM +0100

On 26/02/2021 17:21, Bonita Montero wrote:
>> single ABI that all compilers adhere to, ...
 
> On Windows x64 there's no such thing as __cdecl, __fastcall, __stdcall
> etc. anymore.
 
Well, MS didn't do nearly as badly for Win64 as they did for Win32
(where there are half a dozen conventions) or DOS (where there is so
little defined that it's a stretch to use the word "convention"). They
tried to have a single ABI - though in good old MS fashion, they saw
that everyone else had settled on a single consistent ABI and thus
decided they needed a completely different one instead. But there is
still the "normal" MS Win64 calling convention, and the "__vectorcall"
version.
 
However, I thought you were specifically talking about Win32 since you
were talking about __cdecl, __fastcall, etc., ?
Bonita Montero <Bonita.Montero@gmail.com>: Feb 26 05:43PM +0100

> decided they needed a completely different one instead. But there is
> still the "normal" MS Win64 calling convention, and the "__vectorcall"
> version.
 
With most other platforms there's usually a default calling convention
and mostly a cdecl calling convention which pushes everything on the
stack.
Bonita Montero <Bonita.Montero@gmail.com>: Feb 26 05:48PM +0100

Am 26.02.2021 um 15:17 schrieb Bonita Montero:
> {
>     string str = "hello world";
>     cout << p << endl;
pf, not p
> {
>     string str = "hello world";
>     cout << p << endl;
pf, not p
scott@slp53.sl.home (Scott Lurndal): Feb 26 05:26PM


>With most other platforms there's usually a default calling convention
>and mostly a cdecl calling convention which pushes everything on the
>stack.
 
Most platforms I've seen in the past two decades use calling conventions
that pass the first N parameters in registers, where N varies based
on the number of registers. E.g. x86_64 on unix/linux (N=6), Motorola 88100,
IA64, et alia.
 
Calling conventions also agree on how to handle varargs and how to pass
SIMD, vector (and for ARM, scalable vector) values.
aotto1968 <aotto1968@t-online.de>: Feb 26 02:05PM +0100

Hello everybody,
 
After a while, I would like you to be informed about my current (C++)
project:
 
NHI1 - the POWER of programming
→
https://nhi1.selfhost.co/wiki/index.php?title=NHI1_-_the_POWER_of_programming
 
==========================================================================
 
It is difficult to describe the POWER of NHI1 in a few simple words -
let me try:
 
NHI1 - something that writes code for you
 
The Something is a collection of tools, libraries, and design patterns
that push the boundaries of programming.
 
==========================================================================
 
Some example-tools and libraries are also available:
 
NHI1 - HOME page
→ https://nhi1.selfhost.co/nhi1
 
ccmsgque - an C++ application-server library
→ https://nhi1.selfhost.co/nhi1/ccmsgque/ccmsgqueref.htm
 
mpgrep a massive parallel grep tool
→ https://nhi1.selfhost.co/nhi1/ccmsgque/cc_MpGrep.htm
 
Compiler Factory - Company HOME page
→ https://nhi1.selfhost.co
 
 
mfg
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:

Thursday, February 25, 2021

Digest for comp.lang.c++@googlegroups.com - 21 updates in 3 topics

"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 24 07:10PM -0500

OT: A message regarding the rapid transformation of our world
 
Read this and repost. It's important. This message is to U.S.
citizens, but it applies world-wide.
 
Our nation is under serious assault. Not by the left or right, but by
evil spiritual forces at work inside of people. By our society, people
have sold out to sin in all its various forms, and now those evil
spirits literally dwell inside the physical bodies of people, and from
that place of influence they are moving against all of mankind in the
capacity of the people they occupy. Leaders. Business people. Everyone
of influence is under assault or being replaced in their position by
someone who is compromised.
 
This translates into a world environment where all of us who trust in
the Lord Jesus Christ, who seek to do and be a part of what's true,
what's right in God's sight, deferring to the guidance which God has
given us in the Bible, by His Holy Spirit, through His Son, are also
under assault. No one is sidelined. We are all all in whether we
realize it or not.
 
The United States in its present form will not survive. We read in
Revelation about the coming great tribulation and how the entire world
will go after the mark of the beast system, taking the mark and in so
doing damning their eternal souls.
 
My friends, that time is here. We are seeing the transformation and
preparation for the full-on implementation of that system happening
before our very eyes. We are seeing that mark of the beast system
coming online and rising up before us.
 
It will not be too much longer until everyone who trusts in Jesus Christ
will be cast out of their jobs, their homes, onto the streets, unable
to get employment, unable to provide for their families. They will be
shunned and hated everywhere by those very people who, through sin and
their love of sin, are compromised. Christians will become a band of
outcasts and the whole world will rejoice for a time because of it.
 
But to every Christian: Take heart, because the Lord of hosts has
secured our victory. He will take us out of this world so we will not
go through that mark of the beast system and the seven year tribulation.
 
Stay strong, my friends. Take courage. The Lord Jesus Christ has
already given us the victory. This is the enemy's moment in time to rise
to power and overcome, but scripture teaches us it is a fleeting moment,
and it will not endure, and Jesus has already secured their defeat in
the most final way possible.
 
Be strong no matter what comes. And if you need encouragement, please
contact me. Watch my video on the spiritual nature of our lives on
YouTube. And teach the people around you about this spiritual battle we
are facing, and why and how we must keep our faith and trust in Jesus
Christ no matter what the enemy throws at us.
 
I am there with you in spirit, as are all the saints, across all the
nations, across this entire world, are likewise.
 
Look up, because your redemption draws near.
 
In Christ,
Rick C. Hodgin
 
PS -- To all of you who don't believe, consider these things. Read the
Bible and see for yourself if what I teach you about the correlation
between worldly events and changes aligns with the Biblical teaching.
Do not go another day without knowing for sure. Put God to the test.
Prove Him out by examining and testing what He's written to see if He
is true or not. Do not rely upon me or my guidance / thoughts. I am a
man and can be wrong. But God is not a man like us, and He cannot be
wrong. Jesus wants to forgive you today. Ask Him to forgive you and
escape what's coming. Do this, and you will feel the change, and you
will see the whole world from inside of new eyes. Peace, my friends.
[Jesus Loves You]
Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Feb 25 12:52AM

On 25/02/2021 00:10, Rick C. Hodgin wrote:
> OT: A message regarding the rapid transformation of our world
 
[snip - tl;dr]
 
And Satan invented fossils, yes?
 
/Flibble
 
--
😎
Andy Burns <usenet@andyburns.uk>: Feb 25 08:06AM

Rick C. Hodgin wrote:
 
> someone who is compromised.
 
> This translates into a world environment where all of us who trust in
> the Lord Jesus Christ, who seek to do and be a part of what's true,
 
libSF.c:15:12: error: 'Jesus' undeclared (first use in this function)
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 25 12:14AM -0800

On 2/25/2021 12:06 AM, Andy Burns wrote:
 
>> This translates into a world environment where all of us who trust in
>> the Lord Jesus Christ, who seek to do and be a part of what's true,
 
> libSF.c:15:12: error: 'Jesus' undeclared (first use in this function)
 
Did he finally finish his compiler? I want to install the platform, and
give it go. Have some old computers around.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 25 12:17AM -0800

On 2/25/2021 12:06 AM, Andy Burns wrote:
 
>> This translates into a world environment where all of us who trust in
>> the Lord Jesus Christ, who seek to do and be a part of what's true,
 
> libSF.c:15:12: error: 'Jesus' undeclared (first use in this function)
 
I know that you are being sarcastic... However, when he finally does
finish, and I can install an iso image. I would jump up in the air:
 
https://youtu.be/UZ2-FfXZlAU
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 25 12:09PM -0500

On Thu, 25 Feb 2021 08:06:47 +0000
> > in the Lord Jesus Christ, who seek to do and be a part of what's
> > true,
 
> libSF.c:15:12: error: 'Jesus' undeclared (first use in this function)
 
Very clever and funny! :-)
 
You're using an outdated "compiler." Upgrade to version 2.0, which has
both the physical and spiritual components. It has all the #includes
and knows how to process the new spiritual abilities.
 
--
Rick C. Hodgin
Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Feb 25 05:48PM

On 25/02/2021 17:09, Rick C. Hodgin wrote:
 
> You're using an outdated "compiler." Upgrade to version 2.0, which has
> both the physical and spiritual components. It has all the #includes
> and knows how to process the new spiritual abilities.
 
And Satan invented fossils, yes?
 
evolution.c:15:12: error: 'God' undeclared (first use in this function)
 
/Flibble
 
--
😎
Bonita Montero <Bonita.Montero@gmail.com>: Feb 25 07:24AM +0100

I've got a header with a macro to define new exception-subclasses:
 
#pragma once
#include <exception>
#include <string>
 
#define exc_subclass(base, deriv, default_what) \
struct deriv : public base \
{ \
deriv( char const *what = default_what ) noexcept : \
m_what( what ) \
{ \
} \
deriv( exception_ptr nextException, char const *what = default_what )
noexcept : \
m_nextException( nextException ), \
m_what( what ) \
{ \
} \
deriv( deriv const &other ) noexcept : \
base( other ), \
m_what( other.what() ) \
{ \
} \
virtual char const *what() const noexcept override \
{ \
return m_what.c_str(); \
} \
std::exception_ptr next_exception() const noexcept \
{ \
return m_nextException; \
} \
private: \
std::string m_what; \
std::exception_ptr m_nextException; \
};
 
But this doesn't accept ...
exc_subclass(std::exception, deriv, "my default what")
... because of the :: in it.
Is there any escape for :: ?
Ben Bacarisse <ben.usenet@bsb.me.uk>: Feb 25 11:11AM


> But this doesn't accept ...
> exc_subclass(std::exception, deriv, "my default what")
> ... because of the :: in it.
 
The macro does not care about the ::. If it does not work, it's for
some other reason.
 
--
Ben.
Paavo Helde <myfirstname@osa.pri.ee>: Feb 25 01:43PM +0200

25.02.2021 08:24 Bonita Montero kirjutas:
>     { \
>     } \
>     deriv( exception_ptr nextException, char const *what = default_what
 
You are missing std:: before exception_ptr in the prev line.
 
Colons in preprocessor macros are fine. Commas, on the other hand, might
be a bit tricky sometimes.
Bonita Montero <Bonita.Montero@gmail.com>: Feb 25 02:54PM +0100

> You are missing std:: before exception_ptr in the prev line.
 
Ok, that's what someone else found on Stack Overflow also.
But thanks.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 24 05:16PM -0800

On 2/24/2021 10:28 AM, Richard Damon wrote:
> to do some 'cleanup' on the resource, but if the process isn't releasing
> the resource in the required time, can you really trust that it is doing
> its job right?
 
Are you familiar with robust mutexes? They are designed to allow one to
repair the shared data if a processes dies while holding the lock.
Bonita Montero <Bonita.Montero@gmail.com>: Feb 25 07:08AM +0100

> A lock that works with the OS to so the OS knows what locks the process
> holds can kill a 'bad' process and force the release of the lock.
 
That's impossible because that what the lock guards is in inconsistent
state at this time.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 24 11:39PM -0800

On 2/24/2021 10:08 PM, Bonita Montero wrote:
>> holds can kill a 'bad' process and force the release of the lock.
 
> That's impossible because that what the lock guards is in inconsistent
> state at this time.
 
Think of a "master" process, than can kill a process while its holding a
process-wide mutex. This can be handled and corrected, the state can be
repaired into a consistent state. Its tricky, yet can be done. Wrt
Windows think of the WAIT_ABANDONDED state. POSIX has it with EOWNERDEAD.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 24 11:43PM -0800

On 2/24/2021 10:08 PM, Bonita Montero wrote:
>> holds can kill a 'bad' process and force the release of the lock.
 
> That's impossible because that what the lock guards is in inconsistent
> state at this time.
 
Wrt WAIT_ABANDONED, read the docs:
 
https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitforsingleobject
_____________
WAIT_ABANDONED:
 
The specified object is a mutex object that was not released by the
thread that owned the mutex object before the owning thread terminated.
Ownership of the mutex object is granted to the calling thread and the
mutex state is set to nonsignaled.
If the mutex was protecting persistent state information, you should
check it for consistency.
_____________
 
POSIX has, EOWNERDEAD:
 
https://man7.org/linux/man-pages/man3/pthread_mutex_consistent.3.html
Bonita Montero <Bonita.Montero@gmail.com>: Feb 25 09:49AM +0100

> process-wide mutex. This can be handled and corrected, the state can be
> repaired into a consistent state. Its tricky, yet can be done. Wrt
> Windows think of the WAIT_ABANDONDED state. POSIX has it with EOWNERDEAD.
 
If you have shared memory modified while holding the lock there's
nothing to fix.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 25 01:05AM -0800

On 2/25/2021 12:49 AM, Bonita Montero wrote:
>> Windows think of the WAIT_ABANDONDED state. POSIX has it with EOWNERDEAD.
 
> If you have shared memory modified while holding the lock there's
> nothing to fix.
 
have you ever had to encounter and deal with EOWNERDEAD, or
WAIT_ABANDONDED ?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 25 01:49AM -0800

On 2/24/2021 9:20 AM, Bonita Montero wrote:
>> It does depend on the implementation if frequent reads can starve out
>> writers.
 
> But if this happens is a matter of the lock-behaviour.
 
The way the user actually uses a rwmutex should be read heavy, writes,
not so frequent. However, frequent sustained reads should not have the
ability to starve out writers; lots of rwmutex impls allow just that.
Some even have so-called reader/writer priorities. Bakery algorithms
cannot suffer from these conditions... They just go in order.
Bonita Montero <Bonita.Montero@gmail.com>: Feb 25 11:43AM +0100

>> nothing to fix.
 
> have you ever had to encounter and deal with EOWNERDEAD, or
> WAIT_ABANDONDED ?
 
Boy, you're stupid. If you're modifying memory while holding a lock
and the lock is deleted meanwhile, WAIT_ABANDONNED or whatever doesn't
help.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 25 03:09AM -0800

On 2/25/2021 2:43 AM, Bonita Montero wrote:
 
> Boy, you're stupid. If you're modifying memory while holding a lock
> and the lock is deleted meanwhile, WAIT_ABANDONNED or whatever doesn't
> help.
 
You have never had to clean up after a process dies while holding a mutex?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 25 03:10AM -0800

On 2/25/2021 3:09 AM, Chris M. Thomasson wrote:
 
>> Boy, you're stupid. If you're modifying memory while holding a lock
>> and the lock is deleted meanwhile, WAIT_ABANDONNED or whatever doesn't
>> help.
 
I am not referring to deleting a mutex, I am talking about a process
crashing in the middle of a critical section.
 
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:

Digest for comp.programming.threads@googlegroups.com - 13 updates in 1 topic

Bonita Montero <Bonita.Montero@gmail.com>: Feb 24 06:20PM +0100

> It does depend on the implementation if frequent reads can starve out
> writers.
 
But if this happens is a matter of the lock-behaviour.
Bonita Montero <Bonita.Montero@gmail.com>: Feb 24 06:22PM +0100

> is to have OS support to kill those clients and have it unlock the locks
> it held on to. (It could not kill but just deny further access depending
> on the resource).
 
We're talking about locks which protect shared datastructures. In this
case it would be stupid to kill a process or thread holding such a lock.
Richard Damon <Richard@Damon-Family.org>: Feb 24 01:28PM -0500

On 2/24/21 12:22 PM, Bonita Montero wrote:
>> on the resource).
 
> We're talking about locks which protect shared datastructures. In this
> case it would be stupid to kill a process or thread holding such a lock.
 
A lock that works with the OS to so the OS knows what locks the process
holds can kill a 'bad' process and force the release of the lock.
 
The only way to handle 'bad' processes, is for there to be some
mechanism to deny that process access to the resource that it has taken
the lock on, so it can be given to someone else. That capability is
typically reserved to the OS.
 
Yes, if you abort a process in the middle of its operation, you may need
to do some 'cleanup' on the resource, but if the process isn't releasing
the resource in the required time, can you really trust that it is doing
its job right?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 24 05:16PM -0800

On 2/24/2021 10:28 AM, Richard Damon wrote:
> to do some 'cleanup' on the resource, but if the process isn't releasing
> the resource in the required time, can you really trust that it is doing
> its job right?
 
Are you familiar with robust mutexes? They are designed to allow one to
repair the shared data if a processes dies while holding the lock.
Bonita Montero <Bonita.Montero@gmail.com>: Feb 25 07:08AM +0100

> A lock that works with the OS to so the OS knows what locks the process
> holds can kill a 'bad' process and force the release of the lock.
 
That's impossible because that what the lock guards is in inconsistent
state at this time.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 24 11:39PM -0800

On 2/24/2021 10:08 PM, Bonita Montero wrote:
>> holds can kill a 'bad' process and force the release of the lock.
 
> That's impossible because that what the lock guards is in inconsistent
> state at this time.
 
Think of a "master" process, than can kill a process while its holding a
process-wide mutex. This can be handled and corrected, the state can be
repaired into a consistent state. Its tricky, yet can be done. Wrt
Windows think of the WAIT_ABANDONDED state. POSIX has it with EOWNERDEAD.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 24 11:43PM -0800

On 2/24/2021 10:08 PM, Bonita Montero wrote:
>> holds can kill a 'bad' process and force the release of the lock.
 
> That's impossible because that what the lock guards is in inconsistent
> state at this time.
 
Wrt WAIT_ABANDONED, read the docs:
 
https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitforsingleobject
_____________
WAIT_ABANDONED:
 
The specified object is a mutex object that was not released by the
thread that owned the mutex object before the owning thread terminated.
Ownership of the mutex object is granted to the calling thread and the
mutex state is set to nonsignaled.
If the mutex was protecting persistent state information, you should
check it for consistency.
_____________
 
POSIX has, EOWNERDEAD:
 
https://man7.org/linux/man-pages/man3/pthread_mutex_consistent.3.html
Bonita Montero <Bonita.Montero@gmail.com>: Feb 25 09:49AM +0100

> process-wide mutex. This can be handled and corrected, the state can be
> repaired into a consistent state. Its tricky, yet can be done. Wrt
> Windows think of the WAIT_ABANDONDED state. POSIX has it with EOWNERDEAD.
 
If you have shared memory modified while holding the lock there's
nothing to fix.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 25 01:05AM -0800

On 2/25/2021 12:49 AM, Bonita Montero wrote:
>> Windows think of the WAIT_ABANDONDED state. POSIX has it with EOWNERDEAD.
 
> If you have shared memory modified while holding the lock there's
> nothing to fix.
 
have you ever had to encounter and deal with EOWNERDEAD, or
WAIT_ABANDONDED ?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 25 01:49AM -0800

On 2/24/2021 9:20 AM, Bonita Montero wrote:
>> It does depend on the implementation if frequent reads can starve out
>> writers.
 
> But if this happens is a matter of the lock-behaviour.
 
The way the user actually uses a rwmutex should be read heavy, writes,
not so frequent. However, frequent sustained reads should not have the
ability to starve out writers; lots of rwmutex impls allow just that.
Some even have so-called reader/writer priorities. Bakery algorithms
cannot suffer from these conditions... They just go in order.
Bonita Montero <Bonita.Montero@gmail.com>: Feb 25 11:43AM +0100

>> nothing to fix.
 
> have you ever had to encounter and deal with EOWNERDEAD, or
> WAIT_ABANDONDED ?
 
Boy, you're stupid. If you're modifying memory while holding a lock
and the lock is deleted meanwhile, WAIT_ABANDONNED or whatever doesn't
help.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 25 03:09AM -0800

On 2/25/2021 2:43 AM, Bonita Montero wrote:
 
> Boy, you're stupid. If you're modifying memory while holding a lock
> and the lock is deleted meanwhile, WAIT_ABANDONNED or whatever doesn't
> help.
 
You have never had to clean up after a process dies while holding a mutex?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 25 03:10AM -0800

On 2/25/2021 3:09 AM, Chris M. Thomasson wrote:
 
>> Boy, you're stupid. If you're modifying memory while holding a lock
>> and the lock is deleted meanwhile, WAIT_ABANDONNED or whatever doesn't
>> help.
 
I am not referring to deleting a mutex, I am talking about a process
crashing in the middle of a critical section.
 
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.programming.threads+unsubscribe@googlegroups.com.
Posted by at No comments:

Wednesday, February 24, 2021

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

Bonita Montero <Bonita.Montero@gmail.com>: Feb 24 06:20PM +0100

> It does depend on the implementation if frequent reads can starve out
> writers.
 
But if this happens is a matter of the lock-behaviour.
Bonita Montero <Bonita.Montero@gmail.com>: Feb 24 06:22PM +0100

> is to have OS support to kill those clients and have it unlock the locks
> it held on to. (It could not kill but just deny further access depending
> on the resource).
 
We're talking about locks which protect shared datastructures. In this
case it would be stupid to kill a process or thread holding such a lock.
Richard Damon <Richard@Damon-Family.org>: Feb 24 01:28PM -0500

On 2/24/21 12:22 PM, Bonita Montero wrote:
>> on the resource).
 
> We're talking about locks which protect shared datastructures. In this
> case it would be stupid to kill a process or thread holding such a lock.
 
A lock that works with the OS to so the OS knows what locks the process
holds can kill a 'bad' process and force the release of the lock.
 
The only way to handle 'bad' processes, is for there to be some
mechanism to deny that process access to the resource that it has taken
the lock on, so it can be given to someone else. That capability is
typically reserved to the OS.
 
Yes, if you abort a process in the middle of its operation, you may need
to do some 'cleanup' on the resource, but if the process isn't releasing
the resource in the required time, can you really trust that it is doing
its job right?
mickspud@potatofield.co.uk: Feb 24 09:23AM

On Tue, 23 Feb 2021 17:34:00 GMT
 
>>if something goes wrong. Its called a Kernel panic or blue screen in Windows.
 
>Windows is hardly an exemplar of operating system design. I've been
>writing operating systems for four decades, and I stand by my assertion.
 
I was thinking of *nix mainly, my Windows dev experience is limited.
 
 
>It is quite possible for applications to be quite resiliant, when using
>real operating systems. Tandem non-stop comes to mind, and they're still
>chugging away (HPE).
 
Tandem was a specialist OS and will probably diverge from common OS's in how
threads and processes are demarcated. Anyway, the non-stop part is referring to
the OS maintaining the processes if some hardware goes down, not keeping them
alive if the process itself crashes.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 24 05:16PM +0100

On 11.02.2021 13:29, Mr Flibble wrote:
 
> I am starting work on creating a new Python implementation from scratch
[snip]
 
Possibly relevant: the Julia programming language, e.g. see
https://www.nature.com/articles/d41586-019-02310-3
 
- Alf
mickspud@potatofield.co.uk: Feb 24 05:01PM

On Wed, 24 Feb 2021 17:16:59 +0100
>On 11.02.2021 13:29, Mr Flibble wrote:
 
>> I am starting work on creating a new Python implementation from scratch
>[snip]
 
I missed that recent bit of bullshittery from the groups resident comedian.
There needs to be a new category beyond vapourware for his software,
perhaps Heisenbergware to go along with Heisenbugs - when you look for it it
magically vanishes.
antispam@math.uni.wroc.pl: Feb 24 01:27AM

> multiple times. We don't have to scan the cpu.c copyright header
> multiple times, and not do those #include's twice that are not affected
> by _GEN_ARCH.
 
Well, if you consider self inclusion as bad (or maybe very complicated)
thing, then as you showd one can do this without self inclusion.
I do not know why the authors prefered self inclusion. But they
have real need to compile the same code in few slightly different
contexts. And self inclusion solves this need. I find the code
quite readible and it works fine. I can speculate that they
used self inclusion because this keeps related code in single
file, but I do not know if this is real reason. Anyway, if you
look at this in unbiased way, then alternatives are really not
simpler.
 
--
Waldek Hebisch
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:
Subscribe to: Posts (Atom)