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@wanadoo.fr> 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