Monday, May 11, 2020

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

boltar@nowhere.co.uk: May 11 10:03AM

On Mon, 11 May 2020 21:56:23 +1200
>> at all.
 
>Because it meets the standard's requirements, your code with the three
>changes I posted compiles and runs correctly with both clang and gcc.
 
You posted 2 changes, not 3 (unless you count your nonsense about not mixing
iostreams with stdio). And no, it doesn't compile on gcc never mind run. I
suggest you try it first next time.
David Brown <david.brown@hesbynett.no>: May 11 12:18PM +0200

>> same size?
 
> Long should always be the size of a CPU word. Long long is implementation
> dependent. In a sane world anyway.
 
Perhaps in your imagined world, those are the rules. Back here in the
world of real-life processors, C standards, and real-life platforms, the
rules are different.
 
"long" is at least 32-bit, and at least as big as "int". That is what
the C standards require. Usually it is either 32-bit or 64-bit, and
almost invariably 32-bit on 32-bit processors. For 64-bit processors,
it varies - some systems use 32-bit long, others 64-bit long. The
choice is generally made based on what reduces the work needed to move
code from 32-bit systems to 64-bit systems.
 
"long long" is at least 64-bit, and at least as big as "long". In
practice, that almost invariably means /exactly/ 64-bit. I have never
heard of a system that used anything else for "long long".
 
Both "long" and "long long" are implementation dependent.
 
If you make any assumptions about them other than what I wrote above,
you are wrong.
 
For those that want types for specific purposes, C99 brought in a range
of size-specific types (like uint32_t) and specific purpose types (like
uintptr_t). You'd be hard pushed to find a compiler that doesn't have
these available, even if you are using an older standard like C90 or C++98.
 
 
Personally, I don't see much use of "long" or "long long" in code.
Whenever these /might/ make sense, there are better types that specify
my needs more accurately. Other people might find them more useful.
But often their use is incorrect, or at least inappropriate and
needlessly non-portable.
Manfred <noname@add.invalid>: May 11 12:19PM +0200

>> same size?
 
> Long should always be the size of a CPU word. Long long is implementation
> dependent. In a sane world anyway.
 
Correction. That's the rationale for a plain 'int', not 'long'. On top
of this, historical reasons add up, obviously.
Manfred <noname@add.invalid>: May 11 12:31PM +0200

>> make sure that it won't compile and people will be less helpful.
 
> As I've said, it compiled on 4 different systems. If thats not enough then
> too bad.
 
You should look at
https://en.cppreference.com/w/cpp/named_req/Allocator
 
Then you'll see that your allocator does not meet the requirements as
dictated by the standard - which have not been specified for the sole
purpose of annoying people.
So no, "it compiled on 4 different systems" is not enough.
 
"I tried it, it compiled and it worked" is a good recipe for failure in C++.
boltar@nowhere.co.uk: May 11 10:55AM

On Mon, 11 May 2020 12:31:04 +0200
>purpose of annoying people.
>So no, "it compiled on 4 different systems" is not enough.
 
>"I tried it, it compiled and it worked" is a good recipe for failure in C++.
 
I'll go out and buy a Windows machine with a copy of VC++ to test all further
example code I post to usenet just to keep you pedants happy. That good
enough?
Juha Nieminen <nospam@thanks.invalid>: May 11 03:43PM

>>make sure that it won't compile and people will be less helpful.
 
> As I've said, it compiled on 4 different systems. If thats not enough then
> too bad.
 
Well, don't expect any more help from me, asshole.
Bonita Montero <Bonita.Montero@gmail.com>: May 11 05:47PM +0200

> Long should always be the size of a CPU word.
> Long long is implementation dependent. In a sane world anyway.
 
There are no rules that mandate either.
boltar@nowhere.co.uk: May 11 03:56PM

On Mon, 11 May 2020 15:43:31 +0000 (UTC)
 
>> As I've said, it compiled on 4 different systems. If thats not enough then
>> too bad.
 
>Well, don't expect any more help from me, asshole.
 
Point out where you actually gave me some useful help and I might feel upset
about that - its still not working on gcc despite trying various suggestions
from here. And its ARSEhole unless you're talking about donkeys or you prefer
the american dialect.
"Öö Tiib" <ootiib@hot.ee>: May 11 03:44AM -0700

On Monday, 11 May 2020 11:29:21 UTC+3, Bonita Montero wrote:
> >> Try to really understand it.
 
> > Try to think yourself instead of shooting nonsense from hip.
 
> Write me a benchmark to prove your assumptions.
 
Why should I write you benchmarks when you post groundless
bullshit? Benchmarks written by me can't cure your stupidity.
Bonita Montero <Bonita.Montero@gmail.com>: May 11 12:46PM +0200

> Why should I write you benchmarks when you post groundless
> bullshit?
 
You are not even able to argue against this "bullshit".
 
> Benchmarks written by me can't cure your stupidity.
 
You also aren't able to prove what you said.
So it's you who has groundless assumptions.
"Fred. Zwarts" <F.Zwarts@KVI.nl>: May 11 12:59PM +0200

Op 11.mei.2020 om 10:24 schreef Bonita Montero:
>> first place? To avoid the slow-path!
 
> But as I said the slow path is very unlikely to happen if you're
> in the situation where locks are only held a very short time.
 
But if the slow path is taken always, the locks are held for a long time
always.
 
--
Paradoxes in the relation between Creator and creature.
<http://www.wirholt.nl/English>.
Bonita Montero <Bonita.Montero@gmail.com>: May 11 01:05PM +0200

>> in the situation where locks are only held a very short time.
 
> But if the slow path is taken always, the locks are held for a long
> time always.
 
Doesn't change what I said.
"Öö Tiib" <ootiib@hot.ee>: May 11 04:39AM -0700

On Monday, 11 May 2020 13:46:35 UTC+3, Bonita Montero wrote:
> > Why should I write you benchmarks when you post groundless
> > bullshit?
 
> You are not even able to argue against this "bullshit".
 
Why should I argue when there is only groundless nonsense?
Nonsense without ground should be dismissed on the ground
of its groundlessness ... nothing to argue there.
 
 
> > Benchmarks written by me can't cure your stupidity.
 
> You also aren't able to prove what you said.
> So it's you who has groundless assumptions.
 
I said that you bullshit groundlessly like usual and that your
sentences do not make sense. It is proven by the fact that
you continue to post such sentences.
Bonita Montero <Bonita.Montero@gmail.com>: May 11 02:13PM +0200

> Why should I argue when there is only groundless nonsense?
> Nonsense without ground should be dismissed on the ground
> of its groundlessness ... nothing to argue there.
 
What I said isn't nonsense.
The "benefits" of adaptive locks have never been verified in practice.
"Öö Tiib" <ootiib@hot.ee>: May 11 05:49AM -0700

On Monday, 11 May 2020 15:13:44 UTC+3, Bonita Montero wrote:
> > Nonsense without ground should be dismissed on the ground
> > of its groundlessness ... nothing to argue there.
 
> What I said isn't nonsense.
 
It is classical groundless nonsense. Like "earth is flat" or
"moon landing was hoax".
 
> The "benefits" of adaptive locks have never been verified in practice.
 
Sure, and Elvis is alive.
Bonita Montero <Bonita.Montero@gmail.com>: May 11 02:54PM +0200

> It is classical groundless nonsense. Like "earth is flat" or
> "moon landing was hoax".
 
Compile this ...
 
#define _CRT_SECURE_NO_WARNINGS
#include <Windows.h>
#include <iostream>
#include <cstdint>
#include <cstdlib>
#include <vector>
#include <thread>
#include <random>
#include <atomic>
#include <csignal>
 
#pragma warning(disable: 6031)
#pragma warning(disable: 26495)
 
using namespace std;
 
struct spin_mutex
{
spin_mutex( uint32_t spinCount );
void lock();
void unlock();
uint64_t getSpinSuceeds();
uint64_t getSpinFails();
private:
uint32_t spinCount;
atomic<uint32_t> lockCounter;
HANDLE hEvent;
static
atomic<uint64_t> spinSucceeds,
spinFails;
};
 
atomic<uint64_t> spin_mutex::spinSucceeds = 0;
atomic<uint64_t> spin_mutex::spinFails = 0;
 
spin_mutex::spin_mutex( uint32_t spinCount ) :
spinCount( spinCount ),
lockCounter( 0 )
{
hEvent = CreateEvent( nullptr, false, false, nullptr );
}
 
void spin_mutex::lock()
{
uint32_t sc = spinCount;
for( ; sc; --sc )
{
uint32_t cmp = 0;
if( lockCounter.compare_exchange_weak( cmp, 1, memory_order_acquire,
memory_order_relaxed ) )
{
if( --sc ) // only count if it is not the first attempt to lock the mutex
spinSucceeds.fetch_add( 1, memory_order_relaxed );
return;
}
}
if( spinCount ) // only count fails if there's a spin-count
++spinFails;
if( lockCounter.fetch_add( 1, memory_order_acquire ) != 0 )
WaitForSingleObject( hEvent, INFINITE );
}
 
void spin_mutex::unlock()
{
if( lockCounter.fetch_sub( 1, memory_order_release ) != 1 )
SetEvent( hEvent );
}
 
inline
uint64_t spin_mutex::getSpinSuceeds()
{
return spinSucceeds;
}
 
inline
uint64_t spin_mutex::getSpinFails()
{
return spinFails;
}
 
void spendCycles( uint64_t cycles );
 
atomic<bool> stop = false;
HANDLE hEvtStop;
 
int main( int argc, char **argv )
{
if( argc < 7 )
return EXIT_FAILURE;
unsigned nThreads;
unsigned long long minNonLockedCycles, maxNonLockedCycles;
unsigned long long minLockedCycles, maxLockedCycles;
unsigned spinCount;
sscanf( argv[1], "%u", &nThreads );
sscanf( argv[2], "%llu", &minNonLockedCycles );
sscanf( argv[3], "%llu", &maxNonLockedCycles );
sscanf( argv[4], "%llu", &minLockedCycles );
sscanf( argv[5], "%llu", &maxLockedCycles );
sscanf( argv[6], "%u", &spinCount );
auto sigHandler = []( int signal ) -> void
{
::stop = true;
SetEvent( ::hEvtStop );
};
signal( SIGINT, sigHandler );
size_t const N_DELAYS = 1'000;
vector<uint64_t> nonLockedDelays( N_DELAYS );
vector<uint64_t> lockedDelays( N_DELAYS );
random_device rd;
uniform_int_distribution<uint64_t> uidNonLocked( minNonLockedCycles,
maxNonLockedCycles ),
uidLocked( minLockedCycles,
maxLockedCycles );
for( size_t i = 0; i != N_DELAYS; ++i )
nonLockedDelays[i] = uidNonLocked( rd ),
lockedDelays[i] = uidLocked( rd );
spin_mutex sm( spinCount );
auto thr = [&]( size_t iWaitNonLocked, size_t iWaitLocked )
{
auto getNextDelay = []( vector<uint64_t> delayVector, size_t iDelay )
-> size_t
{
size_t delay = delayVector[iDelay++];
if( iDelay == delayVector.size() )
iDelay = 0;
return delay;
};
spendCycles( getNextDelay( nonLockedDelays, iWaitNonLocked ) );
while( !stop.load( memory_order_relaxed ) )
sm.lock(),
spendCycles( getNextDelay( lockedDelays, iWaitLocked ) ),
sm.unlock(),
spendCycles( getNextDelay( nonLockedDelays, iWaitNonLocked ) );
};
vector<thread> threads;
uniform_int_distribution<size_t> uidIWait( 0, 999 );
for( unsigned t = 0; t != nThreads; ++t )
threads.emplace_back( thr, uidIWait( rd ), uidIWait( rd ) );
WaitForSingleObject( ::hEvtStop, INFINITE );
for( thread &t : threads )
t.join();
cout << "succeeds: " << sm.getSpinSuceeds() << endl;
cout << "fails: " << sm.getSpinFails() << endl;
}
 
... assemble this ...
 
PUBLIC ?spendCycles@@YAX_K@Z
_TEXT SEGMENT
?spendCycles@@YAX_K@Z PROC
test rcx, rcx
jz byebye
cycleLoop:
dec rcx ; roughly one jump per clock-cycle
jnz cycleLoop ; because there's only one branch-unit
byebye:
ret
?spendCycles@@YAX_K@Z ENDP
_TEXT ENDS
END
 
... link it.
And run it with the appropriate parameters to prove what you said.
Bonita Montero <Bonita.Montero@gmail.com>: May 11 02:56PM +0200

>> The "benefits" of adaptive locks have never been verified in practice.
 
> Sure, and Elvis is alive.
 
Tell me _one_ soure where appropriate spin-counts
are given or a way how they're determined.
Bonita Montero <Bonita.Montero@gmail.com>: May 11 03:34PM +0200

There were three little bugs in the C++-file.
1: hEvtStop wasn't initialized.
2: at the return of the signal handler the program was terminated.
3: the fail-counter wasn't incremented with relaxed memory ordering.
 
This should be o.k.:
 
#define _CRT_SECURE_NO_WARNINGS
#include <Windows.h>
#include <iostream>
#include <cstdint>
#include <cstdlib>
#include <vector>
#include <thread>
#include <random>
#include <atomic>
#include <csignal>
 
#pragma warning(disable: 6031)
#pragma warning(disable: 6387)
#pragma warning(disable: 26495)
 
using namespace std;
 
struct spin_mutex
{
spin_mutex( uint32_t spinCount );
void lock();
void unlock();
uint64_t getSpinSuceeds();
uint64_t getSpinFails();
private:
uint32_t spinCount;
atomic<uint32_t> lockCounter;
HANDLE hEvent;
static
atomic<uint64_t> spinSucceeds,
spinFails;
};
 
atomic<uint64_t> spin_mutex::spinSucceeds = 0;
atomic<uint64_t> spin_mutex::spinFails = 0;
 
spin_mutex::spin_mutex( uint32_t spinCount ) :
spinCount( spinCount ),
lockCounter( 0 )
{
hEvent = CreateEvent( nullptr, false, false, nullptr );
}
 
void spin_mutex::lock()
{
uint32_t sc = spinCount;
for( ; sc; --sc )
{
uint32_t cmp = 0;
if( lockCounter.compare_exchange_weak( cmp, 1, memory_order_acquire,
memory_order_relaxed ) )
{
if( --sc ) // only count if it is not the first attempt to lock the mutex
spinSucceeds.fetch_add( 1, memory_order_relaxed );
return;
}
}
if( spinCount ) // only count fails if there's a spin-count
spinFails.fetch_add( 1, memory_order_relaxed );
if( lockCounter.fetch_add( 1, memory_order_acquire ) != 0 )
WaitForSingleObject( hEvent, INFINITE );
}
 
void spin_mutex::unlock()
{
if( lockCounter.fetch_sub( 1, memory_order_release ) != 1 )
SetEvent( hEvent );
}
 
inline
uint64_t spin_mutex::getSpinSuceeds()
{
return spinSucceeds;
}
 
inline
uint64_t spin_mutex::getSpinFails()
{
return spinFails;
}
 
void spendCycles( uint64_t cycles );
 
atomic<bool> stop = false;
HANDLE hEvtStop;
 
int main( int argc, char **argv )
{
if( argc < 7 )
{
cout << "number of threads, min non locked cycles, max non locked
cycles, min locked cycles, max cycles, spin-count" << endl;
return EXIT_FAILURE;
}
unsigned nThreads;
unsigned long long minNonLockedCycles, maxNonLockedCycles;
unsigned long long minLockedCycles, maxLockedCycles;
unsigned spinCount;
sscanf( argv[1], "%u", &nThreads );
sscanf( argv[2], "%llu", &minNonLockedCycles );
sscanf( argv[3], "%llu", &maxNonLockedCycles );
sscanf( argv[4], "%llu", &minLockedCycles );
sscanf( argv[5], "%llu", &maxLockedCycles );
sscanf( argv[6], "%u", &spinCount );
auto sigHandler = []( int sig ) -> void
{
::stop = true;
SetEvent( ::hEvtStop );
signal( SIGINT, SIG_IGN );
};
signal( SIGINT, sigHandler );
::hEvtStop = CreateEvent( nullptr, FALSE, FALSE, nullptr );
size_t const N_DELAYS = 1'000;
vector<uint64_t> nonLockedDelays( N_DELAYS );
vector<uint64_t> lockedDelays( N_DELAYS );
random_device rd;
uniform_int_distribution<uint64_t> uidNonLocked( minNonLockedCycles,
maxNonLockedCycles ),
uidLocked( minLockedCycles,
maxLockedCycles );
for( size_t i = 0; i != N_DELAYS; ++i )
nonLockedDelays[i] = uidNonLocked( rd ),
lockedDelays[i] = uidLocked( rd );
spin_mutex sm( spinCount );
auto thr = [&]( size_t iWaitNonLocked, size_t iWaitLocked )
{
auto getNextDelay = []( vector<uint64_t> delayVector, size_t iDelay )
-> size_t
{
size_t delay = delayVector[iDelay++];
if( iDelay == delayVector.size() )
iDelay = 0;
return delay;
};
spendCycles( getNextDelay( nonLockedDelays, iWaitNonLocked ) );
while( !stop.load( memory_order_relaxed ) )
sm.lock(),
spendCycles( getNextDelay( lockedDelays, iWaitLocked ) ),
sm.unlock(),
spendCycles( getNextDelay( nonLockedDelays, iWaitNonLocked ) );
};
vector<thread> threads;
uniform_int_distribution<size_t> uidIWait( 0, 999 );
for( unsigned t = 0; t != nThreads; ++t )
threads.emplace_back( thr, uidIWait( rd ), uidIWait( rd ) );
WaitForSingleObject( ::hEvtStop, INFINITE );
for( thread &t : threads )
t.join();
cout << "succeeds: " << sm.getSpinSuceeds() << endl;
cout << "fails: " << sm.getSpinFails() << endl;
}
 
The asm-file is o.k..
But there are no "reasonable" values that could proof that adapive
locks make sense.
Bonita Montero <Bonita.Montero@gmail.com>: May 11 03:50PM +0200

>         auto getNextDelay = []( vector<uint64_t> delayVector, size_t
> iDelay ) -> size_t
OMG, does someone guess what's the mistake here ? ;-)
"Öö Tiib" <ootiib@hot.ee>: May 11 07:29AM -0700

On Monday, 11 May 2020 15:56:45 UTC+3, Bonita Montero wrote:
 
> > Sure, and Elvis is alive.
 
> Tell me _one_ soure where appropriate spin-counts
> are given or a way how they're determined.
 
For *adaptive* mutex? It has estimator inbuilt that uses few instructions
to do statistics and then does not to spin longer than twice of what
was estiated.
Bonita Montero <Bonita.Montero@gmail.com>: May 11 04:46PM +0200


> For *adaptive* mutex? It has estimator inbuilt that uses few instructions
> to do statistics and then does not to spin longer than twice of what
> was estiated.
 
You're dreaming ...
Why have this mutexes _static_ spin-counts at initilzation ?
But maybe you could convince me by naming a source for your wild
assumptions. But it would be unrealistic to exptect you could.
Bonita Montero <Bonita.Montero@gmail.com>: May 11 04:52PM +0200

> Why have this mutexes _static_ spin-counts at initilzation ?
 
Look at:
https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-initializecriticalsectionandspincount
So theres no adaptive spin-count.
 
So here's again my code. Now it outputs once a second the number of
failed ans successful spins:
 
#define _CRT_SECURE_NO_WARNINGS
#include <Windows.h>
#include <iostream>
#include <cstdint>
#include <cstdlib>
#include <vector>
#include <thread>
#include <random>
#include <atomic>
#include <csignal>
 
#pragma warning(disable: 6031)
#pragma warning(disable: 6387)
#pragma warning(disable: 26495)
 
using namespace std;
 
struct spin_mutex
{
spin_mutex( uint32_t spinCount );
void lock();
void unlock();
uint64_t getSpinSuceeds();
uint64_t getSpinFails();
private:
uint32_t spinCount;
atomic<uint32_t> lockCounter;
HANDLE hEvent;
static
atomic<uint64_t> spinSucceeds,
spinFails;
};
 
atomic<uint64_t> spin_mutex::spinSucceeds = 0;
atomic<uint64_t> spin_mutex::spinFails = 0;
 
spin_mutex::spin_mutex( uint32_t spinCount ) :
spinCount( spinCount ),
lockCounter( 0 )
{
hEvent = CreateEvent( nullptr, false, false, nullptr );
}
 
void spin_mutex::lock()
{
for( uint32_t sc = spinCount; sc; --sc )
{
uint32_t cmp = 0;
if( lockCounter.compare_exchange_weak( cmp, 1, memory_order_acquire,
memory_order_relaxed ) )
{
if( --sc ) // only count if it is not the first attempt to lock the mutex
spinSucceeds.fetch_add( 1, memory_order_relaxed );
return;
}
}
if( spinCount ) // only count fails if there's a spin-count
spinFails.fetch_add( 1, memory_order_relaxed );
if( lockCounter.fetch_add( 1, memory_order_acquire ) != 0 )
WaitForSingleObject( hEvent, INFINITE );
}
 
void spin_mutex::unlock()
{
if( lockCounter.fetch_sub( 1, memory_order_release ) != 1 )
SetEvent( hEvent );
}
 
inline
uint64_t spin_mutex::getSpinSuceeds()
{
return spinSucceeds.load( memory_order_relaxed );
}
 
inline
uint64_t spin_mutex::getSpinFails()
{
return spinFails.load( memory_order_relaxed );
}
 
void spendCycles( uint64_t cycles );
 
atomic<bool> stop = false;
HANDLE hEvtStop;
 
int main( int argc, char **argv )
{
if( argc < 7 )
{
cout << "number of threads, min non locked cycles, max non locked
cycles, min locked cycles, max cycles, spin-count" << endl;
return EXIT_FAILURE;
}
unsigned nThreads;
unsigned long long minNonLockedCycles, maxNonLockedCycles;
unsigned long long minLockedCycles, maxLockedCycles;
unsigned spinCount;
sscanf( argv[1], "%u", &nThreads );
sscanf( argv[2], "%llu", &minNonLockedCycles );
sscanf( argv[3], "%llu", &maxNonLockedCycles );
sscanf( argv[4], "%llu", &minLockedCycles );
sscanf( argv[5], "%llu", &maxLockedCycles );
sscanf( argv[6], "%u", &spinCount );
auto sigHandler = []( int sig ) -> void
{
::stop = true;
SetEvent( ::hEvtStop );
signal( SIGINT, SIG_IGN );
};
signal( SIGINT, sigHandler );
::hEvtStop = CreateEvent( nullptr, FALSE, FALSE, nullptr );
size_t const N_DELAYS = 1'000;
vector<uint64_t> nonLockedDelays( N_DELAYS );
vector<uint64_t> lockedDelays( N_DELAYS );
random_device rd;
uniform_int_distribution<uint64_t> uidNonLocked( minNonLockedCycles,
maxNonLockedCycles ),
uidLocked( minLockedCycles,
maxLockedCycles );
for( size_t i = 0; i != N_DELAYS; ++i )
nonLockedDelays[i] = uidNonLocked( rd ),
lockedDelays[i] = uidLocked( rd );
spin_mutex sm( spinCount );
using vui64_cit = vector<uint64_t>::const_iterator;
auto thr = [&]( vui64_cit itWaitNonLocked, vui64_cit itWaitLocked )
{
auto getNextDelay = []( vector<uint64_t> const &delays, vui64_cit it )
-> uint64_t
{
uint64_t delay = *it;
if( ++it == delays.end() )
it = delays.begin();
return delay;
};
while( !stop.load( memory_order_relaxed ) )
spendCycles( getNextDelay( nonLockedDelays, itWaitNonLocked ) ),
sm.lock(),
spendCycles( getNextDelay( lockedDelays, itWaitLocked ) ),
sm.unlock();
};
vector<thread> threads;
uniform_int_distribution<size_t> uidIWait( 0, N_DELAYS - 1 );
for( unsigned t = 0; t != nThreads; ++t )
threads.emplace_back( thr, nonLockedDelays.begin() + uidIWait( rd ),
lockedDelays.begin() + uidIWait( rd ) );
while( !stop.load( memory_order_relaxed ) )
if( WaitForSingleObject( ::hEvtStop, 1000 ) == WAIT_TIMEOUT )
{
cout << "succeeds: " << sm.getSpinSuceeds() << endl;
cout << "fails: " << sm.getSpinFails() << endl;
}
for( thread &t : threads )
t.join();
}
 
Asm:
 
PUBLIC ?spendCycles@@YAX_K@Z
_TEXT SEGMENT
?spendCycles@@YAX_K@Z PROC
test rcx, rcx
jz byebye
cycleLoop:
dec rcx ; roughly one jump per clock-cycle
jnz cycleLoop ; because there's only one branch-unit
byebye:
ret
?spendCycles@@YAX_K@Z ENDP
_TEXT ENDS
END
 
Compile, link - and show me which are the parameters that give an
appropriate spin-count.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 11 01:04PM +0200

On 11.05.2020 01:36, Mr Flibble wrote:
 
> Fucktards.
 
> Reddit is shit too.
 
> Fucktards.
 
I'm not the admin who blocked you, but I can comment in general.
 
The posting that got you blocked was apparently a link to a YouTube
video with Kenny Rogers, after a history of some (just a few) off topic
postings among about equally many accepted ones. However, a number of
other postings were deleted in the same action. I can't see what those
were about but likely they were previously accepted postings removed
automatically by Facebook: the Facebook machinery is not ideal.
 
- - -
 
The C++ Enthusiasts group was started by Prasoon Suarav, and is now
about 9000 members with three admins. I started a sister group about the
in-practice, as a place to direct one particular beginner who flooded
Enthusiasts with less generally interesting postings, and that group is
now roughly 11 500 members. You are not blocked there and would be a
welcome new member, in particular in view of your GUI work.
 
In the Enthusiasts group I'm an admin by invitation, and so are the
other admins Matt P. Dziubinski and (not active) Andrew Koenig.
 
Similarly, earlier in comp.lang.c++.moderated I was a moderator by
invitation. So, just as comp.lang.c++.moderated was not my Usenet group,
C++ Enthusiasts is not my Facebook group, but the sister group is still
mine since I haven't invited other admins.
 
- - -
 
A great many people share your sentiment about the proportion of ungood
people, trolls, as admins and regulars in C++ forums. For example, a few
days ago I subscribed to a Facebook group called Programming Jokes, and
I immediately saw a number of jokes about Stack Overflow. One went like:
 
A short story of Stack Overflow user.
Asked a question (graphic of happy)
Got idiot title with 16 downvotes in 6 min (graphic of despair)
 
So, it's common.
 
In fact C++ Enthusiasts was started because Prasoon was very unhappy
with the trolling and moderation at Stack Overflow. Someone else, here
in clc++, once described the Stack Overflow situation as the inmates
having taken over the asylum. Anonymous mods is not a good sign.
 
And from my own experience trolls also have a free rein at Reddit,
though they're much less active there than on Stack Overflow.
 
However, C++ Enthusiasts is clean of trolling.
 
And I guess that's because like comp.lang.c++.moderated in its time, C++
Enthusiasts is a non-commercial group with a small number of admins, who
are admins by invitation only.
 
 
- Alf
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 11 12:48PM +0100

On 11/05/2020 12:04, Alf P. Steinbach wrote:
 
> The posting that got you blocked was apparently a link to a YouTube video with Kenny Rogers, after a history of some (just a few) off topic postings among about equally many accepted ones. However, a number of other postings were deleted in the same action. I can't see what those were about but likely they were previously accepted postings removed automatically by Facebook: the Facebook machinery is not ideal.
 
>   - - -
 
> The C++ Enthusiasts group was started by Prasoon Suarav, and is now about 9000 members with three admins. I started a sister group about the in-practice, as a place to direct one particular beginner who flooded Enthusiasts with less generally interesting postings, and that group is now roughly 11 500 members. You are not blocked there and would be a welcome new member, in particular in view of your GUI work.
 
Could you post a link to that group please Alf?
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 11 03:32PM +0200

On 11.05.2020 13:48, Mr Flibble wrote:
>> group is now roughly 11 500 members. You are not blocked there and
>> would be a welcome new member, in particular in view of your GUI work.
 
> Could you post a link to that group please Alf?
 
https://www.facebook.com/groups/cppInPracticeQuestions/
 
- Alf
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)