Let’s help you to make your post shorter by letting you know something. I am a ‘he’ . At least you didn’t call me ‘it’ LOL
1 Like
Indeed, programming is generally about problem solving, but languages have many features and some features provide better solutions than others, so it pays to be aware of the possibilities.
If languages were completely unimportant then people wouldn’t be as passionate about which languages they prefer.
I don’t think I would be to be honest.
Programming for a company is a very different environment to coding as a hobby/for enjoyment.
Companies are fundamentaly results-driven, so deadlines are rife and the destination tends to matter more than the journey.
(I’d never heard of the ICPC, I had to look that up.)
I hope you’re not trying to imply that’s what I’m doing.
In this case the restrictions are defined by the substitution stage.
The function only fails to instantiate if the arguments passed to it can’t be subtituted into one of the expressions in the body of the template function.
When digging through the standard I discovered that there is actually a technical definition of ‘signature’ defined in the standard, and for non-template functions it doesn’t include the return type.
(I also discovered various other technical distinctions that I wasn’t aware of, like the difference between ‘parameter’ and ‘argument’.)
Just to let you know, the Pokitto library already counts the number of frames that the button is held for.
You can retrieve that with uint8_t Pokitto::Buttons::timeHeld(uint8_t button).
I have a feeling we encountered this problem once before, a long time ago.
At any rate, I think this makes the possibility of the interrupt queue overflowing more likely.
I don’t know if the queue drops new input or overwrites old input, but either would be a reasonable explanation.
Well … not everyone is like this. And one doesn’t need to know everything about a programming language to develop preference.
I don’t believe that a majority of people that goes to ICPC or work at these companies don’t enjoy
the journey of programming. They simply care more about the problem they are trying to solve than the intricacies of the tool they are going to use to materialize their solution. In many aspects, Computer Science is older than computers and programming languages.
Ok… you actually triggered old memories of mine. Yeah… I remembered learning about signature when learning what information the compiler needed to refer to a function uniquely. The signature in C++ only takes into account the type of the parameters due to function overloading. I also remember that in C, the signature is only defined by the number of parameters, since there is no function overloading. Edit 4: actually… I was thinking it through, and it didn’t make sense… I think that in C, the signature only includes the name of the function, since there is no overload… Anyway, it’s something like that.
Edit 5: these definitions of signature seem to be very tied to C/C++… People seem to diverge on the meaning of signature and it seems that for C# it’s equivalent to function prototype. That’s an example why it’s oftentimes not productive to argue over terminology. Terminology changes a lot depending on author, specific context, etc. The semantics are what matters <3
Fair enough. “Signature” is not be the best word to describe the restrictions I wanted to describe. Perhaps I should only say “type”? Like… std::function<bool(int)> is a type that’s different than std::function<bool(double)>… and std::function<bool(TMPL_TYPE)> may accept both.
Do you know a single, short word to describe the restrictions?
Edit: replaced the word “define” with “refer to”, since it reflects better what I wanted to say.
Edit 2: there is no problem in calling parameters just arguments. The C++ standard may specify a distinction for the sake of clarity, but in Compilers (as an area of study), parameters are often called “formal arguments” and arguments are called “actual arguments”.
Edit 3: just found a better word to specify the restriction… Expected prototype.
According to wikipedia:
Damn guys… That’s quite an intense discussion in a game release thread…
3 Likes
I’m sorry… This parallel discussion became way off topic don’t even matter anymore.
The given names don’t affect the problem at hand. Let’s be practical.
I’m not used to the PokittoLib’s code at all. I’ll wait and see if @jonne can reproduce the bug and if he can give some pointers to go forward. Also, @Pharap seemed to be onto something with his interrupt queue overflow theory.
This problem was encountered and solved in another project.
Please look at this (old) thread, perhaps it is of help
1 Like
Well said. I concur.
1 Like
Thank you so much. I took a look at it.
Actually, the only thing that I changed (based on what I read), is that now I’m reading directly from the pins instead of from Pokitto::heldStates.
DigitalIn _leftPin(P1_25);
DigitalIn _rightPin(P1_7);
BtnHolder btnHolderLeft([](){return _leftPin;});
BtnHolder btnHolderRight([](){return _rightPin;});
I played for longer at this time:
Didn’t encounter the bug so far 
Thanks.
raquer.bin (69.0 KB)
Edit: it seems official… Played again, set new highscore (17910), no bugs.
3 Likes
Maybe I’ll shunt it off to a side thread later if people think it’s too distracting.
Remember, when people argue/debate about something it just goes to show that they care. :P
In that case I’ll throw away the majority of the long comment I just wrote.
However there’s one bit that I will post because I think it will clarify something:
Based on your original sentence:
However, if I were going to use it, simple passing std::rand is not an option since it does not have the signature expected by std::random_shuffle.
I think "it does not satisfy the constraints expected by std::random_shuffle" is probably closer.
What I originally meant by “it doesn’t match ‘by signature’ as such” was that it’s the usage that’s important, not the actual signature, because it’s the usage that defines the constraints.
(Should I assume you know enough about C++'s template system to know what I mean?)
Aha, that’s the code I was thinking of. I didn’t have time to track it down earlier.
Here is where I originally stated my ‘interrupt queue’ theory:
So if the solution is using pins rather than interrupts,
does that imply that interrupts might in fact be the problem?
(If so, I’m annoyed I wiped that fork without backing it up first.)
I’m fairly certain that the result of this thread was the code that is currently in the library,
which implies that it didn’t quite fix the problem.
At the time we debated reading pins vs using interrupts,
so now I’m wondering if it might be worth revisiting that debate.
I see what you mean and can agree with you that’s your version of the sentence is precise.
However, I fail to see how my original sentence was ambiguous or unclear.
std::srand has a signature/prototype/whatever that fails to satisfy the constraints of the std::random_shuffle when you try to use the former in the latter (passing the former as the third argument of the latter). That’s the idea.
Terminology is made up, u know? The people behind a technology get to choose. Of course, they try to be consistent… in their inner circle.
In my line of research, I see the same things with many different names everywhere, and things that are completely different (and sometimes opposite) sharing a same name, depending on which inner circle of the literature you are reading.
And the same is reality with programming languages. I just illustrated this with the word signature in the C# context.
It’s vain to discuss terminology, if the communication is effective. Unless you disagree with me and think that I was ambiguous and confused you somehow with my original sentence. If that’s the case, I’m sorry.
I’ll be sincere… I took a fast look at that thread but I had the impression that this was the direction it was taking, but I would never be the rude foreigner. Ideally, I should be able to achieve the same result just by using the options in Pokitto::Buttons like rightBtn(). Glad you noticed that.
But about the game… Did you play it? 
Edit
I realize now that what bothers you is not the terminology per se, but maybe the procedure… Because template tries to use something (class/typename) the way you code it to use that, and fails if it cannot. Like this:
template<typename V> V sum(V a, V b) {
return a + b;
}
In this situation, I’m implicitly assuming the existence of the public operator +, that may not exist for V. In that case, it would generate an error because the constraints are not satisfied.
However, I can argue the prototype of a function is directly related to its capacity of satisfying or not a constraint.
Maybe we should then implement it as standard way of reading inputs?
2 Likes
Excellent! I have occasionally that the same kind of problem in PokittoGP too. I need to test this at some point.
1 Like
So far I see that problem on all the games. Funny thing is that the same games on the pokitto emulator don’t have the issue at all. Unfortunately it sounds more like a hardware problem than anything else.
Please prove me wrong.
Have you tested the latest bin I uploaded? It doesn’t have the problem anymore.
1 Like
Sorry, just tried your latest build, it seems to work nicely now. We should make sure we use the same way you did it on your game in other games then.
1 Like
If you hadn’t added the example code from cplusplus.com then I think yes,
it would have been confusing because, as I say, the function doesn’t expect a specific function signature/prototype/whatever,
it expects an object that satisfies certain contextual constraints.
Perhaps even "std::rand does not have a suitable signature" might have made enough sense, or "std::rand doesn’t accept any arguments".
That’s precisely the point, it’s more than just the type of the function’s arguments and its return type that determines whether the constraints are satisfied.
In that context operator+ could be A operator+(A, A) (or A A::operator+(A)),
or it could be B operator+(A, A) as long as B is implicitly convertible to A
or it could be A operator+(B, B) as long as A was implicitly convertible to B or B was implicitly convertible to A - the possibilities are almost endless.
Perhaps, but that’s not saying much - pretty much anything could be related to an object’s capacity to satisfy a constraint.
But anyway, we’re just splitting hairs here, let’s just forget the whole thing, it’s becoming tedious.
I’m not quite sure what you mean by this.
Do you mean you thought it was going to be a problem with the library?
And that you ought to be able to make the library use input pins instead of interrupts?
As for the ‘rude foreigner’ thing - I have no idea what that means.
‘Foreigner’ in the sense of ‘new to the forum’?
‘Foreigner’ in the literal sense of ‘someone from a foreign country’?
If you mean it literally, I feel like pointing out that almost everyone who has commented on this thread has a different nationality to everyone else.
Personally I haven’t had chance yet.
I rarely get round to trying out games that get posted.
That’s what I mean by “revisiting that debate”.
That was one of the discussions we had in that thread - debating whether to use input pins or interrupts.
The debate starts around here:
where @spinal introduces some code using input pins for reading buttons.
And there’s some related discussion here:
If it doesn’t appear on the emulator, that could also indicate that it’s interrupt-related.
Iirc, it does happen in the emulator. 
1 Like
Does the emulator emulate interrupts at all?
If so then that might further suggest problems with the interrupts.
If not that would imply that the problem is somewhere in the source code rather than a problem with using interrupts.
It does. Otherwise you’d have no inputs and games would halt in an endless loop waiting for timer updates.
In which case, if using digital input pins solves the problem in both the emulator and on hardware then I think it would be safe to say the problem lies with using interrupts.
(That would only be half the puzzle solved though, someone would have to dig further to find out why the interrupts have that problem.)