- Boost - lists.boost.org

trac error
by Steve M. Robbins 20 Dec '11

20 Dec '11

OperationalError: database is locked There was an internal error in Trac. It is recommended that you notify your local Trac administrator with the information needed to reproduce the issue. To that end, you could ==== How to Reproduce ==== While doing a GET operation on `/ticket/6131`, Trac issued an internal error. ''(please provide additional details here)'' Request parameters: {{{ {'id': u'6131'} }}} User agent: `#USER_AGENT#` ==== System Information ==== ''System information not available'' ==== Enabled Plugins ==== ''Plugin information not available'' ==== Python Traceback ==== {{{ Traceback (most recent call last): File "build/bdist.linux-i686/egg/trac/web/main.py", line 513, in _dispatch_request dispatcher.dispatch(req) File "build/bdist.linux-i686/egg/trac/web/main.py", line 258, in dispatch req.session.save() File "build/bdist.linux-i686/egg/trac/web/session.py", line 88, in save @self.env.with_transaction() File "build/bdist.linux-i686/egg/trac/db/api.py", line 77, in transaction_wrapper fn(ldb) File "build/bdist.linux-i686/egg/trac/web/session.py", line 132, in delete_session_cookie """, (self.last_visit, self.sid, authenticated)) File "build/bdist.linux-i686/egg/trac/db/util.py", line 65, in execute return self.cursor.execute(sql_escape_percent(sql), args) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 78, in execute result = PyFormatCursor.execute(self, *args) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 56, in execute args or []) File "build/bdist.linux-i686/egg/trac/db/sqlite_backend.py", line 48, in _rollback_on_error return function(self, *args, **kwargs) OperationalError: database is locked }}} a ticket. The action that triggered the error was: GET: /ticket/6131

2 1

LNK1104: cannot open file 'libboost_unit_test_framework-vc90-mt-gd-1_47.lib'
by ankit master 20 Dec '11

20 Dec '11

Hello, I am a newbie in the world of testing and using boost. I went through some of the previous discussion on this topic with no luck at trouble shooting my current issue. I am using visual c+ 2008 express edition, I tried installing boost using boostpro . I right click on project, and under c++ -> general -> additional dir; have added the following path. C:\Program Files (x86)\boost\boost_1_47 Now, when I try to run boost example I get the following error , No matter what I do I just cannot get rid of this error any help is greatly appreciated . 1>------ Build started: Project: UnitTestPrac1, Configuration: Debug Win32 ----- - 1>Linking... 1>LINK : fatal error LNK1104: cannot open file 'libboost_unit_test_framework- vc90-mt-gd-1_47.lib' 1>Build log was saved at "file://c:\Users\amaster\Desktop\AVM_Documents\CppPractise\UnitTestPrac1\UnitTes tPrac1\Debug\BuildLog.htm" 1>UnitTestPrac1 - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== // Following is my example #define BOOST_TEST_MODULE MyTest #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE(MyTestCase) { // To simplify this example test, let's suppose we'll test 'float'. // Some test are stupid, but all should pass. float x = 9.5f; BOOST_CHECK(x != 0.0f); BOOST_CHECK_EQUAL((int)x, 9); BOOST_CHECK_CLOSE(x, 9.5f, 0.0001f); // Checks differ no more then 0.0001% } Thank you in advance. Sincerely, -- >From the withered tree, a flower blooms. - Zen

2 1

[asio] running code before ssl initialization
by Isidor Zeuner 20 Dec '11

20 Dec '11

Hi, boost::asio::ssl::detail::openssl_init<true>::do_init initializes the SSL library using the static initialization hook, thereby preventing code being ran from main() which must be run before SSL initalization (for example custom allocators being set using CRYPTO_set_mem_functions). Is there an intended way to do so when using boost::asio::ssl? Best regards, Isidor

1 0

Boost compatible with Clang C++11 dialect?
by Torrey Lyons 19 Dec '11

19 Dec '11

When enabling C++11 support on Xcode 4.2 using Clang 3.0 there are many build conflicts in Boost. The C++11 language dialect is not on by default, but we would like to use it. Apparently Boost is not detecting that the compiler already has these features built in when C++11 support is turned on. Should we expect Boost 1.48.0 to work with Clang 3.0 using the C++11 language dialect? Is there a known workaround? Thanks for any tips or insights. -- Torrey VSee: torrey(a)vsee.com <http://vsee.com/call?torrey@vsee.com> | Cell: 310.940.6397 Teamwork made simple vsee.com Blog <http://vsee.com/blog/> Facebook <http://www.facebook.com/VSeeLab> Twitter <http://twitter.com/vsee>

1 0

[bind][phoenix] Compliance with function template bind
by Vicente J. Botet Escriba 19 Dec '11

19 Dec '11

Hi, Boosthas Boost.Bind and Boost.Phoenix that provides a bind function. Are them compliant with C++11 for 20.8.9 Function template bind (in particular move semantics)? If yes, how they work for C++03 compilers? If not, is there any plan to adapt them to support move semantics? Best, Vicente

2 3

[Concept Checking] function_requires
by Jens Müller 18 Dec '11

18 Dec '11

Hi all, as far as I understand http://www.boost.org/doc/libs/1_48_0/libs/concept_check/reference.htm#depre…, function_requires() is deprecated. However, the documentation does not mention very clearly how to replace it. Is the BOOST_CONCEPT_ASSERT macro the replacement? E.g., does function_requires< VertexListGraphConcept<Graph> >(); now become BOOST_CONCEPT_ASSERT((VertexListGraphConcept<Graph>)); function_requires still appears in a lot of test cases of the Graph library. So if it is that easy to change, I would hand in a patch. Best regards, Jens

2 7

[math.special_functions] broken in trunk
by Tim Blechmann 18 Dec '11

18 Dec '11

it seems, there is a problem in boost.math in trunk. the boost.heap testsuite originally used boost.random, but the test farm reports some issues: In file included from ../boost/math/special_functions.hpp:32, from ../boost/random/generate_canonical.hpp:22, from ../boost/random.hpp:52, from ../libs/heap/test/mutable_heap_tests.hpp:1, from ../libs/heap/test/fibonacci_heap_test.cpp:12: ../boost/math/special_functions/expint.hpp: In function ???void boost::math::detail::expint_i_imp_113a(T&, const T&)???: ../boost/math/special_functions/expint.hpp:1028: error: expected primary- expression before ???(??? token (compare http://tinyurl.com/bqfputx) for now, i've reverted to the libc random() function to work around this issue, but it would be great, if someone with insights in boost.math could have a look. thanks, tim

2 2

Add macros for the "enum class" concept?
by Daryle Walker 18 Dec '11

18 Dec '11

Should we add preprocessor stuff to conditionally use the C++11 "enum class" construct? #if Whatever #define BOOST_HAVE_ENUM_CLASS #endif //... #if BOOST_HAVE_ENUM_CLASS #define BOOST_ENUM_CLASS( Name ) enum class Name #define BOOST_ENUM_CLASS_BASE( Name, Type ) enum class Name : Type #define BOOST_ENUM_CLASS_REFER( Type, Enumerator ) (Type :: Enumerator) #else #define BOOST_ENUM_CLASS( Name ) enum Name #define BOOST_ENUM_CLASS_BASE( Name, Type ) BOOST_ENUM_CLASS( Name ) #define BOOST_ENUM_CLASS_REFER( Type, Enumerator ) (Enumerator) #endif I'm not sure that the second version of BOOST_ENUM_CLASS_BASE is the best alternative. Nor do I know if the parentheses around enumerators are best. You can use BOOST_ENUM_CLASS in an enum definition header and BOOST_ENUM_CLASS_BASE as a header or a forward declaration. Since enumerators can be scoped, BOOST_ENUM_CLASS_REFER encapsulates the need to add the enum type's name.

5 9

[parameter] type predicates vs. concepts
by Lorenzo Caminiti 18 Dec '11

18 Dec '11

Hello all, What's the difference between using a Boost.Parameter type predicate and using a concept? I think parameter type predicates are unary metafunctions used to resolve the function call, concepts are asserted on the type after the call has been resolved... Is there more? Can I always do with type predicates what I can do with concepts? Is there ever a reason to use/need both? For example here has_equal_to is the type predicate while DefautlConstructible is the concept. Could/should I have used has_[...]_default_constructor in and_ the type predicate instead of the DefaultConstructible concept? #include <boost/parameter.hpp> #include <boost/concept/requires.hpp> #include <boost/concept_check.hpp> #include <boost/type_traits/has_equal_to.hpp> #include <iostream> template< typename X > BOOST_CONCEPT_REQUIRES( ((boost::DefaultConstructible<X>)), (bool) ) is_default_impl ( X const& x ) { return x == X(); } BOOST_PARAMETER_NAME(x) BOOST_PARAMETER_FUNCTION( (bool), is_default, tag, (required (x, *(boost::has_equal_to<tag::x::_>)) ) ) { return is_default_impl(x); } struct no_equal {}; struct no_default { no_default(int) {} }; bool operator== ( no_default const&, no_default const& ) { return true; } int main ( void ) { std::cout << is_default(123) << std::endl; // ok // parameter error: cannot resolve is_default() call // std::cout << is_default(no_equal()) << std::endl; // concept error: no default constructor // std::cout << is_default(no_default(1)) << std::endl; return 0; } Thanks a lot. --Lorenzo

4 7

Boost Iterator Library - small extension proposal
by Detlef Wilkening 18 Dec '11

18 Dec '11

Hello Boostler, at first, excuse my english - I am not a native speaker. I used sometimes the Boost.Iterator library - especially the filter iterators. I like them much, but I don't like the work to create the iterator objects. --- Example: struct IsEven { inline bool operator()(int n) const { return n%2==0; } }; vector<int> v; IsEven iseven; filter_iterator<IsEven, vector<int>::iterator> filter_iter_begin(iseven, v.begin(), v.end()); filter_iterator<IsEven, vector<int>::iterator> filter_iter_end(iseven, v.end(), v.end()); --- My first problem is, that I need 3 times "v.end()" and 2 times "iseven". And the type is very long. I don't think, that the "make" functions makes it much better. I use "auto" from C++11 in this example, to make it a little bit shorter. --- Example: struct IsEven { inline bool operator()(int n) const { return n%2==0; } }; vector<int> v; IsEven iseven; auto filter_iter_begin2 = make_filter_iterator<IsEven>(v.begin(), v.end()); auto filter_iter_end2 = make_filter_iterator<IsEven>(v.end(), v.end()); --- Again I need 3 times "v.end()" and 2 times the type "IsEven". And the type is again very long - thanks to "auto" in C++11. My second problem is, that both use cases don't work well with lambda expressions in C++11. For "make" I need the type of the lambda, which I don't have - and I need it 2 times. And in the first solution I must write the lambda expression 2 times, which is not good. Perhaps there are some other solutions, wich I don't see - than please explain them to mee. ----- My proposal is a new "make" function, which is easer to use (only 1 time "v.end()") and works well with lambda expressions, but has furthermore a stupid type - but in C++11 with "auto" that doen't matter. --- template<class Iter, class Fct> pair<filter_iterator<Fct, Iter>, filter_iterator<Fct, Iter>> make_filter_iterators(Iter begin, Iter end, Fct fct) { filter_iterator<Fct, Iter> filter_iter_begin(fct, begin, end); filter_iterator<Fct, Iter> filter_iter_end(fct, end, end); return pair<filter_iterator<Fct, Iter>, filter_iterator<Fct, Iter>> (filter_iter_begin, filter_iter_end); } Usage: vector<int> v; auto iters = make_filter_iterators( v.begin(), v.end(), [](int n){ return n%2==0; }); copy(iters.first, iters.second, ostream_iterator<int>(cout, " ")); --- You see, with "auto" easy to use, and work well with lambda expressions. My proposal is to add such a "make" function to all iterator adaptors in Boost.Iterator. Thank you for reading my idea. Greetings Detlef Wilkening

3 3