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

<p id="chapter17.5.4"><strong><emphasis>Порядок создания глобальных объектов не определён...210</emphasis></strong></p>

Локальные объекты создаются в порядке выполнения программы. Для глобальных же объектов порядок создания не определён. Как вы помните, глобальные объекты входят в область видимости программы одновременно. Возникает вопрос: почему бы тогда компилятору не начать с начала файла с исходной программой и не создавать глобальные объекты в порядке их объявления? ( Честно говоря, я подозреваю, что на самом деле большинство компиляторов так и поступают. ) Увы, такой подход отлично работал бы, но только в том случае, если бы программа всегда состояла из одного файла.

_________________

210 стр. Часть 3. Введение в классы

Однако большинство программ в реальном мире состоят из нескольких файлов, которые компилируются каждый в отдельности, а уже затем связываются в единое целое. Поскольку компилятор не управляет порядком связывания, он не может влиять на порядок вызова конструкторов глобальных объектов в разных файлах.

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

    class Student

    {

        public :

            Student ( unsigned id ) : studentId( id ) { }

            const int StudentId ;

    } ;

    class Tutor

    {

        public :

            Tutor ( Student& s ) : tutoredId( s.studentId ) { }

            int tutoredId ;

    } ;

    /* Создаём студента */

    Student randy( 1234 ) ;

    /* Назначаем студенту учителя */

    Tutor jenny( randy ) ;

В этом примере конструктор Student присваивает студенту идентификатор, а конструктор класса Tutor записывает этот идентификатор студента, которому нужен учитель. Программа объявляет студента randy, а затем назначает ему учителя jenny.

При этом подразумевается, что randy создаётся раньше, чем jenny; в этом-то и состоит проблема. Представьте себе, что порядок создания этих объектов будет другим. Тогда объект jenny будет построен с использованием блока памяти, который пока что не является объектом типа Student, а значит, вместо идентификатора студента в randy будет находиться непредсказуемое значение.

«Приведённый выше пример несложен и несколько надуман. Однако проблемы, создаваемые глобальными объектами, могут оказаться гораздо коварнее. Во избежание этого не допускайте, чтобы конструктор глобального объекта обращался к другому глобальному объекту.»

[Советы]

<p id="chapter17.5.5"><strong><emphasis>Члены создаются в порядке их объявления...211</emphasis></strong></p>

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

    class Student

    {

        public :

            Student ( int id , int age ) : sAge( age ) , sId( id ) { }

            const int sId ;

            const int sAge ;

    } ;

_________________

211 стр. Глава 17. Аргументация конструирования

В этом примере sId создаётся до sAge, несмотря на то что он стоит вторым в инициализирующем списке конструктора. Впрочем, единственный случай, когда можно заметить какую-то разницу в порядке конструирования, — это когда оба члена класса имеют конструкторы, которым присуще какое-либо общее побочное действие.

<p id="chapter17.5.6"><emphasis><strong>Деструкторы удаляют объекты в порядке, обратном порядку их создания...212</strong></emphasis></p>

В каком бы порядке ни вызывались конструкторы объектов, вы можете быть уверены, что их деструкторы будут вызваны в обратном порядке. ( Приятно сознавать, что хоть одно правило в С++ не имеет никаких "если", "и" или "но". )

_________________

212 стр. Часть 3. Введение в классы

<subtitle id="chapter18"><emphasis>Глава 18. КОПИРУЮЩИЙ КОНСТРУКТОР...213</emphasis></subtitle>

ОГЛАВЛЕНИЕ

        В этой главе...

►Копирование объекта 213

Перейти на страницу:

Все книги серии Для чайников

Похожие книги