Monday, December 14, 2020

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

Nikki Locke <nikki@trumphurst.com>: Dec 14 11:23PM

Available C++ Libraries FAQ
 
URL: http://www.trumphurst.com/cpplibs/
 
This is a searchable list of libraries and utilities (both free
and commercial) available to C++ programmers.
 
If you know of a library which is not in the list, why not fill
in the form at http://www.trumphurst.com/cpplibs/cppsub.php
 
Maintainer: Nikki Locke - if you wish to contact me, please use the form on the website.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 14 01:07AM

On Sun, 13 Dec 2020 13:50:18 -0800
> object is fully initialized. It is a common error wrt creating thread
> base classes. Try not launch threads in the ctor, that act on the object
> being constructed in the first place!
 
There is no real difference in the requirements for proper sequencing
and (where appropriate) thread synchronization of data objects as
regards code in the body of a constructor and code in the body of any
other method of a class. By the time the constructor is entered all
member sub-objects will have been initialized to their initial state,
so far as they have one (default initialized trivial types may not have
one), including by any member initializer list.
 
The problem is with calling virtual functions in a base constructor.
This is only really acceptable if you suppress the virtual call by
using an explicit base class scope operator.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 13 05:25PM -0800

On 12/13/2020 5:07 PM, Chris Vine wrote:
 
> The problem is with calling virtual functions in a base constructor.
> This is only really acceptable if you suppress the virtual call by
> using an explicit base class scope operator.
 
I have seen many problems with a ctor of a derived class from a thread
object base thing, starting the thread that calls into the derived
class. There is a race condition. The thread can call into the derived
class before the ctor had a chance to complete.
 
<pseudo-code>
 
 
struct thread_base
{
virtual void enter() = 0;
 
void create()
{
// create a thread that calls
// raw_thread_entry with a pointer to this
}
 
static void raw_thread_entry(thread_base* b)
{
b->enter();
}
};
 
 
struct derived : public thread_base
{
derived()
{
// some stuff
create();
// some more stuff...
}
 
void enter()
{
// ummm, this can be called before the ctor completes!
}
};
 
 
Iirc, it went something like that. Then there was the problem that
thread_base::raw_thread_entry was not pure C, or something. Technically,
undefined behavior with pthreads. It been a while.
Bonita Montero <Bonita.Montero@gmail.com>: Dec 14 07:10AM +0100

> Try to emulate in Relacy.
 
Not necessary, it's already tested.
Marcel Mueller <news.5.maazl@spamgourmet.org>: Dec 14 08:45AM +0100

Am 13.12.20 um 21:14 schrieb Alf P. Steinbach:
 
> One of the most common kinds of bug in Java/C# is calling a derived
> class method or during initialization, before the derived class' class
> invariant (the basic assumptions about the state) has been established.
 
I can't confirm this. In the last two decades I never remember that I or
one of my co-workers run into such a bug in Java or C# (which shares the
same behavior).
Of course, you can run into undefined behavior. But you can do this as
well when calling /any/ non-virtual member function from a constructor
or destructor.
 
> That bug is almost non-existent in C++, due to the behavior described
> above. That absence of a whole kind of problem is IMO very useful.
 
Unfortunately the behavior prevents some very useful use cases, i.e.
extending the construction or destruction behavior by a sub class.
A work around is repeated code for an (un)init call in the deepest sub
class constructor or destructor and only there. This is much more error
prone. You need always a second protected constructor or a boolean
argument for further sub classes.
Or you have to push the problem to the application code, which is even
worse, especially in case of the destructor.
 
 
Marcel
Bonita Montero <Bonita.Montero@gmail.com>: Dec 14 09:58AM +0100

> One of the most common kinds of bug in Java/C# is calling a derived
> class method or during initialization, before the derived class' class
> invariant (the basic assumptions about the state) has been established.
 
Is that really a bug but not just a specified different behaviour
than in C++ ?
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 14 10:56AM

On Sun, 13 Dec 2020 17:25:59 -0800
[snip]
 
> Iirc, it went something like that. Then there was the problem that
> thread_base::raw_thread_entry was not pure C, or something. Technically,
> undefined behavior with pthreads. It been a while.
 
Sure, as I said, the problem is with virtual functions.
 
In other words, I think your "Try not launch threads in the ctor, that
act on the object being constructed in the first place!" over-eggs the
pudding. Subject to the normal rules on sequencing and synchronization,
there is no problem with accessing member data of the object under
construction because the member data are intialized before the
constructor is entered. The problem is with calling virtual functions
in constructors except through a scoping operator, irrespective of
whether you are launching threads or doing anything else.
Bonita Montero <Bonita.Montero@gmail.com>: Dec 14 02:45PM +0100

>         m_timeout = msTimeout;
>     else
>         m_timeout = milliseconds( -1 );
m_queueCv.notify_all();
> }
 
Otherwise the threads will begin their waiting-period only
after they've processed a queue-entity.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 14 01:45PM -0800

On 12/13/2020 10:10 PM, Bonita Montero wrote:
>> Try to emulate in Relacy.
 
> Not necessary, it's already tested.
 
Well, it does not hurt to emulate it in a race detector, just for fun?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 14 03:17PM -0800

On 12/14/2020 2:56 AM, Chris Vine wrote:
> there is no problem with accessing member data of the object under
> construction because the member data are intialized before the
> constructor is entered.
 
I was basically referring to the stuff in the ctor:
 
>> create();
>> // some more stuff...
>> }
 
create(); can operate on the object before "some more stuff..." is
committed. Wrt threads, sometimes the thread will start after its
finished, and all is well... Other times it can run right then and
there, and operate on the object before "some more stuff..." had a
chance to run, or right in the middle of it. I have seen code like this
in the past.
 
 
The problem is with calling virtual functions
> in constructors except through a scoping operator, irrespective of
> whether you are launching threads or doing anything else.
 
Basically, I like to create the object fully, then run the thread. Only
run threads after all ctors are finished.
olcott <NoOne@NoWhere.com>: Dec 14 09:16AM -0600

On 12/14/2020 8:48 AM, André G. Isaak wrote:
> Halts(H_Hat, H_Hat) invoked from within H_Hat must be aborted as a
> non-halting function.
 
> This is a contradiction.
 
As I have said very many times (no one notices because they only glance
at a few of my words to contrive some lame basis for a rebuttal that
would fool the gullible):
 
Halts(H_Hat, H_Hat) is only a finite computation because it aborts the
otherwise infinite recursion of its input according to this criteria:
 
On 11/27/2020 9:02 PM, Ben Bacarisse wrote:
> A computation that would not halt if its simulation were not
> halted is indeed a non-halting computation.
 
On Saturday, November 28, 2020 at 2:00:28 PM UTC-8, olcott wrote:
 
--
Copyright 2020 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
olcott <NoOne@NoWhere.com>: Dec 14 12:41PM -0600

On 12/14/2020 9:32 AM, Malcolm McLean wrote:
>>> A computation that would not halt if its simulation were not
>>> halted is indeed a non-halting computation.
 
> If Halts aborts itself, is it halted or aborted? That's the question.
 
Halts() simulates H_Hat() that invokes Halts() in infinite recursion.
Halts() stops simulating H_Hat() including its infinite recursive
invocation of Halts(), returning its non-halting decision to main()
where it is output.
 
> If we say "halted" then H_Hat inverts whatever result it returns,
 
It is not possible for an aborted function to invert any damn thing.
 
> and :Halts" is wrong. If we say "aborted" then "Halts" isn't a function,
> which is a slightly more subtle requirement of H_Hat.
 
Certainly an at least partial halt decider that bases its halting
decision by looking for patterns of behavior of its inputs can stop
simulating this input as soon as it detects any non-halting pattern.
 
It does not make any damn difference if it detects an infinite loop, or
infinite recursion. It also does not make any damn difference which
function is involved in infinite recursion. As long as Halts() detects
the non-halting behavior of its input then it can stop simulating this
input and report non-halting.
 
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
else
HALT
}
 
 
int main()
{
u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
Output("[Input_Would_Halt] =", Input_Would_Halt);
HALT;
}
 
I finally renamed my internal DebugTrace() to Halts() now that it
finally does return its correct halting decision to main().
 
--
Copyright 2020 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
spuddy@isnotyourbuddy.co.uk: Dec 14 08:53AM

On Fri, 11 Dec 2020 18:14:45 +0000
>> everyone is the same or processes visual information in the same way.
 
>Ah, so you are the person who used to post as "Boltar". You were a
>juvenile nobody then, and still a juvenile nobody now.
 
I do love irony :)
olcott <NoOne@NoWhere.com>: Dec 13 11:19PM -0600

On 12/13/2020 7:14 AM, Ben Bacarisse wrote:
 
>> Having an equivalent computation to the {Linz, Sipser} H correctly
>> deciding the Linz Ĥ, the Sipser D and the Kozen N is what I have.
 
> Which you will be (finally) posting today?
 
I just finished the programming of this.
I wanted to get it complete on the anniversary of its creation.
 
--
Copyright 2020 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:

Post a Comment

Subscribe to: Post Comments (Atom)