Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Можно ли проверить указатель на корректность?


Страницы:   1 2 3

SPeller ©   (2010-04-29 04:17:00) 

Есть ли стандартные механизмы проверки некого указателя на корректность? Например, что этот блок памяти выделен текущим менеджером памяти и при обращении к нему не будет AV?


SPeller   (2010-05-05 14:42:00) [1]


> Leonid Troyanovsky ©   (05.05.10 09:08) [53]
> Если размер блока будет удачный, то заранее распределенный
> массив
> будет, IMHO, быстрее, бо не нужны многочисленные alloc-free.
> Ну, это все при условии, что можно разово распределить
> подходящий по размеру фрагмент.

Скорее всего не выйдет. Всегда будет вероятность превышения размера. Заранее неизвестно сколько объектов будет работать и сколько вызовов будет одновременно производиться.

off:

> Игорь Шевченко ©   (05.05.10 10:45) [56]
> Не могу молчать, у меня вызывают живой и неподдельный интерес
> потомки Ивана Кулибина, изобретающие очередной пятиколесный
> велосипед. Хочешь, чтобы молчал - не пиши.

Потомок настрадамуса?? )))
Вот ты же не спросил что для чего, отчего и почему, а уже ярлыков навешал. Это типа так правильно, так подобает Мастерам? По-моему, это обыкновенный старческий снобизм, типа я очень умный, а вы идиоты, и это не я должен думать почему не считать вас идиотами, а вы должны меня убеждать что вы не идиоты.
Проще будь.


brother   (2010-05-05 12:37:00) [2]

> Не могу молчать,

ну, свобода слова)


Игорь Шевченко   (2010-05-05 10:45:00) [3]

SPeller ©   (05.05.10 02:46) [47]


> Есть что сказать по делу - говорите, нет - молчите


Не могу молчать, у меня вызывают живой и неподдельный интерес потомки Ивана Кулибина, изобретающие очередной пятиколесный велосипед. Хочешь, чтобы молчал - не пиши.


Leonid Troyanovsky   (2010-05-05 09:48:00) [4]


> Чилли-Всучилли   (05.05.10 09:14) [54]

>  при необходимости отображая в нужные участки памяти процессов
> в случае GlobalXxx,

Оно ничего не отображает, Global - это дань 16 битному прошлому.

--
Regards, LVT.


Чилли-Всучилли   (2010-05-05 09:14:00) [5]

are slower than other memory management function

Чем другиефункции управления памятью. Некоторое замедление связано с тем, что работа ведется через хендлы ОС, а не через указатели, то есть, ОС должна заносить хендлы во внутренние списки и, при необходимости (xxxLock, xxxFree), проверять наличие хендлов в списках, переводить их в вид простых указателей, при необходимости отображая в нужные участки памяти процессов в случае GlobalXxx, а в случае LocalXxx и этого делать не надо. То есть, на деле, задержки хоть и есть, но весьма небольшие. Тем более, что все это уже даным-давно максимально оптимизировано разработчиками ОС.

То есть, на самом деле это и есть "какой-то быстрый список указателей на выделенные блоки, по которому и бегать при проверке" (С) [42], только реализованный на уровне ОС.


Leonid Troyanovsky   (2010-05-05 09:08:00) [6]


> SPeller ©   (05.05.10 08:56) [51]

> - IMalloc или своё на TBits?

Если размер блока будет удачный, то заранее распределенный массив
будет, IMHO, быстрее, бо не нужны многочисленные alloc-free.

Ну, это все при условии, что можно разово распределить
подходящий по размеру фрагмент.

--
Regards, LVT.


SPeller   (2010-05-05 09:00:00) [7]


> Чилли-Всучилли   (05.05.10 08:45) [50]
> GlobalAlloc() / GlobalLock() / GlobalUnlock() / GlobalFree()
> LocalAlloc() / LocalLock() / LocalUnlock() / LocalFree()
>
> ОС сама будет следить за корректностью хендлов. При попытке
> залочить некорректный хендл памяти - вернет nil. Вот и вся
> проверка.

Что-то msdn сходу пугает: The global functions are slower than other memory management functions. А мне замедлять не нуно :) Наоборот быстродействие здесь критично.


SPeller   (2010-05-05 08:56:00) [8]


> в COM есть еще всякие IMalloc

У меня свой ком :) IMalloc... тоже вариант. Кто будет лучше - IMalloc или своё на TBits? Или без разницы, только IMalloc уже готовый?

С RWM я подумаю. Сейчас использую диапазон сообщений, который отфильтровываю из очереди. RWM не гарантирует что возвращенные номера сообщений будут подряд. Поэтому, скорее всего, придется в одно сообщение всё засунуть. Наверное так и сделаю.


Чилли-Всучилли   (2010-05-05 08:45:00) [9]

Указатель передаю через параметр оконного сообщения...Так вот, нет абсолютно никакой гарантии, что чужое приложение не пошлет окну сообщение с таким же номером, и что оно передаст в wParam тоже неизвестно. Ситуэйшин редкий, согласен, но зачем испытывать судьбу.

GlobalAlloc() / GlobalLock() / GlobalUnlock() / GlobalFree()
LocalAlloc() / LocalLock() / LocalUnlock() / LocalFree()

ОС сама будет следить за корректностью хендлов. При попытке залочить некорректный хендл памяти - вернет nil. Вот и вся проверка.


С любовью, твой дядя Исаак   (2010-05-05 08:33:00) [10]

Удалено модератором


Leonid Troyanovsky   (2010-05-05 08:12:00) [11]


> SPeller ©   (05.05.10 02:46) [47]

> must process the same message. For sending private messages
> within a window class, an application can use any integer

Дык, оно ж не приватное, бо приложение - чужое, и только
его создателю известно как оно на него среагирует.

Для гарантии нужно гарантированно уникальное (на уровне
сессии) сообщение, т.е., RWM.

> Off:

Во-ще-то, в COM есть еще всякие IMalloc.

--
Regards, LVT.


SPeller   (2010-05-05 02:46:00) [12]


> Leonid Troyanovsky ©   (04.05.10 07:31) [45]
> RegisterWindowMessage?

Мсдн не рекомендует:
Only use RegisterWindowMessage when more than one application must process the same message. For sending private messages within a window class, an application can use any integer in the range WM_USER through 0x7FFF


> IMHO, выделить массив блоков потребного размера,
> и использовать TBits для индексов свободных блоков.

Спасибо, подумаю над этим.

Off:

> Игорь Шевченко ©   (04.05.10 12:30) [46]
> А зачем гланды вырезать через непредназначенное для этого
> отверстие ?

Игорь, у меня иммунитет к вашему снобизму. Есть что сказать по делу - говорите, нет - молчите. "Умные" советы вобщем и ни о чем одновременно мне не нужны.


Игорь Шевченко   (2010-05-04 12:30:00) [13]

SPeller ©   (04.05.10 02:02) [42]

А зачем гланды вырезать через непредназначенное для этого отверстие ?


Leonid Troyanovsky   (2010-05-04 07:31:00) [14]


> SPeller ©   (04.05.10 02:02) [42]

> Почему мне это нужно. Указатель передаю через параметр оконного
> сообщения (внутри процесса, ессно) в сообщении WM_USER +

RegisterWindowMessage?

> Наверное, нужно заводить какой-то быстрый список указателей

IMHO, выделить массив блоков потребного размера,
и использовать TBits для индексов свободных блоков.

--
Regards, LVT.


SPeller   (2010-05-04 06:36:00) [15]

Кто запрещает приложению слать сообщения WM_USER?


Германн   (2010-05-04 02:10:00) [16]


> Так вот, нет абсолютно никакой гарантии, что чужое приложение
> не пошлет окну сообщение с таким же номером

Хм. Ты уверен?


SPeller   (2010-05-04 02:02:00) [17]

Почему мне это нужно. Указатель передаю через параметр оконного сообщения (внутри процесса, ессно) в сообщении WM_USER + N, который указывает на структуру с данными (маршалинг). Программа моя в виде длл может загружаться в произвольное приложение. Окно создается моей дллкой в основном гуишном потоке. Так вот, нет абсолютно никакой гарантии, что чужое приложение не пошлет окну сообщение с таким же номером, и что оно передаст в wParam тоже неизвестно. Ситуэйшин редкий, согласен, но зачем испытывать судьбу. И вот тут, чтобы не было ненужных ошибок в будущем, я и хотел вставить проверочку на то, что указатель - это указатель на память и оттуда можно хотябы читать. Поскольку структуры, которые я передаю, используются для маршалинга ком вызовов, то тут алгоритмы, снижающие быстродействие, применять нежелательно.

Наверное, нужно заводить какой-то быстрый список указателей на выделенные блоки, по которому и бегать при проверке.


Демо   (2010-04-30 16:20:00) [18]


> Игорь Шевченко ©   (30.04.10 15:52) [40]
> Демо ©   (30.04.10 13:26) [39]

> Gunsmoker - это не object pascal language guide.


Ну я и не говорил, что по нему нужно Delphi изучать.

По поводу остального позже напишу...


Игорь Шевченко   (2010-04-30 15:52:00) [19]

Демо ©   (30.04.10 13:26) [39]


> http://transl-gunsmoker.blogspot.com/2009/09/blog-post.html


Gunsmoker - это не object pascal language guide.


> > Займись на досуге увеличением на единицу переменной типа
>
> > Pointer
>
>
> А в чём проблема?



> К указателям применима адресная арифметика


У тебя тип Pointer поддерживает арифметику ?
или это тоже не указатель ?


Демо   (2010-04-30 13:26:00) [20]


> Займись на досуге увеличением на единицу переменной типа
> Pointer


А в чём проблема?


> И скажи, что такое ссылка в терминах Object pascal


Лень самому напрягаться...

http://transl-gunsmoker.blogspot.com/2009/09/blog-post.html

Ссылки (References)
Многие типы в Delphi фактически являются указателями, но притворяются простыми типами. Я называю такие типы ссылочными. Примерами таких типов являются динамические массивы, строки, объекты и интерфейсы. Все они являются указателями "под капотом" языка, но с некоторой дополнительной семантикой и часто со скрытым содержанием.

Динамические массивы (dynamic arrays)
Многомерные динамические массивы
Строки (Strings)
Объекты (Objects)
Интерфейсы (Interfaces)
Ссылочные параметры
Нетипизированные параметры
Что отличает ссылки (references) от указателей (pointers):

Ссылки неизменяемы. Вы не можете увеличить или уменьшить ссылку. Ссылки указывают на определённые структуры, но никогда не указывают в середину них, как, например, указатели на данные массива в примерах выше.
Ссылки не используют синтаксис указателей. Это скрывает тот факт, что они являются указателями, и делает их сложнее для понимания для тех, кто не знаком с этой темой (и поэтому люди делают с ними вещи, которых делать нельзя).
Не путайте такие ссылки со ссылочными типами (reference types) в C++. Они во многом отличаются.


Страницы:   1 2 3

Наверх

Титульная страница Поиск, карта сайта Написать письмо