> __unexpected is a pointer that's used to look for an "unexpected" > exception. The problem is that the compiler doesn't know that MemPtrNew > and MemPtrDelete can't throw exceptions. I think if you explicitly turn > off exceptions in the C/C++ Language panel, you should be able to build > without the reference to __unexpected. If it still happens, you have have > to add a local prototype for the file that redeclares > MemPtrNew/MemPtrDelete as having "throw ()" to tell the OS that they won't > throw any exceptions.
Mengtao: Thank you Ben for all your help and once I turned off exceptions in C/C++ Language panel, my project compiled. With new/delete now working, I am able to create some of our objects in the shared library and pass out these pointers correctly to the caller application. I tested and saw these pointers are valid ones since now I can pass the pointers back to my lib funtions which are wrappers of the objects' member methods and see the work is done on these objects . Cheers! But after our research, we do find plenty of virtual member functions in some of our classes. Is there a way to work around this problem since we don't want to rewrite our classes as they are working well with our existing applications which staticly included the classes' source code in their workspace? Though shared lib cann't support to create an object with virtual functions as you disclosed, will the shared library still support the classes which has another classes with virtual functions as their members? If the answer is positive, we may think about avoiding expose the classes with virtual functions though we still have to expose those which themself don't have virtual funcs but their member objects have virtual funcs.Thanks in advance for any of your opinion. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
