и переполнения буферов главным образом
Проблемы утечек ресурсов и переполнения буферов главным образом относятся к Си (и в меньшей степени к его преемнику — Си++). Это не покажется удивительным, если вспомнить, что Си — самый низкоуровневый из всех высокоуровневых языков, всего лишь на одну ступень отстоящий от ассемблера. Си делает только то, о чем его просят, вынуждая программиста самостоятельно выделять и освобождать память, контролировать границы буферов и заботиться о массе других вещей, которые на Java, С# и многих других языках автоматически выполняются компилятором (интерпретатором), однако, ни один из них не завоевал такой популярности как Си и навряд ли завоюет ее в дальнейшем. Почему? На Си написано огромное количество программ, которые необходимо развивать и поддерживать, Си обеспечивает максимальную производительность и переносимость, в то время как его конкуренты предлагают _либо_ производительность, _либо_ переносимость.
Что же касается Си++, то это гибрид, вобравший в себя множество концепций и парадигм программирования, позаимствованных из таких языков как, например, как ADA или Smalltalk, но все равно оставшийся "ручным". В нем нет ни сборщика мусора, ни динамических стековых массивов, ни автоматического контроля границ, ни многих других вещей, которые по-прежнему приходится делать руками. А нет их там потому, что вся эта "автоматизация" заметно снижает производительность и превращает Си++ в пародию на Visual Basic, ярчайшим примером которой является C#. Ходят устойчивые слухи, что значительная часть Longhorn'а была написана на C#, но несмотря на все усилия разработчиков, достичь приемлемой производительности и стабильности им так и не удалось (а что еще можно ожидать от Бейсика, пускай и продвигаемого под видом Си?). В конечном счете, компания была вынуждена похоронить миллионы строк, и начать разработку заново. Если не ошибаюсь, текущая версия Windows Vista базируется на коде Server 2003, написанного на смеси Си с Си++, а это, значит, что отказ от Си/Си++ (по крайней мере в крупных проектов) невозможен и вместо того, чтобы жаловаться на судьбу, лучше придумать пару-тройку новых методов борьбы с утечками и переполняющимися буферам, о чем мы сейчас и поговорим.
