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

← →
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]
>
> > Теперь нужно пихать их везде подряд
>
> зачем везде. Там, где идет работа с данными неизвестной
> на этапе компиляции длины.
>
> Вот ты, видимо, из старой школы. И хотелось бы услышать
> мнение, ЧЕМ в данной ситуации статические массивы лучше?
> Чем лучше динамические - я уже описал - во-первых, автоматическая
> сборка мусора, во-вторых, более быстрая работа и меньшее
> задействование ресурсов.

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

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

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

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

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

Ради флуда.

гг)

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

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

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

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

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

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

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

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

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

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

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