Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2005-06-30 17:50:36


Arkadiy Vertleyb wrote:
> "christopher diggins" <cdiggins_at_[hidden]> wrote
>
>
>>"Arkadiy Vertleyb" <vertleyb_at_[hidden]> wrote in message
>>
>>>So why a solution that clearly involves repeating things multiple times
>>>is less ugly than a macro-based approach, that allows to avoid
>>>duplication?
>>
>>He is entitled to his opinion, Arkadiy. Your comments are disparaging and
>>disrespectful of his contribution.
>
>
> I didn't mean to be disrespectful, and I don't think I was,
> but I do apologize if it sounded like this...
>
> But I am also entitled to my opinion, and this opinion is that any
> solution that doesn't involve duplication is, by definition, cleaner
> than one that does. Firthermore, I do think that the goal of
> eliminating macros for the sake of eliminating macros is not a right
> goal. Therefore, while deeply respecting the author of this proposal,
> I simply think, based on his motivation, that this is a step
> in the wrong direction.

No offense taken :) I understand your position.

I am not against macros per se. I use macros all the time now
if it's clearly the best solution to a particular problem. I
have voted for Eric Niebler's FOR_EACH, for instance. I believe
it (FOR_EACH) is the best solution given the limited tools we
have for solving the matter at hand. With BIL, I am not quite
sure...

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.
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.
3) You can have both! If you still insist on using macros, then
    by all means, use them.

Regards,

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk