Как предотвратить глобально переопределенный “новый” оператор от того, чтобы быть связанным в из внешней библиотеки
Можно всегда делать:
int i, j;
for (i = j = 0; j < foo.length; ++j)
if (!"a".equals(foo[j])) foo[i++] = foo[j];
foo = Arrays.copyOf(foo, i);
5 ответов
Возможно, вы могли бы исследовать, используя GNU objcopy, что-нибудь по аналогии с objcopy --redefine-сим oldNew=newNew libBlue.a. Самая большая проблема, которую я вижу с этим, заключается в том, что набор инструментов для разработчиков Apple, кажется, не включает в себя objcopy. Вы можете установить objcopy из MacPorts (sudo port install binutils), но эта объектная копия, вероятно, не может манипулировать объектными файлами ARM. В MacPorts есть пара бинутилей ARM, и я полагаю, что arm-elf-binutils - это лучший вариант.
Если не считать этого, вы можете разобрать libBlue.a, переименовать его новый оператор с помощью скрипта sed, а затем собрать его заново. Возможно, вы даже сможете напрямую манипулировать таблицей символов libBlue.a.
Я не уверен, что это сработает, но вы можете попробовать переопределить новый локально в своем коде. В вашей реализации вы можете скопировать / вставить реализацию стандартного оператора new . Если вам нужно создать в коде объект новый , вызовите свой новый вместо глобального new , который переопределил libBlue. Затем найдите автора libBlue и поделитесь с ним своим мнением.
Посмотрите http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=40 , чтобы узнать больше резюме, чем я могу надеяться предоставить.
Edit: Вы имеете в виду, что код в libGreen.a будет вызывать new из libBlue, или вы имеете в виду, что ваш код создает " new ClassDefinedInLibGreen (...) "и в конечном итоге использует libBlue ' s новый оператор? Опубликованное мною решение (если оно вообще работает) будет работать только в последнем случае, поскольку у вас нет доступа к источнику какой-либо сторонней библиотеки для управления переопределениями оператора.
Вы можете изолировать libBlue.a и libGreen.a в отдельном процессе, эффективно создавая сервер, который позволяет получить доступ к инкапсулированным функциям посредством некоторой формы межпроцессного взаимодействия. Это явно влияет на производительность, но решает проблему глобального загрязнения пространства имен.
Могут быть нетехнические решения:
- Возможно, можно выделить функции, предоставляемые libBlue, в отдельное приложение.
- Вы можете обратиться в службу поддержки libBlue. У других людей тоже может быть проблема.
- Найдите альтернативу.
PS Странно, если бы разработчики, если libBlue сделали какую-то «умную» вещь, не понимая, как исправить возникшую проблему.
двоичное редактирование библиотек? Если верить interweb, то в формате Mach-O . Смотрите эту ссылку для получения более подробной информации.
libBlue.a должен включать список экспортируемых символов. Попробуйте переименовать его "new" в "neo" или что-то в этом роде. libBlue все еще должен быть внутренне согласованным, но libGreen теперь найдет систему только "новой" при компоновке.
Или поочередно libGreen.a должен включать список неразрешенных символов, включая "new", вероятно, в разделе __DATA,__la_symbol_ptr. Вы можете заменить экземпляры "new" именем функции-обертки, определенной в вашем приложении, которая выполняет ту же самую работу. (может быть даже прямой вызов new, но это может закончиться обратно в libBlue)