Протекающие абстракции Или зачем современному программисту знать все эти низкоуровневые детали

Что пишет типичный современный программист

CLR Что пишет типичный современный программист SQL Server Фреймворк Библиотека Windows Железо C/C++ runtime

Linux А то и еще хуже VMWare CLR SQL Server Фреймворк Библиотека Windows C/C++ runtime VMWare Какая-то еще жизнь Железо

На самом деле все еще хуже CLR SQL Server Фреймворк Библиотека Windows Железо C/C++ runtime Оптимизирующий Генератор байт-кода Препроцессор шаблоны условная компиляция JIT-компилятор STL/ATL, препроцессор, Оптимизирующий компилятор VMWare патчит гостевую ось на ходу Железо руками давно уже никто не проектирует, Везде сплошные CAD, VHDL и FPGA

И как с этим теперь жить? «Я лучше буду знать что-то одно, но буду знать это хорошо» «Пусть за меня думает компьютер, я буду решать только высокоуровневые вопросы» «Преждевременная оптимизация – корень всех зол» «Будет тормозить – будем думать»

Протекающие абстракции Leaky abstraction © Joel Spolsky, Что же может протечь? –Проблемы с безопасностью –Проблемы с производительностью –Ошибки –Документированные особенности реализации

Например Transmission Control Protocol –Абстракция надежного соединения через ненадежную сеть Реальная сеть теряет пакеты или доставляет их не по порядку TCP имитирует надежное соединение

Но TCP использует подтверждения, таймауты и повторную передачу TCP рвет соединение при трех последовательных таймаутах TCP гарантирует доставку, но не гарантирует время доставки

Другой пример Java/C# используют сборку мусора Полезная абстракция, которая устраняет висячие ссылки и утечки памяти Снижение стоимости разработки от 2 до 5 раз

Но Если вы не думаете, куда (а также, когда и почему) у вас деваются объекты, вы будете делать ошибки. В С++ и C# это будут разные ошибки. Кстати, в Java/C# утечки памяти очень даже бывают…

Exception security C++ style RAII (Resource allocation is initalization) Деструкторы зовутся в конце блока Завернуть выделяемый ресурс в объект с конструктором/деструкт ором, и исключения вам не страшны Java/C# style Финализаторы зовутся JVM знает когда Внешние ресурсы надо освобождать явно Висячие ссылки/утечки возвращаются к нам Try {} Catch {} Finally { window.close(); bitmap.recycle(); session.destroy(); …. }

Пример из жизни В Android есть две кучи –Managed heap (Dalvik) –Native heap (OpenGL/BMP) Объектам нативной кучи надо явно звать recycle. Куча приколов –Нативная куча кончилась, вы зовете gc, а толку нет –Утечки памяти в нативной куче –Висячие ссылки в управляемой куче –И прочие радости жизни И все это в условиях жестко ограниченной памяти.

Пример из жизни (самый противный вариант) Класс-обертка вокруг битмапа в нативной куче Битмап большой, обертка маленькая Насоздавали битмапов, нативная куча кончилась, а управляемая куча почти не занята. Сборка мусора не проходит (не видит, чего собирать-то)

Пример из жизни (продолжение) Ну давайте везде звать recycle()? [] Поэтому при работе с битмапами постоянно ставишь recycle. А вот мы и подобрались к объяснению баги, описанной в начале. Даже в доках от гугла есть пример отдачи картинки в OpenGL, где после трансфера её туда битмап "ресайклится". Ага! У меня в коде было тоже самое! Но тот самый злосчастный экран отличалcя от остальных тем, что битмапы грузил не с SD-карты, а из ресурсов прилады! А они (ресурсы) грузятся один раз на всё приложение. И, будучи поресайкленной, битмапа из ресурсов оставалась таковой до рестарта приложения []

На самом деле все еще хуже Приколы вылезают не только при явном освобождении памяти Приколы могут вылезать если вы используете два разных сборщика мусора Например: –CLR (.Net) использует marknsweep –COM (legacy VB) использует reference count

В чем разница? Marknsweep –Сборка мусора дорогая операция –Зовется только от горя (когда память кончилась) Refcount –Сборка мусора происходит «сама», звать ее не надо –Никаких хуков на «что-то мы сожрали много памяти» нету Тот же сценарий: маленькая обертка в marknsweep куче вокруг большого refcount объекта –Refcount куча разрослась до хрен-знает-скольколлиона байт, а marknsweep про это ни сном, ни духом

Безопасность

Dynamic SQL, говорите? Хех… Кавычка попадает в базу Legacy код на VB/ASP/Abscess берет ее из базы

Хорошие практики Ну и что? – скажут многие Не надо знать низкоуровневые детали и не надо знать, что может протечь Надо знать хорошие практики, как бороться с протечками

Хорошие практики не панацея Хорошая практика: нельзя совать пальцы в розетку

Во что это может вылиться