den_po
Участник-
Постов
139 -
Зарегистрирован
-
Посещение
Репутация
0 ОбычныйИнформация о den_po
-
Звание
Частый гость
- День рождения 18.06.1979
Информация
-
Город
Array
-
Менеджер памяти обычно не знает, расположение чего он знает. Без правки хотя бы части операционки (тоже костыль) "посмотреть на ходу что где находится и чем и насколько зянято" (выделенную операционкой память) вы не сможете, вы узнаете только, что есть вот столько-то выделенных кусочков памяти. Жду от вас пару поучительных историй о том, как вам на практике безмерно помогло подобное знание. Нередко многократное пересоздание объектов операционки нафик ненужно. В этом случае именно отказ от использования кучи позволит сэкономить. Ну да, ну да, стоит взять менеджер памяти, и сразу памяти станет завались. Вы опять, как и в другой дискуссии, придумываете за меня, о чём я думаю. Я не предлагаю полностью отказаться от менеджера памяти. У меня есть проекты с ним, частично с ним (куча используется только внутри FreeRTOS) и вообще без него. Но если есть возможность обойтись без него там, где он нафик не нужен, я буду этой возможностью пользоваться.
-
Так пользуйтесь теми вариантами, к которым вы привыкли. Оттого, что ВЫ будете говорить операционке, где хранить данные, контроль над данными не уменьшается, а даже наоборот, ведь структуры FreeRTOS от пользователя скрыты, а значит и добраться до внутренних данных, выделенных операционкой, можно только через костыли. Никто ничего не убирал. Вместо одного способа стало три - динамическое выделение памяти функциями FreeRTOS, динамическое выделение пользователем, выделение компилятором (с подсказкой пользователя, конечно). В одном случае я могу узнать, что перестал влезать в допустимый объём памяти, только после запуска, а в другом на этапе сборки. Вы же не будете спорить, что чем раньше обнаружится проблема, тем лучше?
-
Ничего не мешает. Просто присутствует иногда лишняя сущность. Глупости же. То был ответ на "посмотреть на ходу что где находится и чем и насколько зянято". Смотреть, что где находится, теперь не обязательно "на ходу". И это действительно удобно. В остальном абсолютно ничего не мешает ВАМ смотреть то же самое точно так же, как вы делали с динамическим выделением. Да и использовать статические буферы вас никто не заставляет. Чем же на сосне динамическое выделение внутрях FreeRTOS, по-вашему, так сильно превосходит статическое? Затем, что удобней. Можно раньше проблему найти.
-
Лично я ждал эту фишку как раз ради объектов, которые живут вечно. Но и удалить тоже ничто не мешает. Или я чего-то не знаю? .map, отладчик Отличное приобретение. Особенно когда оно помогает распределять память на этапе сборки.
-
Это если речь о конструкторах глобальных объектов или статических членов классов. А выше разговор шёл об использовании new. Обычно достаточно снять галочку возле "main"
-
Если IAR - ограниченная версия, то в техподдержке вроде как пошлют. Всякоразные баги IAR (а таких действительно хватает) иногда лечатся отключением оптимизации.
-
а что там, собственно, решать? void* operator new(size_t sz) { return pvPortMalloc(sz); } void* operator new[](size_t sz) { return pvPortMalloc(sz); } void operator delete(void* p) { vPortFree(p); } void operator delete[](void* p) { vPortFree(p); } void* operator new(size_t size, void* p) { (void)size; return p; } void* operator new[](size_t size, void* p) { (void)size; return p; } void operator delete(void*, void*) { } void operator delete[](void*, void*) { }
-
Ещё есть хорошая штука - astyle, которая форматирует исходники (бесценно, когда получаешь исходники от иных мастеров), а ещё умеет и конец строки заменять.
-
Не увидел в цитатах ничего про то, кому требуется.
-
Хм. А разве pragma required не перед определением используется?