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: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-11-14 13:15:21

Thanks for your Vicente!
[I haven't had time to go through the reviews from others yet, but will be
read through in short order.]

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?).

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).

 - 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.

>  - 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.

- Jeff