Boost logo

Boost :

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

> - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. See
>> local/doc/html/BOOST_IDENTITY_**TYPE.html<>
>> - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to
>> boost/utility. See
>> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at