Russian Qt Forum

Программирование => С/C++ => Тема начата: Igors от Июль 14, 2013, 14:36



Название: Scoped
Отправлено: Igors от Июль 14, 2013, 14:36
Добрый день

Код
C++ (Qt)
MyOpaqueRef * ref = CreateOpaqueRef(name);
....
// return; ???
...
DestroyOpaqueRef(ref);
 
К сожалению, в теле я не могу удобно выскакивать return'ом, т.к. обязан сделать DestroyOpaqueRef. Возвращаемый ref по существу handle, он не имеет delete. Я могу его "обернуть" во что-то зовущеее Destroy в деструкторе, но выходит накладно/длинновато. А есть ли способ короче/выразительнее?

Спасибо  


Название: Re: Scoped
Отправлено: kambala от Июль 14, 2013, 14:45
можно попробовать через макрос:
Код
C++ (Qt)
#define RETURN_AND_DELETE_REF(ref) DestroyOpaqueRef(ref); return
 
MyOpaqueRef * ref = CreateOpaqueRef(name);
...
RETURN_AND_DELETE_REF(ref);
...
RETURN_AND_DELETE_REF(ref) 0;

или покрасивее, чтобы нормально возвращаемое значение передать (точно не помню только как правильно __VA_ARGS пишется):
Код
C++ (Qt)
#define RETURN_AND_DELETE_REF(ref) DestroyOpaqueRef(ref, ...) DestroyOpaqueRef(ref); return __VA_ARGS
 
MyOpaqueRef * ref = CreateOpaqueRef(name);
...
RETURN_AND_DELETE_REF(ref);
...
RETURN_AND_DELETE_REF(ref, 0);


Название: Re: Scoped
Отправлено: Old от Июль 14, 2013, 14:50
Я могу его "обернуть" во что-то зовущеее Destroy в деструкторе, но выходит накладно/длинновато.
Покажите пожалуйста свой код. Не представляю, что там может быть длинно и накладно.


Название: Re: Scoped
Отправлено: Old от Июль 14, 2013, 14:51
можно попробовать через макрос:
А что это даст?
Разрушаться объект все равно не будет при выходе из области видимости.


Название: Re: Scoped
Отправлено: m_ax от Июль 14, 2013, 14:56
Использовать, например std::unique_ptr. Ему можно задать пользовательский делитер..
http://en.cppreference.com/w/cpp/memory/unique_ptr (http://en.cppreference.com/w/cpp/memory/unique_ptr)

 


Название: Re: Scoped
Отправлено: kambala от Июль 14, 2013, 15:08
можно попробовать через макрос:
А что это даст?
Разрушаться объект все равно не будет при выходе из области видимости.
просто при выходе из области видимости — не будет, придется руками вызывать DestroyOpaqueRef(), а при выходе из функции — будет. если функция возвращает void, то придется в конце дописывать либо DestroyOpaqueRef() либо макрос.


Название: Re: Scoped
Отправлено: Igors от Июль 14, 2013, 15:27
Покажите пожалуйста свой код. Не представляю, что там может быть длинно и накладно.
Код
C++ (Qt)
struct CScoped_OpaqueRef {
CScoped_OpaqueRef( OpaqueRef * ref ) : mRef(ref) {}
      ~CScoped_OpaqueRef( void ) { if (mRef) DestroyOpaqueRef(mRef); }
operator OpaqueRef * ( void ) { return mRef; }
 
void operator = ( OpaqueRef * ref )
{
if (mRef != ref) {
if (mRef) DestroyOpaqueRef(mRef);
mRef = ref;
}
}
 
private:
OpaqueRef * mRef;
CScoped_OpaqueRef( const CScoped_OpaqueRef & ref ) {}
void operator = ( const CScoped_OpaqueRef & ref ) {}
};
 


Название: Re: Scoped
Отправлено: Old от Июль 14, 2013, 15:31
...
Так а в чем "длинность и накладность"? :)


Название: Re: Scoped
Отправлено: Igors от Июль 14, 2013, 15:37
...
Так а в чем "длинность и накладность"? :)
Ну напр есть десяток таких opaque с разными дестроями...


Название: Re: Scoped
Отправлено: m_ax от Июль 14, 2013, 15:38
Покажите пожалуйста свой код. Не представляю, что там может быть длинно и накладно.
Код
C++ (Qt)
struct CScoped_OpaqueRef {
CScoped_OpaqueRef( OpaqueRef * ref ) : mRef(ref) {}
      ~CScoped_OpaqueRef( void ) { if (mRef) DestroyOpaqueRef(mRef); }
operator OpaqueRef * ( void ) { return mRef; }
 
void operator = ( OpaqueRef * ref )
{
if (mRef != ref) {
if (mRef) DestroyOpaqueRef(mRef);
mRef = ref;
}
}
 
private:
OpaqueRef * mRef;
CScoped_OpaqueRef( const CScoped_OpaqueRef & ref ) {}
void operator = ( const CScoped_OpaqueRef & ref ) {}
};
 

И к чему было этот велосипед городить?

Код
C++ (Qt)
std::unique_ptr<OpaqueRef, DestroyOpaqueRef> ref = CreateOpaqueRef(name);
 


Название: Re: Scoped
Отправлено: Old от Июль 14, 2013, 15:39
Ну напр есть десяток таких opaque с разными дестроями...
Да хоть сто питсот. :)
Есть же шаблоны.


Название: Re: Scoped
Отправлено: m_ax от Июль 14, 2013, 15:43
Ну напр есть десяток таких opaque с разными дестроями...
Да хоть сто питсот. :)
Есть же шаблоны.


шаблоны - это  не тру) Не для творческих личностей)


Название: Re: Scoped
Отправлено: Old от Июль 14, 2013, 15:51
шаблоны - это  не тру) Не для творческих личностей)
Ну я думаю, что времена, когда тру программист должен страдать уже прошли. За замученный вид заказчики уже не доплачивают. :)


Название: Re: Scoped
Отправлено: Igors от Июль 14, 2013, 15:56
Код
C++ (Qt)
std::unique_ptr<OpaqueRef, DestroyOpaqueRef> ref = CreateOpaqueRef(name);
 
Вроде "подходит", но только с С++ 11?

Есть же шаблоны.
Видимо придется  :'(

И к чему было этот велосипед городить?
..
шаблоны - это  не тру) Не для творческих личностей)
Не умничайте, задача будет - быстро слетит весь глянец   :)


Название: Re: Scoped
Отправлено: m_ax от Июль 14, 2013, 15:58
Вроде "подходит", но только с С++ 11?
В boost'е тоже есть умные указатели)


Название: Re: Scoped
Отправлено: Old от Июль 14, 2013, 16:10
В boost'е тоже есть умные указатели)
Да там свой шаблончик будет на несколько строк.


Название: Re: Scoped
Отправлено: Igors от Июль 14, 2013, 16:14
Ну вот, я так и знал :'( Полез делать template - и сразу надо еще что-то учить. Для текста выше не проходит
Код
template <class Ref, class Deleter>
struct CScopedRef {
..
Говорит, мол, Deleter ф-ция, а должен быть класс


Название: Re: Scoped
Отправлено: m_ax от Июль 14, 2013, 16:18
Ну вот, я так и знал :'( Полез делать template - и сразу надо еще что-то учить. Для текста выше не проходит
Код
template <class Ref, class Deleter>
struct CScopedRef {
..
Говорит, мол, Deleter ф-ция, а должен быть класс

Ничего подобного) Можно и функцию вставить)


Название: Re: Scoped
Отправлено: Igors от Июль 14, 2013, 16:28
Ничего подобного) Можно и функцию вставить)
Цитированием не злоупотребляйте если и так ясно о чем речь

Код
C++ (Qt)
template <typename TRef, typename TDeleter>
struct CScopedRef {
CScopedRef( TRef * ref ) : mRef(ref) {}
~CScopedRef( void ) { if (mRef) TDeleter(mRef); }
operator TRef * ( void ) { return mRef; }
 
void operator = ( TRef * ref )
{
if (mRef != ref) {
if (mRef) TDeleter(mRef);
mRef = ref;
}
}
 
private:
TRef * mRef;
CScopedRef( const CScopedRef & ) {}
void operator = ( const CScopedRef & ) {}
};
 
typedef CScopedRef <OpaqueRef, DestroyOpaqueRef> CScopedOpaqueRef;
 
На "инстанциации" вякает
Цитировать
error: type/value mismatch at argument 2 in template parameter list for 'template<class TRef, class TDeleter> struct CScopedRef'

error:   expected a type, got 'DestroyOpaqueRef'


Название: Re: Scoped
Отправлено: m_ax от Июль 14, 2013, 16:37
Хе хе) Конечно вякает)


Код
C++ (Qt)
template <typename TRef, typename TDeleter = default_deleter>
struct CScopedRef {
CScopedRef( TRef * ref, TDeleter deleter) : mRef(ref), mDeleter(deleter) {}
       CScopedRef( TRef * ref) : mRef(ref) {}
~CScopedRef( void ) { if (mRef) mDeleter(mRef); }
operator TRef * ( void ) { return mRef; }
 
void operator = ( TRef * ref )
{
if (mRef != ref) {
if (mRef) mDeleter(mRef);
mRef = ref;
}
}
 
private:
TRef * mRef;
       TDeleter mDeleter;
CScopedRef( CScopedRef & )
void operator = ( CScopedRef & )
};
 


Код
C++ (Qt)
typedef void (*FunctionType)(Ref *);
CScopedRef<Ref, FunctionType> ref(new Rew, DestroyOpaqueRef);
 
или ещё проще с decltype..


Название: Re: Scoped
Отправлено: Old от Июль 14, 2013, 16:45
Тут два пути:
Три:
Код
C++ (Qt)
template<typename T, void (*destroyer)( T )>
struct CScopedRef {
{
public:
       ~CScopedRef() { destroyer( mRef ); }
 


Название: Re: Scoped
Отправлено: m_ax от Июль 14, 2013, 16:48
Тут два пути:
Три:
Код
C++ (Qt)
template<typename T, void (*destroyer)( T )>
struct CScopedRef {
{
public:
       ~CScopedRef() { destroyer( mRef ); }
 


Да, так даже лучше)
Только igors туда уже ничего кроме void (*destroyer)( T ) не вставит)
Но, думаю, он не сильно расстроится)


Название: Re: Scoped
Отправлено: m_ax от Июль 14, 2013, 16:50
Тут два пути:
Три:
Код
C++ (Qt)
template<typename T, void (*destroyer)( T )>
struct CScopedRef {
{
public:
       ~CScopedRef() { destroyer( mRef ); }
 


Хотя подождите.. destroyer - это же тип..


Название: Re: Scoped
Отправлено: Old от Июль 14, 2013, 16:51
И наверное лучше не завязываться на указателях, например может понадобиться такое:
Код
C++ (Qt)
typedef unsigned int HANDLE;
 
HANDLE create( ... );
destroy( HANDLE );
 

Пусть лучше пользователь шаблона задает точный тип:
Код
C++ (Qt)
CScoped<Data *, DestroyData> d1 = CreateData( ... );
CScoped<HANDLE, destroy> d2 = create( ... );
 


Название: Re: Scoped
Отправлено: Old от Июль 14, 2013, 16:52
Только igors туда уже ничего кроме void (*destroyer)( T ) не вставит)
Все он вставит. :)


Название: Re: Scoped
Отправлено: m_ax от Июль 14, 2013, 16:58

Хотя подождите.. destroyer - это же тип..

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


Название: Re: Scoped
Отправлено: Old от Июль 14, 2013, 17:01
В смысле я к тому, что ему в любом случае придётся передавать указатель на функцию.. 
Тут, правда, будет затык, если какие то дестроеры имеют не такой прототип, например возвращают значение. Но тут уже Igors решать, по какому пути идти.


Название: Re: Scoped
Отправлено: m_ax от Июль 14, 2013, 17:14

Хотя подождите.. destroyer - это же тип..

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

Ааа.. Всё, дошло до меня) Я не о том подумал просто)
В таком варианте:
Код
C++ (Qt)
template<typename T, void (*destroyer)( T )>
struct CScopedRef {
{
public:
       ~CScopedRef() { destroyer( mRef ); }
 


указатель на функцию в конструкторе передавать уже ненужно) Всё верно)


Название: Re: Scoped
Отправлено: Igors от Июль 14, 2013, 18:39
Да, так бычит, спасибо
Код
C++ (Qt)
template <typename TRef, void (*delFunc)(TRef *)>
struct CScopedRef {
CScopedRef( TRef * ref ) : mRef(ref) {}
~CScopedRef( void ) { if (mRef) delFunc(mRef); }
operator TRef * ( void ) { return mRef; }
 
void operator = ( TRef * ref )
{
if (mRef != ref) {
if (mRef) delFunc(mRef);
mRef = ref;
}
}
 
private:
TRef * mRef;
CScopedRef( const CScopedRef & ) {}
void operator = ( const CScopedRef & ) {}
};
 
typedef CScopedRef <OpaqueRef, DestroyOpaqueRef> CScopedOpaqueRef;
 
Но возникает маленькая неприяность.
Код
C++ (Qt)
OpaqueRef * src = CreateOpaqueRef();
CScopedOpaqueRef ref1(src);  // Ок
CScopedOpaqueRef ref2 = src;  // error
 
Цитировать
error: 'CScopedRef<TRef, delFunc>::CScopedRef(const CScopedRef<TRef, delFunc>&) [with TRef = OpaqueRef, void (* delFunc)(OpaqueRef*) = DestroyOpaqueRef]' is private
Да, он действительно private (я так и хотел), но чего она зовет конструктор копирования, если есть штатный?

Да. кстати, а с unique_ptr работает или m_ax меня просто на понт взял?  :) Там вроде ситуевина та же, но у меня нет под рукой С++ 11


Название: Re: Scoped
Отправлено: _Bers от Июль 15, 2013, 21:48

error: 'CScopedRef<TRef, delFunc>::CScopedRef(const CScopedRef<TRef, delFunc>&) [with TRef = OpaqueRef, void (* delFunc)(OpaqueRef*) = DestroyOpaqueRef]' is private

Да, он действительно private (я так и хотел), но чего она зовет конструктор копирования, если есть штатный?

Рассмотрим пример:

Код:
Some obj = 10;

На языке строгой статической типизации в правой части обязан быть объект такого же типа, как и в левой.

Поэтому, компилятор выполняет приведение типов, что есть суть запуск конструктора:

Код:
Some obj = 10;
эквивалент:
Код:
Some obj = Some(10);
Здесь сразу нужно заметить, что в правой части присутствует временный объект. И компилятор знает, что время жизни этого объекта - гарантированно до конца построения объекта в левой части.

Построение объекта в левой же части происходит по прототипу в правой части:
Код:
Some obj = Some(10);
эквивалент:
Код:
Some obj (  Some(10) );

Здесь нужно понимать: что временный объект в правой части первейший прентендент на оптимизацию RVO, то бишь в релизе компилятор запросто может выпилить все промежуточные конструкторы, изначально построив в левой части нужный объект.

Но в дебаге:

http://codepad.org/L0aneALk


Название: Re: Scoped
Отправлено: m_ax от Июль 15, 2013, 22:19
И чтоб таких нежелательных сюрпризов не было (неявного преоброзования), умные люди используют explicit перед объявлением конструктора:

Код
C++ (Qt)
explicit CScopedRef( TRef * ref )
 
 


Название: Re: Scoped
Отправлено: m_ax от Июль 15, 2013, 22:45
Цитировать
Да. кстати, а с unique_ptr работает или m_ax меня просто на понт взял? Там вроде ситуевина та же, но у меня нет под рукой С++ 11

Ну конечно на понт взял) А Вы повелись) Вообще не верьте ни тому что в boost'e пишут, ни в stl.. И документацию читать (да и вообще читать) тоже дело не благодарное - всё это для неизобретательных буквоедов и программистов средней руки и тех, кто совсем.. не очень)

Голова то не бездонная - получаем новые знания и опыт, а всё старое стирается (в корзину) без возможности восстановления(



   


Название: Re: Scoped
Отправлено: Igors от Июль 16, 2013, 12:55
Рассмотрим пример:
Код:
Some obj = 10;
Этот пример приводится много раз, но с др целью
Код
C++ (Qt)
Some obj;
obj = 10;   // вызывается оператор присваивания
..
Some obj2 = 10;   // вызывается конструктор (но не оператор присваивания)
 
Оказывается не просто конструктор, а конструктор копирования, а уж как там оптимизатор разрулит - то его дело. Да, проверил, все четко, спасибо

И чтоб таких нежелательных сюрпризов не было (неявного преоброзования), умные люди используют explicit перед объявлением конструктора:
Неумные его тоже используют :) Но я совсем не хотел этого запрещать

Ну конечно на понт взял) А Вы повелись) Вообще не верьте ни тому что в boost'e пишут, ни в stl.. И документацию читать (да и вообще читать) тоже дело не благодарное - всё это для неизобретательных буквоедов и программистов средней руки и тех, кто совсем.. не очень)

Голова то не бездонная - получаем новые знания и опыт, а всё старое стирается (в корзину) без возможности восстановления(
Ну в общем правильно  :)

А если std::unique_ptr работает - то объясните каким образом, не вижу каким образом удаляющая ф-ция оказывается описанной. Спасибо.
 


Название: Re: Scoped
Отправлено: m_ax от Июль 16, 2013, 13:09
Цитировать
А если std::unique_ptr работает - то объясните каким образом, не вижу каким образом удаляющая ф-ция оказывается описанной. Спасибо.

Да вот так:

Код
C++ (Qt)
#include <iostream>
#include <memory>
 
void deleter(int *) {
   std::cout << "user deleter" << std::endl;
}
 
typedef void (*func_t)(int *);
 
int main()
{
 
   std::unique_ptr<int, func_t> p(new int(10), deleter);
 
   return 0;
}
 
 

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


Название: Re: Scoped
Отправлено: Igors от Июль 16, 2013, 14:44
Да вот так:
Ну так и я могу. Я имел ввиду
Код
C++ (Qt)
template <class Ref, class Deleter>
void TestProc( Ref * ref, Deleter del )
{
del(ref);
}
 
void MyDel ( int * a ) { printf("%d\n", *a); }
int  MyDel2 ( int * a ) { return *a + 1; }
 
int main( void )
{
int a = 5;
TestProc(&a, MyDel);
TestProc(&a, MyDel2);
 
return 0;
}
Здесь я могу подсовывать все что угодно, абы було (). А вот с template-классом так не выходит  :'( 


Название: Re: Scoped
Отправлено: m_ax от Июль 16, 2013, 14:58
Цитировать
Здесь я могу подсовывать все что угодно, абы було (). А вот с template-классом так не выходит

И что? Чем это принципиально выигрышней, чем вариант с unique_ptr?
Вы не знаете какой делитер вставить на момент создания  unique_ptr?
Это ерунда какая то.., либо Вы сами не знаете чего хотите..


Название: Re: Scoped
Отправлено: Old от Июль 16, 2013, 17:13
Это ерунда какая то.., либо Вы сами не знаете чего хотите..
Как я понял, Igors интересно, как достигается возможность указывать и функтор и функцию. ;)


Название: Re: Scoped
Отправлено: m_ax от Июль 16, 2013, 17:49
Это ерунда какая то.., либо Вы сами не знаете чего хотите..
Как я понял, Igors интересно, как достигается возможность указывать и функтор и функцию. ;)


А я вот понять всё никак не могу:
Цитировать
Здесь я могу подсовывать все что угодно, абы було (). А вот с template-классом так не выходит

и далее в примере:
Код
C++ (Qt)
       TestProc(&a, MyDel);
TestProc(&a, MyDel2);
 

Делитор по смыслу своему и предназначению, назначается объекту один раз и срабатывает тоже однажды, в самом конце. Менять его между началом и концом жизни объекта - это и есть ерунда.. Поэтому он и назначается объекту при его создании (объекта) один раз.
Если на момент создания объекта, неизвестно поведение делитора для него, то здесь уже чего то с логикой.. не того.. 

Или быть может я чего то не понимаю, чего хотел сказать igors..  ???


Название: Re: Scoped
Отправлено: Old от Июль 16, 2013, 17:55
В unique_ptr в качестве дестроера можно указать и объект-функтор и функцию. Как я понимаю Igors интересно как это реализуется.


Название: Re: Scoped
Отправлено: m_ax от Июль 16, 2013, 18:20
В unique_ptr в качестве дестроера можно указать и объект-функтор и функцию. Как я понимаю Igors интересно как это реализуется.

И даже использовать в качестве делитора метод класса.)


Название: Re: Scoped
Отправлено: _Bers от Июль 16, 2013, 21:26
Оказывается не просто конструктор, а конструктор копирования, а уж как там оптимизатор разрулит - то его дело. Да, проверил, все четко, спасибо

Вы не совсем уловили суть.

Суть заключается вот в этом вот вашем: "оказывается не просто конструктор, а конструктор копирования".

Дело в том, что из-за всякого рода оптимизаций, компилятор может использовать move-semantic, и выпилить копирующий конструктор. Тогда его явление станет не наблюдаемым. Это нужно учитывать.

По стандарту, вы имеете полное право рассчитывать только на то, что:
Код:
Some obj = 10; //гарантированно запустится конструктор с параметром

И я вам очень настоятельно не рекомендую рассчитывать на то, что запуск копирующего конструктора будет наблюдаем.

Более того, в вижал студии вы вообще не получите наблюдаемого конструктора копии. даже в дебаге:
Код:
struct Test
{
   Test(const Test& src) { cout<<"copy\n"; }
   Test(int src) { cout<<"ctor with param\n"; }
};

int main()
{
   Test t =10;
   //вывод в консоль: ctor with param
}

Во-первых, студия пренебрегает стандартом там, где стандарт начинает противоречить здравому смыслу (ну действительно: накой хрен тут упал этот конструктор копий, если все равно все сводится к построению бинарно-эквивалентному конструктором с параметром? )

А во-вторых, и вот это уже более важный аспект разработки:

Код:
//debug:gcc
struct Test
{
   Test(int src) { cout<<"ctor with param\n"; }
private:
   Test(const Test& src) { cout<<"copy\n"; }
};

int main()
{
   Test t =10;
   //Line 8: error: 'Test::Test(const Test&)' is private
}


Код:
//debug:mvs
struct Test
{
   Test(const Test& src) { cout<<"copy\n"; }
private:
   Test(int src) { cout<<"ctor with param\n"; } //<--- запрещен
};

int main()
{
   Test t =10;

   //успешная компиляция
   //вывод в консоль: ctor with param
}

Можно запросто подорваться на грабильках различий в поведении разных компиляторов.

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


Название: Re: Scoped
Отправлено: Igors от Июль 17, 2013, 09:16
В unique_ptr в качестве дестроера можно указать и объект-функтор и функцию. Как я понимаю Igors интересно как это реализуется.
Это понятно, но совсем не так удобно как с tempate ф-цией
Код:
    std::unique_ptr<int, func_t> p(new int(10), deleter);
Ну что это за длинная сопля? Надо использовать еще один typedef. Если ф-ция удаления хоть как-то отличается - еще городить typedef

Похожие проблемы с auto_ptr. Вроде "все по уму", но get() неприятно нагружает исходник, а в отладчике пока доберешься "до тела" :'(  В итоге выигрыш не так уж велик, нередко проще поставить пару if'ов ограничившись "просто указателем"


Название: Re: Scoped
Отправлено: Igors от Июль 17, 2013, 09:30
По стандарту, вы имеете полное право рассчитывать только на то, что:
Цитировать
Some obj = 10; //гарантированно запустится конструктор с параметром
Да, проверил (gcc)
Код
C++ (Qt)
#include <stdio.h>
 
struct CTest {
CTest( int a ) : mA(a)
{
printf("def ctor\n");
}
 
CTest( const CTest & src )
{
printf("copy ctor\n");
mA = src.mA;
}
 
int mA;  
};
 
int main( void )
{
CTest test = 5;
return 0;
}
 
Конструктор копирования НЕ вызывается, однако он не может быть private. Какая-то логика в этом есть, ну ладно, придется ограничиться явным вызовом крнструктора

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


Название: Re: Scoped
Отправлено: Old от Июль 17, 2013, 11:36
Ну что это за длинная сопля? Надо использовать еще один typedef. Если ф-ция удаления хоть как-то отличается - еще городить typedef
Какой еще один?

Похожие проблемы с auto_ptr. Вроде "все по уму", но get() неприятно нагружает исходник
Какой get? Зачем get? Если есть ->
Но наверное хочется страдать... :)

 В итоге выигрыш не так уж велик, нередко проще поставить пару if'ов ограничившись "просто указателем"
Конечно, поэтому вы и начали эту тему. :)


Название: Re: Scoped
Отправлено: m_ax от Июль 17, 2013, 12:37
Ну что это за длинная сопля? Надо использовать еще один typedef. Если ф-ция удаления хоть как-то отличается - еще городить typedef
Какой еще один?

Видимо, на тот случай, если делитор будет что-нибудь возвращать) Правда я не понимаю для чего, а главное как igors будет использовать это возвращаемое значение  ???




Название: Re: Scoped
Отправлено: Igors от Июль 17, 2013, 12:54
Конечно, поэтому вы и начали эту тему. :)
Вовсе нет. Понятно что проблема типовая и стандартные решения должны быть. Но особого их удобства не наблюдаю. Чуть сэкономил на if'ах - потерял на typedef.

Видимо, на тот случай, если делитор будет что-нибудь возвращать) Правда я не понимаю для чего, а главное как igors будет использовать это возвращаемое значение  ???
Никак, если нужно то это все не годится. Предполагается что ф-ция удаления внешняя


Название: Re: Scoped
Отправлено: m_ax от Июль 17, 2013, 13:12
Цитировать
Предполагается что ф-ция удаления внешняя
Тогда о каком дополнительном typedef идёт речь?
Вы боитесь лишней одной строчки, но всякий раз оправдываете написание своих (далеко не однострочных) велосипедов.. Мне не понятна ваша логика( И вообще, чего вы хотите..

И, кстати,  для случая с unique_ptr в принципе не обязательно определять typedef. Можно обойтись и без него..
Но готов поспорить, что вы всё равно свой костыль предпочтёте.. 

 


Название: Re: Scoped
Отправлено: Igors от Июль 17, 2013, 14:10
Вы боитесь лишней одной строчки, но всякий раз оправдываете написание своих (далеко не однострочных) велосипедов.. Мне не понятна ваша логика( И вообще, чего вы хотите..
Не надо это так воспринимать. Велосипед! Костыль! Позор!!! В жизни все как раз наоборот. Даже open-source (которые я считаю крутыми) далеко не всегда используют конструкции std, хотя такая возможность есть. Как правило - свой vector, ref, mutex и.т.п. Однако критикующих грамотеев почему-то не видно  :)

Возвращаясь к scoped - вполне возможно что std::unique_ptr делает все что нужно. Однако его использование провоцирует его изучение. И хз что он еше там делает, опять надо читать. Опасность в том что очень быстро это изучение засасывает, задача/работа отходит на второй поан, а то и вовсе болтитcя. Ведь это такой приятный процесс - становиться все умнее и умнее :)  Поэтому видя текст густо усеянный std - возникают большие сомнения. Очень может быть писавший обладает огромными познаниями, но вот будет ли толк в задаче - хз (и даже скорее нет)


Название: Re: Scoped
Отправлено: Old от Июль 17, 2013, 14:20
Опять бестолковое бла-бла-бла, человека который не хочет учиться. Уже сильно наскучило же.


Название: Re: Scoped
Отправлено: Igors от Июль 17, 2013, 20:34
Опять бестолковое бла-бла-бла, человека который не хочет учиться. Уже сильно наскучило же.
Нет, это мнение чнловека который не хочет быть "попкой-запомналкой" :) А если Вам наскучило - не лезьте с флудом


Название: Re: Scoped
Отправлено: Old от Июль 17, 2013, 20:42
Нет, это мнение чнловека который не хочет быть "попкой-запомналкой" :) А если Вам наскучило - не лезьте с флудом
Ага, вы попка-копипастер, который не может осилить примитивный инструмент, не говоря уже реализовать самому свой велосипед, и вынужденный везде в коде вставлять проверки и освобождалки ресурсов.
Хотя сами уже пришли к тому, что это не удобно, но осилить не смогли и сказали "Не надо".


Название: Re: Scoped
Отправлено: _Bers от Июль 17, 2013, 21:37
Возвращаясь к scoped - вполне возможно что std::unique_ptr делает все что нужно. Однако его использование провоцирует его изучение. И хз что он еше там делает, опять надо читать. Опасность в том что очень быстро это изучение засасывает, задача/работа отходит на второй поан, а то и вовсе болтитcя.

Отличительная черта стандартной библиотеки - для того, что бы использовать её механизмы, не нужно вникать в подробности их реализации. Достаточно просто ознакомится с документацией:
http://en.cppreference.com/w/cpp/memory/unique_ptr



Название: Re: Scoped
Отправлено: Old от Июль 17, 2013, 22:12
Отличительная черта стандартной библиотеки - для того, что бы использовать её механизмы, не нужно вникать в подробности их реализации. Достаточно просто ознакомится с документацией:
http://en.cppreference.com/w/cpp/memory/unique_ptr
Это бесполезно. :)
Столько раз уже пробовали рассказать/объяснить... и на пальцах и так....
Все кто осилил стандартную библиотеку это "попки-запоминалки", а если еще и boost освоил... то все... это программист не умеющий думать. :)
А вообще на этой планете есть только один программист, который думает... это конечно Igors. К сожалению, думать он может, только о том, как бы случайно чему не научиться. :)

Опасность в том что очень быстро это изучение засасывает
Опасность обучиться Igors тщательно обходит стороной, что бы не засосало, поэтому и вынужден приходить на форум со школьными вопросами. :)

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




Название: Re: Scoped
Отправлено: m_ax от Июль 17, 2013, 22:23
Возвращаясь к scoped - вполне возможно что std::unique_ptr делает все что нужно. Однако его использование провоцирует его изучение. И хз что он еше там делает, опять надо читать. Опасность в том что очень быстро это изучение засасывает, задача/работа отходит на второй поан, а то и вовсе болтитcя.

Отличительная черта стандартной библиотеки - для того, что бы использовать её механизмы, не нужно вникать в подробности их реализации. Достаточно просто ознакомится с документацией:
http://en.cppreference.com/w/cpp/memory/unique_ptr



Вы, _Bers, из леса что ли вышли?) Сейчас не модно изучать документацию, думать над архитектурой (слово архитектура лучше вообще не произносить), забивать голову всякими патернами, бустами и т.д.. "Всё это требует и провоцирует изучения" (с)..

А, как недавно показали научные исследования, проведённые в Оксфордском,  Принстонском и независимо в Гарвардском университетах,  
человеческий мозг существенно ограничен в способности вмещать в себя новую информацию и опыт(
Так что, любое развитие, и изучение чего то нового с неизбежностью приводит к коллапсу творческого потенциала личности..  

Такие дела(

  


Название: Re: Scoped
Отправлено: Igors от Июль 18, 2013, 10:58
Отличительная черта стандартной библиотеки - для того, что бы использовать её механизмы, не нужно вникать в подробности их реализации. Достаточно просто ознакомится с документацией:
http://en.cppreference.com/w/cpp/memory/unique_ptr
Так я ее давно прочитал - и даже видел раньше. Но вот почеиу я обязан именно ее использовать (иначе "ни разу не гоамотный") - хз. Разве это решение самое лучшее, удобное? Мне кажется что нет.

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


Название: Re: Scoped
Отправлено: _Bers от Июль 19, 2013, 01:47
Вы, _Bers, из леса что ли вышли?) Сейчас не модно изучать документацию

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

Так я ее давно прочитал - и даже видел раньше. Но вот почеиу я обязан именно ее использовать (иначе "ни разу не гоамотный") - хз. Разве это решение самое лучшее, удобное? Мне кажется что нет.

Если не хотите - не используйте.

Лично меня разочаровали стандартные смарт_поинтеры, когда я понял, что они без какой либо корректировки вошли в состав стандартной библиотеки "как есть". Я полагаю их красноречивым примером ущербного дизайна.

Однако, несмотря на это, я не стал бы внедрять в проект собственный велосипед, даже если бы полагал его более качественным с точки зрения дизайна.

Потому что:
1. Я бы предпочел потратить лишние несколько минут на ознакомление с документацией, чем целую неделю на создание собственного велосипеда, а потом  ещё и на отладку то и дело проявляющихся ошибок.

2. Использование готовых решений экономит время и деньги на разработку и сопровождение.

Но когда я ещё только осваивал язык с++, то, конечно, много велосипедил, что бы получить представление о том, "как это все может быть устроенно внутри".


Название: Re: Scoped
Отправлено: Old от Июль 19, 2013, 07:27
Лично меня разочаровали стандартные смарт_поинтеры, когда я понял, что они без какой либо корректировки вошли в состав стандартной библиотеки "как есть". Я полагаю их красноречивым примером ущербного дизайна.
Предлагаю это обсудить. Интересно, какой дизайн вам кажется удобным или что бы вы поменяли.


Название: Re: Scoped
Отправлено: Igors от Июль 19, 2013, 09:35
Потому что:
1. Я бы предпочел потратить лишние несколько минут на ознакомление с документацией, чем целую неделю на создание собственного велосипеда, а потом  ещё и на отладку то и дело проявляющихся ошибок.

2. Использование готовых решений экономит время и деньги на разработку и сопровождение.
Именно эти аргументы чаще всего приводятся, и при этом упорно указывается на что-то типа "целой недели". Однако посмотрим хоть на эту тему. Какая неделя? Наоборот, написать свой микро-класс - действительно неск минут. А вот рыскать искать - куда дольше, да и результат наверное хуже. Др дело напр писать свое красно-черное дерево - ну так я таких велосипедов и не предлвгвл.

Но когда я ещё только осваивал язык с++, то, конечно, много велосипедил, что бы получить представление о том, "как это все может быть устроенно внутри".
Если сами повелосипедили - не грех и воспользоваться. Но плохо когда готовые решения юзаются без всякой критики/осмысления, только на основании "за меня все сделали".


Название: Re: Scoped
Отправлено: Old от Июль 19, 2013, 09:55
А вот рыскать искать - куда дольше, да и результат наверное хуже.
Вы постоянно забываете, что искать и рыскать нужно вам, а другие это уже знают: для них воспользоваться готовым дело одной секунды. С другой стороны, написать примитивный класс, как показала эта тема, не для всех легко и просто.


Название: Re: Scoped
Отправлено: Igors от Июль 19, 2013, 12:43
Вы постоянно забываете, что искать и рыскать нужно вам, а другие это уже знают: для них воспользоваться готовым дело одной секунды.
Допустим, и что
Код
C++ (Qt)
typedef void (*DestroyFunc)(OpaqueRef);
std::unique_ptr<OpaqueRef, DestroyFunc> p(CreateOpaqueRef(name), DestroyOpaqueRef);
 
Вы считаете это очень удобным? И использование совсем не блещет
Код
C++ (Qt)
void DoSomething( OpaqueRef * );
..
DoSomething(p);   // а так нельзя
DoSomething(p.get());   // можно так
DoSomething(& *p);   // хммм...
 
И что я имею с такой великой мудрости? Так, без нужды загвдил текст - и все


Название: Re: Scoped
Отправлено: Old от Июль 19, 2013, 13:00
Как только вы выучите С++ у вас сразу все упроститься. :)
Жесть.


Название: Re: Scoped
Отправлено: Igors от Июль 19, 2013, 13:21
Как только вы выучите С++ у вас сразу все упроститься. :)
Жесть.
Раньше это звучало типа
Цитировать
учение Маркса всесильно потому что оно верно
:)


Название: Re: Scoped
Отправлено: _Bers от Июль 20, 2013, 11:10
Предлагаю это обсудить. Интересно, какой дизайн вам кажется удобным или что бы вы поменяли.

Это предмет для длительной дискуссии. Смысл обсуждать то, как можно было бы улучшить стандартный механизм?

Именно эти аргументы чаще всего приводятся, и при этом упорно указывается на что-то типа "целой недели". Однако посмотрим хоть на эту тему. Какая неделя? Наоборот, написать свой микро-класс - действительно неск минут. А вот рыскать искать - куда дольше, да и результат наверное хуже. Др дело напр писать свое красно-черное дерево - ну так я таких велосипедов и не предлвгвл.

Рыскать по интернетам приходится только тем, кто ещё не в теме (новички). Все остальные просто знают свой язык программирования.

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

Если сами повелосипедили - не грех и воспользоваться. Но плохо когда готовые решения юзаются без всякой критики/осмысления, только на основании "за меня все сделали".

Поддержка собственных велосипедов - слишком дорогое удовольствие. Это - прямые убытки компании.
Либо вы приносите компании прибыль, либо вы не нужны.


Название: Re: Scoped
Отправлено: Old от Июль 20, 2013, 11:18
Это предмет для длительной дискуссии. Смысл обсуждать то, как можно было бы улучшить стандартный механизм?
А что есть смысл обсуждать, если не это?
Давайте обсудим, какой интерфейс умных указателей, по вашему мнению, был бы удобней/эффективней.
Вы же про это говорили? В чем было ваше разочарование?


Название: Re: Scoped
Отправлено: Igors от Июль 20, 2013, 11:55
Новичок, который не знает стандартной библиотеки, не дотягивает даже до джуниора. Ему ещё предстоит многому научится, и многое понять. Но пока он ещё не созрел для работы.
Если человек вообще не знаком с std - конечно не созрел. Но беда когда он начинает лепить std где только можно :'( Ход мЫшления такого программиста карикатурен, ну примерно так
Цитировать
ага, в std это такая-то ф-ция! Значит это правильно. А все остальное, соответственно - неправильно
Исчезают человеческие имена переменных. Не выделяются ф-ции/методы. Все превращается в сплошное std. Такой код практически невозможно поддерживать, и он рассыпается при первом же изменении задачи. У одних эта заразная болезнь проходит, у других - увы :'(

Давайте обсудим, какой интерфейс умных указателей, по вашему мнению, был бы удобней/эффективней.
Есть такое понятие "цена вопроса". На практике эффективней тот умный указатель который пишущий выучил первым или знает лучше - вот и все.

- Qt предлагает свои версии умных указателей. Кстати, а почему не слышим обвинений в велосипедизме?  :)
- в бусте наверняка есть своя реализация
- своя реализация будет "не менее умной"  :)

Какую хотите - такую и юзайте, объективно все хороши. Вообще все эти разговоры охотно ведутся когдв вопрос решается "как угодно" и речь по существу о паре сэкономленных строк. Но вот как только хоть что-то "выше травы" - куда что девается?   :)


Название: Re: Scoped
Отправлено: _Bers от Июль 20, 2013, 13:13
А что есть смысл обсуждать, если не это?

Можно сколько угодно рассуждать на тему: "как можно улучшить с++". Но толку от это не будет никакого. Мы ведь не комитетчики.
Толк будет, если обсуждать такие темы, решения которых можно реально применить на практике.





Название: Re: Scoped
Отправлено: Old от Июль 20, 2013, 13:23
Можно сколько угодно рассуждать на тему: "как можно улучшить с++". Но толку от это не будет никакого. Мы ведь не комитетчики.
Толк будет, если обсуждать такие темы, решения которых можно реально применить на практике.
Честно говоря, я сначала подумал, что у вас есть какое-то мнение по этому вопросу...
А С++ можно легко улучшить, написав свои "умные указатели", если они конечно получаться лучше стандартных.


Название: Re: Scoped
Отправлено: Old от Июль 20, 2013, 13:31
Какую хотите - такую и юзайте, объективно все хороши. Вообще все эти разговоры охотно ведутся когдв вопрос решается "как угодно" и речь по существу о паре сэкономленных строк. Но вот как только хоть что-то "выше травы" - куда что девается?   :)
Ну ваше мнение всем известно, все что выше травы пишите только вы. Эта тема это в очередной раз подтверждает.
И человека я спрашивал о другом, но вы же не читаете или не думаете, о чем вы прочитали, а просто отвечаете. :)


Название: Re: Scoped
Отправлено: Igors от Июль 20, 2013, 14:03
А С++ можно легко улучшить, написав свои "умные указатели", если они конечно получаться лучше стандартных.
Возможно мои высказывания разбудили какие-то дремавшие у Вас чувства - и Вы замахнулись было писать аелосипед :) Но минутный порыв быстро угас..


Название: Re: Scoped
Отправлено: Old от Июль 20, 2013, 14:09
Возможно мои высказывания разбудили какие-то дремавшие у Вас чувства - и Вы замахнулись было писать аелосипед :) Но минутный порыв быстро угас..
Какой велосипед, вы сейчас с кем разговариваете? :)


Название: Re: Scoped
Отправлено: _Bers от Июль 20, 2013, 15:51
Можно сколько угодно рассуждать на тему: "как можно улучшить с++". Но толку от это не будет никакого. Мы ведь не комитетчики.
Толк будет, если обсуждать такие темы, решения которых можно реально применить на практике.
Честно говоря, я сначала подумал, что у вас есть какое-то мнение по этому вопросу...
А С++ можно легко улучшить, написав свои "умные указатели", если они конечно получаться лучше стандартных.


Не просто мнение, а готовое решение. Хотя оно и не до конца соответствует моим ожиданиям.
Механика разрабатывалась в рамках 2003 стандарта языка, когда был выбор: либо буст, либо велосипеды.

Целевая аудитория моего механизма: разного рода библиотеки/приложения, разработчики которых посчитали нерациональным добавлять тяжелую зависимость от boost только ради того, что бы можно было использовать boost::shared_ptr

В настоящие дни, ввиду всеобщей доступности std::shared_ptr мой механизм уже не актуален, даже не смотря на более проработанный дизайн.

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

Этот нюанс сыграл свою роль: у меня на работе действительно рассматривалась возможность использование моего мопеда взамен стандартных.

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

Если я это сделаю: возможно мой велосипед примет участие в коммерческом проекте.

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

***

Представьте себе на секундочку, что вы работаете с готовым движком. Он предоставляет наружу 3 пользовательских класса:

1. Простая картинка. Можно загрузить картинку с диска, произвести с нею манипуляции (разворот, масштабирование и тп).

2. Последовательность картинок. Что-то вроде контейнера простых картинок, который предоставляет пользователю возможность управления принципом следования кадров:    

Код:
sequence.SetQueue("B...E, R3(B ... E/2)");
//B - begin индекс начального кадра
//E - end   индекс конечного кадра
//R - repeat повторение задания (если не указано сколько раз - повторение до бесконечности)
//через запятую перечисляются задания

//в данном примере:
//сначала проигрывать все кадры от первого до последнего
//затем три раза повторить проигрывание от первого до половины

Последовательность картинок эксплуатирует класс простых картинок для своей деятельности.

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

Первый вопрос:

Должны ли разработчики движка предоставить пользователю наружу класс простой картинки, и последовательности кадров?
Или напротив, они должны спрятать эти два класса подальше от пользователя, предоставив ему только класс анимации?

Второй вопрос:

Механизм анимации покрывает область применения простых картинок и последовательности кадров.
Так например: простая картинка - это незапущенная анимация из 1 кадра
Очередь картинок - это незапущенная анимация из нескольких кадров.

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

Что лучше для пользователя:

1. Один механизм, который элегантно покрывает всю возможную область применения для решения всего круга задач?
2. Целый зоопарк механизмов, каждый из которых покрывает лишь незначительную часть области применения этого же круга задач?

Имейте ввиду: интересует исключительно удобства пользователей движка, а не его разработчиков.





Название: Re: Scoped
Отправлено: Igors от Июль 20, 2013, 16:05
_Bers, у меня есть задача о которой Вы говорите. Но пожвлуйста создайте новую тему, там поговорим, эта уже себя исчерпала


Название: Re: Scoped
Отправлено: Old от Июль 20, 2013, 16:09
Имейте ввиду: интересует исключительно удобства пользователей движка, а не его разработчиков.
Здесь очень важно понимать, а кто будет пользователем движка. Это скорее вопрос терминологии, кого мы будем называете пользователем:
* разработчик, который будет описывать сами анимации используя движек;
* разработчик, который будет расширять функционал этого движка.
И первый и второй разработчик - это по сути пользователь, только "рычаги" им потребуется разные.


Название: Re: Scoped
Отправлено: Old от Июль 20, 2013, 16:20
эта уже себя исчерпала
Все... вы окончательно сдались со своим велосипедом? :)
Все же уже разжевали, вам осталось почитать про операторы приведения типа, что бы отказаться от get и радостно пользоваться...
Ну и ладно, настоящие программисты не боятся разрушать ресурсы в 100500 местах в одной функции. ;)


Название: Re: Scoped
Отправлено: Igors от Июль 20, 2013, 16:48
Все... вы окончательно сдались со своим велосипедом? :)
Мои велосипеды всегда при мне, но в данном случае я их особо не продвигал, хотел услышать какие еще есть решения. К сожалению, дело свелось к псевдо-грамотности std - и не без Вашего активного участия :)

Давайте лучше обсудим о чем говорит _Bers - только в отдельной теме


Название: Re: Scoped
Отправлено: Old от Июль 20, 2013, 16:56
Мои велосипеды всегда при мне, но в данном случае я их особо не продвигал
Я в этом не сомневался не на секунду... ;)

К сожалению, дело свелось к псевдо-грамотности std - и не без Вашего активного участия :)
Зато вы научились в шаблоны передавать функции, правда уже не первый раз... Но мы помним как работает ваш мозг, поэтому понимаю что эти знания были вытеснены, чем то более важным.  ;D

Давайте лучше обсудим о чем говорит _Bers - только в отдельной теме
::) Давайте.


Название: Re: Scoped
Отправлено: Old от Июль 20, 2013, 19:50
Перечитал еще раз пост _Bers и думаю, что имеется ввиду пользователь первого типа.
Тогда, я бы скрывал всю реализацию по максимуму, т.е. оставил бы доступ только до функционала анимации. Для конечного пользователя он достаточен и покрывает все его потребности, а закрытая реализация облегчает дальнейшую разработку и сопровождение.

Хотя я бы наверно делал чуть иначе. Я бы оставил пользователю две сущности: источник кадров и плеер. Пользователь формирует источник и передает его в плеер, который его и показывает.


Название: Re: Scoped
Отправлено: Old от Июль 23, 2013, 11:10
Давайте лучше обсудим о чем говорит _Bers - только в отдельной теме
::) Давайте.

Но видно это обсуждение не входило в планы самого _Bers... также как и обсуждение этого:

В настоящие дни, ввиду всеобщей доступности std::shared_ptr мой механизм уже не актуален, даже не смотря на более проработанный дизайн.

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

Ну что же - жаль.  ::)


Название: Re: Scoped
Отправлено: Akon от Июль 23, 2013, 11:32
Извиняюсь, если такой ответ уже дан, тему не читал.

2Igors: (вариант с QScopedPointer, из ассистанта)
Код:
 // this struct calls "myCustomDeallocator" to delete the pointer
 struct ScopedPointerCustomDeleter
 {
     static inline void cleanup(MyCustomClass *pointer)
     {
         myCustomDeallocator(pointer);  // DestroyOpaqueRef
     }
 };

 // QScopedPointer using a custom deleter:
 QScopedPointer<MyCustomClass, ScopedPointerCustomDeleter> customPointer(new MyCustomClass);

С другими смарт поинтерами (не Qt) идея таже.


Название: Re: Scoped
Отправлено: Igors от Июль 24, 2013, 08:49
2Igors: (вариант с QScopedPointer, из ассистанта)
Понял, спасибо

А (для полноты картины) как выглядит это в бусте?


Название: Re: Scoped
Отправлено: Old от Июль 24, 2013, 09:00
А (для полноты картины) как выглядит это в бусте?
Точно также, как для std.
В std умные указатели переехали из буста.