Am 26.02.2007 um 22:00 schrieb Mike Linden:
Below is the debugger showing were it went for the exception.
My guess is whatever is causing the problem with c_str() is also
causing this problem.
catch the exception (by reference), print theException.what();
Is it possible the some type of casting is needed, that is
different from
normal C++ standards?
If in C++ you need casting, usually you have messed something up.
Either from the design point of view or the implemenattion POV.
#0 0x9004802c in kill
#1 0x9012dfb4 in abort
#2 0x0024b63c in std::dthandler
#3 0x0024b5d0 in std::terminate
#4 0x00248654 in ExPPC_ThrowHandler
#5 0x00248078 in __throw_vec
#6 0x00248408 in __throw
#7 0x00280af0 in std::string::replace
#8 0x0028b104 in std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string
#9 0x0028a548 in std::string::substr
#10 0x0105cd84 in XPDBSearch::_parseReadBufferAdv at
XPDBSearch.cpp:2533
The XP in XPDBSearch does not happen to stand for XPress, does it?
The OS X incarnation of the dyld linker will use the first loaded
version of an symbol for ALL later loaded libraries of the same host.
In case an plug-in host was buildt with another implemenation of
std::string::replace, e.g. because it was buildt with CodeWarrior,
the plug-in might resolve the some but not all symbols to the
incompatible version.
Two-level namespaces might or might not help.
HTH,
Tom_E
