C++ in depth

Головоловка

2007-02-16T13:34:00.000+03:00

Синтаксис языка С++ иногда просто поражает.
Как Вы думаете что означает это объявление:


char (*(*(*C::foo(int(C::*)(int const) const) const))())[][1];

Comeau всегда прав!...?

2006-11-08T16:02:00.000+03:00

Код, который я пишу на работе, должен собираться сразу несколькими компиляторами. Само собой иногда возникают разногласия в их трактовках стандарта языка. Обычно, при неоднозначном результате, я считаю правым gcc, однако, в особо щекотливых ситуациях, проверяю код on-line вариантом Comeau. Лишь затем «курю» стандарт, уточняя оставшиеся непонятными моменты. Comeau всегда дает мне 90% понимания сутации.
[Дальше...]

Баг VS или как получить доступ к приватному интерфейсу

2006-10-17T11:29:00.000+04:00

Случайно столкнулся c интересным багом в VS2003/VS2005.
Нехитрый прием позволяет получить доступ к приватному интерфейсу наследуемого класса.


struct ifoo
{
  void test() {}
};

class foo : private ifoo
{
};

struct delegate
{
  delegate(ifoo* i) { i->test(); }
};

class bar : private foo
{
public:
  bar() { delegate(this); } // sic! вызов ifoo::test
};

Эмпирические исследования показали, что прием работает только если ifoo является структурой и delegate используется как временный объект.

Не устаю предупреждать:
Beware of bugs

Отпуск

2006-08-26T10:10:00.000+04:00

Впереди долгожданный отпуск! Улетаю на две недели к черному морю.
Обещаю по возвращению порадовать читателей новыми интересными постами.

ADL в деле

2006-08-26T09:46:00.000+04:00

Продолжение предыдущего поста "Особенности поиска имен".

Как заставить компилятор при поиске operator<< заглянуть в наше собственное пространство имен?
В предыдущем посте я упомянул про ADL и его особенности:
"...ADL предполагает поиск имен в пространствах имен типов агрументов анализируемого выражения..."

Этот вариант поиска имен нам и поможет.
Вызов operator<< находится в operator= класса std::ostream_iterator, а типами аргументов этого выражения являются std::ostream и тип передаваемый std::ostream_iterator в качестве первого параметра шаблона. Мы сами явно его задаем, создавая конкретный экземпляр класса:


std::ostream_iterator< std::pair<std::string, int> >(std::cout)

Заменив std::pair<std::string, int> на некоторый тип (назовен его wrapper) из того же пространства имен что и operator<<, мы заставим компилятор произвести поиск в этом пространстве имен. Следовательно, наш вариант operator<< будет найдет.

Отлично. Проблема поиска решена. Но появились две другие, к счастью легко решаемые проблемы.
Первая заключается в том, что в определении operator= класса std::ostream_iterator требуется теперь в качестве аргумента объект типа wrapper const&, а передается ему std::pair<const std::string, int>.
Вторая проблема обратна первой. Наш operator<< требует в качестве второго аргумента std::pair<const std::string, int> const&, а передается ему wrapper.

Итого, объект типа wrapper должен уметь неявно конструироваться из std::pair<const std::string, int> (проблема 1), неявно преобразовываться к ссылке на константу этого типа (проблема 2), а также хранить саму ссылку.
Обобщая, сам тип можно сделать шаблонным:


template <class T>
class wrapper
{
  T& t_;  // хранимая ссылка
public:
  wrapper(T& t) : t_(t) {} // неявный конструктор из T
  operator T&() const { return t_; } // неявное преобразование к T&
};

Теперь wrapper можно опробовать в деле. Поместим объявление этого типа в пространство имен foo, туда же поместим и operator<<. В качестве аргумента шаблона класса std::ostream_iterator укажем wrapper с std::pair<const std::string, int> в качестве T.
Весь пример:


#include <map>
#include <string>
#include <iostream>

namespace foo
{

  template <class T>
  class wrapper
  {
    T& t_;
  public:
    wrapper(T& t) : t_(t) {}
    operator T&() const { return t_; }
  };

  std::ostream& operator<< (std::ostream& str,
    std::pair<const std::string, int> const& val)
  {
    str << val.first << " = " << val.second << std::endl;
    return str;
  }

} // namespace foo

int main()
{
  std::multimap<std::string, int> int_map;
  int_map.insert(std::make_pair("foo", 1));
  int_map.insert(std::make_pair("foo", 2));

  typedef foo::wrapper< std::pair<const std::string, int> > pair_wrapper;
  std::copy(int_map.begin(), int_map.end(),
    std::ostream_iterator<pair_wrapper>(std::cout));
}

Замечательно, все работает так, как и требовалось, а operator<< вынесен из пространства имен std!

Остается только уточнить небольшой ньюанс. Может появиться желание сделать wrapper еще более универсальным вынеся его в некоторое другое пространство имен, например common, для удобстра использования в случае повторного применения. В foo же при помощи typedef объявить псевдоним wrapper, инстанцируя его для конкретного типа.

Делать этого нельзя, поскольку поиск будет проведен только в пространстве имен в котором объявлен wrapper. Пространства имен его псевдонимов при поиске имен рассмотрены не будут.

Особенности поиска имен

2006-08-24T11:58:00.000+04:00

В предыдущем посте "Контейнеры с эквивалентным ключем" я упростил пример вывода на экран элементов multimap, добавив перегрузку operator<< в пространство имен std. Тем самым несколько покривил душой, ибо стандарт явно запрещает подобные эксперименты (см. 17.4.3.1).

Давайте еще раз взглянем на пример и выясним первопричину вынудившую меня так поступить.
Ключевые моменты примера из предыдушего поста:


namespace std
{

  std::ostream& operator<<(std::ostream& str,
    std::pair<std::string, int> const& val);

} // namespace std

int main()
{
  // ...
  std::copy(int_map.begin(), int_map.end(),
    std::ostream_iterator<
    std::pair<std::string, int> >(std::cout));
}

Как компилятор найдет перегрузку operator<< из примера? Ключевое слово - поиск имен: Ordinary Lookup (OL) и Argument-Dependent Lookup (ADL).

Согласно OL, встретив неквалифицированное имя, компилятор произведет поиск в той области видимости,в которой оно ему встретилось. В нашем случае это области видимости класса (class-scope) ostream_iterator, в operator= которого и вызывается перегружаемый нами operator<<, и пространство имен std, поскольку именно в нем находится объявление ostream_iterator.

Если компилятор не найдет подходящего operator<< согласно OL, поиск продолжится с использованием ADL. Несколько упрощая скажу, что ADL предполагает поиск имен в пространствах имен типов агрументов анализируемого выражения. Типами аргументами при вызове operator<< являются std::ostream и std::pair<>.
Другими словами поиск подходящего operator<< будет снова произведен в пространстве имен std.

Подитожу. Компилятор сможет найти перегрузку operator<< в области видимости класса ostream_iterator и пространстве имен std. Поскольку определение класса ostream_iterator мы изменить не в состоянии, остается только добавить перегрузку в std. Что я и сделал в примере.

В следующем посте я расскажу о том, как избежать внесения operator<< в пространство имен std.

Контейнеры с эквивалентным ключом

2006-08-14T17:45:00.000+04:00

Стоит помнить, что стандарт не дает гарантии перебора элементов с эквивалентным ключем в порядке их вставки в контейнер (multimap, multiset).
Т.е. тот порядок, в котором следующий код выведет на экран список элементов в multimap не определен, и зависит от вендора:


#include <map>
#include <string>
#include <iostream>

namespace std
{

  std::ostream& operator<<(std::ostream& str,
    std::pair<std::string, int> const& val)
  {
    str << val.first << " = " << val.second << std::endl;
    return str;
  }

} // namespace std

int main()
{
  std::multimap<std::string, int> int_map;
  int_map.insert(std::make_pair("foo", 1));
  int_map.insert(std::make_pair("foo", 2));

  std::copy(int_map.begin(), int_map.end(),
    std::ostream_iterator<
    std::pair<std::string, int> >(std::cout));
}

Некоторые вендоры дают подобную гарантию, тогда закладка на порядок перебора делает Ваш код хотя и корректным, но непереносимым.
К примеру код скомпилированный VS2005 c библиотекой STL по умолчанию, выводит на экран элементы в порядке их вставки к контейнер:


foo = 1
foo = 2

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

Указатель на функцию-член класса в качестве параметра шаблона класса

2006-08-10T23:47:00.000+04:00

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

Параметры типа
Параметры не являющиеся типами
Шаблонные параметры шаблонов

Сегодня я бы хотел остановиться подробнее на параметрах не являющихся типами.
Не так часто используемые, как параметры типа, они, тем не менее, позволяют создавать интересные конструкции.
Не являющиеся типами параметры - это константные значения, которые могут быть определены при компиляции или при компоновке.

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

Следующий пример демонстрирует технику использования указателя на функцию-член класса в качестве параметров шаблонов класса. Я поочередно приведу код каждого класса и функции примера:

Mutex - класс, представляющий некоторый объект межпроцессной синхронизации Mutex.
Его функции-члены позволяют захватить mutex (Lock) и освободить его (Unlock).


struct Mutex
{
  void Lock() {}
  void Unlock() {}
};

Locker - класс автоматического управления Mutex.
В конструкторе объект Mutex захватывается, а в деструкторе - освобождается.


struct Locker
{
  Locker(Mutex& m) : m_(m) { m_.Lock(); }
  ~Locker() { m_.Unlock(); }
  Mutex& m_;
};

Unlocker - класс автоматического управления Mutex обратный Locker.
В конструкторе объект Mutex освобождается, а в деструкторе - захватывается.


struct Unlocker
{
  Unlocker(Mutex& m) : m_(m) { m_.Unlock(); }
  ~Unlocker() { m_.Lock(); }
  Mutex& m_;
};

Использование симбиоза Mutex и Locker тривиально:


void foo(Mutex& m)
{
  Locker locker(m);
  // безопасный код;
}

А теперь вглядитесь в классы Locker и Unlocker. Их код не кажется вам похожим?
Если ли возможность обобщить код в некоторый шаблон класса и тем самым избежать дублирования?
Ответ - да. Воспользуемся указателями на функцию-член класса в качестве шаблона класса
Вот, чтополучается в итоге:

LockerT - шаблон класса, вызывающий в конструкторе функцию по адресу Do для переданного объекта типа Т, и вызывающий в деструкторе функцию по адресу Undo для этого же объекта.
void(T::*)(void) - тип функции-члена класса T, без параметров и возвращающая void.
Обратите внимание на дополнительные скобки при вызове функции-члена класса по указателю. Таков синтаксис подбных вызовов в языке.


template <class T, void(T::*Do)(void), void(T::*Undo)(void)> struct LockerT
{
  LockerT(T& m) : m_(m) { ((m_).*Do)(); }
  ~LockerT() { ((m_).*Undo)(); }
  T& m_;
};

Осталось только объявить типы локеров с конкретными аргументами.


typedef LockerT<Mutex, &Mutex::Unlock, &Mutex::Lock> Locker;
typedef LockerT<Mutex, &Mutex::Lock, &Mutex::Unlock> Unlocker;

И можно использовать как раньше:


void foo(Mutex& m)
{
  Locker locker(m);
  // безопасный код;
}

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

CriticalSection - класс, представляющий некоторый объект межпотоковой синхронизации
Его функции-члены позволяют войти в критическую секцию (Enter) и выйти из нее (Leave).


struct CriticalSection
{
  void Enter() {}
  void Leave() {}
};

Объявить локера для CriticalSection с помощью LockerT так же просто.


typedef LockerT<CriticalSection, &CriticalSection::Enter, &CriticalSection::Exit> CSLocker;

"The Most Important C++ Books...Ever" by Scott Meyers

2006-08-10T10:38:00.000+04:00

Статья Скота Мейерса The Most Important C++ Books...Ever.
В ней он приводит свою версию 5-ти наиболее важных книг по C++.
По мнению Мейерса это:

The C++ Programming Language by Bjarne Stroustrup
Effective C++ by Scott Meyers
Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
International Standard for C++
Modern C++ Design by Andrei Alexandrescu

Интересно, что за бортом остался Саттер

std::swap и ADL (часть 2, gcc)

2006-08-09T15:51:00.000+04:00

Вариант обхода ошибки gcc.

Судя по всему использование using std::swap в функции test, находящейся в области видимости foo просто скрывало (hide) объявление foo::swap. Следствием этой ошибки компилятора и был вызов std::swap вместо более подходящей foo::swap.
Решить проблему можно использованием using-directive вместо using-declaration.


void test()
{
  foo::bar<void> a, b;
  using namespace std; // вместо using std::swap;
  swap(a, b);
}

В приведенном выше коде gcc корректно вызывает именно foo::swap.
Вот такой workaround.

std::swap и ADL

2006-08-07T18:45:00.000+04:00

  В книге уважаемого мною автора Скота Мейерса "Эффективное использование С++" в правиле 25 даются рекомендация по использованию std::swap.
Это очень правильные рекомендации, им стоит придерживаться. Вот только жизнь часто вносит свои коррективы в теорию.
  Мейерс рассуждает о возможных действиях, когда необходимо как бы частично специализировать std::swap. "Как бы" из-за того, что частичная специализация функций в C++ и перегрузка функций в std:: запрещена стандартом.
  Что же делать, рассуждает он, если по-прежнему нужен способ, чтобы разрешить другим людям вызывать swap и иметь более эффективную шаблонную версию?

  В результате он принимает решение об объявлении функции swap в той же области видимости что и тип, являющийся ее аргументом. Вызов swap же не квалифицировать и поместить перед ним объявление using std::swap. Когда компилятор встречает вызов swap, он ищет, какую версию вызвать.


namespace foo
{
  template <class T> class bar {};
  template <class T> void swap(bar<T>&, bar<T>&) {}
}

void test()
{
  foo::bar<void> a, b;
  using std::swap;
  swap(a, b);
}

  Следуя правилам разрешения имен в С++ (используется ADL) будет найдена шаблонная функция foo::swap. При ее отсутствии будет вызвана шаблонная функция std::swap.
Стандарт 3.4.2 стих 2а.

  Итак, казалось бы жизнь прекрасна, проблема решена. Но не тут то было. Чудовищные нюансы поджидают нас в компиляторе gcc. Стоит лишь поместить функции test в ту же область видимости что и swap (в примере foo) и код сгенерированный gcc вызовет std::swap вместо foo::swap.
  Явная бага компилятора. Разработчики gcc же отвечают крайне невнятно. В последней версии gcc (на данный момент это 4.1.0) проблема по прежнему осталась.

Так что острожнее.
Beware of bugs.