"Fernando Cacciola" <[EMAIL PROTECTED]> writes: > "Aleksey Gurtovoy" <[EMAIL PROTECTED]> escribió en el mensaje > news:[EMAIL PROTECTED] >> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
