Здравствуйте, Павел.
А можно объявить явную специализацию для деструктора и конструктора auto_ptr для incomplete type , а в скрытой реализации завершить определение типа и определить этот деструктор?
Не то чтобы мне нужно сделать подобную ерунду, просто интересно, можно ли так (видимо, с точки зрения стандарта — это все равно undefined behaviour — о чем Вы и говорили).

//user.h
template<class T>
class holder{
//something
private:
   std::auto_ptr<T>p_laja;
};

class Impl;
template<>
std::auto_ptr<Impl>::~auto_ptr();
//hidden.cpp
///definitions

Здравствуйте, ssm, Вы писали:

ssm>

ssm>#include <iostream>

ssm>struct A{
ssm>  char dummy[1000];
ssm>  static int count;
ssm>  A(){ count ++;}
ssm>  ~A(){ count --;}
ssm>};

ssm>int A::count = 0;

ssm>class B{
ssm>public:
ssm>  B() : a(new A()){
ssm>     throw "!!!";
ssm>  }
ssm>  ~B() {delete a;}
ssm>private:
ssm>  A * a;
ssm>};

ssm>
ssm>int main(){
ssm>  try{
ssm>    B b;  
ssm>  }
ssm>  catch(...)
ssm>  {
ssm>     std::cout << "Утечка памяти >= " << A::count * sizeof(A) << std::endl;
ssm>  }
ssm>}
ssm>

Такого на практике не будет
Все что нам нужно- обертка для какого-то класса. И выглядеть она будет вот так тривиально:

class B{
public:
    B()  { m_a = new A(); }
    ~B() { delete m_a; }
private:
    A * m_a;
};

То что ты говоришь- верно в том случае, если бы в классе B нужно было бы еще какие-то ресурсы получать. Исключение может возникнуть при создании A. И тогда деструктор не вызовится. Ну и отлично.
Задача этого класса B состоит только в создании/уничтожении класса A. Ну, правда, нужно туда (в B) еще добавить методы для доступа к методам класса A.

Здравствуйте, Сray, Вы писали:

С>Такого на практике не будет
С>Все что нам нужно- обертка для какого-то класса. И выглядеть она будет вот так тривиально:

ну ты ведь 10 минут назад спрашивал зачем здесь auto_ptr<> твоя обертка — упрощенный до безобразия auto_ptr<>. вот ты сам и ответил на свой вопрос.

С>

С>class B{
С>public:
С>    B()  { m_a = new A(); }

а куда же ты throw "!!!" девал то?

С>    ~B() { delete m_a; }
С>private:
С>    A * m_a;
С>};
С>

С>То что ты говоришь- верно в том случае, если бы в классе B нужно было бы еще какие-то ресурсы получать. Исключение может возникнуть при создании A. И тогда деструктор не вызовится.

ну почему же только ресурсы? или генерить исключения умеет только operator new ?

С>Ну и отлично.

ню-ню

С>Задача этого класса B состоит только в создании/уничтожении класса A. Ну, правда, нужно туда (в B) еще добавить методы для доступа к методам класса A.

ну это же ведь все утрировано

but you couldn't write:

int illegal_function(my_class);

or:

my_class illegal_function();

struct illegal_class {
my_class f();
};

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

Здравствуйте, ssm, Вы писали:

ssm>ну ты ведь 10 минут назад спрашивал зачем здесь auto_ptr<> твоя обертка — упрощенный до безобразия auto_ptr<>. вот ты сам и ответил на свой вопрос.

Вот! И я об этом! Все что я не понимал- зачем внутри класса выполняющего почти то-же что и auto_ptr нужен еще один auto_ptr.

С>>То что ты говоришь- верно в том случае, если бы в классе B нужно было бы еще какие-то ресурсы получать. Исключение может возникнуть при создании A. И тогда деструктор не вызовится.

ssm> ну почему же только ресурсы? или генерить исключения умеет только operator new ?

Да пусть кто хочет генерит. Не важно.

С>>Ну и отлично.

ssm>ню-ню

А вот этого не люблю.

С>>Задача этого класса B состоит только в создании/уничтожении класса A. Ну, правда, нужно туда (в B) еще добавить методы для доступа к методам класса A.

ssm>ну это же ведь все утрировано

И ничего не утрировано.
Все что фактически нужно- специализированный вариант auto_ptr в котором добавлены методы для доступа к методам класса A.
Конструктор-же может быть один к одному auto_ptr- ский.


Кстати, я назад посты пролистал- так ты и сам предлагал заменить auto_ptr на простой указатель.
А теперь доказываешь что без auto_ptr не обойтись... Ты как-нибудь определись...

вот твоя ссылка http://www.rsdn.ru/forum/Message.aspx?mid=167523&amp;only=1

Автор: Павел Кузнецов
Дата: 08.01.03

Тебе предогалось поменять

ssm>    std::auto_ptr<ImplType> impl_;

на

ImplType* impl_;

Здравствуйте, Fiend, Вы писали:

F>

F>but you couldn't write:
F>int illegal_function(my_class);

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

Верно, здесь маэстро не вполне точен :-) Кроме того, неточны и его высказывания относительно невозможности реализации шаблона std::map, не требующего для инстанциирования полного типа. Например, VC++7 + STLport 4.5.3 прекрасно компилирует следуюющее:

#include <map>

struct C;

struct D
{
  std::map<int, C> m;

  D();
  D(const D&);
  ~D();
};

Тем не менее, с исторической точки зрения, статья, ИМХО, интересна.

Здравствуйте, Аноним, Вы писали:

А>А можно объявить явную специализацию для деструктора и конструктора auto_ptr для incomplete type

Можно.

А>а в скрытой реализации завершить определение типа и определить этот деструктор?

А вот тут возникает вполне закономерный вопрос: а как, собственно, ты сможешь определить деструктор или конструктор std::auto_ptr<>, "не зная" деталей реализации последнего?

Ну, это... Я ведь только объявлю специализации, а определю их где-то в скрутой реализации, после после завершения определения типа. Ведь так-то можно?

Здравствуйте, Сray, Вы писали:

С>Вот! И я об этом! Все что я не понимал- зачем внутри класса выполняющего почти то-же что и auto_ptr нужен еще один auto_ptr.

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

С>А вот этого не люблю.
Твое право

С>>>Задача этого класса B состоит только в создании/уничтожении класса A. Ну, правда, нужно туда (в B) еще добавить методы для доступа к методам класса A.

ssm>>ну это же ведь все утрировано

С>И ничего не утрировано.
С>Все что фактически нужно- специализированный вариант auto_ptr в котором добавлены методы для доступа к методам класса A.
С>Конструктор-же может быть один к одному auto_ptr- ский.

С>
С>Кстати, я назад посты пролистал- так ты и сам предлагал заменить auto_ptr на простой указатель.
С>А теперь доказываешь что без auto_ptr не обойтись... Ты как-нибудь определись...

ты точно хорошо понимаешь, что такое pimpl ? помоему — несовсем. Я не предлагал использовать, я говорил, что использование auto_ptr<> c неполным типом по стандарту — UB

С>вот твоя ссылка http://www.rsdn.ru/forum/Message.aspx?mid=167523&amp;only=1

Автор: Павел Кузнецов
Дата: 08.01.03

ты все спутал Темой того

Автор: ssm
Дата: 08.01.03

топика было возможность написания шаблонного сласса template <class T> class ImplHolder, позволяющего скрыть реализацию для любого класс U порожденного от ImplHolder<T>, где T — класс реализации.

С>Тебе предогалось поменять
С>

ssm>>    std::auto_ptr<ImplType> impl_;
С>

С>на
С>

С>ImplType* impl_;
С>

Там — да, так и должно быть, но если ты заметил, этот топик отличаеться от того. Короче, там где видишь std::auto_ptr<T> читай его как свой менеджер для типа, не требующий полного описания T при инстанцировании. так понятно?

Здравствуйте, Fiend, Вы писали:

F>Ну, это... Я ведь только объявлю специализации, а определю их где-то в скрутой реализации, после после завершения определения типа.

И что ты там напишешь? Из стандарта нельзя вывести даже имя члена, для которого ты должен написать delete X :-) Если, например, для VC++, ты напишешь delete _Ptr, вовсе не факт, что твой деструктор скомпилируется с другой стандартной библиотекой. Например, в STLport 4.5.3 подобный член имеет имя _M_p.

ААаа, ну это само собой.

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

Здравствуйте, Сray, Вы писали:

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

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