выход:

...

Проверка в операторе управления циклом - единственное место, где эффективность действительно является важным обстоятельством, потому что код выполняется многократно. Это особенно верно для внутренних операторов управления вложенных циклов. Проверка флага завершения во внутреннем цикле может существенно замедлить выполнение, и ее лучше избегать.

Часть

Правила программирования на Си++

Эта часть книги содержит правила, уникальные для программирования на Си++. Как мной было сказано во "Введении", эта книга не является учебником по Си++, так что следующие правила предполагают, что вы по крайней мере знакомы с синтаксисом этого языка. Я не буду тратить слова попусту, описывая, как работает Си++. Имеется множество хороших книг, которые познакомят вас с Си++, включая и мою собственную "С+С++". Вы должны также ознакомиться с принципами объектно-ориентированного проектирования. Я рекомендую 2-е издание книги Гради Буча "Object-Oriented Analysis and Design with Applications" (Redwood City: Benjamin Cummings, 1994).

Так же, как и в книге в целом, правила вначале адресуются к общим вопросам, переходя затем к частностям.

Часть 8а. Вопросы проектирования и реализации

90. Не смешивайте объектно-ориентированное и "структурное" проектирование

90.1. Если проект не ориетирован на объекты, то используйте Си

Позвольте мне начать, сказав, что нет абсолютно ничего дурного в хорошо выполненном структурном проектировании. Как-то так получилось, что я предпочитаю объектно-ориентированный (ОО) подход, ибо мне кажется, что я мыслю ОО способом, но было бы самонадеянным назвать ОО проектирование "лучшим". Я верю, что ОО подход дает вам легче сопровождаемый код, если программа большая. Выгода менее явна в случае программ меньшего размера, потому что объектная ориентация обычно добавляет сложность на уровне приложения. (Главная выгода ОО заключается в лучшем сопровождении за счет абстракции данных, а не в сокращении сложности).

Си++ особенно не выносит небрежного проектирования. Мой опыт говорит, что программы на Си++, которые не придерживаются объектно-ориентированного подхода, почти несопровождаемы, соединяя все худшие свойства структурного и объектно-ориентированного проектов и не давая каких-либо выгод как ни от того, так и ни от другого. Со мной не проходит такой аргумент, что можно использовать Си++ как "улучшенный" Си. Для того, чтобы это было правдой, этот язык слишком сложный - кривая обучения слишком крутая. Если вы не используете преимущества объектно-ориентированных свойств этого языка, то в его использовании мало смысла. Некорректное использование объектно-ориентированных свойств лишь увеличит число проблем.

К сожалению, многие программисты знают, как сделать объектно-ориентированный проект, но на самом деле этого не делают. Оправдания варьируются в пределах от "слишком много хлопот (или у меня нет времени), чтобы делать все правильно" до "строгий объектно-ориентированный проект - это учебное упражнение: на него нет времени в реальной жизни, где вы вынуждены работать быстро и не очень чисто". Возможно, что наиболее возмутительным оправданием, слышанным мной по поводу плохого проекта (в этом случае библиотеки классов), было