C++ Builder и BORLNDMM

[Pulsarius]

Привет всем!

 

Кто-нибудь уже заметил, что приложения для десктоп, скомпилированные в последней версии C++ Builder (RAD Studio 10 Seattle), стали зависеть от BORLNDMM.dll? В предыдущих версиях студии такого не было. Я знаю, что это Борландовская библиотека для работы с памятью, и от неё зависели программы, написанные на ранних версиях C++ Builder, ещё будучи при Борланде. Чем же интересно обосновано возвращение такой зависимости и можно ли как-нибудь от неё избавиться?

 

P.S. Я пишу DLL. Пробовал избавиться от зависимости, отключив в настройках проекта "Use 'classic' Borland compiler", т.е. чтобы использовать Clang. Пришлось немного отредактировать код. Зависимость исчезла, но, при выгрузке моей DLL в главной программе функцией FreeLibrary, вылетает ошибка типа access violation. Такая ошибка возникает только тогда, когда DLL скомпилирована в режиме Release, в режиме Debug всё работает нормально, и поэтому отследить в чём дело очень сложно. Когда возникает ошибка, при отладке главной программы, отладчик перебрасывает в окно дизассемблера, где вместо ассемблерных команд знаки вопроса. Т.е. такое ощущение, что при вызове функции FreeLibrary, в каком-то месте происходит "прыжок" на адрес в памяти, где нет никаких инструкций. Если скомпилировать DLL с использованием классического компилятора Borland, то и в режиме Debug, и в режиме Release всё работает нормально.

[Kitty]

интересно обосновано возвращение такой зависимости и можно ли как-нибудь от неё избавиться?

 

 

Это баг. Обсуждалось здесь:

https://forums.embarcadero.com/thread.jspa?threadID=117351&tstart=15

Может исправят в первом апдейте, а может и нет.

[estra]

Попробуй вырезать ненужную зависимость утилитой CFF Explorer

[Pulsarius]

Спасибо большое за ответы! Проблема решена. CFF Explorer помог. Я так понял, что идёт статическая линковка BORLNDMM.dll, но ни одна функция от туда не вызывается. Т.е. получается бесполезная зависимость от этой борландовской библиотеки. Обидный баг конечно. Такое ощущение, что специально делают такие якобы нечаянные и нелепые баги в билдере, вынуждая переходить на Delphi. Т.к. в Delphi таких нелепых багов я не встречал.
В ходе написания DLL я заметил, что есть ещё один скорее всего баг, при работе с TFDQuery (FireDAC). Свойство RecordCound имеет  значение 50 всегда, когда количество записей по факту больше 50-и. Решается это вызовом метода Refresh.

[Kitty]

Насчет принуждения перехода к дельфи это вряд ли. Зачем тогда они развивают Builder?Например попытка добавить поддержку стандарта С++11. Проблема в не желании тестировать свои релизы.

А насчтет FireDAC, FetchAll вызываете при запросе?

Изменено 4 ноября, 2015 пользователем Kitty

[Pulsarius]

Нет, не вызывал. Прочитал в хелпе про FetchOptions, выставил FetchOptions.Manual = fmAll и теперь всё работает как надо. Только не пойму смысла. Если эта опция отвечает якобы за ограничение получения записей, то почему по факту в TFDQuery количество записей было больше выставленного максимума, т.е. все записи, которые возвращает мне запрос? По идее в данном случае в память DataSet не должно было грузиться более 50 записей. А так получается смысла в этой опции нет, она только не даёт свойству RecordCount стать выше установленного максимума, а в DataSet всё равно грузятся все записи, возвращённые запросом, и пройтись по ним можно вызывая в цикле Next() пока свойство Eof не будет истинным.

Изменено 5 ноября, 2015 пользователем Pulsarius