Wednesday, September 11, 2019

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

JiiPee <no@notvalid.com>: Sep 11 03:58PM +0100

On 11/09/2019 15:53, JiiPee wrote:
> So I am thinking that should all this data/functionality relating to
> opengl part of the program logic be left in the View or I should move
> all those member variables to ProgramLogic class?
 
 
I know there is no clear answer, but just asking if this "might" be a
good solution or possibility.
Paavo Helde <myfirstname@osa.pri.ee>: Sep 11 06:22PM +0300

On 11.09.2019 13:41, JiiPee wrote:
> The question is that should I have only windows-related code in the
> Window class and create another class dealing
> with the logic of the program?
 
In general, yes, in the Window class you should have only
windows-related logic.
 
Another way to think about that is that you want to put all your program
logic under unit tests control anyway. Simulating mouse clicks for unit
testing might not be so simple and would mix up testing the GUI and the
program logic, so most of the program should be testable without GUI.
 
So ideally you should first write your program logic classes together
with unit tests. Once the functionality is working and the tests are
passing, only then start adding windows related classes to expose this
functionality in GUI. Refactor, rinse and repeat as needed, unit tests
are now there and holding the functionality intact.
JiiPee <no@notvalid.com>: Sep 11 04:45PM +0100

On 11/09/2019 16:22, Paavo Helde wrote:
> passing, only then start adding windows related classes to expose this
> functionality in GUI. Refactor, rinse and repeat as needed, unit tests
> are now there and holding the functionality intact.
 
Did I understand correctly that you prefer something like 2)? that the
mouse action code is not in the Windows class at all?
 
Yes, I agree that for testing purposes its beneficial its separated, as
testing Windows class would be difficult :).
Paavo Helde <myfirstname@osa.pri.ee>: Sep 11 07:12PM +0300

On 11.09.2019 18:45, JiiPee wrote:
>> are now there and holding the functionality intact.
 
> Did I understand correctly that you prefer something like 2)? that the
> mouse action code is not in the Windows class at all?
 
No, in your example you just forwarded some GUI related logic to another
class, for no obvious reason. GUI logic should remain in the GUI
classes. In general, the program logic classes should not contain word
"mouse" or "click".
 
If you click a mouse "out of the border", this might affect the program
logic or not. Maybe you want to call PauseCalculation() on your app, for
example. If there really is no other effect than changing a message
string, then the mouse click function should call
logic.SetStatusMessage("...") or something like that.
 
Of course, borders are fuzzy here. YMMV.
JiiPee <no@notvalid.com>: Sep 11 05:51PM +0100

On 11/09/2019 17:12, Paavo Helde wrote:
> your app, for example. If there really is no other effect than
> changing a message string, then the mouse click function should call
> logic.SetStatusMessage("...") or something like that.
 
 
ok, so something like this:
 
void MyWindow::MouseClick(Point mousePosition)
{
    if(mousePosition.x > 150)
    {
        logic.SetStatusMessage("...");
    }
}
 
 
So you would leave the mouse condition check there ( if(mousePosition.x
red floyd <dont.bother@its.invalid>: Sep 11 09:56AM -0700

On 9/11/2019 9:51 AM, JiiPee wrote:
> }
 
> So you would leave the mouse condition check there ( if(mousePosition.x
> > 150)   ), but the action related to it would go to logic class?
 
Yes. Mouse position is related to the GUI.
 
There are a couple of paradigms related to this sort of thing:
* Model/View/Controller (MVC), where you classes representing the
data model, the view (GUI), and the controller (program logic)
* Document/View (used by MFC), where you have a view class (the GUI,
or in your case MyWindow), and the "Document" class, which contains
both the data model and the controlling logic.
Paavo Helde <myfirstname@osa.pri.ee>: Sep 11 08:24PM +0300

On 11.09.2019 19:51, JiiPee wrote:
> }
 
> So you would leave the mouse condition check there ( if(mousePosition.x
> > 150) ), but the action related to it would go to logic class?
 
Yes, exactly.
JiiPee <no@notvalid.com>: Sep 11 07:42PM +0100

On 11/09/2019 18:24, Paavo Helde wrote:
 
>> So you would leave the mouse condition check there ( if(mousePosition.x
>>  > 150)   ), but the action related to it would go to logic class?
 
> Yes, exactly.
 
ok thanks. Good to hear others points.
 
 
JiiPee <no@notvalid.com>: Sep 11 07:42PM +0100

On 11/09/2019 17:56, red floyd wrote:
>> if(mousePosition.x  > 150)   ), but the action related to it would go
>> to logic class?
 
> Yes.  Mouse position is related to the GUI.
 
 
thanks, good to get confirmation
 
 
> * Document/View (used by MFC), where you have a view class (the GUI,
>   or in your case MyWindow), and the "Document" class, which contains
>   both the data model and the controlling logic.
 
yes I use MFC, since 1996 :)
Szyk Cech <szykcech@spoko.pl>: Sep 11 08:16PM +0200

Hi all!
 
[What I want]
I want write reliable and modern Semaphore class.
I want write unit test to validate it.
 
[What I do]
I visited some education institution pages and inspired by it
I rewrote their examples. Addresses are:
http://sandbox.mc.edu/~bennet/cs422b/notes/semaphore_h.html
http://sandbox.mc.edu/~bennet/cs422b/notes/semaphore_cpp.html
 
As you can see this class is simple and silly as hell.
But it not works for me.
I have race conditions for unknown reasons.
It works in debuger. It works when I add some:
cout << "message" << endl << flush;
But not works in stand alone (debug and release both).
My system is Linux KDE Neon (based on Ubuntu 18.04 LTS).
My processor is Intel Core Duo (released in 2009).
 
[How to reproduce]
I paste here my code with complete minimal example.
It will compile in release mode.
It is fully automatic you need only to create 3 small files
and run: run.sh form commad line.
After 2-3 executions it hangs for unknown reasons.
 
Please help me! Thanks in advance and best regards!
Szyk Cech
 
[Files]
=============================================================
BEGIN: run.sh
 
#!/bin/bash
 
./make.sh
 
lCounter=0
 
while [ 1 ]; do
lCounter=$[lCounter + 1]
echo "Run: $lCounter"
./semtest
done
 
END: run.sh
 
=============================================================
 
BEGIN: make.sh
 
#!/bin/bash
g++ -std=c++17 -pthread -O2 -s -DNDEBUG ./Main.cpp -o semtest
 
END: make.sh
 
=============================================================
 
BEGIN: Main.cpp
 
#include <mutex>
#include <condition_variable>
#include <chrono>
#include <thread>
#include <vector>
#include <iostream>
 
 
using namespace std;
 
class Semaphore
{
public:
Semaphore(int aCounter);
 
public:
int value();
void up();
void down();
 
protected:
int mCounter;
std::mutex mAccessMutex;
std::condition_variable mWaitingCondition;
};
 
Semaphore::Semaphore(int aCounter)
: mCounter(aCounter)
{
}
 
int Semaphore::value()
{
return mCounter;
}
 
void Semaphore::down()
{
unique_lock lock(mAccessMutex);
--mCounter;
if(mCounter < 0)
mWaitingCondition.wait(lock);
}
 
void Semaphore::up()
{
unique_lock lock(mAccessMutex);
++mCounter;
if(mCounter <= 0)
mWaitingCondition.notify_one();
}
 
void SemTestThread(Semaphore* aSem)
{
aSem->down();
}
 
int main()
{
Semaphore lSem(5);
vector<thread> lArray;
lArray.resize(15);
 
for(unsigned long i(0); i < lArray.size(); ++i)
lArray[i] = thread(SemTestThread, &lSem);
 
bool lResult(true);
 
for(int i(0); i < 5; ++i)
lArray[i].join();
 
lResult = lResult && (lSem.value() == -10);
 
for(int i(10); i > 0; --i)
{
lSem.up();
lArray[15 - i].join();
lResult = lResult && (lSem.value() == -i + 1);
}
 
cout << "lResult: " << lResult << endl << flush;
// return EXIT_SUCCESS;
}
 
END: Main.cpp
Soviet_Mario <SovietMario@CCCP.MIR>: Sep 11 05:43PM +0200

Il 11/09/19 10:58, Juha Nieminen ha scritto:
>> Note its limitations, though. It's not thread-safe, for example.
 
> What do you mean it's not thread-safe? AFAIK errno is thread-local
> according to the standard.
 
maybe errno is such, but I think strerror should return a
pointer to an internal buffer which it alone reserves the
right to modify on subsequent calls.
In this buffer the function should copy the message (or
maybe it just sets the pointer to a more risky internally
maintained table ... much faster).
 
So if different threads calls the functions without notice,
one thread could get the error generated from the other ...
That's the little I have understood
 
 
but my main problem is : even including all possible
headers, QT IDE does not see strerror prototype.
 
Normally when I include sth, within seconds the intellisense
starts popping up the parameters type-info and return value.
Here it does not do so, and underlines the name in red as
unknown :\ :\
 
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
Paavo Helde <myfirstname@osa.pri.ee>: Sep 11 07:23PM +0300

On 11.09.2019 18:43, Soviet_Mario wrote:
 
> but my main problem is : even including all possible headers, QT IDE
> does not see strerror prototype.
 
"All possible headers" are not needed, man strerror clearly says it is
declared in <string.h>.
Thiago Adams <thiago.adams@gmail.com>: Sep 11 09:44AM -0700

On Wednesday, September 11, 2019 at 6:37:40 AM UTC-3, Keith Thompson wrote:
 
> The strerror function is not required to avoid data races with
> other calls to the strerror function. The implementation shall
> behave as if no library function calls the strerror function.
 
I recently came across this subject as well and I was wondering
why strerror is not thread safe. The answer I gave to myself is that
is probably because it uses locales. It is just a guess.
Soviet_Mario <SovietMario@CCCP.MIR>: Sep 11 07:19PM +0200

Il 11/09/19 18:23, Paavo Helde ha scritto:
>> does not see strerror prototype.
 
> "All possible headers" are not needed, man strerror clearly
> says it is declared in <string.h>.
 
thanks a lot.
I included C++ like headers, among them "plain" <string>
and guess what ?
the C++ header DONT have a strerror prototype.
But later I replaced that header with the C-like you
suggested, and exploring the code I found the prototype.
 
Many thanks Paavo !
 
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
Paavo Helde <myfirstname@osa.pri.ee>: Sep 11 08:32PM +0300

On 11.09.2019 20:19, Soviet_Mario wrote:
> I included C++ like headers, among them "plain" <string>
> and guess what ?
> the C++ header DONT have a strerror prototype.
 
That's expected. The C++ equivalent of <string.h> is <cstring>, not
<string>. And even with <cstring> you should call std::strerror(), not
strerror().
Thiago Adams <thiago.adams@gmail.com>: Sep 11 10:39AM -0700

On Wednesday, September 11, 2019 at 2:20:07 PM UTC-3, Soviet_Mario wrote:
> 1) Resistere, resistere, resistere.
> 2) Se tutti pagano le tasse, le tasse le pagano tutti
> Soviet_Mario - (aka Gatto_Vizzato)
 
You can create our own thread safe function replacing strerror.
 
int main(void)
{
printf("const char* mystrerror(int i){\n");
printf(" switch(i) {\n");
for (int i = 0; i < 134; i++)
{
printf(" case %d: return \"%s\";\n", i, strerror(i));
}
printf(" }\n");
printf(" return \"Unknown error\";\n");
printf("}");
}
 
I did this for curiosity in windows and linux.
Window prints "Unknown error" error >= 43
Linux prints "Unknown error 134" error >= 134
 
I also printed side by side. (I think is to big to put here)
There are some diferences for instance:
 
Linux | Windows
7 Argument list too long | Arg list too long
35 Resource deadlock avoided | Unknown error
 
etc..
peteolcott <Here@Home>: Sep 11 12:04PM -0500

On 9/11/2019 2:31 AM, Reinhardt Behm wrote:
>> point is an infinitesimally larger than 3.0: encoded as the first point in
>> the interval: (3,4]
 
> And between 3.0 and your "next" number (xnext) to the right is another real number: (3.0+xnext) / 2.
 
I specified a whole Infinitesimal number system:
Real_Part[Infinitesimal_Part] where the Infinitesimal_Part is the number
of geometric points offset from the real part.
 
0.0[1,∞] specifies the entire set of geometric points with a value
greater than zero on the number line which self-evidently corresponds
to the entire set of positive reals.
 
Notice that this entire set is countable using the set of positive integers.
 
--
Copyright 2019 Pete Olcott All rights reserved
 
"Great spirits have always encountered violent
opposition from mediocre minds." Albert Einstein
rick.c.hodgin@gmail.com: Sep 11 08:08AM -0700

On Wednesday, September 11, 2019 at 10:50:11 AM UTC-4, Mr Flibble wrote:
> 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."
 
https://www.youtube.com/watch?v=ZvEnIkz82A0&t=1s
 
"Trying hard now
It's so hard now
Trying hard now
 
"Gettin' strong now
Coming on, now
Gettin' strong now
 
"Gonna fly now
Flyin' high now
Gonna fly, fly, fly"
 
--
Rick C. Hodgin
Mr Flibble <flibble@i42.removethisbit.co.uk>: Sep 11 05:17PM +0100

Hi Fucktard. No I haven't removed your demented view on evolution from
my .sig: this was from my laptop which has a different .sig. Now fuck
off you egregious misogynist, homophobic batshit crazy cunt.
 
/Flibble
 
 
> "Gonna fly now
> Flyin' high now
> Gonna fly, fly, fly"
 
--
"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."
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)