c++ - OOP vs macro problem -

i came across problem via colleague today. had design front end system goes this:

class lwindow {    //interface common methods windows };  class llistbox : public lwindow {    //do not override methods in lwindow.    //interface list specific stuff }  class lcombobox : public lwindow{} //so on 

the window system should work on multiple platforms. suppose moment target windows , linux. windows have implementation interface in lwindow. , have multiple implementations llistboxes, lcomboboxes, etc. reaction pass lwindow*(implementation object) base lwindow class can this:

void lwindow::move(int x, int y) {    p_impl->move(x, y);   //impl lwindow* } 

and, same thing implementation of llistbox , on

the solution given different. boiled down this:

#define windowscommonimpl {//set of overrides lwindow methods}  class winlistbox : public llistbox {     windowscommonimpl     //the overrides methods in lwindow pasted here.     //llistbox overrides }  //so on 

now, having read macros being evil , design practices, against scheme. after all, code duplication in disguise. couldn't convince colleague of that. , surprised that case. so, pose question you. possible problems of latter method? i'd practical answers please. need convince practical (and used doing sort of stuff. mentioned there's lots of macros in mfc!) bad (and myself). not teach him aesthetics. further, there wrong proposed? if so, how improve it? thanks.

edit: please give me reasons can feel myself supporting oop :(

going bounty. please ask if need clarifications. want know arguments , vs oop against macro :)

your colleague thinking of mfc message map macros; these used in important-looking places in every mfc derived class, can see colleague coming from. these not implementing interfaces, rather details interacting rest of windows os.

specifically, these macros implement part of windows' message pump system, "messages" representing requests mfc classes stuff gets directed correct handler functions (e.g. mapping messages handlers). if have access visual studio, you'll see these macros wrap message map entries in somewhat-complicated array of structs (that calling os code knows how read), , provide functions access map.

as mfc users, macro system makes clean us. works because underlying windows api well-specified , won't change much, , of macro code generated ide avoid typos. if need implement involves messy declarations macros might make sense, far doesn't seem case.

practical concerns colleague may interested in:

• duplicated macro calls. looks you're going need copy line "windowscommonimpl" each class declaration - assuming macro expands inline functions. if they're declarations , implementations go in separate macro, you'll need in every .cpp file - , change class name passed macro every time.
• longer recompile time. solution, if change in lwindow implementation, need recompile lwindow.cpp. if change in macro, includes macro header file needs recompiled, whole project.
• harder debug. if error has logic within macro, debugger break caller, don't see error right away. may not think check macro definition because thought knew did.

so lwindow solution better solution, minimize headaches down road.