> ... I am sorry, but that's very untrue.
>
> As it happens, not every language is implemented using runtime written in C/C++, nor does every language modules written in C/C++ to extend it instead of FFI.
You did an awesome job tearing apart that strawman, but you are misrepresenting what I said. That second sentence is in no way in conflict with my "very untrue" statement.
To refresh, with emphasis added for the reading impaired:
C++ actually makes binding to *a lot* of higher level languages a lot nicer than doing so with C.
That you can find a distinct subclass of languages where you believe that it is hard to do bindings to C++, doesn't mean the above statement is even mildly untrue, let alone very untrue. Please review and reconsider:
* There are certainly a lot of higher level languages which don't qualify for your definition.
* SMOKE is actually a binding through Qt's MOC, which is generally considered by the C++ community to be something which makes Qt pretty un-C++-ish. You are right to phrase it as "Qt's object model", because it sure as heck isn't C++'s.
Try looking at the LuaBind and Boost.Python libraries. They represent a very different approach to language binding, and it isn't dependent on there being a wrapper C API. While writing binding framework for a given language is a bit of a PITA, once that has been built, it really does make binding to a high level language a lot easier than trying to do it through a wrapper C API.
You did an awesome job tearing apart that strawman, but you are misrepresenting what I said. That second sentence is in no way in conflict with my "very untrue" statement.
To refresh, with emphasis added for the reading impaired:
That you can find a distinct subclass of languages where you believe that it is hard to do bindings to C++, doesn't mean the above statement is even mildly untrue, let alone very untrue. Please review and reconsider:* There are certainly a lot of higher level languages which don't qualify for your definition. * SMOKE is actually a binding through Qt's MOC, which is generally considered by the C++ community to be something which makes Qt pretty un-C++-ish. You are right to phrase it as "Qt's object model", because it sure as heck isn't C++'s.
Try looking at the LuaBind and Boost.Python libraries. They represent a very different approach to language binding, and it isn't dependent on there being a wrapper C API. While writing binding framework for a given language is a bit of a PITA, once that has been built, it really does make binding to a high level language a lot easier than trying to do it through a wrapper C API.