Monday, January 11, 2021

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

"Öö Tiib" <ootiib@hot.ee>: Jan 10 06:26PM -0800

On Saturday, 9 January 2021 at 20:15:13 UTC+2, Manfred wrote:
> performance hit being significant due to a few padding bytes. /If/
> performance is suspect to be an actual problem, then demonstration
> first, sure.
 
But that performance is the only issue there can be theoretically (but does
not exist in practice) that raw array can solve.
 
> a possibly complex algorithm to handle some arbitrary padding between lines.
> I mean, the sport of using std::array<std::array<...>, ...> wouldn't
> justify such a rewrite per se.
 
Can you cite such algorithms? I understand that it goes on and on about
that possible (but unexisting) padding that possibly complicates some possible
(but nonexistent) algorithms. I can't argue as I can't prove negative that
such algorithms do not exist. IOW my position stands firm, it is still not
demonstrated that such issues exist.

> even written in different languages, that exchange binary data whose
> layout is part the contract. Then you want full control of such layout,
> including padding.
 
If there is already present C interface then there are no std::arrays in
it possible. So you mean such. legacy interfaces by "algorithmic
simplicity"? Have to carefully static_assert bit widths of every type
if you just want to reinterpret_cast or memcpy some C++ classes
into there bluntly.

> In such scenario I believe you don't want a std::array as a member of
> some struct that is passed through such interface. This is independent
> of performance, of course.
 
The std::array can't be in C interface anyway. The data layout
issue is already within C++ where enum foo {}; can one byte wide type
and enum class moo {}; four bytes wide on very same compiler.
Manfred <noname@add.invalid>: Jan 11 11:51PM +0100

On 1/11/2021 3:26 AM, Öö Tiib wrote:
>> I mean, the sport of using std::array<std::array<...>, ...> wouldn't
>> justify such a rewrite per se.
> Can you cite such algorithms?
 
Not from the top of my head, at this moment (and I am not going to try
any hard to remember one)
 
I understand that it goes on and on about
> (but nonexistent) algorithms. I can't argue as I can't prove negative that
> such algorithms do not exist. IOW my position stands firm, it is still not
> demonstrated that such issues exist.
 
I didn't mean to mount up a case on this.
We can leave it there.
olcott <NoOne@NoWhere.com>: Jan 11 01:54PM -0600

On 1/11/2021 12:53 PM, Kaz Kylheku wrote:
 
> I.e. you admit that your halting decider gives the wrong answer under
> the standard halting problem definition; to fix this, you are insising
> that everyone accept some alternative formulation of the problem,
Does the input halt on its input?
is a standard part of the halting problem undecidability proofs
IT IS NOT A STANDARD PART OF THE ACTUAL HALTING PROBLEM ITSELF.
 
The halting problem itself
IS ONLY CONCERNED WITH DIVIDING INPUTS INTO HALTING AND NON HALTING.
 
Does the simulation of the input have to be stopped to prevent its
otherwise infinite execution?
 
Does divide inputs into halting and not-halting.
 
 
 
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
olcott <NoOne@NoWhere.com>: Jan 11 02:53PM -0600

On 1/11/2021 2:17 PM, Kaz Kylheku wrote:
>> otherwise infinite execution?
 
> That is exactly the same question, unless "its" secretly equivocates
> between different objects.
 
No it is not because the question:
 
Does the input halt on its input?
 
Answers yes when:
(a) The simulation of the input has to be stopped to prevent its
otherwise infinite execution.
 
And also answers yes when:
(b) The simulation of the input terminates without having to be stopped.
 
This new question divides inputs into two distinct sets and the original
question does not.
 
The difference between the two questions is that the original question
has pathological self-reference(Olcott 2004) and the new question does not.
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 11 03:20AM

Jii Fox <kerrttu11@gmail.com> writes:
 
You posted this in comp.lang.c, probably because you used Google Groups
and that interface removes the ++ from the group name. I've just
re-posted it to comp.lang.c++, quoted. Maybe you'll get an answer that
way.
 
 
--
Ben.
Jii Fox <kerrttu11@gmail.com>: Jan 10 11:18PM -0800

On Monday, January 11, 2021 at 5:20:41 AM UTC+2, Ben Bacarisse wrote:
> way.
> --
> Ben.
 
oh, thank you. I am actually JiiPee from last year. I moved and cannot use the ThunderBirds anymore, so using alittle web browser now.
Oh, the browser version removes the ++ ....
Jii Fox <kerrttu11@gmail.com>: Jan 10 11:20PM -0800

(I re-post this because it went to C-group by accident first)
 
Say I have a card game and Windows to draw cards in the game:
 
class MainWindow
{
public:
// methods
void start();
private:
// fields
void drawCurrentGameSituation();
};
 
Then I create a Match class to handle one card game match between players:
 
class Match
{
public:
Match(MainWindow* pMainWnd) : mainWnd_{ pMainWnd }
{}
void playNextCard();
private:
MainWindow* mainWnd_;
};
 
 
then I could create a match in MainWindow something like this:
 
void MainWindow::start()
{
Match match{this};
match.start();
}
 
My question is that how can Match call MainWindow from its playNextCard() function when the game
situation needs to be updated (graphically) so that it could call a *private* drawCurrentGameSituation() function:
 
void Match::playNextCard()
{
// ERROR (the problem): this does not work because drawCurrentGameSituation() is private
mainWnd_->drawCurrentGameSituation();
}
 
I know I could make drawCurrentGameSituation(); public, but I feel it really should be private,
isnt it?
 
Also, I want this to work with concole windows (text based GUI), so using some Windows message is not a solution.
 
So how to solve this issue? I had many times similar issue like this. I wonder what tricks could
be used here. Or is there some totally different better approach to this existing?
Thanks
Richard Damon <Richard@Damon-Family.org>: Jan 11 07:15AM -0500

On 1/11/21 2:20 AM, Jii Fox wrote:
 
> So how to solve this issue? I had many times similar issue like this. I wonder what tricks could
> be used here. Or is there some totally different better approach to this existing?
> Thanks
 
I will ask you why you think this function should be private?
 
A private function tends to mean this is an internal implmentation
detail that others aren't supposed to really need to know about, only I
and my closest friends can use it (friendship being used to allow a
small number of outside elements to be considered part of me).
 
Your function drawCurrentGameSituation(), from the way you seem to want
to use it, seems to be an entry point for an external request, so should
be public.
Jii Fox <kerrttu11@gmail.com>: Jan 11 04:32AM -0800

On Monday, January 11, 2021 at 2:16:11 PM UTC+2, Richard Damon wrote:
> On 1/11/21 2:20 AM, Jii Fox wrote:
> I will ask you why you think this function should be private?
 
Oh ok, you think it should be public?
 
 
> Your function drawCurrentGameSituation(), from the way you seem to want
> to use it, seems to be an entry point for an external request, so should
> be public.
 
Because I am thinking that the drawCurrentGameSituation() is a private operation only between Match object and the Window, so why expose it elsewhere? Like if you create a Window, you would never call it alone outside Match object, right?
An example, lets create the game Windows:
 
int main()
{
MainWindow window;
window.drawCurrentGameSituation(); // 1
window.start(); // 2
window.drawCurrentGameSituation(); // 3
cout << window.getGameResult(); // 4
}
 
Above, I am just thinking, it makes sense to call (2) and (4) from the main, but it does not make sense to call (1) and (3) from outside MainWindow ?
So, in what situation all the public would need to draw the game situation like that? It would be very rare that from main() we would need to draw the game situation into the windows because the program is designed so that it is the Match objects responsibility always to draw the windows.
 
If we make a decision that it is the Match objects responsibility always to draw the game, then what reason would be to expose it to main()?
Richard Damon <Richard@Damon-Family.org>: Jan 11 08:00AM -0500

On 1/11/21 7:32 AM, Jii Fox wrote:
 
> Above, I am just thinking, it makes sense to call (2) and (4) from the main, but it does not make sense to call (1) and (3) from outside MainWindow ?
> So, in what situation all the public would need to draw the game situation like that? It would be very rare that from main() we would need to draw the game situation into the windows because the program is designed so that it is the Match objects responsibility always to draw the windows.
 
> If we make a decision that it is the Match objects responsibility always to draw the game, then what reason would be to expose it to main()?
 
Then you either need to decide that the Match object is 'part of the
implementation' of a Window, and have the MainWindow class make it a
friend, or make it public.
 
Making it a friend exposes ALL the internal details to it, so you need
to decide how much you want to expose to whom.
 
Part of the question comes to what if the Match object uses some other
classes to do some of its work, should those be able to call the draw
function too, or is it restricted to just the original Match class.
 
It really sounds like this operation is part of the API of the window
class. Access to classes is fairly broad in C++, just because some code
doesn't have a need to access something isn't a reason to hide that
operation from that code.
 
Access specifiers are about dividing internal details from external API.
Access is restricted to implementation details, and granted to the
defined interface. Things 'inside' the implementation have full access,
and need to be looked at if you change the implementation.
 
The question comes, do you really think of the Match object as
responsible for the display of the state of the game, and thus part of
the window system, or is it just a user of that system, and should be
accessing it through the API. The existence of the
drawCurrentGameSituation() function seems to imply to me that Match
isn't given implmentation responsibility for a window, and thus that
function is part of the API.
 
Another good question is what harm would it cause if someone
'unauthorized' called this function. My first guess is probably nothing
major, yes, you waste a lot of time doing the update, but nothing really
'breaks', so it can easily be part of the API.
Jii Fox <kerrttu11@gmail.com>: Jan 11 07:28AM -0800

Thanks for the detailed answer... it helps me to make decision.
 
"Making it a friend exposes ALL the internal details to it"
- Yes, I dont like this so much.
 
" or is it restricted to just the original Match class."
- In this project Match is a small class, so pretty sure only Match will be making drawing requests.
 
"It really sounds like this operation is part of the API of the window class."
- It surely would be the easiest solution. But I am a perfectionist, so I am scared if its not the best :).
 
"The existence of the drawCurrentGameSituation() function seems to imply to me that Match
isn't given implmentation responsibility for a window, "
- True. No details at all. Match does not have (and definitely should not have) any drawing/windows related stuff inside it. It only deals with the Match related things (like running/starting the games and player management).
 
"...and thus that function is part of the API."
- hmm, ok.
 
"Another good question is what harm would it cause if someone 'unauthorized' called this function."
- No harm. I can easily make is such that it causes no harm. Its only the thing "what is the perfect way to do it"... I am just doing this for learning purposes really. I know public access function very easily does the job, but just to learn new things (if there is some trick here to learn).
 
If you have any new ideas or final recommendation, am happy to hear.
Jii Fox <kerrttu11@gmail.com>: Jan 11 07:34AM -0800

On Monday, January 11, 2021 at 3:01:19 PM UTC+2, Richard Damon wrote:
> 'unauthorized' called this function. My first guess is probably nothing
> major, yes, you waste a lot of time doing the update, but nothing really
> 'breaks', so it can easily be part of the API.
 
What do you think of using a call back function (the Match class calls Windows class via callback function)? I was thinking it alot also. The limitation of it is that its more difficult to use it (needs to do all that reinterpret casts etc), plus passing the parameters gets a little more complicated.
 
Or is it best to think here (as the project is small ) that needs to keep things simple? Placing that draw function to be public of the Windows obviously is by far the most simple solution. I was just worried if it is logical to place it there.
Richard Damon <Richard@Damon-Family.org>: Jan 11 10:53AM -0500

On 1/11/21 10:34 AM, Jii Fox wrote:
>> 'breaks', so it can easily be part of the API.
 
> What do you think of using a call back function (the Match class calls Windows class via callback function)? I was thinking it alot also. The limitation of it is that its more difficult to use it (needs to do all that reinterpret casts etc), plus passing the parameters gets a little more complicated.
 
> Or is it best to think here (as the project is small ) that needs to keep things simple? Placing that draw function to be public of the Windows obviously is by far the most simple solution. I was just worried if it is logical to place it there.
 
My first thought was have you looked at the M-V-C structure (Model -
View - Controller)
 
 
The "Game" is divided into 3 major pieces.
 
First, the Model, it holds the state of the game, but makes no real
decisions except if a given move is valid, and after a move is recorded,
it invokes the View.
 
The View, is what knows how to display the game that is stored in the
Model. The view will be created with a pointer to the Model and will
give the model a pointer to itself, so the Model can inform it that it
needs to update (this is sort of your callback, but done in a type-safe
manner so no casting needed). The view will also likely link into the
Main Window to implement it drawing on its piece of the screen.
 
The Controller, this part 'runs' the came, and interacts with the user
through the main window too. Based on the input it gets, it sends
command to the Model to make the moves (either player input or its own
AI). Note, the controller doesn't worry about updating the screen after
a move, as that is the job of the Model, and the Controller actually
CAN'T do the update, as it doesn't have a pointer to the View object.
 
You achieve your desire to restrict access to the update display
function not by making it private, but by only giving the view object to
those that need it.
Jii Fox <kerrttu11@gmail.com>: Jan 11 11:11AM -0800

On Monday, January 11, 2021 at 5:54:00 PM UTC+2, Richard Damon wrote:
 
> My first thought was have you looked at the M-V-C structure (Model -
> View - Controller)
 
> The "Game" is divided into 3 major pieces.
 
Yes I am familiar with it. Actually I use MFC and Document/Window/Frame there which is similar.
 
 
> You achieve your desire to restrict access to the update display
> function not by making it private, but by only giving the view object to
> those that need it.
 
Yes you got me thinking. So I am actually now planning to put all draw/UI functions into public section so that becomes an API.
I might come back after ready....
olcott <NoOne@NoWhere.com>: Jan 11 01:04PM -0600

On 9/5/2004 11:21 AM, Peter Olcott wrote:
> If we construe pathological self-reference as another
> error condition, then this does remove the impossibility
> of creating a useful tool.
 
The conventional halting problem undecidability proofs conclude that no
universal halt decider can possibly exist on the basis that a particular
class of universal halt deciders cannot possibly exist.
 
It seems to be true that no universal halt decider exists that attempts
to divide all of its inputs into halting and not halting on the basis of
answering the question:
 
Does the input program halt on its input?
 
On the other hand: A universal halt decider that attempts to divide all
of its inputs into halting and not halting on the basis of answering the
question:
 
Does the simulation of the input have to be stopped to prevent its
otherwise infinite execution?
 
Does not suffer from the Pathological self-reference(Olcott 2004) and
can thus be defined.
 
Because this revised criteria does divide its inputs into halting and
non-halting by 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:
> Every computation that would not halt if its simulation
> were not halted is by logical necessity a non-halting computation.
 
it still directly applies to the actual halting problem itself:
 
 
 
The Halting problem is a problem in computer science. The problem is
looking at a computer program and finding out if the program is going to
run forever or not. We say that a program "solves the halting problem"
if it can look at any other program and tell if that other program will
run forever or not.
 
https://simple.wikipedia.org/wiki/Halting_problem
 
 
 
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 10 09:29PM -0500

On 1/10/21 12:49 PM, Robert Komar wrote:
> like the fight between those who see it as secularization and those
> who see it as a legitimate abbreviation has been around for a long
> time.
 
His name is Jesus Christ. The Christ identifies Him as who He is, our
Redeemer, our Savior, the Messiah.
 
To take "Christ" out of Christmas is to attack who He is, and what He
means to all of mankind (even those who do not acknowledge Him).
 
The world makes Christmas be something other than a celebration of
Christ. Those who are redeemed out of the world celebrate the holiday
in remembrance of Jesus.
 
The world is perishing. Those who are redeemed will not perish, nor
will they taste the second death, for they have already passed from
death to life at the cross. Jesus is truly our Redeemer, our Savior,
the Messiah. And everybody needs to know Him as such (for their own
sake after leaving this world).
 
--
Rick C. Hodgin
Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Jan 11 05:07PM

On 11/01/2021 02:29, Rick C. Hodgin wrote:
 
> To take "Christ" out of Christmas is to attack who He is, and what He means to all of mankind (even those who do not acknowledge Him).
 
> The world makes Christmas be something other than a celebration of Christ.  Those who are redeemed out of the world celebrate the holiday in remembrance of Jesus.
 
> The world is perishing.  Those who are redeemed will not perish, nor will they taste the second death, for they have already passed from death to life at the cross.  Jesus is truly our Redeemer, our Savior, the Messiah.  And everybody needs to know Him as such (for their own sake after leaving this world).
 
Blah, blah, fucking blah.
 
And Satan invented fossils, yes? Spammer?
 
Blah.
 
/Flibble
 
--
😎
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 10 03:35PM -0800

On 1/9/2021 10:01 PM, Bonita Montero wrote:
 
>>> The newed memory would be aligned also.
 
>> Really? ...
 
> Yes.
 
Well, check this crap out, on MSVC 2017... It seems to work fine. Can
you compile it?
_______________________________
#include <iostream>
#include <atomic>
#include <cstdint>
#include <malloc.h> // humm...
 
 
#define CT_PAGE_ALIGNMENT 8192
#define CT_L2_ALIGNMENT 128
 
using namespace std;
 
 
struct alignas(CT_L2_ALIGNMENT) block
{
atomic<uint64_t> value;
};
 
 
struct test
{
int a;
char b;
block c;
char d;
long e;
};
 
 
int main()
{
void* raw_mem = _aligned_malloc(sizeof(test), CT_PAGE_ALIGNMENT);
if (!raw_mem) { std::cout << "failed alloc!\n"; return 0; }
 
std::cout << "raw_mem = " << raw_mem << "\n";
 
// test raw_mem
if ((std::uintptr_t)raw_mem % CT_PAGE_ALIGNMENT)
{
std::cout << "yikes! raw_mem does not fit in CT_PAGE_ALIGNMENT\n";
}
 
else
{
std::cout << "So far so good... raw_mem fits CT_PAGE_ALIGNMENT\n";
}
 
test* t = new (raw_mem) test;
 
// test &t->c
if ((std::uintptr_t)&t->c % CT_L2_ALIGNMENT)
{
std::cout << "yikes! &t->c does not fit in CT_L2_ALIGNMENT\n";
}
 
else
{
std::cout << "So far so good... &t->c fits CT_L2_ALIGNMENT\n";
}
 
_aligned_free(raw_mem);
 
return 0;
}
_______________________________
 
 
Can you get it to work on your end? For some reason my msvc 2017 does
not have std::aligned_alloc. I am getting the following output:
 
raw_mem = 01080000
So far so good... raw_mem fits CT_PAGE_ALIGNMENT
So far so good... &t->c fits CT_L2_ALIGNMENT
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)