Есть память, а есть память

[dz]

Если вы не low level programmer, вам этот пост катастрофически неинтересен.

Comments

[sergegers1]

Смешно. Прямой доступ к памяти нужен не только для обращения к ядру, но и в юзермоде, если идёт речь о юзермоде. А это неэффективно. Вместо

mov dword ptr[ecx+10h], 7h

надо делать

mov edx, ecx
add edx, 10h
push edx
call _myFuckingCheckFunc@4
test eax, eax
jne SHIT_HAPPENS
mov dword ptr[edx], 7h

Это по эффективности.

А вторая проблема - это замена рантайм проверками компайл тайм проверок, которые достигаются строгой типизацией. Их можно обойти, если целенаправленно к этому стремиться, но на практике это происходит редко.
А ведь кроме памяти существуют ещё и другие ресурсы, типа файловых дескрипторов, с которыми управляемым языкам приходится работать в старом добром C стиле. А ещё есть проблема момента освобождения ресурса/объекта, который часто быват нужно явно контролировать. В общем, GC просто замазыват проблему и провоцирует плохой дизайн.

[stealthy_shadow]

Неэффективно - для кого? Для программиста? Так он второе и не пишет - за него компилятор все делает. Да и лукавите вы - откуда вы знаете, что у вас там в ECX и куда ведет ECX+10h? Ниоткуда? Или все-таки есть где-то код проверки? Нету? Ну, получите синий экран

[rblaze]

Мне кажется, ваш разум отравлен страшным сиплюсплюсом и жабой. Ну какое отношение GC имеет к освобождению ресурсов? Только то, что вы привыкли делать это в деструкторе объектов.

[sergegers1]

Подумайте на досуге, зачем нужен GC.

[rblaze]

Память неиспользуемую обратно в дело пускать. У вас есть какие-то иные предположения?

[sergegers1]

А память у нас что такое? Ресурс. Поэтому GC имеет отношение к освобождению ресурсов.

[rblaze]

Окей, замените на "других ресурсов", если вам это важно.

[dz]

1. меня отдельно поражают люди, которые считают, что оптимизатор кодогенератора явы чем-то уступает оптимизатору кодогенератора си