December 2011 - Boost - lists.boost.org

boost.heap in trunk
by Tim Blechmann 07 Dec '11

07 Dec '11

hi all, i've imported my boost.heap library into trunk. it currently won't compile with gcc, but i've submitted patches against boost.parameter [1] and boost.fusion [2]. i hope they are applied, soon. i managed to integrate it into the documentation system, but it still needs to be integrated into the bug tracker and the regression test system. can i do that myself? tim [1] https://svn.boost.org/trac/boost/ticket/6214 [2] https://svn.boost.org/trac/boost/ticket/6215

3 2

Re: [boost] c++11 and gcc 4.7
by Leo Goodstadt 07 Dec '11

07 Dec '11

> > From: Bruce Adams <tortoise_74(a)yahoo.co.uk> > Date: Tue, 6 Dec 2011 19:08:56 +0000 (GMT) > > Hi, > I am attempting to do a cost benefit analysis to justify adopting the > subset of C++11 that is supported by gcc 4.7. > As threads are one of the biggest features of c++11, I may be asked to > justify just boost.thread vs > gcc 4.7 + boost.thread. You may also wish to consider using a higher level threading library on top of std::thread / boost::thread. We have been using Intel Threading Building Blocks (http://threadingbuildingblocks.org/) for a while now, and it seems to live very happily alongside Boost. TBB means that you don't have to roll your own thread pools, or adjust the parallelism each time your programme is run. It is also a very thin layer in terms of efficiency. The modern trend across many programming languages also seems to move away from using (manual) synchronisation primitives whenever possible (just as "raw" new and delete has become rare in c++ over the past 20 years). TBB allows complex pipelines to be supported quite naturally in terms of a data flow. My only reservation is that it requires dynamic linking, which is not always desirable or even possible. Finally, the extra level of abstraction in TBB probably means that the onus on supporting varying standards of c++ 11 conformance falls on Intel and not you or your company! Leo

1 0

Is there any interest in a library which solves C++ class reflection feature just like Java does?
by jinhua luo 07 Dec '11

07 Dec '11

Hi, In brief, I'd designed and implemented somehow C++ class reflection based on boost libraries. It has some unique advantages: a) it doesn't require code generator b) platform independent and compiler independent (I tested it on Windows and Linux, with vs2008 and gcc respectively) c) it's non-intrusive for the class definition, instead, you just need to declare and describe your class via some straightforward macros anywhere (header file or source file, and may be within any namespace), which also means you can wrap an external third-party library (which you have no way to touch the source codes) and reflects it classes. d) Cross shared library boundary, you can dynamic load the shared library and reflect the classes within it, without need to export any symbol manunally in C wrapper function way e) the API looks like Java reflection API Below is some codes snippet to have an overview of this library: -----libTest.cpp---start--- #include <iostream> #include <string> #include <boost/reflection/reflection.hpp> namespace test { class AccountItf { public: virtual std::string getId() const = 0; virtual void setId(std::string id) = 0; }; #define ACCOUNT_INTERFACE_REFL_DECLARE \ BOOST_REFL_INTERFACE(test::AccountItf) \ BOOST_REFL_CONST_METHOD(getId, std::string()) \ BOOST_REFL_METHOD(setId, void(std::string)) class Account : public AccountItf { std::string id; public: Account() : age(0) {} Account(std::string id, unsigned int age) : id(id), age(age) {} static void echo(Account* acct, std::string banner) { std::cout << banner + ": " << acct->getId() << std::endl; } std::string getId() const { return id; } void setId(std::string id) { this->id = id; } public: unsigned int age; }; //Account declaration for used by reflection //this declaration can be placed anywhere, even the header file BOOST_REFL_CLASS ( (test)(Account), //constructors BOOST_REFL_CONSTRUCTOR() BOOST_REFL_CONSTRUCTOR(std::string id, unsigned int age) //static methods BOOST_REFL_STATIC_METHOD(echo, void (Account* acct, std::string banner)) //properties BOOST_REFL_PROPERTY(age, unsigned int) //derived Inteface ACCOUNT_INTERFACE_REFL_DECLARE ) } -----libTest.cpp----end-- Compile the libTest.cpp into the libTest.dll or libTest.so. -----main.cpp----start-- #include <iostream> #include <string> using namespace std; #include <boost/reflection/reflection.hpp> using namespace boost::reflection; #if defined(BOOST_WINDOWS) #include <Windows.h> #else #include <dlfcn.h> #endif int main(int argc, char* argv[]) { #if defined(BOOST_WINDOWS) LoadLibraryA (argv[1]); #else dlopen(argv[1], RTLD_NOW); #endif Class t = Class::forName("test.Account"); boost::any obj = t.newInstance(std::string("Account-id-100"), (unsigned int)26); t.invokeStatic("echo", obj, std::string("TEST")); TypeInfoArray tArray; tArray.push_back(BOOST_REFL_TYPEID(std::string)); Method m1 = t.getMethod("setId", tArray); m1.invoke(obj, std::string("Account-id-200")); Method m2 = t.getMethod("getId"); boost::any ret = m2.invoke(obj); std::cout << "Account getId(): " << boost::any_cast<std::string>(ret) << std::endl; Property prop = t.getProperty("age"); prop.set(obj, (unsigned int)30); std::cout << "Account age: " << boost::any_cast<unsigned int>(prop.get(obj)) << std::endl; return 0; } -----main.cpp---end--- Compile the main.cpp into the executable and execute it: ./main libTest.dll it will output: TEST: Account-id-100 Account getId(): Account-id-200 Account age: 30 This library is very useful for framework-level design which needs C++ reflection, e.g. recently I'm working on somehow SQL mapping library for C++, just like MyBatis, and reflection makes possible to invoke the getter/setter of the object instances of classes specified in the XML file. Regards, JinHua

8 25

c++11 and gcc 4.7
by Bruce Adams 07 Dec '11

07 Dec '11

Hi, I am attempting to do a cost benefit analysis to justify adopting the subset of C++11 that is supported by gcc 4.7. I believe there is a strong case for doing so from just the minor features and library improvements. However, I am having a hard time putting together a convincing cost benefit analysis (actually I would like to be able to do this with parts of boost too - any help with this would be great). I have many subjective arguments for boost, C++11 and TR1 but am tasked with trying to justifying any change in terms of costs and benefits. One of Boost's roles is to fill in gaps in c++ support where compiler vendors have not yet provided an implementation. I know that g++4.7 has incomplete support for multi-threading but it is unclear whether this is in the core language area and/or library area and what platforms it applies to. I am specifically interested in GNU/Linux. The status of boost for gcc4.7 is unclear (I know it has not been officially released yet but the status for gcc 4.6.2 is also unclear). Both of the following links from www.boost.org are several years and versions out of date http://www.boost.org/doc/libs/1_34_0/status/compiler_status.html http://boost.sourceforge.net/regression-logs/ Will boost.thread work as a drop in replacement for std::thread or is anything missing or broken on the core language side? (On the gcc side I am also interested in whether std::thread is a sufficiently complete implementation of the standard that boost.thread might not be necessary). The answer to this question may make my work harder. I was asked to justifiy either TR1, some part of boost or C++11 as my preference. I opted for C++11 as the most useful. I would probably have to justify boost libraries on a case by case basis. Justifying use of C++11 actually amounts to justifying a compiler upgrade + possibly training + possibly boost.thread As threads are one of the biggest features of c++11, I may be asked to justify just boost.thread vs gcc 4.7 + boost.thread. Surprisingly another thing that is unclear is the exact set of boost libraries that were included in C++11. I don't have either the standard (other than the February draft http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf) or a good summary of the standard to hand. Suprisingly neither the boost website nor the g++ page have a list either, though the following two links are helpful: http://www.boost.org/doc/libs/1_48_0/?view=filtered_std-tr1 http://www.boost.org/doc/libs/1_48_0/?view=filtered_std-proposal I found a reference somewhere online (that I can no longer find) claiming, I believe incorrectly, that boost file_system is in C++11. This isn't mentioned on: http://www.boost.org/doc/libs/1_48_0/libs/filesystem/v3/doc/index.htm But nor its is presence in the 2005 "TR2" proposal. I worry that the 2005 TR2 proposal may be confused with any real TR2 proposal following on from C++11. I note that boost.chrono claims to be implemnting C++11 but I would have thought it was other way around and that the boost library was incorporated into the standard. http://www.boost.org/doc/libs/1_48_0/doc/html/chrono.html Anyway, the closest I've come to a list of libraries in C++11 outside of n3242 is: http://www2.research.att.com/~bs/C++0xFAQ.html#library Regards, Bruce.

3 2

Re: [boost] Is there any interest in a library which solves C++ class reflection feature just like Java does?
by Brian Wood 06 Dec '11

06 Dec '11

Matus Chochlik on Tue, Dec 6, 2011 at 2:40 AM, jinhua luo <ljh.home.king(a)gmail.com> wrote: > Hi, > Hi, >> It has some unique advantages: >> a) it doesn't require code generator > Good, but it is not so unique Because C++ compiler is a code generator? [ ...] >> d) Cross shared library boundary, you can dynamic load the shared library >> and reflect the classes within it, without need to export any symbol >> manunally in C wrapper function way > I believe (and I have some expertise in using and implementing reflection > in C++ to base that belief upon) that the basic reflection should > compile-time and any run-time reflection should be built on top > of that. Agreed. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/> (651) 251-9384

1 0

[chrono] steady_clock efficiency
by Kenneth Porter 06 Dec '11

06 Dec '11

I expect most people will use boost::chrono::steady_clock to measure performance. I've been considering switching from my raw calls to the Windows peformance counter APIs to the steady_clock. I'm a little worried about the overhead of what should be a non-intrusive facility. In examing the source, I see that steady_clock::now() reads the performance counter and then multiplies it by the reciprocal of the counter's frequency (acquired on first use of the clock) to return the time in nanoseconds. How expensive is this 64 bit multiply on a 32 bit system? How hard would it be to have now() return a time_point that stores the raw tick value and only converts it to nanoseconds when a calculation in real units is required? (Comparison to another time_point could still be done in performance counter ticks, saving the multiply.) Is it worth the extra complexity to demand-convert ticks to nanoseconds? Source is in boost_1_48_0\boost\chrono\detail\inlined\win\chrono.cpp

5 15

Status of ISO/IEC TR 24733 library idea?
by Mateusz Łoskot 06 Dec '11

06 Dec '11

Hi, There is ISO/IEC TR 24733 draft on decimal floating-point arithmetic. I found old thread by Stefan Slapeta: Decimal floating point library [1] I wonder, what is status of this idea in Boost? [1] http://lists.boost.org/Archives/boost/2006/02/101457.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

3 5

[release] Is Rlease branch is open for merge?
by Artyom Beilis 06 Dec '11

06 Dec '11

Hello, Is release brunch is open for merge of updates from trunk? Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

2 2

disable_if conundrum
by Marshall Clow 06 Dec '11

06 Dec '11

I have a function that returns a pair of iterators. There's also a version that takes a comparison predicate. template<class ForwardIterator, class Compare> std::pair<ForwardIterator, ForwardIterator> foo ( ForwardIterator first, ForwardIterator last ); template<class ForwardIterator, class Compare> std::pair<ForwardIterator, ForwardIterator> foo ( ForwardIterator first, ForwardIterator last, Compare comp ); I want to provide a range-based version of it. template<class Range> std::pair<typename boost::range_iterator<const Range>::type, typename boost::range_iterator<const Range>::type> foo ( const Range &r ); template<class Range, class Compare> std::pair<typename boost::range_iterator<const Range>::type, typename boost::range_iterator<const Range>::type> foo ( const Range &r, Compare comp ); Ok. There's a problem. If I call: foo ( first, last ) I get an error, because there are two perfectly good two argument candidates. Fine. Been there, seen that. I can use disable_if to make sure that the second range based version is only "active" when the arguments are different types. It's verbose, but it (usually) works template<class Range, class Compare> typename boost::disable_if_c<boost::is_same<Range, Compare>::value, std::pair<typename boost::range_iterator<const Range>::type, typename boost::range_iterator<const Range>::type> >::type foo ( const Range &r, Compare comp ); But this time it does not! I get a compile error telling me that the compiler can't deal with boost::range_iterator<XXX>::type, when XXX = some random iterator. It seems that the compiler wants to evaluate all the parameters of disable_if_c before deciding whether or not to SFINAE it (I guess that's not unreasonable, but it's not what I want) Apparently, all the other times that I did this, the return type of the function was not a dependent type of the template arguments. Any suggestions for a workaround here? -- Marshall -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

4 9

[enable_if] compile failure in trunk
by Tim Blechmann 05 Dec '11

05 Dec '11

trying to merge boost.heap into trunk, there is one issue, which seems to be triggered by the enable_if in the boost.heap testsuite. compiling with gcc (4.5 or 4.6), i get the following error: In file included from /home/tim/workspace/boost-trunk/boost/parameter.hpp:17:0, from /home/tim/workspace/boost-trunk/boost/heap/policies.hpp:12, from /home/tim/workspace/boost-trunk/boost/heap/detail/stable_heap.hpp:20, from /home/tim/workspace/boost_heap/libs/heap/test/../../../boost/heap/fibonacci_heap.hpp:20, from /home/tim/workspace/boost_heap/libs/heap/test/fibonacci_heap_test.cpp:8: /home/tim/workspace/boost-trunk/boost/parameter/name.hpp:52:1: error: template argument 2 is invalid In file included from /home/tim/workspace/boost-trunk/boost/fusion/support/detail/segmented_fold_until_impl.hpp:20:0, from /home/tim/workspace/boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_begin_impl.hpp:15, from /home/tim/workspace/boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_begin.hpp:10, from /home/tim/workspace/boost-trunk/boost/fusion/sequence/intrinsic/begin.hpp:17, from /home/tim/workspace/boost-trunk/boost/fusion/container/vector/vector10.hpp:15, from /home/tim/workspace/boost-trunk/boost/fusion/container/vector/vector_fwd.hpp:14, from /home/tim/workspace/boost-trunk/boost/fusion/container/vector/vector.hpp:10, from /home/tim/workspace/boost-trunk/boost/fusion/tuple/tuple.hpp:11, from /home/tim/workspace/boost-trunk/boost/fusion/tuple.hpp:10, from /home/tim/workspace/boost-trunk/boost/fusion/include/tuple.hpp:10, from /home/tim/workspace/boost-trunk/boost/math/tools/tuple.hpp:89, from /home/tim/workspace/boost-trunk/boost/math/special_functions/detail/igamma_inverse.hpp:13, from /home/tim/workspace/boost-trunk/boost/math/special_functions/gamma.hpp:1543, from /home/tim/workspace/boost-trunk/boost/math/special_functions/detail/bessel_jy.hpp:14, from /home/tim/workspace/boost-trunk/boost/math/special_functions/bessel.hpp:17, from /home/tim/workspace/boost-trunk/boost/math/special_functions.hpp:18, from /home/tim/workspace/boost-trunk/boost/random/generate_canonical.hpp:22, from /home/tim/workspace/boost-trunk/boost/random.hpp:52, from /home/tim/workspace/boost_heap/libs/heap/test/mutable_heap_tests.hpp:1, from /home/tim/workspace/boost_heap/libs/heap/test/fibonacci_heap_test.cpp:12: /home/tim/workspace/boost-trunk/boost/fusion/iterator/equal_to.hpp:77:9: error: expected nested-name-specifier before ‘enable_if’ /home/tim/workspace/boost-trunk/boost/fusion/iterator/equal_to.hpp:77:18: error: expected initializer before ‘<’ token /home/tim/workspace/boost-trunk/boost/fusion/iterator/equal_to.hpp:88:9: error: expected nested-name-specifier before ‘enable_if’ /home/tim/workspace/boost-trunk/boost/fusion/iterator/equal_to.hpp:88:18: error: expected initializer before ‘<’ token /home/tim/workspace/boost-trunk/boost/fusion/iterator/equal_to.hpp:98:31: error: ‘boost::fusion::iterator_operators::operator==’ has not been declared /home/tim/workspace/boost-trunk/boost/fusion/iterator/equal_to.hpp:99:31: error: ‘boost::fusion::iterator_operators::operator!=’ has not been declared In file included from /home/tim/workspace/boost-trunk/boost/fusion/iterator/segmented_iterator.hpp:13:0, from /home/tim/workspace/boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_begin.hpp:11, from /home/tim/workspace/boost-trunk/boost/fusion/sequence/intrinsic/begin.hpp:17, from /home/tim/workspace/boost-trunk/boost/fusion/container/vector/vector10.hpp:15, from /home/tim/workspace/boost-trunk/boost/fusion/container/vector/vector_fwd.hpp:14, from /home/tim/workspace/boost-trunk/boost/fusion/container/vector/vector.hpp:10, from /home/tim/workspace/boost-trunk/boost/fusion/tuple/tuple.hpp:11, from /home/tim/workspace/boost-trunk/boost/fusion/tuple.hpp:10, from /home/tim/workspace/boost-trunk/boost/fusion/include/tuple.hpp:10, from /home/tim/workspace/boost-trunk/boost/math/tools/tuple.hpp:89, from /home/tim/workspace/boost-trunk/boost/math/special_functions/detail/igamma_inverse.hpp:13, from /home/tim/workspace/boost-trunk/boost/math/special_functions/gamma.hpp:1543, from /home/tim/workspace/boost-trunk/boost/math/special_functions/detail/bessel_jy.hpp:14, from /home/tim/workspace/boost-trunk/boost/math/special_functions/bessel.hpp:17, from /home/tim/workspace/boost-trunk/boost/math/special_functions.hpp:18, from /home/tim/workspace/boost-trunk/boost/random/generate_canonical.hpp:22, from /home/tim/workspace/boost-trunk/boost/random.hpp:52, from /home/tim/workspace/boost_heap/libs/heap/test/mutable_heap_tests.hpp:1, from /home/tim/workspace/boost_heap/libs/heap/test/fibonacci_heap_test.cpp:12: /home/tim/workspace/boost-trunk/boost/fusion/container/list/cons.hpp:91:22: error: expected nested-name-specifier before ‘disable_if’ /home/tim/workspace/boost-trunk/boost/fusion/container/list/cons.hpp:91:32: error: expected ‘,’ or ‘...’ before ‘<’ token /home/tim/workspace/boost-trunk/boost/fusion/container/list/cons.hpp:122:18: error: expected nested-name-specifier before ‘disable_if’ /home/tim/workspace/boost-trunk/boost/fusion/container/list/cons.hpp:122:28: error: expected initializer before ‘<’ token compiling with gcc against 1.48 works fine. clang++ correctly compiles this code against boost-trunk. any idea, what could go wrong there? thanks, tim

2 2