Чтение исходных текстов

Хочется сразу же дать некоторые определения. Существует программирование для какой-то операционной системы. Программист, который пишет под Unix , под Windows , под DOS , это такой человек, который знает (или догадывается) зачем нужен какой-либо системный вызов, умеет написать драйвер устройства и пытался дизассемблировать код ядра (это не относится к Unix - программист под Unix обычно пытается внести свои изменения в исходный текст ядра и посмотреть что получится).

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

Понятно, что программирование на языке и программирование под архитектуру могут вполне пересекаться. Программист на Си под Unix, например. Тем не менее, в особенности среди новичков, часто встречается подмена этих понятий. Стандартный вопрос новичка: я только начал изучать C++, подскажите пожалуйста, как создать окно произвольной формы? . В общем, нельзя, наверное, изучать сразу же операционную систему и язык программирования. Вопрос же про окно правомерен, наверное, только дя Java, где работа с окнами находится в стандартной библиотеке языка. Но у C++ своя специфика, потому что даже задав вопрос: Как напечатать на экране строку Hello, world!? можно напороться на раздраженное Покажи где у C++ экран? .

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

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

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

Кроме того, при чтении исходников , очень часто программирование на языке незаметно заменяется программированием под ОС . Ведь всегда хочется сделать что-то красивое, чем можно удивить родителей или знакомых? А еще хочется сделать так, чтобы как в Explorer - трудно забыть тот бум на компоненты flat buttons для Delphi/C++ Builder, когда только появился Internet Explorer 3.0. Это б1о что-то страшное, таких компонент появилось просто дикое количество, а сколько программ сразу же появилось с их присутствием в интерфейсе...

Изменять текст существующей программы тоже очень сложно. Дополнить ее какой-то новой возможностью, которая не ставилась в расчет первоначально, сложно вдвойне. Читать текст, который подвергался таким изменениям уже не просто сложно - практически невозможно. Именно для этого люди придумали модульное программирование - для того, чтобы сузить, как только это возможно, степень зависимости между собой частей программы, которые пишутся различными программистами, или могут потребоваться в дальнейшем.

Чтение исходных текстов полезно, но уже потом, когда проблем с языком не будет (а до этого момента можно только перенять чужие ошибки), их коллекционирование никак не может помочь в начальном изучении языка программирования. Приемы, которые применяются разработчиками, значительно лучше воспринимаются когда они расписаны без излишних деталей и с большим количеством комментариев, для этого можно посоветовать книгу Джеффа Элджера C++ .

Функция gets()

Функция gets(), входящая в состав стандартной библиотеки Си, имеет следующий прототип:

char* gets(char* s);

Это определение содержится в stdio.h. Функция предназначена для ввода строки символов из файла stdin. Она возвращает s если чтение прошло успешно и NULL в обратном случае.

При всей простоте и понятности, эта функция уникальна. Все дело в том, что более опасного вызова, чем этот, в стандартной библиотеке нет... почему это так, а также чем грозит использование gets(), мы как раз и попытаемся объяснить далее.

Вообще говоря, для тех, кто не знает, почему использование функции gets() так опасно, будет полезно посмотреть еще раз на ее прототип, и подумать.

Все дело в том, что для gets() нельзя, т.е. совершенно невозможно, задать ограничение на размер читаемой строки, во всяком случае, в пределах стандартной библиотеки. Это крайне опасно, потому что тогда при работе с вашей программой могут возникать различные сбои при обычном вводе строк пользователями. Т.е., например:

char name[10];

...

puts( Enter you name: ); gets(name);

Если у пользователя будет имя больше, чем 9 символов, например, 10, то по адресу (name + 10) будет записан 0. Что там на самом деле находится, другие данные или просто незанятое место (возникшее, например, из-за того, что компилятор соответствующим образом выровнял данные), или этот адрес для программы недоступен, неизвестно.

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