On Jun 30, 12:51 am, Greg Herlihy <gre...@mac.com> wrote:
> On Jun 28, 9:23 pm, Peng Yu <PengYu...@gmail.com> wrote:
>
> > It is benifitical to use macro in certain cases.
>
> Perhaps, but the example below certainly isn't one of them.
>
>
>
>
>
> > #define MACRO_DEF \
> > class A { \
> > public: \
> > A(int a) : _a(a) { } \
> > int the_a() const { return _a; } \
> > private: \
> > int _a; \
> > };
>
> > MACRO_DEF
>
> > #define MACRO \
> > A a(1);\
> > std::cout << a.the_a() << std::endl;
> > However, I found that it is not easy to debug a macro. For example,
> > for the following program, I can not trace into the last macro in gdb.
>
> If you (who wrote the macro) have trouble debugging it, imagine the
> difficulties that the maintenance programmer will face - simply to
> understand what the macro is supposed to do. After all, what would you
> think if you had to debug a C++ program whose main() function looked
> like the main() in your program:
>
> > int main() {
> > MACRO
>
> > }
>
> Having to deal with code like this, in my experience, would be enough
> to convince most programmers that they really should be working -
> somewhere else.

Hi Greg,

I guest you misunderstood my OP. I have never said that my example is
the case that I should use macro.

I just raised that example to show the difficulty of debugging it. It
is not at all similar to the real code that I'm pondering whether I
should use macro or not.

I originally considered macro because there are somewhat redundancies
(not exactly the same) in that code that can not be refactored in with
extract method, etc. However, as macro is hard to debug, I end up with
writing a code generator to generated the somewhat redundant code.

Thanks,
Peng