This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Alternate approach to keeping convenience variables


> >     GDB developers seem to have developed an allergy to C macros that
> >     I just don't understand.  They're not _inherently_ obfuscating
> >     or evil!  They can be both useful and elegant.
> 
> FWIW, I never understood the ``macros are bad, m'kay?'' policy,
> either.

Well, it is clear to me that a unilateral decision against macros might
be a bit too extreme. I think that some of the macro usage in GDB could
be advantageously replaced with something better, though.

I don't have the luxury to always debug on platforms where dwarf2 is
available. So I can't print the value of a macro in the debugger. When
I debug some code and see a function call in the form of the macro,
I can't inspect a function pointer variable, I have to step into the
code to follow it. Same for contant macros. You can't take the address
of a macro either. Even with dwarf2, I don't know how much people use
this new feature that allows us to access macros from the debugger.

There are cases where macros a the best solution too. I found the new
try/catch mechanism a huge improvement over the catch_error abstraction.
A nice additional layer to make programing easier. Same for the
ALL_OBJFILE-like macros. They make the code simpler to write without
propagating too much the details about the structure.

So I welcome the usage of macros. But not without discrimination.

-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]