Задать поведение компилятора.

[sss]

Здравствуйте.

Есть код автобуфера

Код: (C++)

template <typename _T, AutoReleaseMode arm = armMemFree>
class auto_buf
{
protected:
   _T*                        m_ptr;
   mutable bool               m_fConst;

public:
  //-----------------------------------------------------------------------------
 explicit auto_buf( const _T* ptr) : m_ptr( const_cast<_T*>( ptr)), m_fConst( true)
 {
 };
  //-----------------------------------------------------------------------------
 explicit auto_buf( _T* ptr = NULL) : m_ptr( ptr), m_fConst( false)
 {
 };
 //-----------------------------------------------------------------------------
 ~auto_buf( )
 {
   free();
 }

С двумя конструкторами. Когда надо чтобы буфер не удалял при выходе из зоны видимости вызывается конструктор
(const _T*), когда надо чтобы удалял (_T*).
Теперь вот ситуация.

Код: (C++)

typedef  auto_buf<TCHAR>     tchar_a;

{
  TCHAR* p = (TCHAR*) 0xFEEDBABA;//не важно
  bool   fFlag = true; //не важно
  tchar_a b( fSome ? (TCHAR*) p : (const TCHAR*) p);
}

При любой ситуации вызывается конструктор const _T*.
Как мне поступить для исключения такого кода? Просто "не делай так"?
Или может кто-нибудь знает что можно придумать? Пусть он не компилируется
с какой нибудь ошибкой. Но как это сделать?
Атрибут explicit спокойно пропускается компилятором (BDS 2006).

[Вад]

Насколько понимаю, здесь компилятор берёт два типа возвращаемого значения в ?: и выводит общий тип, оказывающийся константным.
Может, с копирующим конструктором сработает? В духе:

Код: (C++)

tchar_a b = fSome ? tchar_a(p) : tchar_a((const TCHAR*) p);

но пока не проверял.

[sss]

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

Код: (C++)

auto_buf( _T* ptr, bool bConst)

Т.е. явное управление константным признаком..

[Вад]

sss, тут, наверное, Александреску в помощь Думается, если подшаманить с шаблонным базовым типом, то можно на этапе компиляции создавать автобуфер с константным или не-константным содержимым, то есть, чтобы, условно, auto_buf<Type*> и auto_buf<const Type*> - это были два разных типа на этапе компиляции, и у каждого своя стратегия для деструктора.
По идее, должно быть реализуемо: нужно лишь сделать статический assert для проверки, что тип является указателем, а далее в конструктор принимать параметр Type, а не Type*.

[Алексей++]

template <typename _T, AutoReleaseMode arm = armMemFree, bool bConst=true>

м ?

[Dimka]

Единственное, чего я не понимаю, так это области применения такого типа. Выглядит он уж очень узкофункциональным.

По-хорошему, это 2 класса, реализующих единый интерфейс: один класс обеспечивает очистку буфера, другой - нет. И конечно, константность значения в общем случае не коррелирует с необходимостью очистки.

А ещё лучше отделить собственно буфер (как объект, сам выделяющий и освобождающий используемую память) от ссылки на буфер - вспомогательного объекта, дающего лишь точку доступа к буферу. Буфер заодно может считать ссылки или же управлять состоянием ссылок (valid, когда буфер жив, invalid, когда буфер уже уничтожен).

Чем-то похожую пару образуют коллекция и её итераторы.

[sss]

Единственное, чего я не понимаю, так это области применения такого типа. Выглядит он уж очень узкофункциональным.
...

Всё верно.
Моё личное убеждение - шаблонные классы могут применяться только как узкофункциональные объекты...
Естественно я показал не все методы класса. Там ещё оператор присваивания указателю на тип есть.
А применяется, например, в функциях в которых вызывающая сторона или предоставляет буфер или нет.
Например в потокобезопасной функции преобразования числа в строку..

Код: (C++)

char_a StrFromLongA( long val, char* buf, long radix)  throw ( ELowResources*, ESystemError*)
{
  char_a res ((const char*) buf);
  if ( buf == NULL)
    res = StrAllocA( STRDEF_CCH_FOR_LONG);
  Str32ToA((unsigned long) val, res, radix, ( radix == 10) && ( val < 0));
  return res;
}

Я нисколько не призываю всех делать также. Просто вдруг понял что есть вот такой "side effect"
без использования макросов и ни хотел бы случайно где нибудь допустить утечки.
Решил спросить - не знает ли кто как это сделать?

template <typename _T, AutoReleaseMode arm = armMemFree, bool bConst=true>

м ?

Не, так наверное не пойдет. Думаю возникнет та же коллизия но уже при инстацировании..
Да и вообще это уже слишком сложно для меня  Я лучше тогда заменю такой класс на класс
без шаблонов  .

[sss]

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

Сейчас перечитал пост в пятый раз и наконец то увидел эти строки.  А то после строк
"Выглядит он уж очень узкофункциональным."
даже дальше не читал получается    - кинулся писать ответ.

Да именно также и я думаю!!! Этот код автобуфера написан лет 9 назад. В течении прошедшего
времени я давно уже перешел на подсчёт ссылок в управлении временем жизни объектов, а вот
этот код не трогал. Он работал да работал.