Re: [boost] Boost.Local Review (Nov 10, 2011 to Nov 19, 2011)

Subject: Re: [boost] Boost.Local Review (Nov 10, 2011 to Nov 19, 2011)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-11-14 16:26:07

Le 14/11/11 19:15, Jeffrey Lee Hellrung, Jr. a écrit :
> On Mon, Nov 14, 2011 at 9:49 AM, Vicente J. Botet Escriba<
> vicente.botet_at_[hidden]>  wrote:
>
>> Le 10/11/11 06:31, Jeffrey Lee Hellrung, Jr. a écrit :
>>
> [...]
>
>> void f() {
>>
>>   BOOST_LOCAL_FUNCTION(template (typename T), T v)
>>     std::cout<<  hex<<  v;
>>   BOOST_LOCAL_FUNCTION_END(**print, std::string, double);
>>
>>   // use of print with doublke or string
>>
>>   ...
>> }
>>
>> I don't have a concrete use case now,  but could something like this be
>> implemented?
>>
> I don't think you can define templates of any kind (function or class) at
> function scope (...yet?).
Oups, my bad :(
>
> Please also consider the following issues and proposals specific to
>>> Boost.Local.  Your opinion is welcome on any or all of these.
>>>
>>> - Boost.Local's local exits provide the same functionality (and then some)
>>> as Boost.ScopeExit.  Does this duplication of functionality need to be
>>> dealt with, and if so, how?
>>>
>> I think that both libraries could be merged in a Scoped library as
>> suggested by Lorenzo in the documentation. Once the Scoped library is
>> released, the ScopedExit library could be set as deprecated during a
>> certain time, before removing it definitively, as it occurred with
>> Boost.Compose.
>>
> I think Boost.Scope or Boost.Scoped wouldn't be bad names for a merged
> library (the current name Boost.Local I think is also fine).
I don't know if in English Locale and Local sound enough different, but 
for me there is no big difference. I will prefer a distinct  name.
>
>   - Lorenzo is proposing to add boost::local::function::**overload to
>>> Boost.Function as boost::function::overload.  See
>>> https://svn.boost.org/svn/**boost/sandbox/local/libs/**
>>> local/doc/html/boost/local/**function/overload.html<https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/local/function/overload.html>
>>>
>> An alternative could be to include it in the Functional library, together
>> with forward and factory.
>>
> I'm currently thinking that unless there's a positive push to move
> boost::local::function::overload out of Boost.Local, it will remain in
> Boost.Local.
>
I have no problem. It was just an idea.
>>   - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility.  See
>>> https://svn.boost.org/svn/**boost/sandbox/local/libs/**
>>> local/doc/html/BOOST_IDENTITY_**TYPE.html<https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDENTITY_TYPE.html>
>>> - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to
>>> boost/utility.  See
>>> https://svn.boost.org/svn/**boost/sandbox/local/libs/**
>>> local/doc/html/BOOST_IDENTITY_**VALUE.html<https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDENTITY_VALUE.html>
>>>
>> I guess that both macros could be better be included in Boost.Preprocessor.
>>
> Except that both IDENTITY_TYPE and IDENTITY_VALUE are intimately related to
> C++ types and C++ expressions; and, AFAIK, the Boost.Preprocessor library
> has no facilities meant to directly address either, i.e., it operates
> purely in "preprocessor space".  I would think the aforementioned macros
> are more like BOOST_STATIC_CONSTANT than anything in Boost.Preprocessor.
You are right, even if the main goal is purely to solve a preprocessor 
issue, the solution goes behind the scope of Boost.Preprocessor.

Best,
Vicente