Hi,

It is benifitical to use macro in certain cases.

http://www.boost.org/doc/libs/1_35_0...doc/index.html

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.

In this sense, if I want to debug the code easily, should I avoid
using macros. Are there any better way to debug macros?

Thanks,
Peng

$ cat main.cc
#include <boost/typeof/typeof.hpp>
#include <iostream>

#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;

int main() {
MACRO
}


$gdb main-g.exe
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "x86_64-linux-gnu"...Using host
libthread_db library "/lib/libthread_db.so.1".

(gdb) start
Breakpoint 1 at 0x40081c: file main.cc, line 20.
main () at main.cc:20
20 MACRO
(gdb) s
A (this=0x7fffb8f0de80, a=1) at main.cc:13
13 MACRO_DEF
(gdb) s
A::the_a (this=0x7fffb8f0de80) at main.cc:13
13 MACRO_DEF
(gdb) s
1
main () at main.cc:21
21 }
(gdb) n
0x00002afcf215b4ca in __libc_start_main () from /lib/libc.so.6
(gdb) n
Single stepping until exit from function __libc_start_main,
which has no line number information.

Program exited normally.
(gdb)

Peng Yu wrote:
> Hi,
>
> It is benifitical to use macro in certain cases.
>
> http://www.boost.org/doc/libs/1_35_0...doc/index.html
>
> However, I found that it is not easy to debug a macro.
>
Which is why they are best avoided. With the exception of passing file
name and line number to debug logs, I don't think I've used a macro in
C++ in the past decade.

--
Ian Collins.

Peng Yu wrote:

> Hi,
>
> It is benifitical to use macro in certain cases.
>
> http://www.boost.org/doc/libs/1_35_0...doc/index.html
>
> 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.
>
> In this sense, if I want to debug the code easily, should I avoid
> using macros. Are there any better way to debug macros?

Look at the output of the preprocessor. I think most compilers allow you to
do that. This way, you can see what the macro expands to.


Best

Kai-Uwe Bux

> It is benifitical to use macro in certain cases.

Use macros for...

- conditional compilation
- token pasting
- stringerization

but, naturally, try to avoid _those_ things unless the alternatives are
worse.

On Jun 28, 9:23pm, 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.

Greg

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