библиотека вызывает глобальные перегрузки новых/удаляющий на мне!
Я поддерживаю плагин (реализованный как dll) для большого приложения с закрытым исходным кодом. Это хорошо работало в течение многих лет. Однако с последним обновлением он - SDK, поставщик перегрузил глобальные новые операторы, и удалить. Это доставляет много неприятностей мне. То, что происходит, - то, что мой плагин выделяет строку. Я передаю эту строку в статически связанную библиотеку, которая изменяет ее (изменения, это - длина, таким образом перераспределяющая его). Мои сбои приложения.
Причина, конечно, что строковые жизни на поставщике выделили пользовательскую "кучу". Статически связанная библиотека ничего не знает об этой "куче" и попытках использовать новые / операторы delete по умолчанию на той памяти. Бум.
Теперь вопрос: как я могу содержать свой код в чистоте и избегать использования операторов поставщика? Нет никакого условного макроса препроцессора. Я не могу избежать включая незаконный заголовок, так как он содержит 2 000 строк больше кода, в котором я нуждаюсь для плагина. Я не могу передать обеспеченное средство выделения в другую библиотеку, так как это не обеспечивает механизмов для этого. Я уже прослушивал поставщика об этом. Я не знаю то, что еще я мог попробовать?
Приложение: После некоторого горячего спора мне удалось убедить поставщика удалять перегрузки снова из следующей версии SDK. Я решил свою непосредственную проблему путем простого взламывания текущего SDK и удаления перегрузок вручную. Спасибо за все предложения в этом потоке. Они служили аргументами и дальнейшим "доказательством" того, почему перегрузки были плохой идеей во-первых.
4 ответа
]Если вы компилируете (через включение заголовка) переопределенный оператор(ы) new/delete, тогда все вызовы в вашем коде на new/delete будут использовать их. Нет способа переопределить его (ошибки ссылок) или только частично переопределить и т.д. [
] [] Это вообще плохая форма переопределения глобальных операторов new/delete. Это плохая идея. Если вы не понимаете, почему это плохая идея, то у вас нет на это квалификации. Если вы понимаете, почему это плохая идея, то у вас есть на это право, но вы, как правило, решаете не делать этого. [
] [] Определение глобального нового/удаленного компонента является экспоненциально более злым в компоненте, который, как вы ожидаете, люди должны включить непосредственно в свой проект. Ваша работа как заказчика - помочь поставщику, делающему это, понять серьезность ситуации или перестать быть его заказчиком.[
] []Вы можете определить пользовательский тип аллокатора (см. эту []ссылку на хорошее учебное пособие[] о том, как это сделать, нужный интерфейс и т.д.) и использовать его исключительно с вашими типами STL (это аргумент шаблона). [
] []Для shared_ptr, вам нужно сделать что-то немного другое: в качестве параметра в конструктор берется объект deleteter, если вы не хотите, чтобы поведение по умолчанию "delete p" было по умолчанию. Это не пользовательский аллокатор, это просто обычный унарный functor.[
].Одним из вариантов является создание собственного перегруженного оператора new, который может быть реализован в терминах malloc.
Это можно определить как:
enum MyNew {EMyNew};
void *operator new(size_t size, MyNew);
Затем Вы можете вызвать его как MyClass* myClass = new (EMyNew)MyClass;
Так как он реализован в терминах malloc, то он должен вести себя так, как и ожидалось. Единственным даунером является то, что Вам придется заменить все экземпляры, в которых Вы использовали новый.
.]Разве это невозможно:[
] [namespace evil{
#include "evil_header.h"
}
]Тогда то, что зло_головок объявляет глобальным new/delete становится злом::new/evil::delete. Сомневаюсь, что это будет хорошо играть, если есть не заголовочные определения вещей, объявленных в evil_header.[
].] Вы можете использовать еще один новый в вашем пространстве имен:[
] [namespace MyNS {
// Declare your new/delete operators here
// and also declare a class implementing the same interface as std::allocator
// using your newly created memory management functions.
// Don't forget to put all your classes in the namespace.
// (if you don't have one already)
}
]Затем вы можете использовать все классы STL, давая им ваш тип аллокатора в качестве шаблонного аргумента[
].