Passing values to a function

"Стандартный" способ передать N значений типа T на C:

void foo(T* values, int N);

Стандартное решение для C++:

template <typename it_t>
void foo(it_t first, it_t last);

Ну, если у нас есть vector<string> и foo() работает с string - то все тривиально. Засада если у нас все лежит как-нибудь не так, например в map<int,string> или в каком-нибудь vector<Object>, у которого нужно вызвать Object::GetString() для каждого элемента. А если еще и не все значения подряд нужны?

Можно, конечно, в цикле перегнать нужные значения в отдельный контейнер, и уже дальше передать его. Но мало того, что это не путь настоящих джедаев C++-программистов, так еще и кучу процессорного времени потеряем да и памяти заодно.

Тут стоит вспомнить, что умные дядьки уже подумали о нас, написали нужные адаптеры для итераторов, и запихнули все это в boost. Так, transform iterator достанет нам строку из pair<int,string> или Object::GetString(), а filter iterator отфильтрует нам элементы на ходу.

std::equal_to

С удивлением обнаружил, что std::equal_to и сотоварищи объявлены так:

template<class _Ty>
    struct equal_to
        : public binary_function<_Ty, _Ty, bool>
    {    // functor for operator==
    bool operator()(const _Ty& _Left, const _Ty& _Right) const
        {    // apply operator== to operands
        return (_Left == _Right);
        }
    };

Я-то наивно полагал, что должно быть как-то так:

template<class T1, class T2 = T1>
struct EqualTo : public std::binary_function<T1, T2, bool>
{
    bool operator()(typename boost::call_traits<T1>::param_type Left,
        typename boost::call_traits<T2>::param_type Right) const
    {
        return Left == Right;
    }
};

Multithreading: Messages

Хорошие языки учат хорошим манерам, но это не мешает использовать эти манеры не только в этих самых хороших языках. (Умные указатели тому пример.)

Многопоточность в C++ - довольно нетривиальная вещь, так как сам язык не дает (пока) абсолютно ничего для этого. Типичная подход - защита совместно используемых объектов критическими секциям. При неаккуратном обращении с ними недалеко до простоя потоков, а иногда и до deadlock-ов.

Как в свое время все вызовы new/delete упаковали в умные указатели, можно так же поступить и с критическими секциями, оставив для общения потоков такой вот простой интерфейс:

template <typename T>
void SendMessage(Thread, std::auto_ptr<T> Message);

(можно отказаться от шаблона в пользу IMessage вместо T - это на свой вкус и цвет).

Послали сообщение - и бежим дальше, никаких лишних простоев.

PS. Почему auto_ptr, а не копия объекта: не всегда нужна копия, часто сообщение готовится только для того чтобы быть посланным - нет смысла делать оверхед в виде копии. А уж если нужна копия, то все просто:

SendMessage(SomeThread, Сlone(Message));

(или Message.Сlone(), у кого как)

Quick way or right way

Бывало ли у вас так, что можно сделать:
а) как проще
б) как правильно?

У меня - постоянно ;) Примеров - хоть отбавляй. Одна из наиболее частых ситуаций: добавление нового атрибута (member-а) к объекту.

Как это выглядит:

class Object { ... };

class ObjectUser1
{
  void UseObject(Object&);
  Object ReturnObject();
  std::container<Object> SomeMember_;
};

class ObjectUser2...

И тут для конкретной задачи UserOfObjectUser1 требуется чтобы Object еще имел, например, и атрибут Name:

class Object
{
  ... здесь то, что было...

  // добавляем
  void SetName(NameType);
  NameType Name() const;
  NameType Name_;
};

Хочется думать, что Name - очень полезный атрибут для Object, и он ему совсем не помешает. Хотя предыдущим ObjectUser-ам (и user-ам этих user-ов) он вообще не нужен, но они при новой компиляции ничего и не заметят. А думать так хочется потому как альтернатива этому - такова:

class ObjectWithName : public Object
{
  ObjectWithName(A a) : Object(a) {}
  ObjectWithName(B b, C c) : Object(b, c) {}
  ObjectWithName(D d) : Object(d) {}
  ...
  ... сколько еще там у Object конструкторов?
  ... и не забыть добавить сюда новый конструктор если появится у Object
  ...
  ObjectWithName(const Object& o) : Object(o) {}

  void SetName(NameType);
  NameType Name() const;
  NameType Name_;
};

Да еще ObjectUser1 придется делать шаблонным - чтобы мог работать как с Object, так и с ObjectWithName.

Но если сделать как проще, а не как правильно - последствия дадут знать о себе потом. Вот пример:

class File
{
  string Name;
  int Size;
  vector DiskSectors;
  void Read(...);
  void Write(...);
}

Хотя файл по определению - именованная область на диске, но Name явно здесь лишнее. Точнее - лишнее все, кроме Name. Не верите? Попробуйте создать hard link ;)

Истина где-то рядом:

class DiskArea
{
  int Size;
  vector<int> DiskSectors;
  void Read(...);
  void Write(...);
};

class File
{
  string Name;
  shared_ptr<DiskArea> Area;

  // адаптеры - расплата за правильный дизайн
  void Read(...) { Area->Read(...); }
  void Write(...) { Area->Write(...); }
};

Function overloading vs template specialization

Перегрузка функций работает отлично со времен plain C. Пример:

Foo.h:

void Foo(bool);
void Foo(int);
void Foo(const char*);

Foo.cpp:

void Foo(bool) { ... }
void Foo(int) { ... }
void Foo(const char*) { ... }

Test.cpp:

#include "Foo.h"

void Test()
{
    bool b(true);
    int i(10);
    const char *c("hello");

    Foo(b);
    Foo(i);
    Foo(c);

    Foo(*c); // хм... компилируется!

    shared_ptr<int> p;
    Foo(p); // тоже компилируется
}

Неприятность доставляет тип bool, к которому конвертируются многие другие типы. Например, можно забыть разыменовать [умный] указатель, и компилятор нам ничего не подскажет.

Все было бы замечательно, если бы можно было написать void Foo(explicit bool);, но ведь в случае параметра функции explicit не прокатит...

Выход - вместо перегрузки функций использовать специализацию шаблонов. Правим Foo.h:

template <typename T> void Foo(T);
template <> void Foo(bool);
template <> void Foo(int);
template <> void Foo(const char*);

Кстати, у меня под Visual C++ 2005 не пришлось даже менять и/или перекомпилировать Foo.cpp - сингатуры функций в объектных файлах для template <> void Foo(xxx) и void Foo(xxx) видимо совпадают.

Теперь Foo(*c) и Foo(p) из приведенного выше примера не пройдут - линкер скажет, что не нашел определений нужных символов. Можно попросить ругаться не линкер, а компилятор, добавив немного кода в первую строчку Foo.h:

template <typename T> void Foo(T) { typename T::IncorrectParameterType; }

Из минусов такого подхода - все вызовы Foo() требуют теперь точного указания типа параметра:

class ConvertableToInt
{
public:
    operator int() { return 0; }
};
Foo(ConvertableToInt()) // теперь так не получится :(
Foo(static_cast<int>(ConvertableToInt())) // только так;

Если такие минусы не устраивают - придется идти на более радикальные меры, например разделить реализации bool и не-bool на функции с разными именами. Интерфейс при этом останется тот же - Foo(x):

Новый Foo.h:

template <typename T> void Foo(T t) { FooImpl(t); }
void Foo(bool);
void FooImpl(int);
void FooImpl(const char*);

Новый Foo.cpp:

void Foo(bool) { ... }
void FooImpl(int) { ... }
void FooImpl(const char*) { ... }

ADO::Recordset::Seek()

Изменить (или удалить) несколько записей в ADO::Recordset, источником которого служит база данных Microsoft Jet, можно довольно понятным подходом:
1. открывается нужная таблица в виде ADO::Recordset (с CursorLocation = adUseServer)
2. задается индекс, по которому будут отыскиваться записи
3. вызывается Seek() для быстрого переходу по ключу индекса
4. выполняется Update() (или Delete())
повторить п.п.3-4 нужное количество раз
5. закрыть открытый ADO::Recordset

Самое удивительное, что когда источник - MS SQL Server, такой подход не прокатит. Дело в том, что его провайдер SQL сервера не поддерживает метод Seek(). В инете миллион вопросов почему "оно" не работает. Ответ печальный: by design.

Я было заменил Seek() на Find() и расслабился. Понятное дело, ненадолго. На реальных данных все это жутко затормозило и понятное дело почему. Когда в таблице миллион записей, ждать Find() приходится очень долго - тупой перебор записей оказывается штукой довольно тормознутой.

Но ведь индекс-то есть, и нужно использовать его. И раз Seek() не работает, выход один - открывать на каждую запись свой рекордсет вида "Select * From [Table] Where [KeyField]=KeyValue". Не забываем Recordset->CursorLocation = adUseServer.

Integer division with rounding

Понадобилось мне целочисленное деление с округлением результата (точнее не целочисленное, а с фиксированной точкой - но суть-то, как известно, одна). "С округлением" - это когда 10/3=3, а 20/3=7.

С математикой у меня туго, поэтому написал это дело так:

__int64 RoundedDivision(__int64 Dividend, __int64 Divisor)
{
    __int64 DoubleResult = (Dividend << 1) / Divisor;
    return ((DoubleResult < 0) ? DoubleResult : (DoubleResult + 1)) >> 1;
}

Однако не покидает мысль что можно написать как-то попроще.

PS. Заодно немного потормозил над тем, что при отрицательном знаке DoubleResult не нужно вычитать единичку. Видимо совсем забыл как считать в дополнительном коде.

Policy-based programming

Александреску в своей книге "Современное проектирование на С++" заразил меня тем, что он называет policy-based class design - разработка класса на основе его составляющих - "политик". Примером может являться умный указатель: при разработке обобщенного умного указателя можно не догадываться как именно конечному программисту потребуется от умного указателя:
а) управлять памятью (выделять память, удалять...),
б) реализовывать "владение" объектом (разделять одно значение, копировать...),
в) проверять значение указателя на правильность инициализации (через assert или исключения...),
г) ...

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

Так вот эту же замечательную идею можно легко использовать не только в статике (шаблоны), а и в динамике. Идея такова: для нужных стратегий (policy) пишете интерфес и храните в своем классе указатель (умный, разумеется) на объект этого интерфейсного класса.

Пример:

template <class StoragePolicy, class OwnershipPolicy>
class StaticPolicyDemo
{
    void Delete()
    {
        if (OwnershipPolicy::IsDeletable())
            StoragePolicy::Delete(ptr);
    }
    ...
};

class DynamicPolicyDemo
{
    class IStoragePolicy
    {
        virtual void Delete(Object*) = 0;
        ...
    };
    class IOwnershipPolicy
    {
        virtual bool IsDeletable() = 0;
        ...
    };

    void Delete()
    {
        if (_OwnershipPolicy->IsDeletable())
            _StoragePolicy->Delete(ptr);
    }

    DynamicPolicyDemo(PStoragePolicy StoragePolicy, POwnershipPolicy OwnershipPolicy) :
        _StoragePolicy(StoragePolicy), _OwnershipPolicy(OwnershipPolicy)
    {
    }

    void SetStoragePolicy(PStoragePolicy StoragePolicy)
    {
        _StoragePolicy = StoragePolicy;
    }

    void SetOwnershipPolicy(POwnershipPolicy OwnershipPolicy)
    {
        _OwnershipPolicy = OwnershipPolicy;
    }

    typedef std::auto_ptr<IStoragePolicy> PStoragePolicy;
    typedef std::auto_ptr<IOwnershipPolicy> POwnershipPolicy;
    PStoragePolicy _StoragePolicy;
    POwnershipPolicy _OwnershipPolicy;
};

Такая конструкция очень полезна, когда нужно в run-time менять части поведения некоторого объекта. Например, графического контрола Grid это может быть: а) внешний вид графического элемента (skin), б) источник записей, в) фильтр записей, и др. Если часто используются типовые policy, то для их хранения логично использовать shared_ptr (вместо auto_ptr, приведенного в примере).

Default window procedure

При обработке оконных сообщений типичная ситуация такова: обработал сообщение, вернул значение. А если не обработал - тогда уж оно пойдет в DefWindowProc() / DefMDIChildProc (). Оказывается, такой алгоритм не всегда верен.

Например, если не передать WM_SIZE в DefMDIChildProc() для MDI-child окна, то при максимизации этого окна пользователь не сможет восстановить его размер - у окна не будет кнопок minimize и restore (обычно они появляются с правой стороны полосы меню mdi parent-а).

Как мне кажется, общее правило для обработки событий лучше иметь таким: если обработал сообщение, но не нужно ничего возвращать (как в случае уведомительных сообщений типа WM_SIZE) - лучше передать сообщение дальше по цепочке обработчиков. В WTL это можно сделать так:

LRESULT WindowClass::OnSize(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
{
    do stuff;

    return bHandled = 0; // сбрасываем флаг bHandled
}

Hash calculation

Как правильно заметил Not a kernel guy, лишний раз бросаться исключениями не стоит. Если знаешь как обработать ошибку - обработай ее сразу. Не знаешь - брось исключение, "на верху" разберутся.

В качестве примера - код получения хэша. В фокусе - вызов CryptGetHashParam:

#include <windows.h>
#include <Loki/ScopeGuard.h>
#include <boost/range/size.hpp>
#include <boost/static_assert.hpp>
#include "TestWinFn.h"

template <class TOutputContainer, typename TInputContainer>
void Hash(ALG_ID Algorithm, const TInputContainer& Input, TOutputContainer& Output)
{
    BOOST_STATIC_ASSERT(sizeof(typename TOutputContainer::value_type) == sizeof(BYTE));

    HCRYPTPROV hProv = 0;
    TestWinFn(CryptAcquireContext(&hProv, NULL, NULL, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT));
    LOKI_ON_BLOCK_EXIT(CryptReleaseContext, hProv, 0);

    HCRYPTHASH hHash = 0;
    TestWinFn(CryptCreateHash(hProv, Algorithm, 0, 0, &hHash));
    LOKI_ON_BLOCK_EXIT(CryptDestroyHash, hHash);

    TestWinFn(CryptHashData(hHash, reinterpret_cast<const BYTE*>(&Input[0]),
        static_cast<DWORD>(boost::size(Input) * sizeof(Input[0])), 0));

    DWORD HashSize = 0;
    DWORD Error = CryptGetHashParam(hHash, HP_HASHVAL, NULL, &HashSize, 0) ? 0 : ::GetLastError();
    if ((Error == ERROR_MORE_DATA) || (!Error && HashSize))
    {
        Output.resize(HashSize);
        TestWinFn(CryptGetHashParam(hHash, HP_HASHVAL, &Output[0], &HashSize, 0));
    }
    else
        throw WindowsError(Error);
}

Windows exceptions

Функции WinAPI сообщают об ошибках в C-стиле - через коды ошибок. Классика C++ - сообщать об ошибках через исключения. Достаточно обернуть вызов функции в специальный "адаптер", и брюки превращаются в элегантные шорты:

#include <comdef.h>

inline void TESTHR(HRESULT hr)
{
    if (FAILED(hr))
        _com_issue_error(hr);
};

...
TESTHR(::CoCreateGuid(&UniqueID));

Типичный адаптер для обработки ошибок COM. Не помешает иметь такой же адаптер для не-COM функций:

#include <windows.h>

inline void TestWinFn(BOOL WindowsFunctionResult)
{
    if (!WindowsFunctionResult)
        throw WindowsError(::GetLastError());
}

...
TestWinFn(::ConvertSidToStringSid(SID, &StringSID));

Единственное - не хватает того самого класса WindowsError.

#include <windows.h>
#include <exception>
#include <Loki/ScopeGuard.h>

class WindowsError : public std::exception
{
public:
    WindowsError(DWORD ErrorCode = ::GetLastError())
        std::exception(Message(ErrorCode).c_str()),
        _ErrorCode(ErrorCode) {}

    DWORD ErrorCode() const { return _ErrorCode; }

private:
    static std::wstring Message(DWORD ErrorCode)
    {
        std::wstring Result;
        LPVOID Buffer = NULL;

        if (::FormatMessage( 
            FORMAT_MESSAGE_ALLOCATE_BUFFER | 
            FORMAT_MESSAGE_FROM_SYSTEM | 
            FORMAT_MESSAGE_IGNORE_INSERTS,
            NULL,
            ErrorCode,
            0, // Default language
            (LPTSTR) &Buffer,
            0,
            NULL))
        {
            LOKI_ON_BLOCK_EXIT(LocalFree, Buffer);
            Result.assign((LPCWSTR)Buffer);
        }

        return Result;
    }

private:
    DWORD _ErrorCode;
};

PS. Кто не использует Loki - сюда.

WTL's cracked handlers

До чего же мне нравится идея "cracked handlers" в WTL, но вот реализация...

Идея cracked handlers такова. Обработчики оконных событий в WTL выглядят так:

class SomeWindowImpl
{
    BEGIN_MSG_MAP(SomeWindowImpl)
        MESSAGE_HANDLER(WM_LBUTTONDOWN, OnLButtonDown)
        MESSAGE_HANDLER(WM_SIZE, OnSize)
    END_MSG_MAP()

    LRESULT OnLButtonDown(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
    LRESULT OnSize(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
};

Потом приходится копаться в MSDN и выковыривать из wParam и lParam нужную информацию. Идея cracked handlers проста - сделать все по-человечески:

class SomeWindowImpl
{
    BEGIN_MSG_MAP(SomeWindowImpl)
        MSG_WM_LBUTTONDOWN(OnLButtonDown)
        MSG_WM_SIZE(OnSize)
    END_MSG_MAP()

    LRESULT OnLButtonDown(UINT nFlags, CPoint Point);
    LRESULT OnSize(UINT nType, CSize Size);
};

Все бы было нормально, если не видеть как реализованы все эти MSG_WM_xxx:

#define MSG_WM_LBUTTONDOWN(func) \
  if (uMsg == WM_LBUTTONDOWN) \
  { \
    SetMsgHandled(TRUE); \
    func((UINT)wParam, CPoint(GET_X_LPARAM(lParam), GET_Y_LPARAM(lParam))); \
    lResult = 0; \
    if(IsMsgHandled()) \
      return TRUE; \
  }

#define MSG_WM_SIZE(func) \
  if (uMsg == WM_SIZE) \
  { \
    SetMsgHandled(TRUE); \
    func((UINT)wParam, CSize(GET_X_LPARAM(lParam), GET_Y_LPARAM(lParam))); \
    lResult = 0; \
    if(IsMsgHandled()) \
      return TRUE; \
  }

Посмотришь на них - и начинаешь задумываться: что произойдет быстрее - появятся мониторы с 33 тыс.точек по горизонтали (или вертикали), или люди перестанут пользоваться программой, которую ты пишешь. Я, конечно, про GET_x_LPARAM - они работают до поры до времени, позже все же придется воспользоваться GetClientRect() и GetMessagePos(). Или не придется?... ;) Попробуй угадай.

А иногда там встречаются менее заметные вещи, типа использования unsigned вместо signed. Сразу и не догадаешься. Вобщем, в результате:

// #include <atlcrack.h>

Trim

Всегда было интересно - почему реализации функции trim либо изменяют исходную строку, либо генерируют новую? Ведь результат функции - это подстрока, а ее можно задать парой итераторов. Тогда не потребуется никакого лишнего копирования:

template <typename TStringIterator>
std::pair<TStringIterator, TStringIterator> Trim(
    TStringIterator Begin, TStringIterator End,
    const std::locale& Locale = std::locale())
{
    std::pair<TStringIterator, TStringIterator> Result(
        ::boost::algorithm::detail::trim_begin(Begin, End, boost::is_space(Locale)),
        ::boost::algorithm::detail::trim_end(Begin, End, boost::is_space(Locale)));
    if (Result.first > Result.second)
        Result.first = Result.second;
    return Result;
}

PS. Вместо std::pair можно вернуть boost::iterator_range.

Fixed point arithmetics

Почему-то в Boost-е до сих пор нет арифметики с фиксированной точкой. Была предложена подобная библиотека, но ее завернули, попросив автора немного доработать библиотеку. А автор на это забил. Поэтому приходится изобретать очередные велосипеды. Что-то типа такого:

template <unsigned Precision = 8, typename Integer = int>
class Fixed
{
public:
    Fixed() {}
    Fixed(Integer Value) : _Value(Value << Precision) {}
    Fixed& operator +=(Fixed rhs) { _Value += rhs._Value; return *this; }
    Fixed& operator +=(Integer rhs) { _Value += (rhs << Precision); return *this; }
    Fixed operator /(Integer rhs) { return Fixed(_Value / rhs, RawValue); }
    Integer Int() { return _Value >> Precision; }
    Integer Round() { return (_Value + (1 << (Precision - 1))) >> Precision; }

private:
    enum ERawValueFlag { RawValue };
    Fixed(Integer Value, ERawValueFlag) : _Value(Value) {}

private:
    typename Integer _Value;
};

Reporting system на скорую руку

Задача: написать систему генерации и просмотра отчетов для некого бизнес-приложения
Исходные данные: данные из базы SQL

Решение:
1. Используем контрол, умеющий показывать некие XML-файлы. Например, внешний или встроенный в нашу программу веб-браузер.
2. Получаем с сервера SQL данные в виде XML.
3. С помощью XSLT преобразуюем данные в формате п.2 в формат для п.1 (например, XHTML).
4. Рендерим полученный в п.3 отчет в нашем контроле из п.1.
Готово.

Описание каждого отчета имеет вид:
а) команды для SQL-сервера
б) XSLT файл

Writing a calculator

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

Сейчас пишу вычисление формул, вспоминаю тот калькулятор ;) Задача сейчас такова: есть описание GUI в XML в виде
<control
  name="Button1"
  x="100"
  y="200"
  width="300"
  height="400"
/>

Необходима возможность понимать такие выражения:
<control
  name="Button1"
  x="Button2.x + 100"
  y="Form.height - 200"
  width="Form.width - (Button3.width*2 + 100)"
  height="400"
/>
И чтобы при resize окна (изменении пользователем размеров формы) пересчитались все зависимые от размеров формы координаты.

Как решалась задача:
1. Парсим каждую формулу на лексемы (операнды, операторы и скобки) - получаем выражение в инфиксной форме.
2. Переводим инфиксную форму в постфиксную.
3. Заменяем имена переменных (типа "Form.width" и "Button2.x") на указатели на них.
4. Одна формула может ссылаться на другую, та - на третью, четвертая - на первую и т.п. Поэтому топологической сортировкой выясняем порядок вычисления формул.
5. Вычисляем формулы по порядку, вычисленному в п.4. Формулы в постфиксной форме вычисляются очень просто и быстро.

При изменении размеров формы выполняем только п.5, причем можно вычислять не все формулы, а только прямо или косвенно зависимые от размеров формы.

PS. А мой первый калькулятор был гораздо проще - состоял всего из трех INPUT-ов и четырех IF-ов (на каждый поддерживаемый оператор).

Is it simple to write text editor for Windows?

Казалось бы - насколько просто написать небольшой текстовый редактор для Windows?

Вот очень интересный tutorial на эту тему: Design and Implementation of a Win32 Text Editor. Автор описывает как решать ту огромную кучу нюансов, с которыми приходится столкнуться: unicode, разные направления письма, большие тексты, переменная скорость прокрутки при выделении мышью и многое другое.

Жаль, автор не закончил сей труд. Но возможно он еще продолжит.

PS. Там же на сайте можно найти еще много интересного по Windows programming.

`this' is just an ordinary pointer

Как вы думаете, насколько надежна такая конструкция:

int Bar();
class Foo
{
    int x;
public:
    void y()
    {
        x = Bar();
    }
};

На первый взгляд все отлично. До тех пор, пока не увидим всю картину:

Foo* foo;
int Bar()
{
    if (...) delete foo;
    return ...;
}
void Main
{
    foo = new Foo();
    foo->y();
}

Ситауция представлена здесь довольно утрированно, но суть понятна: мембер-функция Foo::y() вызывает другую функцию Bar(), которая удаляет объект. Тот самый объект, который Foo::y() знает как this. Далее Foo::y() пытается записать что-то в this->x, который уже не существует.

Реальна ли такая ситуация, или это ошибка архитектуры? Думаю, такая ситуация вполне может иметь место. Ведь мы давно свыклись с тем, что после vector::push_back() может привести в негодность все наши итераторы на этот вектор, и к другим подобным ситуациям. Нужно просто при вызове функции (в нашем случае Bar()) знать, что this может стать недействительным.

Такая ситуация может возникнуть, например, если элементы GUI (controls) реализованы как объекты (привет WTL):

void Button::OnClick()
{
    Dialog.Close();
    // this больше недействителен!
}

Вобщем, this - это такой же обычный указатель, и логично сделать его умным указателем. Пусть сам о себе заботится.

class Foo : public boost::enable_shared_from_this<Foo>
{
    int x;
public:
    void y()
    {
        boost::weak_ptr<Foo> This(shared_from_this());
        int bar = Bar();
        if (!This->expired()) x = bar;
    }
};

boost::shared_ptr<Foo> foo;
int Bar()
{
    if (...) foo.reset();
    return ...;
}

Smart pointer with copy semantic

Умные указатели - вещь полезная не только для уменьшения кода, но и отсутствием головной боли с удалением объектов. Например, следующий класс легко положить в контейнер, для него можно не переопределять копирующий конструктор и оператор присваивания:

class Foo
{
    std::vector<Bar> A;
    boost::shared_ptr<Bar> B;
};

Члены A и B сами позаботятся о своем копировании: A сделает deep copy своего содержимого в новый объект, B будет вести подсчет ссылок.

Однако, почему-то в популярных (STL и boost) библиотеках нет умного указателя, аналогичного shared_ptr, но не с подсчетом ссылок, а с глубоким копированием. То есть чтобы он указывал на один (или ноль, если SmartPointer=NULL) объект, а не как vector - на массив. Подходящий указатель есть в Loki, благо там все разбито по стратегиям и можно задать любую стратегию копирования (подсчет ссылок, глубокое копирование, ...). Однако лишний раз иметь зависимость от Loki не всем удобно. Писать свой велосипед - еще менее удобнее. Компромисный вариант: использовать std::vector, кладя в него не больше одного элемента. Звучит смешно, но работает.

mutable

Интересно, почему не все понимают смысл и полезность ключевого слова mutable. Истинная его ценность состоит в том, чтобы дать возможность в const member-функциях производить такие изменения в объекте, которые не видны снаружи. Все, что видно "снаружи" пользователям объекта - это то, что можно получить через публичный интерфейс. Это нужно для кэширования и ленивых вычислений.

Например, мы пишем адаптер, позволяющий приводить строки типа const char* и std::string к единому интерфейсу вида Data, Size. Для const char* размер можно расчитать через strlen() сразу (не важно, потребуется нам результат вычислений или нет), но можно сделать это только если понадобится:

class StringAdapter
{
public:
    explicit StringAdapter(const std::string& String) :
        _Data(String.data()), _Size(String.size()), _SizeCached(true) {}

    explicit StringAdapter(const char* String) :
        _Data(String), _SizeCached(false) {}

    const char* Data() const { return _Data; }

    size_t Size() const
    {
        if (!_SizeCached) { _Size = strlen(_Data); _SizeCached = true; }
        return _Size;
    }

private:
    const char* _Data;
    mutable size_t _Size;
    mutable bool _SizeCached;
};

Без mutable мы бы не смогли внутри Size(), объявленной как const, модифицировать наш кэш.