C / C++ / MFC

Re: mapping pthread id to custom id

13-Jul-18 21:48

Why are you using a struct for a simple value, i.e. int? And why do you need to map the real thread id to some other value? It is not really clear what you are trying to do.

meerokh14-Jul-18 1:24

meerokh

14-Jul-18 1:24

I am planning to have more variable in the struct e.g.

struct thread_data {
int  thread_id;
const char *message;
double result
};

Richard MacCutchan wrote:
And why do you need to map the real thread id to some other value?

The application in which i am creating pthreads is a simulation environment on top of which my actual thread scheduling library will execute so the each pthread act like virtual core. Each core(pthread) has its own work package queue from which it retrieves the package for execution and when it is empty it attempts to steal from other cores(via work stealing method). Every core has a package manager singleton class which is responsible for adding and getting the package from the queue. In order to access the other cores(using the singleton class) i need the mapping so that whenever each core access the package manager class (and its queue), it do based on the custom id.

I hope i explained it better this time

Re: mapping pthread id to custom id

Richard MacCutchan14-Jul-18 4:36

How to disable a HTML Input in c#

14-Jul-18 4:36

Quote:
whenever each core access the package manager class (and its queue), it do based on the custom id.

Why not the real id?

Member 1219465611-Jul-18 16:50

Member 12194656

11-Jul-18 16:50

Hi all,

Tt's a HTML Input box like this.

<input id="testInput" name="testInput" value="" tabindex="0" />

and for some reason, I cannot use ASP.net textbox.

However, I need to disable it when a button is clicked (I tried both AUTOPOSTBACK and non-AUTOPOSTBACK button) .

I tried the followings in c# but none of these works.

Page.ClientScript.RegisterStartupScript(this.GetType(), "clientscript", "document.getElementById('testInput').readOnly = true;");

Page.ClientScript.RegisterStartupScript(this.GetType(), "clientscript", "document.getElementById('testInput').disable= true;");

Page.ClientScript.RegisterStartupScript(this.GetType(), "clientscript", "document.getElementById('testInput').disable= 'true';");

'
Please advice, thanks!

Re: How to disable a HTML Input in c#

Bryian Tan11-Jul-18 18:30

Bryian Tan

11-Jul-18 18:30

The syntax should be "disabled" not "disable"

JavaScript

document.getElementById('testInput').disabled = true;

HTML DOM Input Text disabled Property[^]

By the way, I think you should had posted this question to Web Development Discussion Boards[^] instead of "C / C++ / MFC"

Bryian Tan

c++ - std :: map - Is my idea too dirty?

User 1106097911-Jul-18 9:40

11-Jul-18 9:40

Would you ever do something like this:

C++

std :: map<double, MyType, std :: less<double> >

I don't see a reason why not to do it, but I have a bad feeling doing it.
Any Remarks / objections?

Ok, this double - Key is a user Input with a known/limited number of decimal places. I could also take this into acount and use a

C++

std :: map<int, MyType, std :: less<int> >

But why I should?

Btw: Performance is out of questions, the map size is Maximum 10 items.

Thank you very much in advance.

It does not solve my Problem, but it answers my question

modified 19-Jan-21 21:04pm.

harold aptroot11-Jul-18 10:48

harold aptroot

11-Jul-18 10:48

In 64bit code (so using XMM registers) it'll probably work, unless any DLL secretly changes a rounding mode on you and "forgets" to set it back. In 32bit code (usually using the x87 FPU stack), who knows? The danger there as usual is that keeping a double in an FPU register keeps it at whatever value was actually computed (which depending on how stod works internally may have bits set in the part of the 64bit significand that extends beyond the 53 bits you usually get) while storing it to memory and reloading it changes the value, and this is something that compilers think is a normal part of how they work so they do it outside of your control, though you can force a store/reload to get a safer value to work with. So it may still work, but there are some sneaky conditions that may depend on specific codegen choices the compiler makes.

User 1106097911-Jul-18 10:54

11-Jul-18 10:54

Thank you so much!
To be honest I don't get all of your explanations at the moment. But the most important Thing is, that you Point out, that there can be a Problem... and that corresponds with "my bad Feeling".

So now it will be my part to investigate more for possible pitfalls
Thank you very much again.

[Edit]
And please flag your Response as an answer, it is much more than a "general"

It does not solve my Problem, but it answers my question

modified 19-Jan-21 21:04pm.

Richard MacCutchan11-Jul-18 20:44

11-Jul-18 20:44

Simple answer: no. Double and float values have an inherent precision problem so you can never rely on two numbers being the same. You need to rethink your design.

harold aptroot12-Jul-18 13:34

harold aptroot

12-Jul-18 13:34

This is really too pessimistic about floating point arithmetic though. There are definitely cases where doubles will reliably have exactly equal values. They're not non-deterministic, just hard to work with and 80bit nonsense messes things up extra.

Richard MacCutchan12-Jul-18 20:42

12-Jul-18 20:42

This is really too pessimistic
No, realistic. Far too many people use floating point numbers where they are not necessary, or actually wrong.

harold aptroot12-Jul-18 21:19

harold aptroot

12-Jul-18 21:19

That is true, but "you can never rely on two numbers being the same" is not. There are conditions that can be satisfied that will make the numbers the same.

Richard MacCutchan12-Jul-18 21:41

12-Jul-18 21:41

Yes, but you understand floating point representation. Too many developers do not appear to share that understanding.

User 1106097913-Jul-18 8:44

13-Jul-18 8:44

So with your Argumentation one Need also to say: Don't use int_64 ... which of course makes no sense.

A double value has a discret number of numbers it can represent, same as an int_64 has Wink | ;)

It does not solve my Problem, but it answers my question

modified 19-Jan-21 21:04pm.

Richard MacCutchan13-Jul-18 20:13

13-Jul-18 20:13

No, that is not what I am saying at all. And it appears, that like so many people on these forums, you also do not understand how floating point numbers work.

Richard MacCutchan14-Jul-18 5:10

14-Jul-18 5:10

Try this

C++

#define NUMBER 133333333
int main()
{
    int nValue = NUMBER;
    float fValue = NUMBER;
    
    printf("%d\n", nValue);
    printf("%f\n", fValue);

User 1106097914-Jul-18 6:19

14-Jul-18 6:19

Thank you very much for this. I'm completely aware of such effects and also on the normalizing stuff.
Thank you again Thumbs Up | :thumbsup:

It does not solve my Problem, but it answers my question

modified 19-Jan-21 21:04pm.

CPallini11-Jul-18 22:22

CPallini

11-Jul-18 22:22

Quote:
Is my idea too dirty?

I have just the same feeling about.

Jochen Arndt13-Jul-18 0:13

Jochen Arndt

13-Jul-18 0:13

I'm a bit late to the party.

The key point of a map is that no two elements in a map container can have equivalent keys. If the number of significant digits entered is less than the precision of double values, this will not happen (besides entering the same value again which applies to ints as well).

But you might get problems when trying to access elements by key when the argument is from other sources (affected by rounding).

That would be my bad feeling:
While there is no problem with the map itself, key based operations ([]operator, erase, swap, find) might behave not as expected (no match). Even when not using such operations now but only iterator based ones, they may be used later when updating the code. So you should at least place a comment about this.

Another option is creating your own std::map based class that disables the affected operations or replaces them with a version that treats close numbers as identical (defining an epsilon).

User 1106097913-Jul-18 7:54