Текущий архив: 2013.06.02;
Скачать: CL | DM;
Вниз
Зачем delphi свой менеджер памяти? Найти похожие ветки
← →
Павиа (2013-01-23 18:08) [120]
Ну, про такие в общем-то понятно. Может, если в процессоре их реализуют, так то и будет.
>
Зачем в процессоре! dz делает ОС с такими указателями. Называется ФантомОС (не путать с человеком)
← →
Inovet © (2013-01-23 18:11) [121]> [119] Игорь Шевченко © (23.01.13 17:59)
> Ты вообще о чем ?
Это фантазии. Указатели, которые в Интел, на слишком крупные куски указывают. Надо, чтобы на любой адрес. В общем памяти для трасляции понадобится ещё столько же, как и основной.
← →
Inovet © (2013-01-23 18:16) [122]> [120] Павиа (23.01.13 18:08)
> ФантомОС
Посмотрел.
← →
Игорь Шевченко © (2013-01-23 18:20) [123]Inovet © (23.01.13 18:11) [121]
Фантазии должны быть другие
← →
Pavia © (2013-01-23 20:24) [124]
> Полагаю что говоря об OpenCV-менеджере куч мы имеем ввиду
> MemStorage-механизм с соответствующим набором касаемых его
> OpenCVAPI-вызовов..http://locv.ru/wiki/8.1_%D0%A5%D1%80%D0%B0%D0%BD%D0%B8%D0%BB%D0%B8%D1%89%D0%B0_%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D0%B8
Добрался до дому. Залес в исходники OpenCV. Для основных объектов OpenCV используется malloc. И ещё раз повторюсь в грамотной архитектуре не нужно лишнего. Что касается того что описано в вике то оно используется рас два и обчёлся где. И судя по всему появилась после открытия исходников OpenCV. (т.е кривыми руками).
> Я что-то не понял - ты подменил дельфийский менеджер opencv"шным
> что ли ?
Нет. У меня свой аналог OpenCV на Delphi.
← →
Сергей М. © (2013-01-23 20:33) [125]
> [124]
Бред какой-то..
← →
icWasya © (2013-01-24 09:49) [126]А вот ещё
http://www.gunsmoker.ru/2009/01/blog-post.html
← →
Дмитрий С © (2013-01-24 10:12) [127]
> А вот ещё
> http://www.gunsmoker.ru/2009/01/blog-post.html
Про HeapAlloc автор ничего не сказал.
← →
Тымохов (2013-01-24 14:36) [128]наск. помню по манагеру старому и манагеру начиная с fastmm они и берут большой кусок сразу, потом распределяют.
fastmm наск. помню историю во много спас какой-то из дельфей. вроде как 8-ой дельфи был страшно тормознутый. потом вышла след. версия в новым манагером (как в создаваемых программах, так и в самой IDE) и стало все существенно быстрее.
в 2007 год я глубоко изучил fastmm на тот момент. у автора там хитро сделано. т.е. он как-бы учел специфику задач к манагеру и прооптимизировал с учетом этой специфики. в частности у него по-разному выделяются большие и маленькие блоки.
видимо, в этом и есть ответ - зачем свой манагер - так быстрее.
← →
icWasya © (2013-01-25 15:02) [129]>Про HeapAlloc автор ничего не сказал.
зачем свой манагер - дабы не нарушать авторские права фирмы MicroSoft. При возможном переезде на другую платформу портируется СВОЯ рун-тайм библиотека - и всё будет работать.
← →
jack128 © (2013-01-25 15:23) [130]
> зачем свой манагер - дабы не нарушать авторские права фирмы
> MicroSoft. При возможном переезде на другую платформу портируется
> СВОЯ рун-тайм библиотека - и всё будет работать.
угу, тут на WinRT не могут переехать, а ты про другие платформы..
← →
Eraser © (2013-01-25 16:17) [131]
> jack128 © (25.01.13 15:23) [130]
вообще очень радует firemonkey, пока "промышленно" под него ничего не писали, но тесты провожу регулярно. например, без особого труда удалось перевести две известные криптобиблиотеки (LockBox 3 и dcpcrypt), да и вообще исходные модули XE3 уже фактически готовы для ARM и Linux (для Mac уже можно компилировать). Генофонд сильно переписан за последнее время. Т.е., по крайней мере у меня, впечатление, что на этот раз, с N-ой попытки, им удалось сделать хороший кроссплатформенный инструмент, верной дорогой идут.
Страницы: 1 2 3 4 вся ветка
Текущий архив: 2013.06.02;
Скачать: CL | DM;
Память: 0.75 MB
Время: 0.017 c