Tuesday, February 12, 2019

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

"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Feb 11 10:32PM -0800

> Thanks to many suggestions of people on here and reddit here's the event object implementation I came up with: http://blog.vorbrodt.me/?p=556
 
Fwiw, actually, I remember several use cases for the auto-reset event.
One is to treat it like the "slow" sema in the fast semaphore. Instead
of a semaphore, this is a mutex developed by Alex Terekhov. He showed it
to me back on comp.programming.threads. Iirc, it should be in the
following source code for a pthread_mutex_t:
 
https://www.sourceware.org/pthreads-win32
 
Have translated it back in the day to C++ _before_ threads, atomics and
membars. Have translated it to several assembly languages, but not C++11.
 
I have not tested your code in a Relacy test unit yet. They look fine,
but it is good to test them. A great test would be to use the auto-reset
event as the slow path for a mutex.
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Feb 11 10:47PM -0800

On 2/11/2019 10:32 PM, Chris M. Thomasson wrote:
 
> I have not tested your code in a Relacy test unit yet. They look fine,
> but it is good to test them. A great test would be to use the auto-reset
> event as the slow path for a mutex.
 
Interested? :^)
mvorbrodt@gmail.com: Feb 12 05:48AM -0800

On Tuesday, February 12, 2019 at 1:48:13 AM UTC-5, Chris M. Thomasson wrote:
> > but it is good to test them. A great test would be to use the auto-reset
> > event as the slow path for a mutex.
 
> Interested? :^)
 
yes, interested :) please email me directly at martin@vorbrodt.me and we can work on implementing it in modern C++ :)
mvorbrodt@gmail.com: Feb 12 08:01AM -0800

On Tuesday, February 12, 2019 at 1:32:31 AM UTC-5, Chris M. Thomasson wrote:
 
> I have not tested your code in a Relacy test unit yet. They look fine,
> but it is good to test them. A great test would be to use the auto-reset
> event as the slow path for a mutex.
 
This?
 
class fast_mutex
{
public:
fast_mutex() : m_event(true) {}
 
void lock() noexcept
{
m_event.wait();
}
 
void unlock() noexcept
{
m_event.signal();
}
 
private:
auto_event m_event;
};
 
Or this?
 
class fast_mutex
{
public:
fast_mutex() : m_semaphore(1) {}

void lock() noexcept
{
m_semaphore.wait();
}

void unlock() noexcept
{
m_semaphore.post();
}

private:
fast_semaphore m_semaphore;
};
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Feb 12 02:43PM -0800

>> but it is good to test them. A great test would be to use the auto-reset
>> event as the slow path for a mutex.
 
> This?
[...]
> Or this?
[...]
 
Neither. It is using some atomics for the fast-path of the mutex before
the slow-path is engaged. Think of an auto-reset event as a binary
semaphore. Will have some more time later on today, or tomorrow. Take a
look at the source code for a pthread_mutex_t in pthreads-win32. It is
in there. Very similar to the fast semaphore avoiding calls into the
"slow" mutex/cond slow-path.
Paul <pepstein5@gmail.com>: Feb 12 02:42PM -0800

The strong birthday problem asks for the minimum positive number of people so that the probability that no person in the set has a unique birthday >= 50%. The literature gives this number as 3064. Obvious assumptions: By "unique birthday", I mean the month/day. Birthdays assumed to be uniformly distributed throughout the year. Assume no one born in a leap year. I've done many simulations and my answers (output to the console) are consistently in the 3019-3021 range. I get 3019 with C++'s std::rand() and also with the later C++11 random number generators. I'd be very grateful to understand what I'm doing wrong? As a check, I used the same approach for the standard birthday problem, and I do indeed get the textbook answer of 23 for that one.
Code is below.
Thank you very much for your help.
 
#include <iostream>
#include <vector>
#include <algorithm>
#include <random>
 
int main()
{
constexpr int num = 1000001;
constexpr int daysInYear = 365;
std::vector<int> numTrials(num);
std::default_random_engine generator;
std::mt19937 gen(generator());
std::uniform_int_distribution<int> distribution(0,364);
for(int i = 0; i < num; ++i)
{
int counter = 0;
std::vector<int> calendar(daysInYear);
int numOdd = 0;
do
{
const int next = distribution(gen);
++calendar[next];
if(calendar[next] == 1)
++numOdd;
else if(calendar[next] == 2)
--numOdd;
++counter;
}
while(numOdd);
 
numTrials[i] = counter;
}
std::sort(numTrials.begin(), numTrials.end());
std::cout << numTrials[num/2];
 
}
mvorbrodt@gmail.com: Feb 12 11:46AM -0800

My blog entry about designing a simple thread pool using only standard C++ components: http://blog.vorbrodt.me/?p=631
 
Enjoy!
viren patel <patel.viren.b1@gmail.com>: Feb 11 05:34PM -0800

> You can use Boost in MFC.
 
> Cheers!,
 
> - Alf
 
thank you so much !
viren patel <patel.viren.b1@gmail.com>: Feb 11 05:35PM -0800

> in bad).
 
> Or if this is really just a single list control you want to display, it
> might be that a common tool like zenity or wish can do the work.
 
thank you so much !
viren patel <patel.viren.b1@gmail.com>: Feb 11 05:35PM -0800

> Just use std::list instrad of CListCtrl - that's the same.
 
thank you so much !
viren patel <patel.viren.b1@gmail.com>: Feb 11 05:36PM -0800

> > Just use std::list instrad of CListCtrl - that's the same.
 
> std::list is an analogue of MFC's CList, not CListCtrl.
 
thank you so much !
viren patel <patel.viren.b1@gmail.com>: Feb 11 05:38PM -0800

On Friday, February 8, 2019 at 6:01:00 PM UTC-8, viren patel wrote:
> hello friends, struggling with finding MFC - CListCtrl equivalent to linux c++ boost. any suggestions please ?
 
thank you so much all for your help !!
Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 12 06:46AM

On Sun, 2019-02-10, Christian Gollwitzer wrote:
>> or without MFC)
 
> Don't get hooked up, he is an obvious troll. His nickname already tells
> this (it's German for "Just for fun")
 
And if he isn't, his style of communication (see above) makes
responding meaningless anyway.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Bonita Montero <Bonita.Montero@gmail.com>: Feb 12 09:17AM +0100


>> No, you're wrong, I'm right.
 
> Certainly you have never programmed GUI applications for
> Windows (with or without MFC)
 
I'm right!
You can simply BASE64-encode whatever you want to store
and put it in CListCtrl and decode it when you read it!
Of course, not everyone knows such professional technology.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 12 06:08PM

On 09/02/2019 02:00, viren patel wrote:
> hello friends, struggling with finding MFC - CListCtrl equivalent to linux c++ boost. any suggestions please ?
 
Seriously you need to stop using MFC NOW!
 
/Flibble
 
--
"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," Bryne 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."
red floyd <dont.bother@its.invalid>: Feb 11 04:12PM -0800

On 2/11/2019 11:14 AM, Alf P. Steinbach wrote:
 
>> So it is defined, it is valid, and no warning is required.  At least
>> as of C++03.
 
> The problem isn't lack of a `return` statement, it's the implicit `int`.
 
Ah, I totally missed the implicit int. I guess it's a case of seeing
what you are expecting to see. Sorry about that, and thanks for
pointing it out!
ailynkasabroso@gmail.com: Feb 11 08:50PM -0800

Ok.
 
#include <iostream>
 
template<typename T>
class Test;
 
template<typename T>
Test<T> operator + (const Test<T>& lhs, const Test<T>& rhs);
 
template<typename T>
class Test
{
// this "friend" compiles
//friend Test<T> operator + <T> (const Test<T>& lhs, const Test<T>& rhs);
public:
explicit Test(T value)
: m_value(value)
{
}
 
// we comment this operator then it compiles
Test operator + (T value)
{
return Test(m_value + value);
}
 
private:
// this "friend" doesn't compile
friend Test<T> operator + <T> (const Test<T>& lhs, const Test<T>& rhs);
// this "friend" compiles
//friend Test<T> operator + (const Test<T>& lhs, const Test<T>& rhs)
//{
// return Test<int>(lhs.m_value + rhs.m_value);
//}
T m_value;
};
 
template<typename T>
Test<T> operator + (const Test<T>& lhs, const Test<T>& rhs)
{
return Test<T>(lhs.m_value + rhs.m_value);
}
 
int main(int argc, char* argv[])
{
Test<int> t1(5);
Test<int> t2(6);
Test<int> t3 = t1 + t2;
}
 
Obviously question is not about returned value/signature of main.
 
I don't think "friend Test<T> operator + <T> (const Test<T>& lhs, const Test<T>& rhs);" is syntactic error.
 
https://en.cppreference.com/w/cpp/language/friend
Go to section friend operators and you will find "friend std::ostream& operator<< <> (std::ostream&, const Foo&);"
If you want you can replace "<T>" by "<>" - effect will be same.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 12 07:23AM +0100

> Test<int> t3 = t1 + t2;
> }
 
> Obviously question is not about returned value/signature of main.
 
When you post in clc++, expect everything to be dissected. ;-)
 
It can be a good learning experience.
 
 
 
 
> https://en.cppreference.com/w/cpp/language/friend
> Go to section friend operators and you will find "friend std::ostream& operator<< <> (std::ostream&, const Foo&);"
> If you want you can replace "<T>" by "<>" - effect will be same.
 
Ooops. You're right.
 
I've never seen this before, but it picks up the non-static member
function of same name, and somehow thinks this `friend` declaration is a
data member declaration.
 
One fix is to qualify with namespace:
 
friend auto ::operator + <T> (const Test<T>& lhs, const Test<T>&
rhs) -> Test<T>;
 
Which illustrates that something can be repaired without quite
understanding the problem.
 
That's often the case.
 
Hopefully others will chime in with an /explanation/.
 
 
Cheers!
 
- 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)