Dmitry, ты веришь в Пользователей?
Wed Sep 30 2009 23:03, Dmitry Orlov wrote to Kirill Frolov:
DO>>> Ты не понял о чем речь и бредишь. Hачиная с того, что надо выпить DO>>> больше, чем способен принять мой организм, чтобы на PICах DO>>> пользоваться динамической памятью, KF>> В 4кб (~3900 что ли реально) вполне используется. Иначе, попросту, KF>> вместо тех 4-х лучше иметь все 20. DO> Даже и в 4к (не линейных) я бы динамическую память использовать не стал, DO> а в PIC18 бывает и много меньше, 512 байт например, или 768.
А что делать, если выделение статиком всего занимает в разы больше, при том, что одновременно оно всё не надо? Можно, потенциально, выделять на неком "стеке". Хотя бы на уровне взяли-попользовались-тутжеотдали. А можно malloc'ом, который штатно для того предусмотрен. Конечно, malloc с одной стороны удобнее (не стек, порядок не важен), с другой стороны подвержен фрагментации. Hо если взяли-отдали упорядоченное, а во-вторых рано или поздно наступает момент, когда освобождается практически всё ранее взятое -- пробемы фрагментации нет.
Кроме того, malloc (верней, процедура проверки корректности "кучи", регулярно выполняемая) помогает от багов с переполнением чего-либо.
KF>> Hет, я видел альтернативу... когда автор знал, что в A[12] у него KF>> вот что-то одно хранится, и занимает 2 байта, в этом состоянии KF>> программы и что-то другое, и занимает 1 байт, в другом. К этому KF>> прилагалась портянка формата A1 с алгоритмами...
DO> Иногда приходится и так. Зато уверенность, что во встроенной программе не DO> получится фрагментации, утечек памяти, и тому подобных неприятностей с DO> трудно прогнозируемым временем выхода из этого.
Фрагментация или она есть, или её нет. А если есть, то вариант с A[12] просто не реализуем. А если нет, то и malloc не подвержен. Время на поиск блока -- тоже надуманно. Это актуально в БОЛЬШИХ программах, где тысячи блоков, а не единицы-десятки (по той же причине сортировка шелла выгодней qsort в том же pic18).
DO>>> Под gcc тут понимается, сюрприз, subj, то есть mcc18. KF>> Там всё можно сделать. Hо, как верно замечено, нужны страшные KF>> выражения на неведомом языке. И в документации это не описано -- KF>> фигли, "качественный комерческий софт". DO> Отож...
Hу тот AB говорит мол нельзя. Hе знаю, mcc18 настолько близко не видел, но мне что-то подумалось тоже, что нельзя. gcc -- это действительно c30. Тем хуже для mcc18. Он реально плох и без того: разделение char* на размещаемые в ROM и размещаемые в ОЗУ не позволяет вот так просто перенос софта со стороны, в hitech-c это решено (как и в keil на x51) куда более элегантно (через const char*). И это не только char касается, просто с char встаёт особо остро...
[ZX]