It always bugged me that you would have to write your private class members inside the header files in C++. This means that everytime you change you implementation, client code has to be rebuild.I found thise site which describes how to hide implementation detail in C++: http://www.octopull.demon.co.uk/c++/implementation_hiding.htmlHowever I also wanted the code to be generic, so that I didn't have to rewrite the same code for each and every class I create. Here is what I got:#define TL_UTILS_IMPL_DECL(member) \    private: \        class impl; \        impl* member;#define TL_UTILS_IMPL_START(t_class, parent) \    class t_class::impl \    { \        public: \            t_class* parent; \            impl(t_class* self) \                : parent(self) \            {}#define TL_UTILS_IMPL_END() \    };#define TL_UTILS_IMPL_INIT(member) \    member = new impl(this);#define TL_UTILS_IMPL_TERM(member) \    delete member;#define TL_UTILS_IMPL_PREFIX(t_class) \    t_class::impl::Example usage:// Header file:    class foo    {            TL_UTILS_IMPL_DECL(m)        public:            foo();            ~foo();    };// Source file:    TL_UTILS_IMPL_START(foo, p)        void bar();    TL_UTILS_IMPL_END()    foo::foo()    {        TL_UTILS_IMPL_INIT(m)        // from here on we can use the private        // data and methods stored in m        m->bar();    }    foo::~for()    {        TL_UTILS_IMPL_TERM(m)    }    void TL_UTILS_IMPL_PREFIX(foo) bar()    {        // do something useful        // use p as a pointer to the parent class instance    }I always hear that preprocessor macros are dirty and should not be used in C++, and I agree to some degree. However I could not realize what I wanted using templates.So what do you think?Is the use of preprocessor macros justified here?Is the code safe?Any improvements you can think of?
C++: Hiding class implementation detail generic
c++
I certainly sympathize with you about increasing build times. The C++ project I currently work on takes 45 - 60 minutes to build from scratch. But those macros are unreadable. When I see them my eyes glaze over and I don't even want to try to understand what you're doing.void TL_UTILS_IMPL_PREFIX(foo) bar()This line in particular is obnoxious. It looks ugly, it's  not at all initially clear why you would do this, and once a developer does figure it out, it'll probably make them angry! =)Since your concern is compile times, let me suggest a set of strategies that I use to alleviate your problem.Divide your application into a number of small, focused DLL's.Don't expose concrete classes from you DLL. Instead, have your concrete classes implement interfaces, and compile against these interfaces from other DLL's/EXE's.Check out this article from CodeProject. Under the heading, Mature Approach: Using an Abstract Interface, for a thorough explanation of point 2.The end result of these two changes is that all of your DLL's will be able to compile independently of each other. If you keep them small and focused, the cost of recompiling a couple files inside the DLL's isn't too high.Otherwise, if you really want to use PIMPL, just write the code. Don't bury it in ugly macros.