Скачать: 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 вся ветка

Скачать: CL | DM;



Память: 0.73 MB
Время: 0.017 c