А как будет в этом случае выглядет дефрагментация?

С помощью MMU можно реализовать непрерывное логическое адресное пространство из нескольких малых физических блоков памяти по разным физическим адресам. Т.е. произвести определяемую менеджером памяти (с функцией дефрагментации) трансляцию логических адресов в физические.

MMU нужен инициализыровать если для ARM9 хочется включить Data-Cache.

Т.е., в приципе, можно и не производить дефрагментацию?

Zltigo - не пугайте людей.
new в случае неуспеха вернет нулл. 1) "If unsuccessful, new returns zero or throws an exception"
2) " specified in the C++ standard, which is to throw a std::bad_alloc exception if the memory allocation fails"

В принципе да, но многое будет зависеть от особенностей MMU.

Господь с авторм приведенной Вами цитаты, но ни при каких условиях new не может возвращать NULL. В 'нормальном' варианте cо свопами и прочими наворотами просто циклится в ожидании появления памяти и в случае если и это не удается - система может просто прибить задачу. В мелких системах, где более-менее сразу ясно, что памяти скорее всего не появится - exeption. В самых примитивных реализациях - просто вечный цикл. Но никак не NULL'.
Ну а то, что автору, цитаты, что NULL, что 'zero' все едино - еще раз указывает на его некомпетентность.




Ага битик включил и "само работать будет" - не будет :-(. Это только механизм, которым можно воспользоваться в менеджере памяти для РЕАЛИЗАЦИИ компенсации фрагментированости.

ну это я с переводом лопухнулся. По умолчанию генерируется исключение bad_alloc. Вызовом set_new_handler() мы можем назначить иное поведение. Это по Страуструпу. Ну уж если он некомпетентен.... Вот из MSDN "If unsuccessful, new returns zero or throws an exception; see The new and delete Operators for more information. You can change this default behavior by writing a custom exception-handling routine and calling the _set_new_handler run-time library function with your function name as its argument"

С этим согласен. Если установить new_handler возвращающий NULL, то new() возвратит результат
NULL. Вопросы:
1.Вы когда-нибудь его переустанавливали?
2.Мы обсуждаем поведение new() или того что МОЖНО сделать из new() установкой new_handler,
перегрузкой или написанием макроса new ???


А вот на это "MS" ссылаться не надо. Из того, что у них в Windows на 32 разрядном x86
#define NULL 0
никоем образом не следует, то NULL являющийся абстрактным нулевым _указателем_ может всегда, везде и на всех платформах использоваться как попало и его физическое представление 0.
Не говоря о том, что размеры указателя могут ОТЛИЧАТЬСЯ от разрядности ЧИСЛА.
И в любом случае писать, что функция которая по определению возвращает УКАЗАТЕЛИ
вернула не УКАЗАТЕЛЬ а число 0 (или три или любое другое) некорректно в принципе.

Что касается путаницы и самой возможности использовать 0 как NULL, то за это отдельное спасибо
авторам С, которые вместо отдельного ключевого слова для нулевого указателя типа паскалевского "nil" использовали ключевое слово "0" :-(. Потом ANSI выкрутились через макрос NULL,
который всетаки был в С определен как УКАЗАТЕЛЬ.

хорошо, если не переустанавливать set_new_handler, то какие пакеты вызовут зацикливание в new а не выброс исключения ? Приведите пожалуйста список, дабы я (а может и еще кто) никогда их (эти пакеты) не использовали

Разбираться как ведет себя new() в конкретной библиотеке это задача того, кто решил его использовать.
Я лично - не использую. Мне лет 15-17 назад хватило BCC, дабы отбить сие желание.
Лет пять назад копался в ЧУЖОМ линуксовом приложении которое аккуратно периодически
молча отстреливалось системой как зависшее. Догадались что там было?
Ну и самое главное - чем Вам "exception" буде он реализован во EMBEDDED приложении сильно поможет? А? Типа "перезагрузимся и сделаем вид, что ни ничего не случилось".

new() практически во всех ранних C++ компиллерах умел возращать NULL.

Многие нынешние компиляторы/библиотеки поддерживают конструкцию:

О чем и речь :-(, что кто-то, где-то, как-то...
Посему, либо разбираться конкретно :-( и не забывать о повторных разборках при портировании,
либо устанавливать свой new_handler(), причем единственным разумным вариантом
new_handler() для embedded предстваляется возвращение им NULL для возможности максимально безболезненого выхода из каждого конкретной ситуации.
Либо не использовать new() в принципе.

А вот тут zltigo не прав. Цитирую Страуструпа:

Так что ноль вполне законен и даже очень правилен. Кстати, IAR 4.30 после вызова new проверяет R0 на ноль и если не ноль вызывает конструктор. Глубже не копал, но интуитивно понял что new таки в случае неудачи возвращает ноль. Счас отловлю другие ошибки и попробую организовать нехватку памяти.

Это всего лишь личное мнение Страуструпа :-)))) который и затвердил :-( его в своей реализации ++.
Я не слишком слежу за процессом стандартизации C++, но похоже комитет пока еще не родил
стандарта :-(.
В моей полной цитате речь шла о проблеме более широко:
- не только по отношению к C++, но и к C (более того это был именно кусок по С );
- по отношению к разным платформам, как например должен выглядеть Страуструповский
0 на платформе типа Cray-Cyber с кольцевыми указателями?
Короче в С++ болезнь вместо лечения ( введением ключевого слова, как в Паскале) была загнана вовнутрь наложением исскуственного требования иметь внутреннее представление нулевых указателей нулевым. И с легкостью необыкновенной считать, что ключевое слово для нулевого указателя это "0".