If I am not using THE major feature(s) of the language, the reason for switching to it in the first place, tell me pratel: why would I switch to it?

You listed some requirements in your original post. The purpose of switching language is to satisfy those requirements, nothing more.

So the real question is why would you not switch to a language that meets your requirements only because that language offers other functionality that you don't intend on using?

Haha, you are exactly right. After last night I realized that I might actually just want to let this thread quietly die. I am not getting anywhere. That or I was going to request a mod to close it.

I found out very quickly that this was the wrong forum to post this in. That was my mistake. A lot of the responses from people are completely and utterly incorrect, but I realize that is only because they don't finely understand my problem space. Then if you apply my responses to the fact that you are talking mostly to game programmers (more generally programmers who are working on systems with tons of RAM, MMU, etc..), it makes perfect sense why I am getting a lot of the responses I am.

I will make a final statement on the heap compaction and C++ member function issue. The heap compaction and member function issue are two separate problems.

"If I have the memory to support heap compaction, then I must be able to support std::bind, because it takes less memory". I am sitting here listening to a bunch of people on this forum telling me "this is going to happen" or, "it won't work" To that, I will concede that in your eyes and with the information I am giving you, you have made a valid statement on the operation of such a heap. Unfortunately, I will not go any further in giving out information on the implementation. It does actually work very well, it does not fail. The issue lies within the manual calls to do the reference tracking. With regards to performance, allocations and de allocations are O(1). Heap compaction happens while the system is idle and therefore has no performance penalty. The compactor is incremental. This is not up for discussion. It works, period, end of story. How you 'try' and reason out the implementation because I have not given you that information is up to you. Lastly, our system does do a lot of multi threading, just on a single core at the current time.

With regards to one member who thought it necessary to write out code to show me how member functions can be used by providing a data member inside the class: Yes, this not is not a new concept to me. However, doing it that way defeats the simplicity of doing "pObj->callback = whatever. If my classes have to provide a wrapper for each and every callback like that, it is a very useless feature to me. Having to do extra tracking like this, no matter how trivial it is not an option that I can give my end users. It does not work like that where I am.

I now would like to request that this topic either be closed or deleted by a mod. This was the wrong forum to post the topic in, and I apologize for it.

Thank you