[boost] Re: Fun PP lib example

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2003-08-01 21:24:45

"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.

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.

Fernando Cacciola