Не дадим abstraction сделать ненужный penalty!

//Fast Winnie Pimple Idiom. (FWPI);

#include <memory>

#ifdef NDEBUG

#include "Implementation.h"
typedef CImplementaition CWrapper;

#else

class CImplementaition;

class CWrapper
{
public:
    void Do(); //.cpp:       void CWrapper::Do() { return this->m_pImpl->Do(); }

    CWrapper(); //.cpp:      CWrapper::CWrapper() :m_pImpl(new CImplementaition) { }
    ~CWrapper(); //.cpp:     CWrapper::~CWrapper() {}

private:
    std::auto_ptr<CImplementaition> m_pImpl; 
};
 
#endif

//------------------------------------------------------------------------------------

int main()
{
    CWrapper x;
    x.Do();
}

Если implementation.h доступен клиенту, то зачем вообще нужен этот враппер CWrapper?

Теперь вот еще что. Я просто не в курсе как обстоит дело сейчас, но до этого параметризация шаблона стандартной библиотеки неполным типом означало effects are undefined:

class foo;
std::auto_ptr<foo> ptr;

И еще одно. Подменять реализации для DEBUG-а и RELEASE-а — зло — отладку проводим для одного класса, а в релиз включаем совсем другой.

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

АШ>Теперь вот еще что. Я просто не в курсе как обстоит дело сейчас, но до этого параметризация шаблона стандартной библиотеки неполным типом означало effects are undefined:
Я как бы в курсе. Но не забывай, что <memory> — это обычный текстовый файл. И Саттер рекомендует auto_ptr. Если ты такой пурист, пиши my_bycicle_non_standart_auto_ptr_wich_can_be_paramerized_with_incomplete_type<T>. Но зачем, если он уже лежит где в
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\memory
с:\stlport\STLport-4.6.2\stlport\memory
c:\MinGW\include\c++\3.4.2\
/usr/include/c++/memory
?

АШ>Если implementation.h доступен клиенту, то зачем вообще нужен этот враппер CWrapper?
А как ты предлагаешь? #define CWrapper CImplementation
Или тебя названия смущают?

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

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

_W>Я как бы в курсе. Но не забывай, что <memory> — это обычный текстовый файл.

Не понял, правда, причем здесь текстовый файл — ведь в конечном итоге будет интересовать реализация шаблона и ее требования к параметрам.

АШ>>Если implementation.h доступен клиенту, то зачем вообще нужен этот враппер CWrapper?
_W>А как ты предлагаешь? #define CWrapper CImplementation
_W>Или тебя названия смущают?

Меня смущает использование идиомы pimpl, так где она на фиг не нужна.

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

АШ>Меня смущает использование идиомы pimpl, так где она на фиг не нужна.

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

Compilation Firewalls

Но тебе не кажется странным, что пользователь должен платить за скорость компиляции в Debug-режиме?

"_Winnie" <23256@users.rsdn.ru> wrote in message
news:1435243@news.rsdn.ru...
> std::auto_ptr<CImplementaition> m_pImpl;

Злой ты.
Зачем грабли положил?

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

_W>Не дадим abstraction сделать ненужный penalty!

Не дадим писать illformed или undefined программы!

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

class Cargo;

class Holder
{
private:
  damned_ptr<Cargo> p; // будучи шаблоном, имеет инлайновый деструктор
public:
  Holder(); // инициализирует p в .cpp где Cargo полностью определён
  ~Holder() {} // может быть проинлайнен в любом месте
};

Все явно объявленные методы Cargo доступны компилятору только в контексте, где Cargo полностью определён; так что с этим проблем нет.
Другие неявно определяемые методы — конструктор без параметров, конструктор копирования и оператор присваивания — можно запретить к использованию за пределами реализации (объявив damned_ptr некопируемым или использовав совместное неинтрузивное владение). Но деструктор должен быть как-то доступен.

Один из способов — сделать вызов деструктора косвенным.
В том месте, где damned_ptr'у присваивается валидный объект, мы тут же присвоим указатель на функцию-разрушитель (например, checked_delete<Cargo>).
В деструкторе damned_ptr — вызовем разрушитель по указателю, с аргументом-указателем. Kein Problem!

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

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

_W>>Не дадим abstraction сделать ненужный penalty!

К>Не дадим писать illformed или undefined программы!
???
Я же написал, что деструктор определен в .cpp файле. Ты читал код в посте?

PS.
Поставь себе в stdafx.h
# pragma warning(error: 4150) //deletion of pointer to incomplete type 'x'; no destructor called
И забудь про проблему и лишний код для ее решнения

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

SD>"_Winnie" <23256@users.rsdn.ru> wrote in message
SD>news:1435243@news.rsdn.ru...
>> std::auto_ptr<CImplementaition> m_pImpl;

SD>Злой ты.
SD>Зачем грабли положил?

Если ты имеешь в виду знаменитый <censored> 17.4.3.6 bullet 5, то смотри здесь
Если ты имеешь в виду deletion of pointer to incomplete type 'CImplementaition'; no destructor called то я не знаю что ты имел в виду. Этого здесь нет.

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

К>>Не дадим писать illformed или undefined программы!
_W>???
_W>Я же написал, что деструктор определен в .cpp файле. Ты читал код в посте?

Читал. Думаешь, это много что меняет?

Твой класс формально является copy constructible. Неявно определённый почленный конструктор копирования выглядит так

inline CWrapper::CWrapper(/*const*/CWrapper& src) :
  m_pImpl(src.m_pImpl)
  , m_some_extra(src.m_some_extra)
{}

Стоит добавить член m_some_extra, который может метнуть исключение в конструкторе — и мы получим ещё одну точку для вызова деструктора m_pImpl.
Значит, придётся или делать CWrapper некопируемым, или тащить конструктор копирования внутрь .cpp и писать руками.

Не кажется ли, что слишком высока плотность геморроя на душу населения?

_W>PS.
_W>Поставь себе в stdafx.h
_W># pragma warning(error: 4150) //deletion of pointer to incomplete type 'x'; no destructor called
_W>И забудь про проблему и лишний код для ее решнения

Нифига себе! Просто-напросто деструктор из какого-нибудь неожиданного места не будет вызван.
Такие варнинги ни в коем случае нельзя маскировать.

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

К>Стоит добавить член m_some_extra, который может метнуть исключение в конструкторе — и мы получим ещё одну точку для вызова деструктора m_pImpl.

И что произойдет? Не вызовется деструктор CImplementaton?
А я думал, что достаточно, определить деструктор CWrapper (даже пустой) в .cpp файле вместе с полным определением CImplementation и об остальном можно не волноваться. Разве это не так?

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

К>Твой класс формально является copy constructible. Неявно определённый почленный конструктор копирования выглядит так

Забыл написать/спрятать конструктор копирования/оператор присваивания. mea culpa.
Что вы придрались к std::auto_ptr. Да какая разница! Юзайте хоть boost::shared_ptr, хоть голый указатель.
Главный пойнт — отсусвие перекомпиляции в debug, и отсусвие ненужного penalty в release!

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

_W>>PS.
_W>>Поставь себе в stdafx.h
_W>># pragma warning(error: 4150) //deletion of pointer to incomplete type 'x'; no destructor called
_W>>И забудь про проблему и лишний код для ее решнения

К>Нифига себе! Просто-напросто деструктор из какого-нибудь неожиданного места не будет вызван.
К>Такие варнинги ни в коем случае нельзя маскировать.




_W>># pragma warning(!!!! ----------------------> ERROR <--------------------------!!!: 4150) //deletion of pointer to incomplete type 'x'; no destructor called

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

_W>Забыл написать/спрятать конструктор копирования/оператор присваивания. mea culpa.
_W>Что вы придрались к std::auto_ptr. Да какая разница! Юзайте хоть boost::shared_ptr, хоть голый указатель.
_W>Главный пойнт — отсусвие перекомпиляции в debug, и отсусвие ненужного penalty в release!

Уж больно запаристый этот пойнт

_W>>># pragma warning(!!!! ----------------------> ERROR <--------------------------!!!: 4150) //deletion of pointer to incomplete type 'x'; no destructor called

Прости, совсем ослеп, пымаешь...

Кстати говоря, вот здесь http://www.gotw.ca/gotw/028.htm Herb Sutter предложил очень даже неплохое решение.

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

sch>Кстати говоря, вот здесь http://www.gotw.ca/gotw/028.htm Herb Sutter предложил очень даже неплохое решение.

И что?
Таже лишняя косвенность.
Мелкие методы Implementation не заинлайнятся.
Компилятор не будет видеть тела функций Implementation, не будет знать, бросают они исключение или нет, и будет генерить лишний код, как будто бы исключения бросаются.
В общем, все те недостатки, из-за которых Compilation Firewall является Compilation Firewall.
Невозможно для компилятора не знать о внутренностях implementation и одновременно знать о внутренностях implementation(для оптимизации)

---

Использование fixed block size аллокатора, который ни в коем случае не является панацеей (иначе бы его использовали бы всегда, когда размер известен на этапе компиляции).
Его бездумное использование для всех типов подряд может быть ещё большим evil, чем general purpose аллокатора.

---

Причём здесь fast?

_W>Таже лишняя косвенность.

Ну, уж если вести разговор в этом ключе, то легко можно доказать абсолютную ненужность pimpl-ов, что, кстати говоря, недалеко от истины.

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


_W>>Таже лишняя косвенность.

sch>Ну, уж если вести разговор в этом ключе, то легко можно доказать абсолютную ненужность pimpl-ов, что, кстати говоря, недалеко от истины.

Или я чего то не понимаю или pimpl легко и явно заменяется интерфейсом ?

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

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


_W>>>Таже лишняя косвенность.

sch>>Ну, уж если вести разговор в этом ключе, то легко можно доказать абсолютную ненужность pimpl-ов, что, кстати говоря, недалеко от истины.

M>Или я чего то не понимаю или pimpl легко и явно заменяется интерфейсом ?

Абсолютно верно -- у меня были те же мысли. Причем интерфейс значительно проще, понятнее и прозрачнее.

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

>Ну, уж если вести разговор в этом ключе, то легко можно доказать абсолютную ненужность
Не понял смысла фразы. Да, в Release он абсолютно не нужен. Но он нужен для уменьшения зависимостей, быстрой компиляции(если не нужна полиморфость, потенциальное отсуствие (NULL), Handle/Body для ускорения копирования).
Поясняю не знаю в который раз.

Я хочу преимущества pimple, которые он даёт(быстрая компиляция, меньше зависимостей), но не хочу страдать из-за его недостатков в Release.
Я ХОЧУ И НА ЁЛКУ ВЛЕЗТЬ И НЕ ОБОДРАТЬСЯ! Попробуйте это с интерфейсом!

>Или я чего то не понимаю или pimpl легко и явно заменяется интерфейсом ?
Предположим, не надо менять интерфейс в runtime и не нужна его полиморфность.
То есть, это только для того, что бы скрыть реализацию, ни для чего больше.
Попробуй этот же трюк с интерфейсом — отсуствие malloc+косвенности в Release.

Чёрт возми, для тех кто не заметил. Там стоит #ifdef NDEBUG
Или вы у вас в голове всегда этот #define не определен по умолчанию, и вы скипаете при чтении кода соответсвующую ветку условной компиляции?