Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-07-18 10:57:55


David Abrahams <dave_at_[hidden]> writes:

> "Peter Dimov" <pdimov_at_[hidden]> writes:
>
>> David Abrahams wrote:
>>
>>> FWIW, one of the main reasons I brought this issue up was that I
>>> was hoping you'd convince me that the reasons to do it your way were
>>> important enough to outweigh the reasons to go the other way.
>>
>> If you let people add a semicolon after the macro, how can you change the
>> macro later in a way that doesn't tolerate a trailing semicolon? The
>> expansion of the macro is an implementation detail; the interface shouldn't
>> depend on a particular expansion.
>>
>> Right?
>
> I agree; that's the first argument I find truly compelling. All the
> other ones, including the arguments I started with, seem a bit weak by
> comparison.
>
> Thank you.
>
> I am still hesitating though, because the macros in question aren't
> really an abstraction: the library is designed to be usable without
> the macros (in case you don't like them or whatever), and the
> library documents exactly what they generate.

Having given this further thought, I don't think it matters that
they're not an a very strong abstraction. It still might make sense
to change the library in the future in a way that's compatible with
the "normal" usage of the old macro.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

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