Недоиспользование динамических типов в Дельфи?

← →
It's not me (2009-03-03 14:56) [0]

Например, я в своих проектах активно использую тип Types.TByteDynArray - но я еще ни одного проекта не видел, чтобы делали также.

С одной стороны, это ведь очевидно удобно, в тех же сетевых / транспортных делах. Пришла информация - определил размер, сделал SetLength, забрал информацию (из сокета, допустим). Но с другой стороны, почему это так мало используется?

Хрен где встретишь код:

function Answer: TByteDynArray; begin SetLengthh(Result, Sock.Len); Sock.WriteBuf(Result[0], Length(Result) ); end;

Зато можно встретить код аля:

cMaxUdpLen = 64kb; TUdpBuffer = array[0..cMaxUdpLen-1] of byte; function Answer(out Buf: TUdpBuffer): integer; begin Result := Sock.Len; Sock.WriteBuf(Buf[0], Result ); end;

Ну это я совершенно для примера. То есть, вместо того чтобы использовать динамический массив байтов (нигде не встречал) используется знание, что дейтаграмма UDP не может быть более 64 кбайт и соответственно используется статический массив.

Почему, откуда это берется? Это привычка, перепевки примеров с Си, где нет удобной работы с дин. массивами или есть объективные причины?

Скорость? Вроде нет, насколько я знаю нет принципиальной разницы выделить память под статическую локальную переменную в 64 кбайт и выделить память для динамического массива, но уже по факту. Более того, можно только сэкономить, так как реально 64 кбайт предельный случай, а на практике гораздо меньше и выделять память мЕньшего объема - быстрее. И меньше ресурсов требует.

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

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

Что думаете?

← →
Ega23 © (2009-03-03 15:00) [1]

> Что думаете?

Я TMemoryStream использую. Отсутствие сборки мусора не напрягает.

← →
It's not me (2009-03-03 15:07) [2]

ну со Stream я понять могу.

Интерес больше касается, когда предпочитают писать на статических байтовых массивах. Зачем, когда есть динамические?

Причем, ладно новички, но ведь такое встречается иногда в серьезных продуктах. Что это - привычка, неумение / нежелание работать с динамикой?
Или есть какие-то объективные полезные причины?

← →
Сергей М. © (2009-03-03 15:13) [3]

> предпочитают писать на статических байтовых массивах. Зачем,
> когда есть динамические?

И что ? Теперь нужно пихать их везде подряд, по делу и без дела, лишь потому что кто-то там обещал убрать за тобой ?

← →
test © (2009-03-03 15:15) [4]

It"s not me (03.03.09 14:56)
Это такая хитрая подстава Java программистов,
"Пишите наконец чтобы тормозило как у нас" ?
Кто это чудо удалять будет и когда?
А он сегодня подойдет удалять все лишнее или можно не ждать?

← →
It's not me (2009-03-03 15:22) [5]

> Теперь нужно пихать их везде подряд

зачем везде. Там, где идет работа с данными неизвестной на этапе компиляции длины.

Вот ты, видимо, из старой школы. И хотелось бы услышать мнение, ЧЕМ в данной ситуации статические массивы лучше? Чем лучше динамические - я уже описал - во-первых, автоматическая сборка мусора, во-вторых, более быстрая работа и меньшее задействование ресурсов.

Какие аргументы в пользу статических?

> Это такая хитрая подстава Java программистов,
> "Пишите наконец чтобы тормозило как у нас" ?
> Кто это чудо удалять будет и когда?
> А он сегодня подойдет удалять все лишнее или можно не ждать?
>

я не понимаю зачем писать такие посты при полном непонимании вопроса.

← →
Сергей М. © (2009-03-03 15:27) [6]

> ЧЕМ в данной ситуации статические массивы лучше?

"Данная" ситуация - эта какая, прием произвольной UDP-дейтаграммы ? Или что ?

← →
KSergey © (2009-03-03 15:32) [7]

> It"s not me (03.03.09 14:56)
> Что думаете?

Во-первых, привычка и калька с С кода, сэмплы и все такое.
Во-вторых, переаллокация памяти - штука хреновая, тем более если можно гарантированно обойтись весьма небольшим статическим массивом + Int-размер. Кому сильно хоцца круточти - на TxxxStream переходят, по всем аспектам кошернее.

← →
test © (2009-03-03 15:37) [8]

It"s not me (03.03.09 15:22) [5]
>>во-первых, автоматическая сборка мусора
Работает в произвольный момент

>>во-вторых, более быстрая работа и меньшее задействование ресурсов
Разработчика, когда сборщик удалит никто не знает(зависит от алгоритма) то есть какая то часть памяти будет хранить данные которые никому не нужны уже. Поскольку память не бесконечна, то через некоторое время памяти 0 и все работает через файл подкачки(снижение производительности на 1000)

← →
It's not me (2009-03-03 16:12) [9]

> "Данная" ситуация - эта какая, прием произвольной UDP-дейтаграммы
> ?

допустим, да

> Во-вторых, переаллокация памяти - штука хреновая

а я нигде не призываю использовать переаллокацию. Штука в том, что динамический массив на мой взгляд полностью перекрывает возможности, скорости и эффективности статического. ПЛЮС добавляет некоторые возможности, например, переаллокация памяти, которой в статических по определению просто нет. Начальное выделение памяти не считается, ибо такое же выделение проделывается со статическим массимом, только неявно.

> >>во-первых, автоматическая сборка мусора
> Работает в произвольный момент

ты про java? А нахрена ты второй раз склоняешь тему в java-область? Речь идет о дельфи. А в дельфи сборщик мусора работает строго по области видимости переменной. Поэтому заранее все четко и понятно. Если четко можно выявить область видимости.

> когда сборщик удалит никто не знает(зависит от алгоритма)
> то есть какая то часть памяти будет хранить данные которые
> никому не нужны уже. Поскольку память не бесконечна, то
> через некоторое время памяти 0 и все работает через файл
> подкачки(снижение производительности на 1000)

данный бред даже комментировать не хочется.

← →
Сергей М. © (2009-03-03 16:31) [10]

> It"s not me (03.03.09 16:12) [9]

> допустим, да

Если буфер макс.размером в 64К нужен на всем протяжении работы приложения, то, разумеется, предпочтительней будет дин. распределение памяти. Как это будет сделано - не суть важно, это м.б. и дин.массив, и GetMem, и что угодно использующее рантайм-менеджер памяти.

Но гораздо чаще требуется временный буфер сравнительно небольшого фиксированного размера, к которому можно было бы обращаться как к массиву. В таких случаях очевидное решение - использование локальной переменной, объявленной как стат.массив: память под него компилятор резервирует в стеке и автоматически балансирует стек при выходе переменной из области видимости.

← →
test © (2009-03-03 16:35) [11]

It"s not me (03.03.09 16:12) [9]
>>Если четко можно выявить область видимости.
А если нет?

← →
KSergey © (2009-03-03 16:42) [12]

> It"s not me (03.03.09 16:12) [9]
> > Во-вторых, переаллокация памяти - штука хреновая
> а я нигде не призываю использовать переаллокацию.

Т.е.? А дин. массив - он из волшебства?? Дин массив - это как минимум выделил/освободил. Статический на стеке в этом плане предпочтительнее, тем более если размер известен заранее.

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

Вообще от задачи зависит, понятно, но в высокопроизводительных серверах стоит стараться без переаллокаций обходиться. Если же сетевой обмен только время от времени или производительность всех устраивает - то можно использовать что нравится и удобнее программисту в смысле телодвижений/надежности. Вот и все.

← →
KSergey © (2009-03-03 16:44) [13]

> test © (03.03.09 16:35) [11]
> >>Если четко можно выявить область видимости.
> А если нет?

Глобальные переменные - наше все! :)

← →
It's not me (2009-03-03 17:02) [14]

> Но гораздо чаще требуется временный буфер сравнительно небольшого
> фиксированного размера

а причем тут это? Речь идет о случаях, когда на этапе компиляции размер данных неизвестен.
Как пример - смотрим верхний пост.

> к которому можно было бы обращаться как к массиву

к динамическому массиву точно также можно обращаться как и к статическому. Кроме разве возможности при объявлении задать нумерацию элементов.

> А если нет?

а если нет - то в таких случаях использование статических массивов просто невозможно.

> А дин. массив - он из волшебства??

не не не, Девид Блейн. Волшебство - это умение не читать чужие посты:

> Начальное выделение памяти не считается, ибо такое же выделение
> проделывается со статическим массимом, только неявно

впрочем:

> Статический на стеке в этом плане предпочтительнее

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

> высокопроизводительных серверах стоит стараться без переаллокаций
> обходиться

и правильно. Но причем тут сабж? Еще раз - переаллокация всего лишь дополнительная возможность, которая в статических массивах отсутствует! Да, это возможность тормозная, но ругать из-за этой возможности дин. массивы? Не хочешь - не пользуй.
Делай только начальное выделение, которое эквивалентно (не считаем стек) неявному выделению памяти для статического массива. И ты сэкономишь на том, что выделишь на этапе исполнения ровно столько памяти, сколько нужно в случае изначально неизвестной длины данных. В отличии от статики, где выделить нужно максимально возможный объем.

Понятное дело, что если размер известен на этапе компиляции смысла использовать динамику нету.

← →
Сергей М. © (2009-03-03 17:05) [15]

> Хрен где встретишь код

> совершенно для примера

Ну почему же ?
Возврат дин.массива результатом ф-ции - не такая уж и редкость.
Но пример совершенно не показателен, ибо вырван непонятно из какого контекста.

← →
It's not me (2009-03-03 17:12) [16]

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

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

А насчет первоначального выделения памяти в куче - так для стека тожно изначально память выделяться должна.

← →
It's not me (2009-03-03 17:14) [17]

> Возврат дин.массива результатом ф-ции - не такая уж и редкость

не помню, чтобы я вообще это где-то видел, кроме своих проектов (и если не рассматривать string). Примеры из VCL?

← →
Сергей М. © (2009-03-03 17:20) [18]

> виндовый и дельфовый менеджер памяти тоже используют оптимизацию
> для кучи

Значит ты должен четко представлять принципы и особенности этой оптимизации для конкретного менеджера.

> с таким же успехом может не хватить памяти в стеке

А на то ты и программист, чтобы настроить и использовать стек своего приложения эффективно и безопасно.

Разумеется, если предел размера стека тобой осознанно выбран сравнительно небольшим, то и аллокировать в нем шматки по 64К тобой явно не предполагается.

← →
Sapersky (2009-03-03 17:23) [19]

не помню, чтобы я вообще это где-то видел, кроме своих проектов (и если не рассматривать string). Примеры из VCL?

Кстати, string и дин. массив байтов - это практически "одно и то же лицо", разве что у массивов нет copy-on-write, или как оно правильно называется.
Что касается конкретно VCL - вероятно, дело в том, что дин. массивы появились с D4, а бОльшая часть кода VCL была написана раньше.

← →
Ega23 © (2009-03-03 17:27) [20]

function Answer: TByteDynArray; begin SetLengthh(Result, Sock.Len); Sock.WriteBuf(Result[0], Length(Result) ); end;

function Answer: TMemoryStream; begin Result := TMemoryStream.Create; try Result.Size := DataSize; Result.Write(pData^, DataSize); Result.Position := 0; except Result.Free; Result := nil; end; end;

← →
It's not me (2009-03-03 17:50) [21]

> Значит ты должен четко представлять принципы и особенности
> этой оптимизации для конкретного менеджера

...

> А на то ты и программист, чтобы настроить и использовать

порадовало )))

> Что касается конкретно VCL - вероятно, дело в том, что дин.
> массивы появились с D4, а бОльшая часть кода VCL была написана
> раньше

да, это, видимо, тоже.
В общем, код со стат. массивами остался, видимо, по привычке или как наследие.

← →
test © (2009-03-03 18:34) [22]

It"s not me (03.03.09 17:14) [17]
Не дай бог тебе про STL узнать))

← →
It's not me (2009-03-03 19:09) [23]

Дай бог тебе научиться писать по теме.

← →
test © (2009-03-03 19:26) [24]

It"s not me (03.03.09 19:09) [23]
По теме, ты нашел сборщик мусора и думаешь что он решит все твои проблемы, нет не решит, это только еще одна фишка в программировании. Таких фишек еще дофига, и новых и старых.

← →
Сергей М. © (2009-03-03 19:54) [25]

> It"s not me (03.03.09 17:50) [21]

А ты от кого собссно шифруешься, г-н нежданно обрадованный ?)
Это ж ты, хоть ты и трижды не ты)..

← →
KSergey © (2009-03-03 21:29) [26]

капец... чувак пытается отстоять своё мнение во что бы то ни стало. Да оно никому не обосралось! никому нет до этого дела, соображаешь?
Ну хочешь ты пользовать дин. массивы - ну пользуй! в чем беда-то? никто ж не против. Только не забывай, что дин. массив - это выделил/удалил, выделил/удалил. По определению.
Если один раз выделили и пользуешь - это уже не динамический массив.

а вот когда ты под профайлером на это выделил/удалил посмотришь - тогда будет смысл разговаривать.

Сейчас же аргументов привели кучу, не ты хочешь их слышать, тогад зачем тема? никто не заставляет ведь пользовать статику. комплексы?

← →
Сергей М. © (2009-03-03 21:44) [27]

> KSergey © (03.03.09 21:29) [26]

> комплексы?

Еще какие)
Это один из недавнихних местных "обиженых", судя хотя бы по нику)

← →
oxffff © (2009-03-03 22:47) [28]

> It"s not me (03.03.09 15:22) [5]
>
> > Теперь нужно пихать их везде подряд
>
> зачем везде. Там, где идет работа с данными неизвестной
> на этапе компиляции длины.
>
> Вот ты, видимо, из старой школы. И хотелось бы услышать
> мнение, ЧЕМ в данной ситуации статические массивы лучше?
> Чем лучше динамические - я уже описал - во-первых, автоматическая
> сборка мусора, во-вторых, более быстрая работа и меньшее
> задействование ресурсов.

У каждого подхода есть свои + и -.

← →
oxffff © (2009-03-03 23:03) [29]

> И хотелось бы услышать
> > мнение, ЧЕМ в данной ситуации статические массивы лучше?
>

1. Выделение памяти под локальную переменную - статический массив проходит быстрее.
2. Вопрос интероперабельности с не Delphi кодом динамических массивов(да и вообще всех управляемых типов) потребует дополнительных затрат,

← →
Ega23 © (2009-03-04 09:58) [30]

А мне кажется, что это очень хорошо законспирированный развод.

← →
test © (2009-03-04 10:32) [31]

Ega23 © (04.03.09 09:58) [30]
В чем смысл развода?

← →
Ega23 © (2009-03-04 10:42) [32]

> В чем смысл развода?

Ради флуда.

← →
brother © (2009-03-04 10:43) [33]

гг)

← →
test © (2009-03-04 10:46) [34]

Ega23 © (04.03.09 10:42) [32]
А ну тогда все в порядке, это ж "Потрепаться" ,а не "Базы" ))

← →
Marser © (2009-03-04 10:52) [35]

> Ega23 © (04.03.09 09:58) [30]
>
> А мне кажется, что это очень хорошо законспирированный развод.
>
>

IT-троллинг? Так тут не мальчики собрались :-)

ИМХО, у автора с критериями некоторые проблемы. 64 килобайта это сейчас смех один, хуже когда программа работает сутками, эти структуры плодятся и не освобождаются, но если они нужны в заданном количестве, то динамическая работа может стать ненужным тормозом.
Вот между двумя этими полюсами - утечкой памяти и утечкой процессорного ресурса, и нужно выбирать что-то посередине, а не шарахаться из крайности в крайность, ИМХО.

P.S. Естественно, если человек понимает, что он делает и зачем, а не просто использует динамические массивы, потому что это круто...

← →
Anatoly Podgoretsky © (2009-03-04 11:21) [36]

> Ega23 (04.03.2009 9:58:30) [30]

Или провокация.

← →
Anatoly Podgoretsky © (2009-03-04 11:22) [37]

> test (04.03.2009 10:32:31) [31]

А для развода смысл требуется?

← →
clickmaker © (2009-03-04 11:39) [38]

> А для развода смысл требуется?

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

← →
test © (2009-03-04 11:44) [39]

Marser © (04.03.09 10:52) [35]
"Когда умеешь пользоваться только молотком, все вокруг кажется гвоздями"

← →
test © (2009-03-04 11:45) [40]

Marser © (04.03.09 10:52) [35]
Я эт про автора, у него похоже динамические структуры поперек мозга застряли

← →
It's not me (2009-03-04 11:48) [41]

> У каждого подхода есть свои + и -.

вот именно. И в данной ситуации не вижу плюсов у статических массивов. А тем не менее в коде неоднократно их встречал. Вот и хочется узнать - это хоть чем-то обосновано или просто привычки?

> 1. Выделение памяти под локальную переменную - статический
> массив проходит быстрее

это ты про стек говоришь? Я уже рассматривал данный вариант.

> 2. Вопрос интероперабельности с не Delphi кодом динамических
> массивов(да и вообще всех управляемых типов) потребует дополнительных
> затрат

не понял.

← →
clickmaker © (2009-03-04 11:52) [42]

> И в данной ситуации не вижу плюсов у статических массивов

+ такой, что нет накладных расходов на выделение памяти и отслеживания ссылок на переменную.

← →
Сергей М. © (2009-03-04 11:56) [43]

> это хоть чем-то обосновано

Да, обосновано - конкретным контекстом их применения.

А ты вырвал свой шматок кода из какого-то никому кроме тебя неведомого контекста и считаешь что тем самым "обосновал" решение с дин.массивом.

← →
oxffff © (2009-03-04 12:09) [44]

> > 1. Выделение памяти под локальную переменную - статический
>
> > массив проходит быстрее
>
> это ты про стек говоришь? Я уже рассматривал данный вариант.
>

Где рассматривал? Ссылку на вашу работу можно?
Существуют способы динамического выделения памяти на стеке при условии определенных правилах.
Ты их рассматривал?

> > 2. Вопрос интероперабельности с не Delphi кодом динамических
>
> > массивов(да и вообще всех управляемых типов) потребует
> дополнительных
> > затрат
>
> не понял.

Внешние языки могут не содержать такой семантический эквивалент типа(динамический массив). Хотя могут быть совместимы для использования, но несовместимы для управления временнем жизни(ссылок), именно для этого придется либо принудительно продлевать время жизни, либо нагораживать дополнительную семантику(вручную либо через перегрузку операторов).

← →
KSergey © (2009-03-04 12:23) [45]

> oxffff © (04.03.09 12:09) [44]
>>> 2. Вопрос интероперабельности
>> не понял.
> могут не содержать такой семантический эквивалент

Из серии "кто уже и так знает - тот поймет" :)

PS
Все правильно, пусть мозг включит наконец.
А то ему пишут-пишут плюсы/минусы, а он заладил как попка-попугай "не вижу, не вижу". И сам одно и тоже талдычит всю ветку совершенно не обращая внимания на ответы.

← →
KSergey © (2009-03-04 12:27) [46]

> It"s not me (04.03.09 11:48) [41]
> > У каждого подхода есть свои + и -.
> вот именно. И в данной ситуации не вижу плюсов у статических массивов.

Их вполне может и не быть. Ну написал кто-то вот так, оно работет, стабильно. Все довольны.
Солнце вон тоже всходит и заходит. "А есть ли в этом плюсы и минусы?"

← →
It's not me (2009-03-04 12:44) [47]

> Где рассматривал?

пост [16]

> Внешние языки могут не содержать такой семантический эквивалент
> типа(динамический массив). Хотя могут быть совместимы для
> использования, но несовместимы для управления временнем
> жизни(ссылок),

вообще непонятно, что ты имеешь в виду. Если говорить о внешних языках, то они в любом случае несовместимы в вопросах выделения / освобождения памяти для какой бы то ни было переменной вообще, и это не касается ни конкретно статических, ни конкретно динамических массивов. Просто хотя бы потому, что в дельфи свой менеджер памяти, а во внешнем языке будет свой или ориентация исключительно на WinApi"шные функции.

Я вообще НИ РАЗУ не встречал ситуаций, когда память выделяется в одном модуле (Exe / DLL), а высвобождается в другом. Так никто никогда не делает. Если ты имеешь в виду ВНЕШНИЕ языки.

> + такой, что нет накладных расходов на выделение памяти
> и отслеживания ссылок на переменную

блин, про выделение памяти уже приподзапарило. Как это на статический массив не нужно выделение памяти?! А откуда возьмется блин память тогда? Ну хватит уже.

Под статический массив один фиг нужна память, она будет или выделена неявно в куче (какая при этом разница по сравнению с явным выделением памяти в куче?!) или выделена в стеке. Но память под стек один хрен в свое время была выделена опять же в куче, просто заранее. Давайте не будем сто раз одно и тоже прокручивать, а?

Что касается отслеживания ссылок... А где там накладные расходы? Только при присвоении массивов, в этом случае у статических массивов еще больше расходов - происходит полное копирование элементов. Хочешь добиться поведения как у статических массивов? Пиши: DynArray1 = Copy(DynArray2... ) - наздоровье. В любом случае динамические массивы полностью перекрывают возможности статических массивов.

И там где используются статические массивы - ВСЕГДА можно использовать динамические, причем так, что затраты будут одинаковые. Это если размер данных заранее известен. А если размер данных неизвестен - то тут динамические массивы позволят только выиграть в скорости и ресурсах.

← →
Ega23 © (2009-03-04 12:54) [48]

А народ всё ведётся и ведётся.... И народ-то не глупый.... :)

← →
clickmaker © (2009-03-04 12:55) [49]

> Под статический массив один фиг нужна память, она будет
> или выделена неявно в куче

а не в сегменте DATA?

← →
clickmaker © (2009-03-04 13:01) [50]

вернее, в BSS

> А если размер данных неизвестен - то тут динамические массивы
> позволят только выиграть в скорости и ресурсах.

а как в этом случае можно вообще использовать статические массивы?
К тому же, скорость зависит от реализации конкретного менеджера памяти.
Вот автор ФАРа - Рошал - к примеру, говорил, что они принципиально компилят его на борладн с++, потому что по каким-то тестам его менеджер обогнал майкрософтовский

← →
Сергей М. © (2009-03-04 13:29) [51]

> Я вообще НИ РАЗУ не встречал ситуаций, когда память выделяется
> в одном модуле (Exe / DLL), а высвобождается в другом. Так
> никто никогда не делает. Если ты имеешь в виду ВНЕШНИЕ языки

Зашибись аргумент: "так никто не делает, потому что Я НИ РАЗУ НЕ ВСТРЕЧАЛ"

)

p.s.

О непобедимости в споре
(религиозная аргументация)

- Земля имеет форму чайника носиком внутрь!
- Вы чего, обалдели?!
- А по-вашему лучше, чтобы Земля имела форму задницы, как нас учат Марсианские Клопогрызы по космическим лучам?!
- Но почему форму задницы?!
- Да потому что Марсианские Клопогрызы об этом говорят целыми днями! Они уже все космические лучи захватили! Вы разве не видите?!
- Да не слушайте вы этих космических лучей!
- Нет! Мы не можем не слушать, как они нас развращают! Только мы с нашей Идеей Великого Чайника можем противостоять Марсианским Клопогрызам!
- Ну и противостоите на здоровье, кто же вам мешает. Вам для этого и полигон выделили. Чего ко мне-то пристали?
- Идёт война миров! Или чайник, или задница! Третьего не дано!
- Да как же не дано? Земля имеет форму сплюснутого сфероида.
- Значит, вы за Марсианских Клопогрызов? А может, даже скрытый Клопогрыз! Ведь от сфероида до задницы один шаг!
- Да не Клопогрыз я! Какое мне вообще дело до каких-то Марсианских Клопогрызов?!
- А вы хотите жить в заднице?
- Нет, не хочу.
- Что и требовалось доказать. Земля имеет форму чайника носиком внутрь!

← →
KSergey © (2009-03-04 13:31) [52]

снова терминологический спор.

It"s not me, что есть динамический и статический массив? В примерах, плиз.

← →
Плохиш © (2009-03-04 13:40) [53]

Прикольно, у деток новый холивор :-))

← →
test © (2009-03-04 13:43) [54]

Сергей М. © (04.03.09 13:29) [51]
Это он похоже и есть ))
Автор темы "используем пустые try..except..end все равно все ошибки не отловишь"))

← →
It's not me (2009-03-04 14:02) [55]

> А народ всё ведётся и ведётся.... И народ-то не глупый..
> .. :)

Олежка, я тебе обязательно памятник поставлю как самому лучшему пинкертону на форуме. Ну надо же, все ведутся, один ты смог определить, что все это развод. Какой умный развод! Я уже запарился деньги со счета снимать.

> вернее, в BSS

не знаю, что такое BSS... То есть, память для статического массива все таки выделяется быстрее и есть принципиальные отличия от GetMem / SetLength ?

> а как в этом случае можно вообще использовать статические
> массивы?

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

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

Еще один пример - определение пути. Ты ведь не знаешь длину какого-то файлового пути, но при этом знаешь, что он не может быть более MAX_PATH. Это как пример просто.

> Зашибись аргумент: "так никто не делает, потому что Я НИ
> РАЗУ НЕ ВСТРЕЧАЛ"

я такого нигде не говорил. Это твое намеренное искажение моих слов, один только вопрос остается - зачем намеренно искажать мои слова? Видимо, чтобы сделать вывод, что я дурак. Поздравляю, получается как всегда гениально.

> It"s not me, что есть динамический и статический массив?
> В примерах, плиз.

статический: StatArray: array[0..65545] of byte;
динамический: DynArray: array of byte;

← →
Сергей М. © (2009-03-04 14:11) [56]

> я такого нигде не говорил

Говорил-говорил, не отнекивайся)

← →
clickmaker © (2009-03-04 14:13) [57]

> не знаю, что такое BSS... То есть, память для статического
> массива все таки выделяется быстрее и есть принципиальные
> отличия от GetMem / SetLength ?

она выделяется один раз при старте
BSS - для неинициализированных данных
DATA - для инициализированных и констант

← →
KSergey © (2009-03-04 14:19) [58]

> It"s not me (04.03.09 14:02) [55]
> статический: StatArray: array[0..65545] of byte;
> динамический: DynArray: array of byte;

Очень замечательно.
Теперь осталось прикинуть какие операции нужны для создания/уничтожения этих массивов - и все станет понятно. Можно свериться с ассемблером, для точности.

← →
KSergey © (2009-03-04 14:22) [59]

> clickmaker © (04.03.09 14:13) [57]
> она выделяется один раз при старте

В нотации автора - вообще только на стеке. У него весьма узкое толкование стат. массивов.
В общем случае оно шире. Даже DynArray: array of byte; в глобальной видимости тоже можно считат стат. массивом при условии, что память под него выделяется однажды при старте программы; тогда накладные расходы на это дело в сравнении со временем работы программы - ничтожны.

← →
oxffff © (2009-03-04 14:37) [60]

> It"s not me (04.03.09 12:44) [47]
>
> > Где рассматривал?
>
> пост [16]
>
>
> > Внешние языки могут не содержать такой семантический эквивалент
>
> > типа(динамический массив). Хотя могут быть совместимы
> для
> > использования, но несовместимы для управления временнем
>
> > жизни(ссылок),
>
> вообще непонятно, что ты имеешь в виду. Если говорить о
> внешних языках, то они в любом случае несовместимы в вопросах
> выделения / освобождения памяти для какой бы то ни было
> переменной вообще, и это не касается ни конкретно статических,
> ни конкретно динамических массивов.

Не нужно касаться вопросов работы кучи(хотя и и этот вопрос можно решить), у типа есть контракт по его использованию например Добавить_ссылку, Удалить_ссылку на экземпляр.
Внешние просто следуют ему.

> Под статический массив один фиг нужна память, она будет
> или выделена неявно в куче (какая при этом разница по сравнению
> с явным выделением памяти в куче?!) или выделена в стеке.

Смотрел функции? Сравни скорость.

function StackAlloc(Size: Integer): Pointer; register;
asm
POP ECX { return address }
MOV EDX, ESP
ADD EAX, 3
AND EAX, not 3 // round up to keep ESP dword aligned
CMP EAX, 4092
JLE @@2
@@1:
SUB ESP, 4092
PUSH EAX { make sure we touch guard page, to grow stack }
SUB EAX, 4096
JNS @@1
ADD EAX, 4096
@@2:
SUB ESP, EAX
MOV EAX, ESP { function result = low memory address of block }
PUSH EDX { save original SP, for cleanup }
MOV EDX, ESP
SUB EDX, 4
PUSH EDX { save current SP, for sanity check (sp = [sp]) }
PUSH ECX { return to caller }
end;

{ StackFree pops the memory allocated by StackAlloc off the stack.
- Calling StackFree is optional - SP will be restored when the calling routine
exits, but it"s a good idea to free the stack allocated memory ASAP anyway.
- StackFree must be called in the same stack context as StackAlloc - not in
a subroutine or finally block.
- Multiple StackFree calls must occur in reverse order of their corresponding
StackAlloc calls.
- Built-in sanity checks guarantee that an improper call to StackFree will not
corrupt the stack. Worst case is that the stack block is not released until
the calling routine exits. }
procedure StackFree(P: Pointer); register;
asm
POP ECX { return address }
MOV EDX, DWORD PTR [ESP]
SUB EAX, 8
CMP EDX, ESP { sanity check #1 (SP = [SP]) }
JNE @@1
CMP EDX, EAX { sanity check #2 (P = this stack block) }
JNE @@1
MOV ESP, DWORD PTR [ESP+4] { restore previous SP }
@@1:
PUSH ECX { return to caller }
end;

> Но память под стек один хрен в свое время была выделена
> опять же в куче, просто заранее. Давайте не будем сто раз
> одно и тоже прокручивать, а?

Кто выделил память в кучи для стека, виртуальная машина?

← →
It's not me (2009-03-04 15:06) [61]

> Говорил-говорил, не отнекивайся)

тогда цитату, пожалуйста, приведи.
Естественно, ты цитату привести не сможешь, но будешь продолжать уверять, что я это говорил. Это мне всегда нравится.

> она выделяется один раз при старте

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

Ты, вероятно, говоришь исключительно о глобальных переменных. О глобальных статических массивах. А речь я считаю не о том.

> В общем случае оно шире. Даже DynArray: array of byte; в
> глобальной видимости тоже можно считат стат. массивом при
> условии

вот именно, что можно его фактически считать статическим массивом. И это не минус по отношению к реально статическому массиву.

А плюс в том, что в случае, когда нельзя определить размер данных на этапе компиляции динамический массив позволяет сэкономить ресурсы.

> Смотрел функции? Сравни скорость.

ты опять про сравнение скорости выделение в куче и в стеке? Еще раз - я об этом уже говорил, прочитай, пожалуйста. ты или уж комментируй это мое заявление про выделение скорости, или уж ничего не пиши. А то ты мне в 10-ый раз доказываешь, что в стеке память выделяется быстрее, чем в куче. Я с этим не спорю при такой постановке вопроса, а подробнее читай в посте.

> Кто выделил память в кучи для стека, виртуальная машина?

не знаю. Тонкости не знаю. Я так понимаю, что для каждого потока винда создает стек. или менеджер памяти дельфовый создает стек... В общем, не знаю я.
Но насколько я понимаю, стек - это просто заранее выделенный (зарезервированный) участок памяти. "Выделять память" в таком участке, конечно, проще, просто сдвигая указатель, ибо память уже заранее фактически была выделена.

← →
Sha © (2009-03-04 15:12) [62]

> It"s not me (03.03.09 14:56)

В первом варианте менеджер памяти вызывается столько раз,
сколько раз вызывается функция. И хотя реальное перераспределение
происходит не каждый раз, тут есть потери времени на копирование
содержимого буфера и потери памяти на фрагментацию.

Во втором варианте в худшем случае память выделяется один раз
при вызове родительской функции, и никаких дополнительных потерь
времени и памяти.

← →
Сергей М. © (2009-03-04 15:13) [63]

> Это мне всегда нравится

Нравится ? Заполучи еще раз !)

> It"s not me (04.03.09 12:44) [47]
> ..
> Я вообще НИ РАЗУ не встречал ситуаций, когда память выделяется
> в одном модуле (Exe / DLL), а высвобождается в другом. Так
> никто никогда не делает.

Так вот в моей фразе

> Зашибись аргумент: "так никто не делает, потому что Я НИ
> РАЗУ НЕ ВСТРЕЧАЛ"

квинтессенция этого сногосшибательного аргумента - смысл тот же, только букаф меньше)

← →
test © (2009-03-04 15:22) [64]

It"s not me (04.03.09 15:06) [61]
Я НИ РАЗУ НЕ ВСТРЕЧАЛ (рус.) перевод на Паскаль*Русский

Хрен где встретишь код:

function Answer: TByteDynArray;
begin
SetLengthh(Result, Sock.Len);
Sock.WriteBuf(Result[0], Length(Result) );
end;

Зато можно встретить код аля:

cMaxUdpLen = 64kb;

TUdpBuffer = array[0..cMaxUdpLen-1] of byte;

function Answer(out Buf: TUdpBuffer): integer;
begin
Result := Sock.Len;
Sock.WriteBuf(Buf[0], Result );
end;

← →
clickmaker © (2009-03-04 15:28) [65]

> Я вообще НИ РАЗУ не встречал ситуаций, когда память выделяется
> в одном модуле (Exe / DLL), а высвобождается в другом. Так
> никто никогда не делает

например StrDup из slwapi.dll, или FormatMessage из kernel32

← →
It's not me (2009-03-04 15:34) [66]

> В первом варианте менеджер ...

Sha, да, ты прав абсолютно.. Я почему-то об этом не подумал. Действительно, ведь эта функция наверняка будет вызвана не один раз, а много. И очень вероятно, что будет передаваться один и тот же буфер от вызова к вызову... И чем больше вызовов, тем более эффективен будет стат. массив... Хотя на одном вызове выиграет динамический массив...

Спасибо! Тема закрыта.

← →
Marser © (2009-03-04 15:34) [67]

> динамический: DynArray: array of byte;

Вообще-то это называется открытым массивом, а с динамическими автор, наверное, никогда и не работал :-))

← →
KSergey © (2009-03-04 15:35) [68]

> test © (04.03.09 15:22) [64]
> Хрен где встретишь код:
> function Answer: TByteDynArray;
>
> Зато можно встретить код аля:
> function Answer(out Buf: TUdpBuffer): integer;

И это правильно!
Т.к. в первом случае память постоянно будет принудительно аллоцироваться при каждом вызове функции и ничего с этим будет поделать нельзя (интерфейс не позволяет иного), а во втором - каждому будет предоставлена возможность организовать это по своему вкусу: хочешь каждый раз выделяй, хочешь - один раз выдели и получи несколько Answer"ов. Или несколько в однажды выделенный большой буфер просто перемещая в нем ссылку.

← →
It's not me (2009-03-04 15:36) [69]

> квинтессенция этого сногосшибательного аргумента - смысл
> тот же, только букаф меньше)

попробуй найти различие между двумя фразами:

"У Антона были синие глаза. Он был ярым поклонником коммунистического движения"

отличие от:

У Антона были синие глаза, потому что он был поклонником коммунистического движения".

Так вот мой вариант - первый. А твой переформулированный вариант - второй. На мой взгляд разница очевидна. Если тебе не очевидна - ну и пофик.

Автор, уже давно пора понять, что нет абсолютно ничего принципиально плохого в дин. массивах и в стат. массивах.
Можно применять и то и это, на довольность заказчика вне контекста это не влияет.

Насколько я помню из своего босоногого детства, чтобы использовать динамический массив, мы должны объявить тип-указатель на массив до огого каких пределов ($FFFF по-скромному), а затем уж под него выделить памяти ровно столько, сколько нам нужно. Вот это и есть динамический массив, это было в Паскале столько, сколько там были указатели, а открытые массивы лишь в Делфи 4 появились....

Динамический массив никогда не выиграет по скорости работы у статического, потому что для каждого обращения к элементу такого массива требуется неявное разыменование указателя, а на это тоже уходит процессорное время.

← →
It's not me (2009-03-04 15:50) [73]

> Вообще-то это называется открытым массивом, а с динамическими
> автор, наверное, никогда и не работал :-))

> чтобы использовать динамический массив, мы должны объявить
> тип-указатель на массив до огого каких пределов ($FFFF по-
> скромному), а затем уж под него выделить памяти ровно столько,
> сколько нам нужно

ты пишешь сейчас такой бред, что просто слов нету. Еще и пытаешься автора в чем-то обвинять. А ведь наверняка уверен в своей правоте.

Так вот понятие "открытый" массив применимо исключительно к понятиям объявления функций или метода.

Вот это: var a: array of byte - динамический массив. Понятия "открытый" массив при объявлении переменных просто нету. Только в объявлениях функций / процедур / методов, например:

procedure Test(A: array of byte) - вот тут можно сказать, что процедура Test принимает ОТКРЫТЫЙ массив в качестве параметра A.

Здесь же:

type TDynArray = array of byte; procedure Test(A: TDynArray)

процедура Test принимает ДИНАМИЧЕСКИЙ массив в качестве параметра A.

> на массив до огого каких пределов ($FFFF по-скромному),

абсолютное путаница. Это лишь реализация способа адресации неизвестного (потенциально огромного) массива элементов. И размер объявляется так, чтобы такой массив ТЕОРЕТИЧЕСКИ мог существовать в ВАП процесса, иначе дельфи не скомпилит код. Но реально такой массив никогда не создается, конечно, только указатель на него.

В общем, это принцип TList.

> Григорьев Антон © (04.03.09 15:41) [72]
> потому что для каждого обращения к элементу такого массива требуется неявное разыменование указателя,

не очень понимаю про "разименование" в терминах скомпилированного кода (вроде это чистая абстракция для объяснения в терминах языка высокого уровня?), но сейчас специально посмотрел и с удивлением обнаружил, что для строчки вида bb[2] := 5; в случае стат. массива генерится 1 команда ассемблера, а в случае дин. массива - 2, т.к. надо еще прочитать значение указателя на дин массив; в случае стат массива он уже всегда имеется. Вот бы не подумал...

> It"s not me (04.03.09 15:36) [69]

Ты давай уже оглобли не разворачивай)

Так делают, и факты тебе уже привели ! А маловато будет - еще полну котомку фактов тебе понапхаем)

Суслик-то есть, даже если ты его не видишь и видеть не желаешь)

← →
Sapersky (2009-03-04 16:32) [76]

чтобы использовать динамический массив, мы должны объявить тип-указатель на массив до огого каких пределов ($FFFF по-скромному), а затем уж под него выделить памяти ровно столько, сколько нам нужно. Вот это и есть динамический массив

Ну если уж в Борланде назвали array of <тип> динамическим массивом - то лучше их так и называть, ИМХО (открытые тоже есть, но это другое).
А то, про что вы пишете я называю "массив-указатель". Это же типизированный указатель по сути.

в случае стат. массива генерится 1 команда ассемблера, а в случае дин. массива - 2, т.к. надо еще прочитать значение указателя на дин массив

Компилятор опасается, что массив может быть в любой момент переаллоцирован и указатель "уедет". Но если передавать массив в функцию как const, компилятор может использовать одну команду вида mov [reg1 + reg2 * elSize]. Что, кстати, тоже выглядит избыточно - const-массив точно никуда не "убежит", можно было бы использовать "простой" mov. Не знаю, почему так сделали.
Но в общем, всё это ловля блох. В реальных проектах тормозят не обращения к элементу. Разве что у многомерных дин. массивов это может быть заметно, по причине сложной внутренней структуры.

>
> абсолютное путаница. Это лишь реализация способа адресации
> неизвестного (потенциально огромного) массива элементов.
> И размер объявляется так, чтобы такой массив ТЕОРЕТИЧЕСКИ
> мог существовать в ВАП процесса, иначе дельфи не скомпилит
> код. Но реально такой массив никогда не создается, конечно,
> только указатель на него.

И кто ещё пишет бред :-)

← →
It's not me (2009-03-04 16:56) [78]

> в случае стат массива он уже всегда имеется. Вот бы не подумал.
> ..

вот видишь как оно. Я тоже этого не знал, но подозревал, что что-то такое есть. И для тебя ветка стала полезной. Одно непонятно - нафига говорить, что так делают исключительно потому, что так делают и вообще строить вид о бесполезности ветки, когда и самому неизвестны все подноготые процессов...

> Так делают, и факты тебе уже привели !

Я не считаю приведенный пример доказательством, что так делают. Один фиг:

The caller should use the LocalFree function to free the buffer when it is no longer needed.

По факту все равно память что освобождается, что выделяется в модуле kernell.dll - согласен?
Я тоже самое могу сделать в своем модуле, выделить память и обязать внешний источник вызывать мою MyFreeMemory, в которой уже и будет освобождение памяти. Как это трактовать? Я трактую, что память освобождается все равно в МОЕМ модуле, хотя и по приказу извне. Но я понимаю, что это философский вопрос, поэтому предлагаю не разворачивать бесполезную дискуссию.

> И кто ещё пишет бред :-)

ты пишешь бред. именно ты продемонстрировал полное незнание понятий что такое динамический и что такое открытый массив.

Попробуй объявить такой тип в дельфи:

TTestArray = array[1..High(Integer)+1] of byte;

и посмотри, почему будет ошибка.

А теперь попробуй объявить:

TTestArray = array[1..High(Integer)] of byte;

и подумай почему получилось. Почему объявление типа массива, который занял бы в ВАП 2 ГБайт (столько выделяется в ВАП для данных приложения) можео объявить, а 2 Гбайт плюс 1 байт уже нельзя. По-моему, разжевал для самых маленьких.

> Sapersky (04.03.09 16:32) [76]
> const-массив точно никуда не "убежит", можно было бы использовать "простой" mov.

Регистров-то ограниченное число, в отличии от памяти :)
Впрочем, я смотрел с отключенной оптимизацией, может все было бы сильно иначе.

> It"s not me (04.03.09 16:56) [78]
> вот видишь как оно. Я тоже этого не знал, но подозревал, что что-то такое есть. И для тебя ветка стала полезной.

Бесполезной.
Я заглядывал в профайлер. Мне хватило, написанное же - оно про блох.

> память что освобождается, что выделяется в модуле kernell dll - согласен?

А кто говорит о системной куче ?

Мы тут вообще-то о менеджерах более высокого уровня, с которыми непосредственно взаимодействуют рантайм-библиотеки различных языковых сред разработки).. С твоей, кстати, подачи)

← →
It's not me (2009-03-04 17:58) [82]

> Я заглядывал в профайлер. Мне хватило

заглядывал ты после поста: Григорьев Антон © (04.03.09 15:41) [72] .
И этот пост был в данной ветке. не было бы ветки - не было бы поста Антона. Не было бы поста Антона - не полез бы ты в профайлер, не узнал бы эту особенность динамических массивов. Прямо как маленькому... Впрочем, доказывать тебе, что ветка оказалась полезной для тебя - бред, конечно... Можешь даже делать вид, что знал все это изначально - мне уже пофигу...

> А кто говорит о системной куче ?
>
> Мы тут вообще-то о менеджерах более высокого уровня, с которыми
> непосредственно взаимодействуют рантайм-библиотеки различных
> языковых сред разработки).. С твоей, кстати, подачи)

что-то я потерял нить дискуссии... А причем тут системная куча?

Вот ход, поправь если не согласен:

1) я сказал, что так никто не делает. В смысле того, что не делается так, что память выделяется в одном модуле, а высвобождается в другом.

Для сего процесса нужно соглашение о том, какие WinApi функции использовать для выделения / освобождения памяти, чтобы не возникло фигни. Я не видел таких соглашений, ибо разные модули могут быть написаны на разных языках со своими менеджерами памяти, которыми в 90% случаев и пользуются, а потому обеспечить нативную совместимость невозможно.

2) ты сказал, что так делают и привел в пример FormatMessage из кернела

3) я тебе сообщил, что пример некорректен. Ты не освобождает память самостоятельно, ты один фиг должен вызвать LocalFree, таким образом передав управление опять модулю кернела и именно ТАМ освобождается память.

Точно также можно было бы привести пример: socket / closesocket - и утверждать, что память, допустим, освобождается в твоем модуле. Но это не так, память под сокет один фиг и выделяется и освобождается в ДРУГОМ модуле, просто по твоей комманде.

Но я прекрасно понимаю, что тут бесконечное поле для флуда, ибо в пример приведена системная DLL, в которой в частности и происходит "настоящее" высвобождение и выделение памяти по командам VirtualAlloc, HeapAlloc и прочие, к которым в любом случае обращаются все собственные менеджеры памяти.

Настоящим так сказать примером я бы считал такой пример, когда какой-то модуль выделил бы память исключительно виндовыми средствами напрямую без использования сторонник несовместимых менеджеров памяти. И данную структуру бы передавал / возвращал стороннему модулю с соглашением, что сторонний модуль должен высвободить память опять же стандартными средствами windows исключительно (ибо ТОЛЬКО ТАК возможна полная совместимость выделения / освобождения памяти в приложениях, написанных на разных ЯВУ). И вот такого я действительно нигде не видел, ни в готовых модулях DLL, ни в самой винде, нигде.

В каком модуле выделяется память, в таком она и освобождается потом. Просто по разному реализован момент определения освобождения, можно по выгрузке модуля, можно по таймеру, можно до следующего вызова подобной функции, можно по комманде извне. Но никогда модуль извне непосредственно память не освобождает.

> It"s not me (04.03.09 17:58) [82]
>
> > Я заглядывал в профайлер. Мне хватило
>
> заглядывал ты после поста: Григорьев Антон © (04.03.09
> 15:41) [72] .
> И этот пост был в данной ветке. не было бы ветки - не было
> бы поста Антона. Не было бы поста Антона - не полез бы ты
> в профайлер, не узнал бы эту особенность динамических массивов.
> ..

А это мягко говоря камень к разработчикам. Последовательное обращение по указателю на статический массив он оптимизирует, а последовательное обращение к элементам динамического массива нет. Так что есть куда оптимизировать. Проверял на D7.

> [82] It"s not me (04.03.09 17:58)

> Настоящим так сказать примером я бы считал такой пример,
> когда какой-то модуль выделил бы память исключительно виндовыми
> средствами напрямую без использования сторонник несовместимых
> менеджеров памяти. И данную структуру бы передавал / возвращал
> стороннему модулю с соглашением, что сторонний модуль должен
> высвободить память опять же стандартными средствами windows
> исключительно (ибо ТОЛЬКО ТАК возможна полная совместимость
> выделения / освобождения памяти в приложениях, написанных
> на разных ЯВУ). И вот такого я действительно нигде не видел,
> ни в готовых модулях DLL, ни в самой винде, нигде.

в winAPI есть примеры, подтверждающих обратное. например при работе с SecurityDescriptor"ами некоторые функции сами выделяют память, которую потом нужно оснобождать самому через LocalFree.
при работе с некоторыми WTS функциями тоже память выделяется внутри модулей, а освобождается из приложения.
это только из того, что сразу вспомнилось.

← →
It's not me (2009-03-04 19:23) [85]

> winAPI есть примеры, подтверждающих обратное. например
> при работе с SecurityDescriptor"ами некоторые функции сами
> выделяют память, которую потом нужно оснобождать самому
> через LocalFree

то есть, существуют функции (вызываемые НЕ ИЗ кернела), которые что-то создают, что потом приходится освобождать это через LocalFree?

Можно название этой функции хотя бы одной?

использование kernel32.dll программами "чисто на апи" - примерно то же самое, что и использования borlndmm.dll VCL-приложениями, если они хотят кидать блоки памяти друг другу. В частности, строки и массивы.
Только borlndmm.dll предоставляет более высокий уровень абстракции от вирутальной памяти, к которой все в итоге сводится.

ConvertStringSecurityDescriptorToSecurityDescriptor, ConvertStringSidToSid и т.д.

> ConvertStringSecurityDescriptorToSecurityDescriptor

длина впечатляет -)

← →
It's not me (2009-03-04 19:36) [89]

> ConvertStringSecurityDescriptorToSecurityDescriptor, ConvertStringSidToSid
> и т.д.

действительно, есть такие функции. Честное слово, не встречал )
Это, видимо, более современный подход. Мне кажется, что в WinApi, которые описаны в хелпе от D7 ни одной такой функции не найдешь. Я так думаю.

> [89] It"s not me (04.03.09 19:36)

дескриптор безопасности, полученный с пом. довольно древней функции InitializeSecurityDescriptor, после использования тоже нужно освобождать через LocalFree кстати.

я понял про какой развод говорил Ega32, он сюда учиться пришел, возможно пишет доклад по теме))

← →
It's not me (2009-03-04 19:58) [92]

ну если под разводом понимать мои попытки больше узнать про программирование, то да, извините, господа, но это чистой воды развод.

кстати насчет InitializeSecurityDescriptor погорячился что-то, туда надо передавать уже выделенный фрагмент памяти, хотя вроде память должна быть правильно выделена именно с пом. LocalAlloc (кстати какой-то API или интерфейс, если не подводит память, возвращает уже готовый SD, который нужно освобождать именно через LocalFree, когда то сталкивался с такой проблемой). Но зато довольно часто-используемая функция AllocateAndInitializeSid тоже ипользует именно обсуждаемый здесь подход.

+ SetEntriesInAcl

← →
Jack128_ (2009-03-05 10:31) [97]

> oxffff © (04.03.09 18:35) [83]

Оффтоп, Сергей, не подскажешь ссылку на свой блог ? Ты там сорцы выкладывал любопытные??

> Jack128_ (05.03.09 10:31) [97]

http://santonov.blogspot.com/

> Jack128_ (05.03.09 10:31) [97]

Можешь меня в Wiki найти. :)))
См. coroutine.

Недоиспользование динамических типов в Дельфи? Найти похожие ветки