In the last 2 weeks I started to write a DIB wrapper object that I intend to use in a very flexible way. At the moment, this object has more than 20 methods full of code. Now, a new design problem comes up since in an app not all of these methods are used and we will have a bigger overhead if we include all of them.
Methods that are accessed using VMTs should always be present but Bound Methods are different, so Iím thinking to change or extend them to fit a new feature. That means that Bound Methods that are not called at all in the main code, are not included in the final binary.
I think I can achieve this using the compiled objects, since they are mini libraries. Iím not sure if I can modify the current BoundMethod macro to do so, or if I have to create a new one, like ExternMethod or whatsoever. In this last case, the methods should be separated manually, which isnít too much work, considering the goal we want to achieve.

If you have better ideas, they are welcome!  ;)

Posted on 2006-05-07 09:50:35 by Biterider
Just be careful about double-defining procs/objects. When I did something like
class1_mthd1 proto :dword,:dword
class1_mthd1 proto :dword,:dword
(but defined dynamically) , the class1.lib got always included in the final binary, used or not.
Posted on 2006-05-08 00:35:06 by Ultrano