C++ Initialization Lists

Все C++ программисты знают, что члены класса можно инициализировать в списке инициализации в конструкторе, но не все хорошо понимают когда члены класса должны получать свои значения в списке инициализации, а когда в теле конструктора. К тому же использование списков инициализации сопряжено с некоторыми тонкостями реализации, пренебрежение которыми может приводить к трудно понимаемым ошибкам.

Чтобы понять разницу в механизме работы списка инициализации и тела конструктора, для начала нужно обратиться к понятиям инициализации и присваивания. Инициализация — это момент получения объектом значения в первый раз. Получение же проинициализированным объектом нового значения является присваиванием. Функционально разница между этими понятиями проявляется в том, что при инициализации вызывается конструктор (в том числе конструктор копирования), а при присваивании выполняется operator=. Важным моментом является то, что к моменту входа в тело конструктора все члены класса всегда являются проинициализированными, даже если это не указано явно.

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

Если же в классе имеется большое число членов встроенных простых типов (int, double и др.), то может быть более разумным создать приватный метод, который бы присваивал нужные значения всем таким членам и вызывался во всех конструкторах, где это необходимо. Потеря производительности в этом случае будет ничтожно малой, но при этом улучшится читаемость кода.

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

Mercurial installation

Mercurial — распределённая система контроля версий (SCM). От остальных отличается простотой использования и, как следствие, маленьким временем освоения новичками. При этом mercurial достаточно функционален для подавляющего количества задач.

В этой статье я опишу как создать на мой взгляд достаточно стандартную конфигурацию, которая удовлетворит нужды большинства небольших групп разработчиков. В целом установка mercurial’а не сложна, но может вызвать некоторые трудности у непосвящённых.

Хотя распределённые SCM не нуждаются в центральном репозитории (repository), обычно бывает очень полезно иметь «интеграционный» репозиторий в качестве того места, откуда всегда можно получить актуальное состояние разработки от всех разработчиков, и места обмена наборами изменений (changesets).

Итак, интеграционный репозиторий будет храниться на linux-сервере, к которому имеется доступ по SSH. Плюсом такой конфигурации является также возможность доступа к репозиторию удалённых разработчиков, если сервер имеет доступ в интернет.

Для начала в целях безопасности нужно создать группу пользователей в /etc/groups, содержащую всех разработчиков, которые должны иметь доступ к хранилищу. В качестве примера такой группой будет scm. Как создать группу и добавить туда пользователей смотрите документацию вашего дистрибутива. Репозиторий у нас будут находиться в каталоге /hgrepo. Создадим новое хранилище и запретим доступ к нему всех, кто не входит в группу scm:

$ cd /hgrepo
$ hg init myrepo

Репозиторий создан и уже практически готов к работе. Установим права доступа к репозиторию:

# chgrp -R scm myrepo # устанавливаем группу доступа к репозиторию
# chmod -R o= myrepo # запрещаем доступ для всех, кто не входит в группу scm
# chmod -R g+w myrepo # установим право записи в репозиторий для группы
# find myrepo -type d -exec chmod g+s {} \; # все новые файлы и каталоги будут иметь группу scm

Для удобства доступа к репозиторию создадим символическую ссылку в корне:

$ cd /
# ln -s /hgrepo/myrepo

Всё готово. Чтобы воспользоваться репозиторием, у разработчиков должен быть установлен mercurial версии не ниже той, что на сервере и прописано имя пользователя в файле .hgrc в домашнем каталоге пользователя. Версию mercurial’а можно проверить командой:

$ hg --version

Для того, чтобы сделать клон, выполните:

$ hg clone ssh://<username>@<servername>//hgrepo

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

Ссылки:

http://ru.wikipedia.org/wiki/Mercurial
http://mercurial.selenic.com/wiki/MultipleCommitters