search

jamoma / JamomaCore

Jamoma Frameworks for Audio and Control Structure
Other
36 stars 14 forks source link

a new TTValue is different to kTTValNONE #155

Closed theod closed 11 years ago

theod commented 11 years ago

There is a very simple test into TTValueTestBasic function which fails :

capture decran 2013-07-11 a 16 26 37

tap commented 11 years ago

Wow -- This one was tricky!

In many places we have been passing kTTValNONE anywhere we didn't really care about the value. This includes passing it as the return value to sendMessage() -- in which case a return value overwrites the value of kTTValNONE!

Because of the way we re-wrote TTValue we are no able to change the initialization of the value cache and declare these const -- which makes it so that compiler errors will catch these scenarios for us rather than letting us corrupt memory unpredictably (yay). I'll try to push the fixes shortly, but it is a little more involved than I was expecting...

tap commented 11 years ago

This bug sucks. In the process of pulling all of my hair out I think I've come to conclude a few things. One of them is that the value cache is a bad idea.

The idea of it was that then we could have a set of constants and then it would speed up comparisons to these constants because we would not have to construct a TTValue to do the comparison. This is dumb. We can just overload the == operator to make comparisons fast (even faster, actually) than using the value cache.

So, unless @theod thinks I'm insane (and tells me so) my plan is to remove the value cache entirely.