- Boost - lists.boost.org

[review] [Local] Review Result - ACCEPTED
by Jeffrey Lee Hellrung, Jr. 13 Dec '11

13 Dec '11

Local is ACCEPTED into Boost. After following the lively Local review discussion several weeks ago, and reviewing the discussion a second (and sometimes third) time, I have come to the above conclusion. There was quite a bit of passion on both the sides of "aisle", and thus, obviously, no decision I make would be well-received by all. Let me start by summarizing the main arguments against including Local in Boost: (a) Local functions are not very useful, at least in the presence of existing alternatives (e.g., namespace functions and Boost.Phoenix). (b) Local is really a portability library for C++03 presenting an imperfect emulation of features readily available in C++11. (c) Local's interface is primarily macro-based, making code ugly and difficult to read. In my opinion as the review manager, a sufficient number of individuals in the discussion found the library "useful" to address (a) (sometimes with additional positive adverbs); indeed, at least a couple individuals have shared positive experiences with real-world use. Namespace functions require one to move code to somewhere other than where one may prefer to have it, and often requires a significant amount of boilerplate when binding local variables. Aside from any perceived issues with Boost.Phoenix's syntax and compiler error messages, it has been noted that binding member functions within Boost.Phoenix can get ugly. As far as (b) is concerned, the community seems pretty far from reaching a consensus on whether a library described by (b) belongs in Boost. There are certainly libraries currently in Boost that could be pegged to satisfy (b) as well, though they all have other mitigating features they make their situation different from Local in some way. As far as (c) is concerned, several have acknowledged that a macro-based interface is necessary to implement local functions in C++03, and it seems to have been generally agreed that, given this limitation, Lorenzo has done an admireable job making the interface as easy-to-use as possible. Some find it ugly, others find it reasonable. In addition to the counterarguments of (a-c) above, the following facts weighed into my final decision: * Lorenzo has been engaging and in constant communication with the developer's list during the development of Local. This gives me confidence that he will continue to actively maintain (and improve?) Local. * The documentation is unanimously agreed to be of Boost quality. * The transition of some organizations from C++03 to C++11 may take several more years, and Boost has a history of supporting "ancient" compilers (for better or worse). The point being, a library that eases the transition from C++03 to C++11 has some merit based on current precedent. * There had been previous work on local functions by Alexander Nasanov and Steven Watanabe shared on the developer's list, suggesting a desire for this functionality for some time. * Local is approximately an extension of Boost.ScopeExit; indeed, it basically fulfills the request to Alexander Nasanov from the review result [2] of Boost.ScopeExit to create such an extension. Lastly, my own opinion of "what Boost is" factored in here. I view Boost as *partly* a collection of general purpose libraries that can be used in wide variety of applications (and thus Boost frequently acts as a staging ground for standard adoption). Based on review feedback, I believe Local satisfies this criterion; and based on the mailing list discussion, I believe this view of Boost is not entirely inconsistent with others on the mailing list. Ultimately, it wasn't so much a # of "yes" votes versus # of "no" votes as it was the above general considerations. Regardless, I think independent of how the votes were counted, the "yes" votes outnumbered the "no" votes. This required some discretion on my part as not everyone who expressed an opinion submitted a formal review, and some participants were only arguing in favor of some specific point supporting either acceptance or rejection of Local. "Yes" reviews (7) -------- Krzysztof Czainski Andrzej Krzemienski Pierre Morcello Nat Lindon John Bytheway Edward Diener Gregory Crosswhite "No" reviews (3) -------- Vicente J. Botet Thomas Heller Hartmut Kaiser Paul A. Bristow and Alexander Nasanov (the author of Boost.ScopeExit) both submitted reviews but did not express an opinion (as far as I could tell) on whether Local should be included in Boost, though if I had to peg Paul's, it would be to reject Local. From what I gathered, Joel de Guzman, Joel Falcou, Dean Michael Berris, and Lucanus J. Simonson were opposed to including Local in Boost (the aforementioned did not submit a formal review, though a formal review might be unnecessary if your vote is "no"). On the other hand, Brian Wood, Philippe Vaucher, Mathias Gaunard, Robert Ramey, Nathan Ridge, Brent Spillner, Thomas Klimpel, Christopher Jefferson, Daniel James, Rafael Fourquet, Matthias Schabel, and Robert Stewart participated in the discussion and argued in favor of some point that supported accepting Local in Boost. I want to be clear here that certainly not everyone in the aforementioned list even implied that they supported acceptance of Local (I would guess that only roughly half implied as much), but they indirectly helped its case by addressing arguments against inclusion. Overall, that indicates to me that more individuals support acceptance of Local into Boost than rejection. [Apologies for any name misspellings and absent accents.] Regarding Boost.ScopeExit: 4 reviews were in favor of deprecating Boost.ScopeExit; 3 reviews felt there was nothing wrong with both Boost.ScopeExit and Local coexisting; and 3 reviews mentioned the possibility of improving Boost.ScopeExit with the features provided by Local's exits. As such I'm inclined to let Alexander (who opposed any kind of merging of Local and Boost.ScopeExit) work with Lorenzo on improving Boost.ScopeExit as he sees fit, and hopefully both libraries can address this apparent duplication of functionality within their respective documentation to avoid user confusion. Regarding local::function::overload: Based on the review comments, it makes the most sense to add this to Boost.Functional. Regarding BOOST_IDENTITY_TYPE: This should be added to Boost.Utility. On the other hand, there doesn't appear to be a compelling use case for BOOST_IDENTITY_VALUE. The following are some suggested *possible* improvements that reviewers brought up. This list is by no means exhaustive. Further, I personally don't think all of these suggestions are necessarily "good", but I think it's fair for Lorenzo (and the community) to consider them nonetheless. Parenthetic comments are my own opinions. * Some aren't convinced of the utility of LOCAL_BLOCK. (It's use cases appear fairly narrow so it might be best to simplify the library and remove this capability.) * Use "this_" (as opposed to "_this") as an alias for "this" within function bodies, and possibly also within bind declarations. * Present Boost.PP sequence interface as a workaround for the variadic interface? (I don't have a problem with supporting both interfaces at the top level.) * "Local" and "Locale" look too much alike, suggesting a name change to "Scope", "Scoped", "LocalFunction", "Closure" may be a good idea? * Allow use without dependence on Boost.TypeOf. * Rename prefix and postfix macros from XXX_PARAMS/XXX_NAME to XXX/XXX_END? (I don't mind the current macros.) * Explicitly separate bound variables from function parameters. (I think this suggestion has merit but I don't know what the interface could look like.) * Remove support for default parameters to simplify interface and documentation? (It doesn't seem like default function parameters would be very useful.) * Use "capture" instead of "bind" for the bind/capture keyword? (I like and prefer "bind".) Finally, here the links to the submitted formal reviews, for reference. Of particular note are Krzysztof's and John's reviews for their comments on the documentation. Some "yes" votes were conditional, but AFAIK Lorenzo has already agreed to address the relevant conditions. Krzysztof Czainski http://permalink.gmane.org/gmane.comp.lib.boost.devel/225543 Vicente J. Botet http://permalink.gmane.org/gmane.comp.lib.boost.devel/225604 Andrzej Krzemienski http://permalink.gmane.org/gmane.comp.lib.boost.devel/225656 Paul A. Bristow [...cannot find link to review...] Pierre Morcello http://permalink.gmane.org/gmane.comp.lib.boost.devel/225694 Nat Lindon http://permalink.gmane.org/gmane.comp.lib.boost.user/71508 Thomas Heller http://permalink.gmane.org/gmane.comp.lib.boost.devel/225736 Hartmut Kaiser http://permalink.gmane.org/gmane.comp.lib.boost.devel/225745 John Bytheway http://permalink.gmane.org/gmane.comp.lib.boost.devel/225746 Alexander Nasanov http://permalink.gmane.org/gmane.comp.lib.boost.devel/225783 Edward Diener http://permalink.gmane.org/gmane.comp.lib.boost.devel/225795 Gregory Crosswhite http://permalink.gmane.org/gmane.comp.lib.boost.devel/225807 Finally, really big thanks to everyone for participating in the review and ancillary discussions. I attempted to be as transparent as possible in outlining the rationale for my decision above, but if you have any further questions, do not hesitate to ask. - Jeff, Review Manager for Local [1] http://thread.gmane.org/gmane.comp.lib.boost.devel/168612 [2] http://lists.boost.org/boost-announce/2008/05/0190.php

7 6

[test, parameter, fusion] en/disable_if name clash in trunk
by Tim Blechmann 13 Dec '11

13 Dec '11

it seems that the new boost::unit_test::decorator::enable_if, introduced in [1] clashes with boost::enable_if under certain circumstances. this currently breaks the boost.heap testsuite (see [2]). maybe the test/parameter/fusion maintainers could discuss, how that can be resolved? thanks, tim [1] https://svn.boost.org/trac/boost/changeset/74663 [2] http://www.boost.org/development/tests/trunk/developer/heap.html

4 14

Question regarding parallel boost graph library status
by Delalondre Fabien Jonathan 13 Dec '11

13 Dec '11

Hi, I would like to use the parallel boost graph library for projects I am working on and was wondering whether I could get an update on its development. I am for example wondering: 1) Whether this is still an projet under active development and how many people are working on it. 2) What the status of the mpi/threading implementation is. 3) What are the machines on which the implementation has been tested (and on how many processors). I am interested in using it on HPC machines such as Cray and IBM which includes more than 100k processors. Thank you, Fabien Delalondre

2 1

Use constexpr with BOOST_STATIC_CONSTANT?
by Daryle Walker 12 Dec '11

12 Dec '11

Should BOOST_STATIC_CONSTANT be changed to add the C++11 "constexpr" attribute, if it's defined? I guess we would need a preprocessor flag to check if constexpr is available.

3 2

[regex] compilation warnings questions by a newbee
by Rai, Neeraj 12 Dec '11

12 Dec '11

Hi All, Reposting this based on feedback from Beman. I get the same error with latest boost. I earlier posted this to user group and atleast one user confirmed (s)he was getting the same error with newer version and not getting any error with older one. It is a simple program (just declares regex). Pls advise. Thx Neeraj _____________________________________________ From: Rai, Neeraj [ICG-MKTS] Sent: Friday, December 09, 2011 1:29 PM To: 'boost(a)lists.boost.org' Subject: [boost-dev] compilation warnings questions by a newbee Hi, I am writing my first boost program and having trouble with the compiler warning against boost 1.44.0. Is there any way to get rid of those warnings so I can focus on real warnings in my code ? This seems to happen with newer version of g++ : tried 4.4.5 and 4.6 The gist of warning is : boost_1_44_0/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: warning: the result of the conversion is unspecified because '-0x00000000000000001' is outside the range of type 'boost::numeric::udt_builtin_mixture_enum' [-Wconversion] Any help or pointers are appreciated. Neeraj ====== The following program is a cut down version of my code, just declares sregex #include <iostream> #include <boost/xpressive/xpressive.hpp> int main (int _argc, const char** _argv) { std::cout << "argc=" << _argc << " argv=" << _argv << std::endl; using namespace boost::xpressive; std::string keyword(""); sregex const re(sregex::compile(keyword, sregex::icase)); } ====== The following cmd is used to build it (tried g++ v 4.4.5 and 4.6 with same results) g++ -ftemplate-depth-128 -O0 -fno-inline -Wall -g -Wconversion -Wno-strict-aliasing -Wextra -Wnon-virtual-dtor -Wno-missing-field-initializers -Wno-array-bounds -Wno-ignored-qualifiers -Wno-parentheses -Wno-strict-aliasing -fPIC -DBOOST_ALL_NO_LIB -I/work/loc1/atddds -I/work/loc1/boost_1_44_0/include -Iinclude -c -o boost_regex_test.o boost_regex_test.cpp ====== The following cmd is used to build it (tried g++ v 4.4.5 and 4.6) g++ -ftemplate-depth-128 -O0 -fno-inline -Wall -g -Wconversion -Wno-strict-aliasing -Wextra -Wnon-virtual-dtor -Wno-missing-field-initializers -Wno-array-bounds -Wno-ignored-qualifiers -Wno-parentheses -Wno-strict-aliasing -fPIC -DBOOST_ALL_NO_LIB -I/work/loc1/atddds -I/work/loc1/boost_1_44_0/include -Iinclude -c -o boost_regex_test.o boost_regex_test.cpp In file included from /work/loc1/boost_1_44_0/include/boost/mpl/integral_c.hpp:32:0, from /work/loc1/boost_1_44_0/include/boost/type_traits/integral_constant.hpp:11, from /work/loc1/boost_1_44_0/include/boost/type_traits/detail/bool_trait_def.hpp:15, from /work/loc1/boost_1_44_0/include/boost/type_traits/is_volatile.hpp:40, from /work/loc1/boost_1_44_0/include/boost/type_traits/remove_const.hpp:14, from /work/loc1/boost_1_44_0/include/boost/proto/proto_fwd.hpp:25, from /work/loc1/boost_1_44_0/include/boost/xpressive/xpressive_fwd.hpp:53, from /work/loc1/boost_1_44_0/include/boost/xpressive/detail/detail_fwd.hpp:24, from /work/loc1/boost_1_44_0/include/boost/xpressive/regex_primitives.hpp:21, from /work/loc1/boost_1_44_0/include/boost/xpressive/xpressive_static.hpp:24, from /work/loc1/boost_1_44_0/include/boost/xpressive/xpressive.hpp:18, from boost_regex_test.cpp:2: /work/loc1/boost_1_44_0/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 'mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>': /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/meta.hpp:30:13: instantiated from 'boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u> >' /work/loc1/boost_1_44_0/include/boost/mpl/if.hpp:67:11: instantiated from 'boost::mpl::if_<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u> >, boost::mpl::identity<boost::numeric::convdetail::get_subranged_BuiltIn2BuiltIn<unsigned char, int> >, boost::mpl::eval_if<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)1u> >, boost::mpl::identity<boost::mpl::identity<boost::numeric::convdetail::subranged_BuiltIn2Udt<unsigned char, int> > >, boost::mpl::if_<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)2u> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2BuiltIn<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2Udt<unsigned char, int> > > > >' /work/loc1/boost_1_44_0/include/boost/mpl/eval_if.hpp:37:41: instantiated from 'boost::mpl::eval_if<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u> >, boost::mpl::identity<boost::numeric::convdetail::get_subranged_BuiltIn2BuiltIn<unsigned char, int> >, boost::mpl::eval_if<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)1u> >, boost::mpl::identity<boost::mpl::identity<boost::numeric::convdetail::subranged_BuiltIn2Udt<unsigned char, int> > >, boost::mpl::if_<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)2u> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2BuiltIn<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2Udt<unsigned char, int> > > > >' /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/meta.hpp:82:9: instantiated from 'boost::numeric::convdetail::ct_switch4<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)1u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)2u>, boost::numeric::convdetail::get_subranged_BuiltIn2BuiltIn<unsigned char, int>, boost::mpl::identity<boost::numeric::convdetail::subranged_BuiltIn2Udt<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2BuiltIn<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2Udt<unsigned char, int> > >' /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/udt_builtin_mixture.hpp:45:9: instantiated from 'boost::numeric::convdetail::for_udt_builtin_mixture<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, boost::numeric::convdetail::get_subranged_BuiltIn2BuiltIn<unsigned char, int>, boost::mpl::identity<boost::numeric::convdetail::subranged_BuiltIn2Udt<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2BuiltIn<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2Udt<unsigned char, int> > >' /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/is_subranged.hpp:206:11: [ skipping 9 instantiation contexts ] /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:281:13: instantiated from 'boost::xpressive::detail::sequence<BidiIter> boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::parse_alternates(FwdIter&, FwdIter) [with FwdIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >]' /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:212:75: instantiated from 'boost::xpressive::basic_regex<BidiIter> boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::compile_(FwdIter, FwdIter, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type, std::forward_iterator_tag) [with FwdIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:120:60: instantiated from 'boost::xpressive::basic_regex<BidiIter> boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::compile(InputIter, InputIter, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type) [with InputIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:129:71: instantiated from 'typename boost::disable_if<boost::is_pointer<InputRange>, boost::xpressive::basic_regex<BidiIter> >::type boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::compile(const InputRange&, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type) [with InputRange = std::basic_string<char>, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >, typename boost::disable_if<boost::is_pointer<InputRange>, boost::xpressive::basic_regex<BidiIter> >::type = boost::xpressive::basic_regex<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' /work/loc1/boost_1_44_0/include/boost/xpressive/basic_regex.hpp:193:61: instantiated from 'static boost::xpressive::basic_regex<BidiIter> boost::xpressive::basic_regex<BidiIter>::compile(const InputRange&, boost::xpressive::basic_regex<BidiIter>::flag_type) [with InputRange = std::basic_string<char>, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, boost::xpressive::basic_regex<BidiIter>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' boost_regex_test.cpp:9:57: instantiated from here /work/loc1/boost_1_44_0/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: warning: the result of the conversion is unspecified because '-0x00000000000000001' is outside the range of type 'boost::numeric::udt_builtin_mixture_enum' [-Wconversion] /work/loc1/boost_1_44_0/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 'mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>': /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/meta.hpp:30:13: instantiated from 'boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u> >' /work/loc1/boost_1_44_0/include/boost/mpl/if.hpp:67:11: instantiated from 'boost::mpl::if_<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u> >, boost::mpl::identity<boost::numeric::convdetail::get_subranged_Int2Int<unsigned char, int> >, boost::mpl::eval_if<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)1u> >, boost::mpl::identity<boost::mpl::identity<boost::numeric::convdetail::subranged_Int2Float<unsigned char, int> > >, boost::mpl::if_<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)2u> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Int<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Float<unsigned char, int> > > > >' /work/loc1/boost_1_44_0/include/boost/mpl/eval_if.hpp:37:41: instantiated from 'boost::mpl::eval_if<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u> >, boost::mpl::identity<boost::numeric::convdetail::get_subranged_Int2Int<unsigned char, int> >, boost::mpl::eval_if<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)1u> >, boost::mpl::identity<boost::mpl::identity<boost::numeric::convdetail::subranged_Int2Float<unsigned char, int> > >, boost::mpl::if_<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)2u> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Int<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Float<unsigned char, int> > > > >' /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/meta.hpp:82:9: instantiated from 'boost::numeric::convdetail::ct_switch4<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)1u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)2u>, boost::numeric::convdetail::get_subranged_Int2Int<unsigned char, int>, boost::mpl::identity<boost::numeric::convdetail::subranged_Int2Float<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Int<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Float<unsigned char, int> > >' /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/int_float_mixture.hpp:63:9: instantiated from 'boost::numeric::convdetail::for_int_float_mixture<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, boost::numeric::convdetail::get_subranged_Int2Int<unsigned char, int>, boost::mpl::identity<boost::numeric::convdetail::subranged_Int2Float<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Int<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Float<unsigned char, int> > >' /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/is_subranged.hpp:184:35: [ skipping 10 instantiation contexts ] /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:281:13: instantiated from 'boost::xpressive::detail::sequence<BidiIter> boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::parse_alternates(FwdIter&, FwdIter) [with FwdIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >]' /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:212:75: instantiated from 'boost::xpressive::basic_regex<BidiIter> boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::compile_(FwdIter, FwdIter, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type, std::forward_iterator_tag) [with FwdIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:120:60: instantiated from 'boost::xpressive::basic_regex<BidiIter> boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::compile(InputIter, InputIter, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type) [with InputIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:129:71: instantiated from 'typename boost::disable_if<boost::is_pointer<InputRange>, boost::xpressive::basic_regex<BidiIter> >::type boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::compile(const InputRange&, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type) [with InputRange = std::basic_string<char>, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >, typename boost::disable_if<boost::is_pointer<InputRange>, boost::xpressive::basic_regex<BidiIter> >::type = boost::xpressive::basic_regex<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' /work/loc1/boost_1_44_0/include/boost/xpressive/basic_regex.hpp:193:61: instantiated from 'static boost::xpressive::basic_regex<BidiIter> boost::xpressive::basic_regex<BidiIter>::compile(const InputRange&, boost::xpressive::basic_regex<BidiIter>::flag_type) [with InputRange = std::basic_string<char>, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, boost::xpressive::basic_regex<BidiIter>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' boost_regex_test.cpp:9:57: instantiated from here /work/loc1/boost_1_44_0/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: warning: the result of the conversion is unspecified because '-0x00000000000000001' is outside the range of type 'boost::numeric::int_float_mixture_enum' [-Wconversion]

1 1

Re: [boost] FW: FW: Proposal for a Differential Evolution C++ library
by Adrian Michel 12 Dec '11

12 Dec '11

On 12/12/2011 7:19 AM, Sebastian Redl wrote: > Your website went down, it redirects the webhost's site. My apologies - I ftp-ed an updated version of the documentation with the wrong structure - instead of it being located at .../de/doc/html/... it was at .../de/html, as Thomas Kimpel noted in his reply. It should work again shortly. Also, I realized posting urls for individual documentation pages was a mistake, as I don't believe doxygen guarantees they will stay the same as the documentation evolves, so if you notice any errors when accessing the Overview or Tutorial urls, try the documentation home page http://www.amichel.com/de/doc/html/. Thanks both. Adrian

1 0

A demonstration of why horrendous error messages can destroy usability
by Gregory Crosswhite 12 Dec '11

12 Dec '11

At the unfortunate risk of reopening a poisonous argument, I just wanted to relate an experience I had just earlier today to emphasize a point that I and others tried to make a couple of weeks ago. For the last couple of days I have been trying to get Digikam to compile on my machine using MacPorts. Getting software written for Linux to compile on OSX is always a bit of a black art, so I wasn't surprised when I started running into hurdles. The first problem that I ran into was that I had set Python 3.1 to be my default rather than Python 2.7, which screwed up the libplist CMake configuration script; fortunately, although I had to scratch my head for a few minutes, it was clear roughly where the error was taking place and that gave me enough information to eventually figure out where the problem was. I also went ahead and filed a bug report to MacPorts to let them know about this problem. After that it was smooth sailing until I got to the final package, Digikam itself. Unfortunately, it refuses to build. Why is that? For reasons that apparently took an overwhelming *56 kilobytes of error message* to explain. (See attached, if you dare. ) Now, you could argue that this is the fault of the compiler for not being more helpful, the fault of Digikam for using deprecated methods, the fault of MacPorts for creating a bad environment for configuration, or whatever else you want. You could also argue that were I familiar with Boost and/or the Digikam codebase then the implication of this message would be obvious --- heck, maybe it even *is* obvious to many of the people here. All of this is beside the point, though. I am not an expert in any of these codebases and I really don't care whether it is ultimately the fault of Boost, Digikam, Qt, MacPorts, or the compiler for producing such horrendous error messages. All that matters to me is that these pages of error messages are so overwhelming that they make it very difficult for me to get any sense at all of what kind of thing is going wrong so that I can track down what needs to be done to fix it. Furthermore, the error message is such a mess that it is hard for me to even *motivate* myself to *want* to go through it to figure out where is going on, and seeing the impact that this kind of thing can have on end users really turns me off a bit from the idea of continuing to use Boost libraries in my projects in the future. That is to say, I had heard people in the past say that they actively avoid Boost (and sometimes even C++) because of the way they introduced nasty complexities (like horrible error messages), and I used to (politely :-) ) scoff at them because I figured that they were overstating the problems in practice. Now however, having experienced these problems from the viewpoint of a casual user who just wants to get some darn code to compile so that I can run a program I wanted to try out, I can really appreciate their point. To be perfectly clear, I am not saying that this has made me never want to use Boost again, for I really hate rolling out my own code to solve a problem when somebody else has already developed and tested a solution for me. :-) My point is exactly and *only* the following: horrendous error messages are a *big deal* with a *serious impact* on usability not only for the developers using a library, but for end-users who want to compiler and use the software being developed. Most people here fortunately already seem to recognize this, but I have been truly shocked to hear so many arguments that horrendous error messages are *not* a serious problem, either because they are someone else's fault, because they only occur when the code is wrong, or --- worst of all --- because it is ultimately the fault of the user for being ignorant or lazy when he or she cannot quickly figure out what the problem causing the message was. So I just wanted to share this anecdote to provide a real-world example where horrendous error messages have added an incredible cost for a relatively technically experienced end-user to actually use a particular piece of software. And once more, I am sorry to bring this tired point up again, it's just that the experience I had today really reminded me just how frustrating these kinds of error messages can be, and the absurdity of denying that this is in any way a problem. I feel very strongly that the ultimate goal of writing software is not merely to push the boundaries of what we can do but to provide people with tools that make their lives easier. Horrendous error messages, even when there is no better design to accomplish a particular task (in C++, at least), are *really bad things* and should *not* be dismissed as something not worth fussing about, *especially* when fault is then placed on the *user* (as in some cases it sadly seemed to be) for being too ignorant or lazy to be willing to go to the trouble to decipher them. I am not claiming to know what the solution is to these kinds of issues, and in many cases there might not even be better solutions given the current design of C++. I was just very concerned to see that in the eyes of many the presence of such error messages are not considered in any way to be a problem (*) with a library, and to hear it claims that if anything users turned off by horrendous messages are simply being lazy by not just sucking them up for the good of the cause. Cheers, Greg (*) And let me be clear that by "problem" here I really do mean "less than ideal circumstance" rather than "flaw", because in many cases these libraries are very elegantly designed codes which are probably close to the optimal solution given the limits imposed by the C++ language.

5 8

[BGL] reverse_graph
by Fabien Castan 12 Dec '11

12 Dec '11

Hi, I have some troubles using boost::transpose_graph since boost 1.48. See the sample code. Fabien #include <boost/graph/graph_traits.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/copy.hpp> #include <boost/graph/transpose_graph.hpp> template<class GraphIn, class GraphOut> class Copier { public: Copier( const GraphIn& gIn, GraphOut& gOut ) : _gIn(gIn) , _gOut(gOut) {} template<class VIn, class VOut> void operator()(const VIn& vIn, VOut& vOut) { _gOut[vOut] = _gIn[vIn]; } private: const GraphIn& _gIn; GraphOut& _gOut; }; struct CustomVertex { }; struct CustomEdge { }; typedef boost::adjacency_list< boost::setS, // disallow parallel edges (OutEdgeList) boost::vecS, // vertex container (VertexList) boost::bidirectionalS, // directed graph CustomVertex, CustomEdge, boost::no_property, // no GraphProperty boost::listS // EdgeList > GraphContainer; int main( int argc, char** argv ) { const GraphContainer a; GraphContainer b; Copier< GraphContainer, GraphContainer > copier( a, b ); // still works as before boost::copy_graph( a, b, boost::vertex_copy(copier).edge_copy(copier) ); // works with boost 1.47, but doesn't compile with boost 1.48 boost::transpose_graph( a, b, boost::vertex_copy(copier).edge_copy(copier) ); //<<<<< }

2 4

Re: [boost] Proposal for a Differential Evolution C++ library
by Adrian Michel 12 Dec '11

12 Dec '11

I was asked this question regarding DE: >... The Boost Graph Library (BGL) >is often used for graph optimization purposes, and the geometry stuff >is used to do things like lay out integrated circuits with lots of >costs and constraints. There are the math and statistical functions. >Are these and other Boost libraries complementary or orthogonal to >your library? > I'm not familiar with BGL, but from its documentation, DE and BGL seem to be rather orthogonal. As for the math and statistical functions, I believe DE could complement these as yet another mathematical tool. Adrian Michel

1 0

Re: [boost] FW: Proposal for a Differential Evolution C++ library
by Adrian Michel 12 Dec '11

12 Dec '11

Hi Beman On 12/11/2011 6:31 PM, Beman Dawes wrote: > >> Would there be interest in a C++ Differential Evolution optimization (DE) >> library as part of boost? > > Seems interesting, and you've clearly put in a lot of work, and the > documentation makes a good initial impressions. But see below... > Thanks! >> The full documentation is at http://www.amichel.com/de/doc/html but I'd >> suggest these pages for a first read >> http://www.amichel.com/de/doc/html/dd/d53/overview.html and >> http://www.amichel.com/de/doc/html/db/d4e/tutorial.html . > > After skim reading the overview and the beginning of the tutorial, I > was left with several unanswered questions: > > * What are some practical scientific or engineering problems that DE > is good for? I personally got interested in DE while doing some research in the area of algorithmic trading system optimization. But DE is generic - it can be used to optimize any function that would otherwise be very hard or impossible to optimize using more traditional methods. DE is used in many areas, some of which are listed here: http://www.icsi.berkeley.edu/~storn/code.html#appl and here: http://www.icsi.berkeley.edu/~storn/code.html#comm or to summarize: chemistry, electronics, physics, agriculture, telecommunications etc. > I'm having trouble calibrating - is your library > primarily aimed at research and academic problems or is it an everyday > tool for use in a broad spectrum of organizations? > I believe the answer is "both". > * Who is the library aimed at? Is the library most likely to be used > by optimization specialists who already know about DE or is it > something that can be used by a wide range of programmers? > I tried to design the library so that it can be easily used "out of the box" by all programmers, who can choose any of the predefined policy classes for default behavior. The de_test application illustrates this usage mode: the user can implement a de::objective_function derived class with their own function to optimize, and then build and run the application to get the best output. However, those interested in tweaking its behavior, can create their own policy classes and override the defaults. One of the obvious advantage of a standardized DE library is that these customized components could then be shared with the community at large. BTW, DE has the added benefit of not having been patented by its authors, for the very purpose of making it widely available. Thanks, Adrian Michel

1 0