Здравствуйте, srggal, Вы писали:

S>ЗЫЗЫ
S> Возникло подозрение, что на этапе поддержки ПО, все остальные касты, которые Вы хотите выбросить, используются на право и налево в большинестве проектов. Поскольку обычно ведут уже другие люди, которым вдаватьася в подробности архитектуры неохота, либо исправление ошибки ( или не дай бог ипрувмент ) — требуют слишком много времени, и проще наплевать на всё и использовать эти конструкциии и работу с памятью.
S> Предвижу — Вы скажете, что если бы была заложена правильная Архитектура — то все -бы прохолдило на ура. Но ведь много проектов с неправильной, в этом плане архитектурой, которые продаются/используются/сопровождаются. Кроме того, я участвовал в проекте с Правильной Архитектурой, где только о ней и думали ( как сделать так чтобы потом ихменять было легко ), ничего хорошего из этого не вышло. В данный момент — одна из моих задач — соправождение продукта, он кривой, написан через задницу, исправлять ошибки в нем — мучение, не говоря уже об импрувментах, НО он хорошо продается и много копий уже стоит у заказчиков. Так что — язык должен мне отказать в возможности эффективно решать поставленную задачу? Т.е. вместо того, чтобы прсле 2х часовых поисков взять и интерпретировать буффер памяти по-своему, я должен 40 часов заниматься изменением архитектуры, и потом выходить на полный цикл тестировани?

S>ЗЫЗЫЗЫ
S> Видимо убедился я в Вашей правоте еще не полностью. Страуструп — прав этого надо избегать, но ИНОГДА от ЭТОГО НИКУДА НЕ ДЕТЬСЯ

Действительно, деться трудно. У меня на одном из мест работы года 4 назад были регулярные конфликты с тим-лидером, из-за того, что я вместо того, чтобы "заниматься делом", т.е. замазывать соплями очередной баг и бежать к следующему, занимался "всякой ерундой", т.е. выискивал первопричины возникновения ошибочных ситуаций (правильнее сказать — допущения программистами этих ситуаций) и довольно много кода перелопачивал вручную... Положительный эфект сказался не сразу, но суть его была в том, что баги стали уходить не по одному, а целыми классами или семействами, и большинство из них уже не возвращались на вновь разрабатываемые модули.

Да, о чем это я... Последние пару лет плотно сижу на C#, и овладел такой штукой как Resharper на уровне "слепого десятипальцевого метода". В общем, постоянное поддержание кода в состоянии up to date — это вполне себе нормальное состояние кода. В противном случае код загнивает и обесценивается. Если бы для С++ существовали в настоящий момент ср-ва рефакторинга, типа тех, что мы имеем для Java и C#, то БЫЛО БЫ КУДА ОТ ЭТОГО ДЕТЬСЯ.

И еще обнаружил интересный момент. Помимо того, что этот рефакторинг или даже более "глубокий", чем рефакторинг, ремонт кода не требует видимых постоянных усилий ныне, приводить код в порядок инструментом типа Решарпера — это само по себе приятное занятие. Испытываешь прямо-таки эстетическое наслаждение от процесса. А, помятуя усилия, которые порой приходилось затрачивать на рефакторинг чужого кода на С++, так все еще не могу отделаться от удивления: "вот же ж блин же ж!!! ай да Пушкин, ай да бычий глаз"... (оффтопная лирика).

---------
Ну, а раз подобных по мощности инструментов для С++ пока нет (и все опасные конструкции тоже на месте), то — внимание и еще раз внимание при разработке. Такой уж он у нас требовательный...