Boost logo

Boost :

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
>>> 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
>>> 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.
You are right, even if the main goal is purely to solve a preprocessor
issue, the solution goes behind the scope of Boost.Preprocessor.


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