текст представляет собой простой набор битов, а не символы кодировки ASCII или Unicode, то мы не можем рассматривать его как обычный текст. Можно было бы использовать двоичный ввод-вывод (см. раздел 11.3.2), но мы решили выводить числа в шестнадцатеричном виде.
ПОПРОБУЙТЕ
Ключом было слово bs; что представляет собой текст?
Любой эксперт по безопасности скажет вам, что хранить исходный текст вместе с зашифрованным очень глупо. Кроме того, он обязательно сделает замечания о процедуре заполнения, двухбуквенном ключе и так далее, но наша книга посвящена программированию, а не компьютерной безопасности.
Мы проверили свою программу, прочитав зашифрованный текст и преобразовав его в исходный. Когда пишете программу, никогда не пренебрегайте простыми проверками ее корректности.
Центральная часть программы расшифровки выглядит следующим образом:
unsigned long inptr[2];
char outbuf[nchar+1];
outbuf[nchar]=0; // терминальный знак
unsigned long* outptr = reinterpret_cast<unsigned long*>(outbuf);
inf.setf(ios_base::hex,ios_base::basefield); // шестнадцатеричный
// ввод
while (inf>>inptr[0]>>inptr[1]) {
decipher(inptr,outptr,k);
outf<<outbuf;
}
Обратите внимание на использование функции
inf.setf(ios_base::hex,ios_base::basefield);
для чтения шестнадцатеричных чисел. Для дешифровки существует буфер вывода outbuf, который мы обрабатываем как набор битов, используя приведение.
Следует ли рассматривать алгоритм TEA как пример программирования встроенной системы? Не обязательно, но мы можем представить себе ситуацию, в которой необходимо обеспечить безопасность или защитить финансовые транзакции с помощью многих устройств. Алгоритм TEA демонстрирует много свойств хорошего встроенного кода: он основан на понятной математической модели, корректность которой не вызывает сомнений; кроме того, он небольшой, быстрый и непосредственно использует особенности аппаратного обеспечения.
Стиль интерфейса функций encipher() и decipher() не вполне соответствует нашим вкусам. Однако эти функции были разработаны так, чтобы обеспечить совместимость программ, написанных как на языке С, так и на языке С++, поэтому в них нельзя было использовать возможности языка С+, которыми не обладает язык C. Кроме того, многие “магические константы” являются прямым переводом математических формул.
25.6. Стандарты программирования
Существует множество источников ошибок. Самые серьезные и трудно исправимые ошибки связаны с проектными решениями высокого уровня, такими как общая стратегия обработки ошибок, соответствие определенным стандартам (или их отсутствие), алгоритмы, представление идей и т.д. Эти проблемы здесь не рассматриваются. Вместо этого мы сосредоточимся на ошибках, возникающих из-за плохого стиля, т.е. из-за кода, в котором средства языка программирования используются слишком небрежно или некорректно.
Стандарты программирования пытаются устранить вторую проблему, устанавливая “фирменный стиль”, в соответствии с которым программисты должны использовать средства языка С++, подходящие для конкретного приложения. Например, стандарты программирования для встроенных систем могут запрещать использование оператора new. Помимо этого, стандарт программирования нужен также для того, чтобы программы, написанные двумя программистами, были больше похожи друг на друга, чем программы, авторы которых ничем себя не ограничивали, смешивая все возможные стили. Например, стандарт программирования может потребовать, чтобы для организации циклов использовались только операторы for, запрещая применение операторов while. Благодаря этому программы становятся более единообразными, а в больших проектах вопросы сопровождения могут быть важными. Обратите внимание на то, что стандарты предназначены для улучшения кодов в конкретных областях программирования и устанавливаются узкоспециализированными программистами.
Не существует одного общего стандарта программирования, приемлемого для всех приложений языка С++ и для всех программистов, работающих на этом языке.
Таким образом, проблемы, для устранения которых предназначены стандарты программирования, порождаются способами, которыми мы пытаемся выразить наши решения, а не внутренней сложностью решаемых задач. Можно сказать, что стандарты программирования пытаются устранить дополнительную сложность, а не внутреннюю.
Перечислим основные источники дополнительной сложности.
• Слишком умные программисты, использующие свойства, которые они не понимают, или получающие удовольствия от чрезмерно усложненных решений.
• Недостаточно образованные программисты, не знающие о наиболее подходящих возможностях языка и библиотек.
• Необоснованные вариации стилей программирования, в которых для решения похожих задач применяются разные инструменты, запутывающие программистов, занимающихся сопровождением систем.
• Неправильный выбор языка программирования, приводящий к использованию языковых конструкций, неподходящих для данного приложения или данной группы программистов.
• Недостаточно широкое использование библиотек, приводящее к многочисленным специфическим манипуляциям низкоуровневыми ресурсами.
• Неправильный выбор стандартов программирования, порождающий дополнительный объем работы или не позволяющий найти наилучшее решение для определенных классов задач, что само по себе становится источников проблем, для устранения которых вводились стандарты программирования.
25.6.1. Каким должен быть стандарт программирования?
Хороший стандарт программирования должен способствовать написанию хороших программ; т.е. должен давать программистам ответы на множество мелких вопросов, решение которых в каждом конкретном случае привело бы к большой потере времени. Старая поговорка программистов гласит: “Форма освобождает”. В идеале стандарт кодирования должен быть инструктивным, указывая, что следует делать. Это кажется очевидным, но многие стандарты программирования представляют собой простые списки запрещений, не содержащие объяснений, что с ними делать. Простое запрещение редко бывает полезным и часто раздражает.
Правила хорошего стандарта программирования должны допускать проверку, желательно с помощью программ. Другими словами, как только вы написали программу, вы должны иметь возможность легко ответить на вопрос: “Не нарушил ли я какое-нибудь правило стандарта программирования?” Хороший стандарт программирования должен содержать обоснование своих правил. Нельзя просто заявить программистам: “Потому что вы должны делать именно так!” В ответ на это они возмущаются. И что еще хуже, программисты постоянно стараются опровергнуть те части стандарта программирования, которые они считают бессмысленными, и эти попытки отвлекают их от полезной работы. Не ожидайте, что стандарты программирования ответят на все ваши вопросы. Даже самые хорошие стандарты программирования являются результатом компромиссов и часто запрещают делать то, что лишь может вызвать проблемы, даже если в вашей практике этого никогда не случалось. Например, очень часто источником недоразумений становятся противоречивые правила именования, но люди часто отдают предпочтение определенным соглашениям об именах и категорически отвергают остальные. Например, я считаю, что имена идентификаторов вроде CamelCodingStyle[10] весьма уродливы, и очень люблю имена наподобие underscore_style[11], которые намного понятнее, и многие люди со мной согласны. С другой стороны, многие разумные люди с этим не согласны. Очевидно, ни один стандарт именования не может удовлетворить всех, но в данном случае, как и во многих других, последовательность намного лучше
