- Boost - lists.boost.org

shared_ptr<X[5]>
by Peter Dimov 06 Nov '12

06 Nov '12

Now that we (are going to) have shared_ptr<X[]>, what should shared_ptr<X[5]> do? >From user point of view, it seems obvious that this is as good a pointer to an array as shared_ptr<X[]> is, so it should behave similarly, having op[] and an element_type of X. >From a generic point of view, this could potentially break code that assumes that shared_ptr<T>::get() always returns a T*, even when T is X[5]. But how common is such a scenario? On the other hand, it will actually _fix_ generic code of the form shared_ptr<T> p( new T ); when T is X[5].

2 1

Re: [boost] C++ announcements coming tomorrow
by Brian Wood 05 Nov '12

05 Nov '12

From: Paul Mensonides > In that last announcement talk alone together with the follow-up Q & A > there are numerous "subtle" bits of marketing. The entire general trend > is one of attempting to turn a product (software) into a service. That > is an anti-consumer nickle-and-dime model which is just as anti-consumer > as trying to trick people that can't afford something into making > payments. It is just as anti-consumer as many other related things > occurring in the software industry nowadays--microtransactions being one > of them. I bet MS investors would think differently. Is there another option available to them than services? -- Brian Wood Ebenezer Enterprises -- so far G-d has helped us. http://webEbenezer.net

2 1

Boost mpi, serialization and shared_ptr
by Gabriel 05 Nov '12

05 Nov '12

Hello, Has this problem been solved? I have the same problems, I have a class with a shared_ptr member which does not compile with MPI skeleton and content. I receive the same error: *class boost::mpi::packed_skeleton_* *iarchive' has no member named 'reset' *and so on (I refere to the older posts) Thanks for any reply! BR Gabriel Nützi

1 0

[iterator] Library name (was [website] Wrong library name)
by Daniel James 04 Nov '12

04 Nov '12

On 4 November 2012 07:51, Michel Morin <mimomorin(a)gmail.com> wrote: > Boost.Iterator is listed as "Iterators" (note the plural form) in > > * http://www.boost.org/doc/libs/ > * trunk/boost/libs/libraries.htm > > But it should be "Iterator". I'll fix this in a sec, although 'libs/libraries' will only be updated in 1.53. I replied with an 'iterator' subject so that the appropriate people might see this.

2 2

Help! Detecting that two template aliases are equal.
by Matt Calabrese 04 Nov '12

04 Nov '12

In working on Boost.Generic I need, in multiple parts of the library, to detect if two template aliases are equivalent. For instance, this is required when comparing the compatibility of an automatically generated concept map of a less-refined concept with an explicitly created concept map for the less-refined concept when the concept in question has an associated class template. This seems like it shouldn't be too difficult, but apparently my understanding of template aliases is incomplete: //////////////////// // Create a template template< class > struct template_ {}; // Make a simple alias of the template template< class A > using template_alias = template_< A >; // Create a metafunction to determine if two unary type templates are the same template< template< class > class L, template< class > class R > struct templates_are_the_same { static bool constexpr value = false; }; template< template< class > class T > struct templates_are_the_same< T, T > { static bool constexpr value = true; }; // In Clang and GCC, the following static_assert will be triggered static_assert( templates_are_the_same< template_, template_alias >::value , "Templates are not the same." ); //////////////////// This behavior is observed in both Clang and GCC, though I haven't verified that it is correct behavior in the standard. Assuming that it is in fact standard, can anyone conceive of a way around this limitation? I've considered passing dummy arguments to the templates based on the template parameter list and checking that the resultant types are equal, but I'd like to avoid that if at all possible, since it seems like it would be difficult or impossible to support certain templates properly (I.E. consider the template parameter list of a template where one parameter type is dependent on another, like std::integral_constant). This type of detection is very important in making Boost.Generic work as closely to N2914 as possible so any workaround, however hairy, would be a huge help. -- -Matt Calabrese

5 8

[test] linking issues on trunk
by Vicente J. Botet Escriba 04 Nov '12

04 Nov '12

Hi, I have found some linking issues (see bellow) with Boost.Test ubuntu gcc-4.4.6,gcc-4.6.1.0(c++0x),intel-12.1.3.0(c++0x). I'm linking with boost_unit_test_framework. Should other libraries be added? Best, Vicente P.S. This worked well before. time bjam --build-dir=/tmp/bin.v2 toolset=gcc-4.4.6,gcc-4.6.1.0x,intel-12.1.3.0x -q -d2 gcc.link /tmp/bin.v2/boost/bin.v2/libs/thread/test/test_thread.test/gcc-4.4.6/debug/threading-multi/test_thread "g++-4.4" -Wl,-R -Wl,"/tmp/bin.v2/boost/bin.v2/libs/chrono/build/gcc-4.4.6/debug/threading-multi" -Wl,-R -Wl,"/tmp/bin.v2/boost/bin.v2/libs/system/build/gcc-4.4.6/debug/threading-multi" -Wl,-R -Wl,"/tmp/bin.v2/boost/bin.v2/libs/thread/build/gcc-4.4.6/debug/threading-multi" -Wl,-rpath-link -Wl,"/tmp/bin.v2/boost/bin.v2/libs/chrono/build/gcc-4.4.6/debug/threading-multi" -Wl,-rpath-link -Wl,"/tmp/bin.v2/boost/bin.v2/libs/system/build/gcc-4.4.6/debug/threading-multi" -Wl,-rpath-link -Wl,"/tmp/bin.v2/boost/bin.v2/libs/thread/build/gcc-4.4.6/debug/threading-multi" -o "/tmp/bin.v2/boost/bin.v2/libs/thread/test/test_thread.test/gcc-4.4.6/debug/threading-multi/test_thread" -Wl,--start-group "/tmp/bin.v2/boost/bin.v2/libs/thread/test/test_thread.test/gcc-4.4.6/debug/threading-multi/test_thread.o" "/tmp/bin.v2/boost/bin.v2/libs/chrono/build/gcc-4.4.6/debug/threading-multi/libboost_chrono.so.1.52.0" "/tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a" "/tmp/bin.v2/boost/bin.v2/libs/thread/build/gcc-4.4.6/debug/threading-multi/libboost_thread.so.1.52.0" "/tmp/bin.v2/boost/bin.v2/libs/system/build/gcc-4.4.6/debug/threading-multi/libboost_system.so.1.52.0" -Wl,-Bstatic -Wl,-Bdynamic -lrt -Wl,--end-group -g -pthread /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(unit_test_main.o): In function `boost::unit_test::unit_test_main(boost::unit_test::test_suite* (*)(int, char**), int, char**)': /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/unit_test_main.ipp:92: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(framework.o): In function `boost::unit_test::framework::impl::apply_filters(unsigned long)': /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:506: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:533: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:537: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:548: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(framework.o):/mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:603: more undefined references to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' follow /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(framework.o): In function `visit': /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:686: undefined reference to `boost::unit_test::decorator::for_test_unit::apply(boost::unit_test::test_unit&)' /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(framework.o): In function `boost::unit_test::framework::init(boost::unit_test::test_suite* (*)(int, char**), int, char**)': /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:691: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:698: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(framework.o): In function `boost::unit_test::framework::run(unsigned long, bool)': /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:1008: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:1045: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(framework.o): In function `boost::unit_test::ut_detail::label_filter::visit(boost::unit_test::test_unit const&)': /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:217: undefined reference to `boost::unit_test::test_unit::has_label(boost::unit_test::basic_cstring<char const>) const' /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(framework.o): In function `boost::unit_test::ut_detail::remove_disabled::visit(boost::unit_test::test_unit const&)': /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:300: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(progress_monitor.o): In function `boost::unit_test::traverse_test_tree(boost::unit_test::test_unit const&, boost::unit_test::test_tree_visitor&, bool)': /mnt/boost/trunk/libs/thread/test/../../../boost/test/tree/traverse.hpp:46: undefined reference to `boost::unit_test::traverse_test_tree(boost::unit_test::test_case const&, boost::unit_test::test_tree_visitor&, bool)' /mnt/boost/trunk/libs/thread/test/../../../boost/test/tree/traverse.hpp:48: undefined reference to `boost::unit_test::traverse_test_tree(boost::unit_test::test_suite const&, boost::unit_test::test_tree_visitor&, bool)' /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(results_reporter.o): In function `boost::unit_test::results_reporter::make_report(boost::unit_test::report_level, unsigned long)': /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/results_reporter.ipp:181: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' collect2: ld returned 1 exit status ...failed gcc.link /tmp/bin.v2/boost/bin.v2/libs/thread/test/test_thread.test/gcc-4.4.6/debug/threading-multi/test_thread... ...failed updating 1 target...

2 1

[website] Wrong library name
by Michel Morin 04 Nov '12

04 Nov '12

Boost.Iterator is listed as "Iterators" (note the plural form) in * http://www.boost.org/doc/libs/ * trunk/boost/libs/libraries.htm But it should be "Iterator". Regards, Michel

1 0

[variant] awkward recursion
by Dave Abrahams 03 Nov '12

03 Nov '12

I've been playing around with variant a bit and decided to try to build a data structure for storing json. I came up with several different approaches but none are super-satisfying. I'd like some feedback. (If you need a refresher on what's in json, the front page of http://json.org tells all). In the abstract, json looks like: struct null {}; typedef std::map<std::string, value> object; typedef std::vector<value> array; typedef variant< null, std::string, double, object, array, bool > value; Naturally, this code isn't legal C++, so I set about making it be. The first thing I tried was to use recursive_wrapper<>, as the documentation implies it is the most flexible way to do this sort of thing. Unfortunately, there's no clean way to reformulate this type in a way that allows recursive_wrapper work, because the type that needs to be wrapped in recursive_wrapper includes "value" in its name, and I can't forward-declare it. The only way to forward-declare a type X, as far as I know, is: struct X; // or class X; So to try to get recursive_wrapper to work, I tried a couple of formulations that started with that, but it turns out that when you do this, you end up not needing recursive_wrapper at all struct value; typedef std::map<std::string, value> object; typedef std::vector<value> array; typedef variant< null, std::string, double, object, array, bool > value_base; struct value : value_base { value() {}; template <class T> value(T const& x) : base(x) {} // no move; I'm in C++03-land value& operator=(value const& x) { base::operator=(x); return *this; } } }; I don't know if I've missed some things that should be in that "value" class. I know that a recursive variant, in principle, requires a pointer indirection somewhere, so I was wondering if, had I wrapped object and array in recursive_wrapper as below, I would have been adding an unnecessary inefficiency. typedef variant< null, std::string, double, reference_wrapper<object>, reference_wrapper<array>, bool > value_base; I also wondered whether that would give me different results from typedef std::map<std::string, value> object; typedef std::vector<value> array; typedef variant< null, std::string, double, std::map<std::string, reference_wrapper<value> >, std::vector<reference_wrapper<value> >, bool > value_base; and which one was better. Does anyone know? I think that should be in the docs. Using recursive_variant_ works out quite nicely, except that it doesn't allow me to separately declare "object" and "array" and re-use them in the definition of "value": typedef boost::make_recursive_variant< null , std::string , double , std::map<std::string, boost::recursive_variant_> , std::vector<boost::recursive_variant_> , bool >::type value; I also wonder if I'm getting an unnecessary inefficiency in that case. Lastly, what flexibility am I sacrificing by using this approach? -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

9 28

[1.52.0] Release candidates available
by Marshall Clow 03 Nov '12

03 Nov '12

Release candidate files for 1.52.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, -- Marshall

5 5

New Stepanov lecture videos released by A9
by Mat Marcus 02 Nov '12

02 Nov '12

http://www.youtube.com/user/A9Videos/videos?flow=grid&view=1

1 0