From: Jeff Garland (jeff_at_[hidden])
Date: 2005-06-30 21:53:20
On Fri, 01 Jul 2005 06:50:36 +0800, Joel de Guzman wrote
> Here's my rationale for the macro-less Interfaces:
> 1) An interface is supposed to be read a lot of times. It has
> to be immediately understandable to the human parser. It is
> not an implementation detail. It is a contract.
It's the human parser that's the real problem -- no question ;-) To quote
myself from Feb of this year:
"Also, I really hate macros for doing these sorts of things because I have to
reverse engineer what the macro is doing when I need to read the code. At a
minimum that means I need to go to another file, try and grok whether the
macro applies to what I'm doing, mentally add in whatever functions/types it
creates. I'm getting too old for these sorts of mental gymnastics -- I'd
rather have the code just written out."
I'd add to this that THE ALL CAPS STUFF IN CODE GETS REALLY TIRESOME TO READ
MAKING CODE LOOK UGLY in my view. Of course macros don't technically "have to
be all caps", but well they mostly are to prevent more serious problems.
> 2) I need one that can be parsable by a documentation extraction
> tool such as Doxygen and Synopsis. This is very important!
> Interfaces need to be documented.
These can be expanded before processing, although last I knew some debuggers
have problems dealing with macros. Certainly tool vendors have said one
reason they can't easily implement C++ tools (like say refactoring tools) is
b/c of complications created by macros in C++.
> 3) You can have both! If you still insist on using macros, then
> by all means, use them.
Having the option is exactly the right approach -- when feasible. I'm really
interested in Boost.Interfaces -- this looks like an incredibly cool design
approach, but I, like you, would be put off by the need to use lots of macros
in application code. So thx Joel!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk