Лекция 5 (1160838), страница 3
Текст из файла (страница 3)
А мы, вдобавок, еще и мусор образовали из того обьекта, на который ссылался з до присваивания ему p1.
Что страшнее? Мусор или висячая ссылка? Страшнее, как показывает практика, мусор, который копится, копится, копится и....мы не знаем, где программа в итоге «свалится». А при возникновении висячих ссылок она свалится сразу.
Страх мусорной проблемы именно в том, то внешне она никак не проявляется. Для обнаружения подобных ошибок написаны специальные библиотеки, анализирующие состояние кучи.
Эти проблемы будут тяготить программиста до тех пор, пока не появится динамической сборки мусора. Если ЯП строгий и в нем есть сборка мусора проблем будет намного меньше(к примеру, язык Оберон).
А как дело в данном сллучае обстоит с Адой?
Создатели Ады, как мы помним, ставили перед собой 3 цели:
1)надежность
2)эффективность
3)читабельность
ЯП – это совокупность компромиссов. При его создании могут быть 2 противоречащие цели: надежность и эффективность. Динамическая сборка мусора, хоть и повышает надежность программы, сильно вредит эффективности(сборка мусора – дорогостоящее по времени занятие). Сборка мусора противопоказана системам, работающим в режиме реального времени.
Есть еше 1 выход: создание UNCHECKED_DEALLOCATION(p);// если в системе из соображений эффективности не присутствует динамической сборки мусора – это неконтролируемое освобождение памяти.
Указатель – это некоторая переменная, содержащая значение, которое может каким-либо образом интерпретироваться. Заметим, что в C# и Java указателя нет(он превратился в ссылку). Обьекты в этих ЯП находятся только в динамической памяти. На них похож и язык Delphi, где также теализовала референциальная модель обьекта.
То есть, когда мы пишем
T x;
Мы заводим не обьект типа Т, а ссылку на этот обьект.
Отличие Delphi от C# и Java в том, что там нет динамической сборки мусора, а, следовательно, там возникают и «мусор», и «висячие» ссылки.