недавно тут презентацию смотерл по очередной версии с++ там о пимпле упамянули, помню как-то пробовал, но не перешёл, а как вообще в с++ в народе, часто пимпл используют?

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

K>недавно тут презентацию смотерл по очередной версии с++ там о пимпле упамянули, помню как-то пробовал, но не перешёл, а как вообще в с++ в народе, часто пимпл используют?

Используют, как и все остальное — только там, где реально необходимо.

да

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

K>недавно тут презентацию смотерл по очередной версии с++ там о пимпле упамянули, помню как-то пробовал, но не перешёл, а как вообще в с++ в народе, часто пимпл используют?
А чего это такое? Можно в двух словах?

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

MM>А чего это такое? Можно в двух словах?
Это такая страшная хрень...
foo.h

class FooImpl;
class Foo
{
public:
    Foo();
    void Do();
private:
    boost::scoped_ptr<FooImpl> impl_;
};

foo.cpp

#include "foo.h"

class FooImpl
{
public:
    void Do()
    {
    }
};

Foo::Foo()
    : impl_(new FooImpl())
{}

void Foo::Do()
{
    impl_->Do();
}

И все это дело закатывается в dll/so/или что там на целевой платформе.

Теперь мы можем спокойно использовать эту длл.
Если мы захотим добавить в FooImpl новые поля, то размер Foo не изменится, и мы сможем заменить нашу длл без перекомпиляции остального софта.

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

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

K>недавно тут презентацию смотерл по очередной версии с++ там о пимпле упамянули, помню как-то пробовал, но не перешёл, а как вообще в с++ в народе, часто пимпл используют?

Только безграмотные програмисты которое не освоили виртуальные функции.

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

M>Только безграмотные програмисты которое не освоили виртуальные функции.

Дааа.. Qt писали неудачники!!!

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

А ты че плюс поставил, это вообще-то сарказм был

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

M>Только безграмотные програмисты которое не освоили виртуальные функции.

лол, что?

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

M>>Только безграмотные програмисты которое не освоили виртуальные функции.

A>Дааа.. Qt писали неудачники!!!

Qt особый случай. Они могли так сделать для борьбы с глюками компиляторов или для обратной совместимости.

В целом PIMPL — это костыль. По-хорошему, те проблемы, которые он решает, нужно решать как-то по-другому.
Уродство данного решения становится очевидным, когда у инкапсулируемого объекта оказывается много методов. Приходится ваять много тупого кода.

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

M>В целом PIMPL — это костыль. По-хорошему, те проблемы, которые он решает, нужно решать как-то по-другому.
M>Уродство данного решения становится очевидным, когда у инкапсулируемого объекта оказывается много методов. Приходится ваять много тупого кода.

и как ещё можно сделать кроссплатформенно?

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

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

MM>>А чего это такое? Можно в двух словах?
WH>Это такая страшная хрень...

Так это же делегирование, которое в COM существует уже лет так 20 с лишним.

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

K>недавно тут презентацию смотерл по очередной версии с++ там о пимпле упамянули, помню как-то пробовал, но не перешёл, а как вообще в с++ в народе, часто пимпл используют?

Удобно для написания кроссплатформенных библиотек интенсивно работающих ОС API. Других полезных применений не припомню. )

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

K>недавно тут презентацию смотерл по очередной версии с++ там о пимпле упамянули, помню как-то пробовал, но не перешёл, а как вообще в с++ в народе, часто пимпл используют?
Строго по необходимости.
Как то надо было чтоб в public headers одной библиотеки не попадало никаких внешних зависимостей, а в некоторых классах в private секции были поля, требующие сторонних библиотек.

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

WH>Это такая страшная хрень...
WH>Короче это героическое решение одной из проблем, которых в нормальных языках нет.
А почему не так?
foo.h

class Foo
{
public:
    virtual void Do()=0;
    virtual ~Foo()=0;// гы-гы, виртуальный® деструктор™.
};
Foo *createFoo();

foo.cpp

class FooImpl : public Foo
{
public:
    void Do()
    {
    }
};
Foo *createFoo()
{
  return new FooImpl();
}

Неужели только ради конструктора? Или такой код компиляторно-зависимый?

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

.>Неужели только ради конструктора? Или такой код компиляторно-зависимый?

часто динамический полиморфизм- сильно вреден.

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

S>часто динамический полиморфизм- сильно вреден.

C++ сам по себе вреден.

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

.>>Неужели только ради конструктора? Или такой код компиляторно-зависимый?
S>часто динамический полиморфизм- сильно вреден.
Чем вреден-то?

Хотя я понял. Не только ради конструктора, но и чтобы можно было наследоваться. Скажем, всем привычный QWidget моим способом не состряпать. Придётся сильно менять дизайн всей системы.

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

а ускорение компилирования можно достичь и другими методами, по крайней мере я знаю как в 3-4 раза ускорить vc++ просто настроив кое что

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

K>я сам не сильно понял нафига такой изврат, потому что на практике интрефейсная часть класса обычно редактируется не на много реже имплементации, а разделение можно сделать через обычные интерфейсы, как я и делаю.
Это ты зря. Интерфейсная часть в правильных библиотеках обычно не редактируется вообще, либо с соблюдением хотя бы backward compatibility.
А нужно это для наследования. Скажем, как бы ты класс QWidget описал/реализовал?
А вообще, это очередной камень в огород ООП...