Saturday, January 16, 2021

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

Brian Wood <woodbrian77@gmail.com>: Jan 16 03:15PM -0800

On Thursday, January 14, 2021 at 5:23:17 PM UTC-6, Nikki Locke wrote:
 
> URL: http://www.trumphurst.com/cpplibs/
 
> This is a searchable list of libraries and utilities (both free
> and commercial) available to C++ programmers.
 
My software is simultaneously free and commercial --
similar to Duckduckgo. It might be better to say free
and/or commercial.
 
 
 
> 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
 
I thought I was slow getting https going.
 
 
Brian
Ebenezer Enterprises
https://github.com/Ebenezer-group/onwards
https://webEbenezer.net
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 16 03:22PM -0800

On 1/14/2021 3:23 PM, Nikki Locke wrote:
 
> 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.
 
Gotta love the following link!
 
http://www.trumphurst.com/TrumphurstRemoteControl.exe
 
lol.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 15 05:56PM -0800

On 1/15/2021 6:21 AM, Juha Nieminen wrote:
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> I think the code is more readable than with the std::-srpaying.
 
> Care to present an actual argument of why?
[...]
 
> Do you whine about having to write it in
> front of every name, and go on to create preprocessor macros to create
> names without that "png_" prefix?
 
Oh wow. I actually remember, around two decades ago, reading some code
where the author actually did that to pthreads. It made me laugh. Iirc,
it was something like:
 
#define tcreate pthread_create
#define tjoin pthread_join
 
ect...
 
 
wow.
 
[...]
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 15 08:13PM -0800

On 1/15/2021 2:22 AM, Chris M. Thomasson wrote:
>         m_state(state),
>         m_waitset(CreateSemaphore(nullptr, 0, LONG_MAX, nullptr))
>     {
 
Humm... should probably add in a check to make sure that state is > -1:
 
assert(m_state.load(std::memory_order_relaxed) > -1);
 
humm... ;^)
 
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 15 09:12PM -0800

On 1/15/2021 1:54 AM, Bonita Montero wrote:
>>>>      return futex( (uint32_t *)&m_semCounter, FUTEX_WAKE, 1,
>>>> nullptr, 0, 0 ) == 1;
>>>> }
 
also, you need to make sure that releasing a semaphore has at least
release memory order semantics. You used relaxed. Now, sometimes a
syscall can act like a "membar", but its not guaranteed.
 
Incrementing a semaphore needs to have at least release semantics.
 
Decrementing a semaphore must ensure at least acquire semantics.
 
This fits into using a binsema as a mutex where locking a mutex needs an
acquire membar, and unlocking needs a release. Where a binsema with an
initial state of 1, used as a mutex has a decrement to acquire, and an
increment to release.
 
Bonita Montero <Bonita.Montero@gmail.com>: Jan 16 07:45AM +0100

> also, you need to make sure that releasing a semaphore has at least
> release memory order semantics. You used relaxed. Now, sometimes a
> syscall can act like a "membar", but its not guaranteed.
 
Isn't needed because of the syscall.
"Öö Tiib" <ootiib@hot.ee>: Jan 16 02:12AM -0800

On Friday, 15 January 2021 at 22:59:25 UTC+2, Jorgen Grahn wrote:
> I suggest to drop the issue.
 
> For what it's worth, me and everyone I've worked with in recent years
> do it your way. But I think I've mentioned that before.
 
Yes large projects tend to be explicit indeed. How to know if it
is boost::numeric::ublas::vector, boost::container::pmr::vector,
boost::interprocess::vector or some other like that? Just be
explicit. Someone does not want to be explicit saying that if you hover
with mouse in some kind of visual studio over the name then it shows
long form in tooltip? Just don't hire him ... problem solved.
Pointless to argue and to waste time.
Bonita Montero <Bonita.Montero@gmail.com>: Jan 16 12:09PM +0100

> with mouse in some kind of visual studio over the name then it shows
> long form in tooltip? Just don't hire him ... problem solved.
> Pointless to argue and to waste time.
 
That's just a matter of taste.
"Öö Tiib" <ootiib@hot.ee>: Jan 16 07:56AM -0800

On Saturday, 16 January 2021 at 13:09:07 UTC+2, Bonita Montero wrote:
> > long form in tooltip? Just don't hire him ... problem solved.
> > Pointless to argue and to waste time.
 
> That's just a matter of taste.
 
Yes, and it is pointless to take someone with too different taste
into team. Resulting code base will look inconsistent garbage and
trying to achieve more consistency will waste precious time.
Bonita Montero <Bonita.Montero@gmail.com>: Jan 16 06:18PM +0100


> Yes, and it is pointless to take someone with too different taste
 
> into team. Resulting code base will look inconsistent garbage and
> trying to achieve more consistency will waste precious time.
 
But there's no better style here - but just different tastess.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 16 01:35PM -0800

On 1/15/2021 10:45 PM, Bonita Montero wrote:
>> release memory order semantics. You used relaxed. Now, sometimes a
>> syscall can act like a "membar", but its not guaranteed.
 
> Isn't needed because of the syscall.
 
Bonita Montero wrote:
 
> return futex( (uint32_t *)&m_semCounter, FUTEX_WAKE, 1, nullptr,
> 0, 0 ) == 1;
> }
 
But, either way, it is in the wrong place. A release barrier must be
placed _before_ the atomic logic that actually increments the semaphore.
So for releasing, or basically incrementing a semaphore, the release
membar must be:
 
using explicit standalone C++11 membars here for clarity. It shows
correct placement for semaphore memory order operations:
__________________________
// using windows semaphore for slowpath
struct ct_benaphore
{
std::atomic<long> m_state;
HANDLE m_waitset;
 
ct_benaphore(long state) :
m_state(state),
m_waitset(CreateSemaphore(nullptr, 0, LONG_MAX, nullptr))
{
if (! m_waitset) throw; // oh shit!
}
 
~ct_benaphore()
{
CloseHandle(m_waitset);
}
 
void inc()
{
std::atomic_thread_fence(std::memory_order_release);
 
if (m_state.fetch_add(1, std::memory_order_relaxed) < 0)
{
ReleaseSemaphore(m_waitset, 1, nullptr);
}
}
 
void dec()
{
if (m_state.fetch_sub(1, std::memory_order_relaxed) < 1)
{
WaitForSingleObject(m_waitset, INFINITE);
}
 
std::atomic_thread_fence(std::memory_order_acquire);
}
};
__________________________
 
 
So, your "membar" is in the wrong place, assuming syscall acts like a
barrier at all... Sometimes they can. Now, an acquire barrier needs to
be placed _after_ the atomic logic that decrements a semaphore.
"Öö Tiib" <ootiib@hot.ee>: Jan 16 02:54PM -0800

On Saturday, 16 January 2021 at 19:17:54 UTC+2, Bonita Montero wrote:
 
> > into team. Resulting code base will look inconsistent garbage and
> > trying to achieve more consistency will waste precious time.
> But there's no better style here - but just different tastess.
 
Yes there are no universal better. For you it is better to write ambiguous
code because of 5 characters less to type. For me it is better when such
people are not in my team. Tastes vary.
olcott <NoOne@NoWhere.com>: Jan 16 03:45PM -0600

On 1/14/2021 7:34 PM, Ben Bacarisse wrote:
 
>> The Linz H would simply be Halts() in global mode.
 
> Then you don't need any of the others. The others are there for you to
> pull of your huckster trick.
 
OK then.
Halts() simply returns its result to the command line and then halts.
 
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
return;
}
 
int main()
{
Halts((u32)H_Hat, (u32)H_Hat);
}
 
_H_Hat()
[00000879](01) 55 push ebp
[0000087a](02) 8bec mov ebp,esp
[0000087c](01) 51 push ecx
[0000087d](03) 8b4508 mov eax,[ebp+08]
[00000880](01) 50 push eax
[00000881](03) 8b4d08 mov ecx,[ebp+08]
[00000884](01) 51 push ecx
[00000885](05) e8fffdffff call 00000689
[0000088a](03) 83c408 add esp,+08
[0000088d](03) 8945fc mov [ebp-04],eax
[00000890](04) 837dfc00 cmp dword [ebp-04],+00
[00000894](02) 7402 jz 00000898
[00000896](02) ebfe jmp 00000896
[00000898](02) 8be5 mov esp,ebp
[0000089a](01) 5d pop ebp
[0000089b](01) c3 ret
 
_main()
[000008a9](01) 55 push ebp
[000008aa](02) 8bec mov ebp,esp
[000008ac](05) 6879080000 push 00000879
[000008b1](05) 6879080000 push 00000879
[000008b6](05) e8cefdffff call 00000689 ; Call Halts(H_Hat,H_Hat)
[000008bb](03) 83c408 add esp,+08
[000008be](02) 33c0 xor eax,eax
[000008c0](01) 5d pop ebp
[000008c1](01) c3 ret
 
 
Output_Debug_Trace() Trace_List.size(20)
---[000008a9](01) 55 push ebp
---[000008aa](02) 8bec mov ebp,esp
---[000008ac](05) 6879080000 push 00000879
---[000008b1](05) 6879080000 push 00000879
---[000008b6](05) e8cefdffff call 00000689 ; Call
Halts(H_Hat,H_Hat)
---[00000879](01) 55 push ebp
---[0000087a](02) 8bec mov ebp,esp
---[0000087c](01) 51 push ecx
---[0000087d](03) 8b4508 mov eax,[ebp+08]
---[00000880](01) 50 push eax
---[00000881](03) 8b4d08 mov ecx,[ebp+08]
---[00000884](01) 51 push ecx
---[00000885](05) e8fffdffff call 00000689 ; Call
Halts(H_Hat,H_Hat)
---[00000879](01) 55 push ebp
---[0000087a](02) 8bec mov ebp,esp
---[0000087c](01) 51 push ecx
---[0000087d](03) 8b4508 mov eax,[ebp+08]
---[00000880](01) 50 push eax
---[00000881](03) 8b4d08 mov ecx,[ebp+08]
---[00000884](01) 51 push ecx
---[00000885](05) e8fffdffff call 00000689 --CALL [00000689]
The PRIOR Instruction Specifies Infinite Recursion: Simulation Stopped:
 
The fact that the above execution trace matches the [Infinite Recursion
detection criteria] combined with the fact that this criteria can be
verified as [self-evidently true] (verified as totally true entirely
based on its meaning_ proves that Halts() does correctly decide H_Hat().
 
Infinite Recursion detection criteria (self-evident truth)
(a) Within an execution trace
(b) The same function is called
(c) From the same machine address
(d) With the same data // Richard Damon credit
(e) A second time
(f) Without any control flow instructions inbetween
 
 
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
"Öö Tiib" <ootiib@hot.ee>: Jan 16 12:54AM -0800

On Tuesday, 12 January 2021 at 22:53:27 UTC+2, Jorgen Grahn wrote:
> What is it about JSON which makes parsing speed so essential, anyway?
> You'd think the actual I/O, plus the business logic, would dwarf the
> parsing work for most use cases.
 
Lot of projects use directories of json or xml as their
data files. Usually compressed ... say 20 MB of directory
structure of json files compresses to 1.6 MB data file.
Modern SSD tend to perform awesomely, decompression
algorithms are great ... and so the bottle neck can be json
parsing. If file is opened 3 sec or 20 sec makes significant
difference in perceived performance.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 15 07:17PM -0500

I wanted to take a moment and say thank you to everyone for being a
part of my life. I know we don't always see eye-to-eye on everything,
but a vast overwhelming majority of you I respect greatly. I admire
your skills, your devotion to your love here in these groups.
 
I'm glad you're a part of my life. And I wish we could be a part of
each other's lives more than we are presently.
 
--
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)