А.В. Столяров - Введение в язык Си++ (1114949), страница 10
Текст из файла (страница 10)
Неявный конструктор копирования производит копирование наиболее очевидным способом: поля,которые сами имеют конструкторы копирования, копируются с помощьюэтих конструкторов, прочие поля — побитовым копированием.С конструктором по умолчанию ситуация чуть сложнее: он генерируется неявно, если програм м ист не описал в структуре иликлассе вообщ е ни одного кон структора. Если в классе или структуре явно описать хотя бы один конструктор (любой), компилятор не будетгенерировать неявный конструктор по умолчанию, поскольку сочтёт, чтопрограммист взял заботу о конструировании в свои руки. Именно поэтому в примерах, которые рассматривались в § 2.1.3, мы могли описыватьпеременные типа str_complex без всяких параметров, пока не ввели первый конструктор, после чего возможность описания переменных этоготипа без указания параметров нами была утрачена до тех пор, пока мы(уже сами, явно) не определили конструктор по умолчанию.Сделаем ещё одно важное замечание. Поскольку конструктор копирования может быть сгенерирован неявно, отсутствие явно описанногоконструктора копирования не означает невозможности создания копииобъекта.
Существует, однако, способ зап рети ть копирование объектов некоторого класса: для этого достаточно описать конструкторкопирования явно, но сделать это в приватной части класса. Такойприём часто применяют для классов, объекты которых по смыслу копи43роваться не должны, чтобы исключить случайные ошибки, связанные,например, с передачей их по значению. Ясно, что объект, для которогокопирование запрещено, не может быть ни передан по значению в функцию, ни возвращён из функции; это не исключает, разумеется, передачи по ссылке. Забегая вперёд, отметим, что аналогичный приём можноприменить и для запрещения присваивания объектов (именно, убрать вприватную часть соответствующую форму оператора присваивания).§2.15. О писание те л а м етода вне класса.Р аск р ы ти е области видим остиДо сих пор все описываемые нами методы состояли из одной-двухстрок кода. Конечно, так получается далеко не всегда, а размер теламетода, вообще говоря, не ограничен, как не ограничен и размер телаобычной функции8.Вместе с тем, описание класса при наличии в нём нескольких методовзначительного объёма может стать (в силу своих размеров) совершеннонедоступным для понимания.
Вообще говоря, чаще всего программистычитают описания классов, чтобы узнать, как с соответствующим классомработать. Ясно, что для этого необходим список (публичных) методов.Пока описание класса умещается на одной странице, список его методовможно охватить одним взглядом; если же в классе описаны громоздкиеметоды, для ознакомления с заголовками методов может потребоватьсядолгое перелистывание кода туда и обратно, причём в процессе поисказаголовка одного метода программист может успеть забыть про другие,так что изучение класса становится занятием долгим и утомительным.Есть и ещё одна проблема с телами методов, которая возникает принаписании многомодульных программ. В языке Си мы помещали описания структур, необходимые более чем в одном модуле, в заголовочные файлы.
В С и + + с классами и структурами ситуация совершенно такая же: если мы хотим использовать некоторый класс или структуру в нескольких модулях, следует поместить описание этого классаили структуры в заголовочный файл и включить этот файл директивой#include " . .. " во все нужные модули.®Это, впрочем, не означает, что написание громоздких функций в чём-то правильно. Чем функция длиннее, тем труднее стороннему программисту понять, что она делает. Многие программисты придерживаются точки зрения, что всё описание любойфункции (тело вместе с заголовком) должно укладываться в 25 строк или в крайнемслучае быть чуть-чуть больше. Такую функцию можно охватить одним взглядом.
Если код функции разбух и стал гораздо больше, из неё следует выделить логическиечасти и оформить их в виде отдельных функций, то есть разбить одну функцию нанесколько. Всё это справедливо и для методов.44Если при этом класс или структура содержит тела методов, это будетозначать, что код, составляющий их тела, окажется откомпилирован вк аж д о м из модулей.
Если таких модулей много, в итоговом исполняемом файле окажется значительное количество дублируемого кода: методы нашего класса (один и тот же код!) будут присутствовать в такомколичестве копий, сколько модулей используют наш класс.Обе проблемы (громоздкость описания класса и дублирование объектного кода методов) решаются вынесением тел методов за пределыописания класса (называемого также заголовком класса). При этомв заголовке класса оставляется только прототип (заголовок) функцииметода, то есть тип возвращаемого значения, имя метода, список формальных параметров и (возможно) модификатор const, после чего вместо тела метода ставится точка с запятой, как и после обычного прототипа функции.Тело функции-метода при этом описывается в другом месте, за пределами заголовка класса, возможно даже, что в другом файле (чаще всегоэто происходит, если заголовок класса вынесен в заголовочный файл; тела методов при этом описываются в файле реализации соответствующегомодуля).При описании функции-метода за пределами заголовка класса необходимо указать компилятору, что речь идёт именно о методе определённого класса, а не о простой функции.
Это делается с помощью си м волар а с к р ы т и я о б л а с т и в и д и м о с ти , в роли которого в С и + + выступаетдва двоеточия : : (иногда программисты называют этот символ «четвероточием»). Например, если мы описываем некий класс С1 и в нём естьконструктор по умолчанию и некоторые методы f () и g (), вынесениеописания методов за пределы класса может выглядеть так:c la s s Cl {II . . .p u b lic :C IO ;void f ( i n t a, in t b ) ;in t g(con st char * s t r ) const;>;// ... //C l::C 1 (){/ / тело конструктора}45void C l : : f ( i n t a , in t b){/ / тело метода f}in t C l::g (c o n s t char * s t r ) const{/ / тело метода g}Смысл «раскрытия области видимости» можно пояснить следующимобразом.
Имена полей и методов локализованы в классе в том смысле,что, если в классе есть метод с именем f , то вне класса мы можем использовать идентификатор f для других целей, либо вовсе не использоватьего; появление идентификатора f вне класса не имеет никакого отношения к методу f (), описанному в классе. Вместе с тем, в некоторых случаях имя метода f всё же появляется вне класса именно как имя этогометода — например, при вызове его для объекта класса.
Таким образом, вотличие от, например, локальных переменных в функциях, имена членовкласса доступны вне класса (конечно, если они не закрыты механизмомзащиты), но только если имеются указания на то, что требуется имя изкласса; при вызове метода для объекта таким указанием считается типобъекта.Говорят поэтому, что класс (или структура) представляет собой обл а с т ь в и д и м о с ти .
В области видимости имеются свои имена, не конфликтующие с именами вне её даже при совпадении идентификаторов.Вместе с тем, имена, локализованные в области видимости, от этого нестановятся, вообще говоря, недоступны; они доступны, но только при наличии указаний на область видимости. Символ раскрытия области видимости как раз и является средством для таких указаний. Можно сказатьи так, что один и тот же метод имеет внутри класса С1 (то есть в телахего методов) имя f , а вне класса — имя С1: -Л.Отметим, что символ раскрытия области видимости применяется нетолько для описания методов вне заголовка класса. С другими случаямиего применения мы столкнёмся позже.§2.16.
И н и ц и ал и зац и я член ов к л асс а вкон структореДо сих пор мы задавали значения полей объекта с помощью обычного оператора присваивания в теле конструктора. Такой способ можетоказаться неприемлемым; действительно, никто не мешает объявить в46классе поле, имеющее, в свою очередь, тип класс, причём не имеющийконструктора по умолчанию.Рассмотрим эту ситуацию подробнее.
Пусть А — класс, единственныйконструктор которого требует на вход два параметра типа int:c la s s А {// ...p u b lic :A(int х , in t у) { / * . . . * / }// ...>;Опишем теперь класс В, в котором есть поле типа А. Для простоты картины будем считать, что в классе В нам нужен только конструктор поумолчанию (для других конструкторов ситуация будет абсолютно аналогична) :c la s s В {А а;p u b lic :ВО ;// ...Рассмотрим теперь тело конструктора В ().
В нём (то есть во время егоработы) уж е доступно поле а, а для этого, как мы знаем, должен былотработать конструктор класса А. Но ведь единственный конструкторкласса А требует параметров! Как же их ему передать?Чтобы решить возникшую проблему, в С и + + введён специальныйсинтаксис для инициализации полей о б ъ е к т а . При описании конструктора между его заголовком и началом тела (открывающей фигурной скобкой) можно поставить двоеточие, после которого через запятуюперечислить вызовы конструкторов для некоторых или всех полей класса.
В рассматриваемом примере выглядеть это будет так:В ::В () : а (2 , 3) { / * . . . * / }Таким образом мы указываем компилятору, что поле а следует инициализировать (сконструировать) с помощью конструктора от двух параметров (2 и 3). Обнаружив такой код, компилятор вставит вызов соответствующего конструктора класса А непосредственно в начале телаконструктора В.Отметим, что так можно инициализировать любые поля, а не толькополя типа класс. В частности, для нашего типа Complex конструкторымогли бы выглядеть и так:47c la s s Complex {double r e , im;p u b lic :Complex(double a_re, double a_im) : r e (a _ r e ), im(a_im) -QComplex(double a_re) : r e (a _ r e ), im(0) { }ComplexO : r e ( 0 ) , im(0) { }II ...Сделаем ещё одно важное замечание.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
