I agree. It would be very compiler dependent to have the library find arbitrary classes in a linked library and determine their methods. What I was thinking of is a bit simpler. It would require a reflected class to have it's reflected methods declared as such. It would be a bit similar to the Boost.Python syntax, except that it would, like Boost.Extension, require only one library entry point and it would need to add some stuff for type safety, without inducing a lot of runtime overhead. On 3/15/07, Sohail Somani <s.somani@fincad.com> wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeremy Pack
The method that would fit best with Boost.Extension would probably be the ability to instantiate classes that are not derived from known (that is, known to the instantiator) base classes, and then discover functions that can be called on them.
Isn't this painfully compiler dependent? It would be awesome, totally awesome if one was able to handle it. But that would probably be quite difficult? Maybe __FUNCTION__ can help... _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost