[boost] Re: Fun PP lib example

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-01 22:09:11

"Fernando Cacciola" <fcacciola_at_[hidden]> writes:

> "Aleksey Gurtovoy" <agurtovoy_at_[hidden]> escribió en el mensaje
> news:045f01c3587c$5fa650b0$9a44a8c0_at_metacomm.com...
>> David Abrahams wrote:
>> > Here's an example I just cooked up of using the PP lib to solve a
>> > classic C++ OO problem: repeated boilerplate in the definition of
>> > Pimpl classes.
>> There is another variation of the idiom, sometimes called "hidden
>> state", which doesn't have the shortcoming in the first place:
>>
> A shortcoming of the hidden state idiom compared to the classic
> delegation idiom is that only the state is encapsulated, not the
> behaviour.  IOWs, if you need to hide the operations, not just the
> state, you still need to mirror the interface class member functions
> into the impl class.  For this case, delegation would be preferred,
> and so Dave's macros.

Yep, I think that's why Aleksey's idea didn't seem like much of a
help to me.  I could easily hide the impl base class, but it didn't
seem like a big advantage.

> As for the macros, they are certainly handy...
>
> Though almost a decade ago I have had bad experiencies using macros to
> do the job of a good editor, so eventually I preferred to have only
> straight up C++ code to feed the compiler and use external tools to
> handle code generation.  Problems were mostly related to very excesive
> preprocessing times (paid on each compilation), blind-debugging and
> the fact that a variate of handy macros started to proliferate as new
> code patterns wanted to be automated, pollutting the code base with so
> many macros that source code looked as being written in another
> language. For me who designed all those macros the resulting code
> looked very clear, but the rest of the team -who had to use them- kept
> complaining about having to learn too many non standard things.
>
> Nowaday, however, I would use the PP, and the handy macros like the
> one Dave just invented, to implement meta-code that generates the
> actual source files that get compiled and 'seen' by felow
> programmers. That way, only the actual maintainer has to know what
> extactly the macro does, while code 'users' (including the compiler
> that has to preprocess the file every day), deals with the expanded
> code only.
>
> So, I like Dave's macro, though I would prefer code generation macros
> not to be put in code directly requiring users to know the inner
> details of expanded code (for debugging, for instance).
>
> Just a thought.

FWIW, my macro only generates declarations, so it doesn't interfere
with debugging.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com