On Wed, Feb 2, 2011 at 6:31 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> 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@ens-lyon.org> 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