Re: [boost] Rave for proposed Boost.Local (functions)

Subject: Re: [boost] Rave for proposed Boost.Local (functions)
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-02-05 12:14:10

On Wed, Feb 2, 2011 at 6:31 AM, Mathias Gaunard
<mathias.gaunard_at_[hidden]> wrote:
> On 02/02/2011 08:46, Michael Caisse wrote:
>>
>> On 02/01/2011 11:24 PM, Jeffrey Lee Hellrung, Jr. wrote:
>>>
>>> It might help Lorenzo's cause to give specific examples where he (or
>>> anyone else) feels the (proposed) Boost.Local construct is superior in
>>> some way to the Boost.Phoenix construct.
>>>
>>
>> Agreed. As a heavy user of Phoenix 2.0 I am unable to see the
>> improvements over existing Phoenix or the anticipate release of 3.0. A
>> list of benefits over existing solutions as well as known limitations
>> would be extremely helpful in determining the relevance of this proposed
>> library.
>
> I can see one clear advantage: error messages are readable.

That is true for the error within the function body. The function body
is normal C++ syntax and it is programmer *outside* the macro
programmers get the usual C++ error messages (which might already be
cryptic enough ;) ), error line numbers, etc (this is also spelled out
as the main Rationale for keeping the body code outside the macro
parameters in the library doc).

However, errors within the macro when specifying the parenthesized
syntax can lead to cryptic preprocessor errors. The macro parser
attempt to to so basic syntax checking for the parenthesized syntax
but while this error checking could be (and probably should be)
improved there are fundamental limitation about what can be done
(e.g., there is no way I can gracefully detect and report missing
closing parenthesis `)` ). The parenthesized syntax errors which are
detected are gracefully reported as compiler-errors using static
assertions (BOOST_MPL_ASSERT...). That said, in my experience when you
get cryptic preprocessor errors, you take a good look at the
parenthesized syntax and you just find the problem, plus after a while
you get used to the parenthesized syntax and you just get it right in
the first place. This library limitation is well discussed in the
library doc.

On Wed, Feb 2, 2011 at 5:12 PM, Mathias Gaunard
<mathias.gaunard_at_[hidden]> wrote:
> On 02/02/2011 13:23, Thomas Heller wrote:
>
>> To quote the Boost.Local docs:
>> "Warning
>> Unfortunately, there are intrinsic limitations to the amount of syntactic
>> error checking that can be done by the parsing macros implemented using
>> the
>> preprocessor. As a consequence, an error in using the parenthesized syntax
>> might result in cryptic preprocessor errors. The best way to identify and
>> correct these errors is usually to visually inspect the signature
>> comparing
>> it with the parenthesized syntax grammar (see the Grammar section). When
>> syntactic errors can be detected by the parsing macros, they are raised at
>> compile-time using error messages of the form ERROR_description_text."
>
> Enumeration of parameters and bindings is not where code complexity is.

Yes, I agree. Most of the complexity of the code is (usually) in the
local function definition (normal compiler errors) and not in its
declaration (sometimes cryptic preprocessor errors) so in my
experience this is an important plus for Boost.Local overall.

To people that have experimented with Boost.Local:
1) Did you find it hard to write the parenthesized syntax declarations?
2) Did you find it hard to find and correct eventual parenthesized
syntax errors you made? (If so, this I might be able to improve it a
bit...)

-- 
Lorenzo