Последний раз обновлено 27.06.01
Сразу развею все сомнения и скажу честно: я не буду писать для вас программы. Если я сделаю это, то что же делать вам? Язык С++, его подмножество, использован мной почти как язык объектной модели, вернее, он и пространство сообщений дополняют друг друга. У такого способа огромное количество недостатков, но есть и преимущества:
При выборе примеров я руководствовался следущими соображениями:
Здесь не решается задача надежности кода, отсутствуют специфические для С++ конструкции явно не необходимые для решения, т.к. предполагается слабое знание С++. Я пришел к выводу, что можно: либо ущербно описать важные для составления модели свойства, либо ущербно описать технические подробности языка, что, к сожалению, акцент можно сделать только на одной вещи.
Если верить Страуструпу, то язык должен позволять использовать некоторые его подмножества, что-то вроде: "то, что вы не знаете, не должно вам навредить". Для программирования необходимо, чтобы было ясно, как получить объектную модель программы и что это такое, что, по моему мнению, является главной сложностью, по крайней мере при переходе от структурных программ к объектным. В худшем случае, придется одновременно с этим изучать и новый синтаксис объектного языка, правила которого могут быть сложны. Но для пары С/С++ это не так, можно ограничиться таким подмножеством С++, которое почти совпадает с правилами С, что позволит сосредоточить внимание на програме. Я еще раз напомню, что данная работа не учебник по С++, а описывает объектную модель программы для людей знакомых с языком С.
Я старался не нагружать код const определениями, inline функциями, отличными от С правилами использования переменных и прочее, так как, в добавок к выше сказанному,
Надежность кода и оптимальность это, вообще говоря, проблема второго уровня, когда вы знаете что вы хотите описать и ищите как это сделать, но не здесь ищите, а в описании С++.
Относительно новые возможности С++ я тоже не использую, так как сам еще с ними хорошо не разобрался, а пример, идея и этот текст создавались до широкой доступности этих новшеств, и я не хочу ничего модернизировать.
Можно задать такие вопросы:
stdio.h и conio.h реализовать самому? Где граница этого нуля?
На эти вопросы есть элементарные ответы:
Желание разрабатывать самому базовые элементы (список, строка, окно), чем бы оно не вызывалось, прямо в процессе работы над прикладной задачей, мягко говоря, не помогает в решении задачи. Приходится это делать или нет при работе с реальной задачи и правильном стиле программирования это другой вопрос. Я поступлю комбинированно: для некоторых базовых элементов потребую определенных свойств как условие задачи и без объяснений, для других будет видно, как они образовались.
Даже самые элементарные примеры потребовали определенной продвинутости в знании С++ и ООП, что как раз хочется получить из этих примеров. От ряда свойств и идей пришлось совсем отказаться, а другие существенно упростить. Можно даже сказать, что подобрать хорошие и простые примеры не удалось, т.к. подобрать пример в котором бы сочетались простота, все свойства да еще от простого к сложному это уже искусство.
Проблемы тонкостей описания объекта на С++, характерных только для С++, выходят за рамки данного текста, а я не хочу вставлять код, объяснить происхождение которого здесь будет затруднительно. Многие объекты по сути заготовки для разработки, которые выполняют только минимум работы, обязательной для задачи. Не стоит использовать для объекта любые стандартные операции, которые не описаны явно, или думать, что он такой же, как встроенный тип, передавать объекты по значению в параметрах или возвратах функций. Исключением являются те классы, которые специально создавались как аналоги встроенных типов.
В защиту этих примеров можно сказать только то, что они ранее не были сделаны и развивались от нуля до того уровня, до которого развились, исключительно по методам предложенным в этой работе.
К сожалению, пока нет возможности организовать набор примеров имеющих раздельные промежуточные результаты для любого этапа, поэтому последовательность основных шагов будет изложена текстом здесь, а конечные результаты в виде исходников и откомпилированных модулей в архиве.
Легкие изменения привычного стиля оформления программы: имена и действия по умолчанию, отступы и прочие, казалось бы, мелкие детали делают текст программы вполне нечитабельным, и без головной боли вы не поймете о чем идет речь. Причем обилие комментариев не всегда может помочь, если вы слабо знаете язык комментария или он составлен, с вашей точки зрения, плохо. Это напоминает то, как если бы к вам пришел человек, который выучил ваш язык но с другими ударениями, паузами и интонациями: устная речь будет совершенно не понятной. Но, к сожалению, не существует стандартных жестких правил по оформлению программы С++ предназначенной для переноса в исходнике, что, может быть, и хорошо.
В таблице (Таблица 1) указаны сокращения, которые применяются в примерах.
Наличие _p суффикса в именах пришло от того, что в ряде моделей памяти есть far и near указатели, смешивание которых нежелательно, а явное задание типа указателя довольно утомительно. Этот _p скрывает за собой это, что облегчает перенос программы из flat модели в другую.
Я не люблю ИменаВСтилеПаскаля, которые используются там из-за недопустимости знака "видимого пробела" в именах символов, и редко их использую.
Таблица 1
Сокращения в примерах программ
| u_< type > | unsigned < type > |
| < type >_p | < type > * |
| t_< name > | Тип структуры С |
| T< name > | Класс С++ |
Нет ничего хуже, чем копаться в чужих исходниках, но я не вижу другой возможности посмотреть на примеры, кроме этой. Конечно, примеры серьезно не проверялись, и, фактически, являются черновым вариантом, содержат достаточно много ошибок, но они являются той ниткой, которую я хотел протянуть от задачи до программы, которая выполняет ряд основных частных случаев задачи. Это позволяет надеяться, что какие-либо изменения над кодом будут проводиться локально, что позволит хорошо видеть преимущества объектной модели.
В примерах используются как вложение, так и наследование, множественное наследование, шаблоны кода. Все функции выполняются по классической схеме
Лучше, конечно, в качестве примера брать исходники, разработанные профессионалами, специально для обучения, если они есть. Именно отсутствие их и побудило меня написать это. Я просто собрал в одну кучу те проблемы, с решением которых мне приходилось сталкиваться, и изложил их в том порядке, какой считаю правильным и легким. Надеюсь, что это кому-нибудь поможет когда-нибудь при борьбе с чем-то подобным.