- Boost-users - lists.boost.org

large variant performance compared (50 elements)
by Paul 29 Jan '11

29 Jan '11

In a project we are using variants holding shared_ptr's. These variants are typically 20 items large but are growing as the project progresses. Now it seems that each time we add elements, we fall into issue's regarding excessive compilation time, huge pdb file or out of heap space errors on the compiler or linker. I took some time to compare various approaches using variants, here are the results: stdafx.h #include <boost/mpl/vector.hpp> #include <boost/mpl/vector/vector100.hpp> #include <boost/variant/variant.hpp> #include <boost/variant/apply_visitor.hpp> #include <boost/variant/static_visitor.hpp> test.h class CTest { public: void foo(const Cs_t& rt); }; type.h class C1 { public: int i; }; class C2 { public: int i; }; class C3 { public: int i; }; ... class C50 { public: int i; }; //v1 typedef boost::variant< boost::shared_ptr<C1>, boost::shared_ptr<C2>, <...> boost::shared_ptr<C49>, boost::shared_ptr<C50> > v_t; //v2 typedef boost::mpl::vector50< boost::shared_ptr<C1>, boost::shared_ptr<C2>, <...> boost::shared_ptr<C49>, boost::shared_ptr<C50> > Mplv_t; typedef boost::make_variant_over<Mplv_t>::type v_t; //v3 typedef boost::variant< C1, C2, <...> C49, C50 > v_t; test.cpp namespace { class CVisit : public boost::static_visitor<> { public: template<typename T> void operator()(const T& rt) const { std::cout << typeid(T).name() << std::endl; } }; } void CTest::foo(const v_t& v) { //A: (invoke visitor directly, no new variant) boost::apply_visitor(CVisit(), v); //B: Copy variant using copy constructor v_t v2(v); <...> //C: Copy variant using assignment operator v_t v2; v2 = v; <...> } main.cpp int main(int argc, char* argv[]) { CTest t; v_t v = boost::shared_ptr<C10>(new C10); t.foo(v); return 0; } Setup: Boost 1.38 Msvc2005, Release target Optimize MaxSpeed (/O2) Debug info enabled (/Zi) Build time = rebuild solution; cl + link Variant type: v1 Foo logic:A Obj size: 2.4MB Exe size: 348KB Pdb size: 9.0MB Build time: 0:49 Peak commit: 500MB Variant type: v2 Foo logic:A Obj size: 1.4MB Exe size: 348KB Pdb size: 11.7MB Build time: 1:02 Peak commit: 600MB Variant type: v3 Foo logic:A Obj size: 1.9MB Exe size: 344KB Pdb size: 3.9MB Build time: 0:25 Peak commit: 300MB Variant type: v1 Foo logic:B (copy variant using copy constructor) Obj size: 3.1MB Exe size: 352KB Pdb size: 9.0MB Build time: 0:50 Peak commit: 500MB Variant type: v2 Foo logic:B Obj size: 2.2MB Exe size: 352KB Pdb size: 11.7MB Build time: 1:03 Peak commit: 600MB Variant type: v3 Foo logic:B Obj size: 2.1MB Exe size: 344KB Pdb size: 3.9MB Build time: 0:26 Peak commit: 300MB Variant type: v1 Foo logic:C (copy variant using assignment operator) Obj size: 71.3MB Exe size: 356KB Pdb size: 10.7MB Build time: 5:18 Peak commit: 1.2GB Variant type: v2 Foo logic:C Obj size: 80.6MB Exe size: 356KB Pdb size: 13.6MB Build time: 8:46 Peak commit: 1.4GB Variant type: v3 Foo logic:C Obj size: 2.4MB Exe size: 344KB Pdb size: 3.9MB Build time: 0:26 Peak commit: 300MB Is there any way to explain these (huge) differences and what is preffered? - Why does the use of assignment operator have such a hugh impact? - Why the difference between using shared_ptr or not? - When to use the numbered variant or boost::variant<...>? Help is greatly appreciated! Paul

9 67

lexical_cast<> in 1.39 does not provide basic_stringstream to operator>>
by Max Motovilov 29 Jan '11

29 Jan '11

Just ran into a regression in old code that last worked [probably] with 1.32 -- I have a number of ADTs which use tellg()/seekg() in their implementations of operator>>. This used to work fine with lexical_cast and now it breaks because the [optimized?] version in 1.39 uses a statically allocated buffer and plain Jane basic_streambuf which does not implement seekpos() and seekoff(). According to http://www.boost.org/doc/libs/1_45_0/libs/conversion/lexical_cast.htm#n1973, operator>> called from a lexical_cast should have at least basic_stringbuf to work with. Now, this project is locked into 1.39 for administrative reasons and I will have to work around the issue anyway. Still, I'm curious whether this is a problem that has been fixed since 1.39, a previously unnoticed bug or a by-design behavior that I am misinterpreting as a violation of spec... Thanks in advance, ...Max...

2 2

[serialization] plugin dll: What project settings are really needed?
by Georg Gast 28 Jan '11

28 Jan '11

Hi! Currently i'm trying to understand serialization via base pointer in a dll. My environment: - Windows XP SP3 - MS Visual Studio 2010 Prof (German) - Boost: 1.45.0 To try that i created 2 projects in one solution: test.exe (like test_dll_plugin) and test_plugin.dll (like dll_polymorphic_derivied2). Copied these files from boost/libs/serialization/(test|examples). Files in test.exe project (console app): - polymorphic_base.hpp - test_tools.hpp - text_archives.hpp Files in test_plugin.dll (standard win32 dll): - polymorphic_base.hpp - test_dll_plugin.cpp - polymorphic_derived2.cpp shared files: - test_decl.hpp - polymorphic_base.hpp Then i tried to copy the project settings to know the exact required settings: test.exe: --------- Preprozessor: WIN32;(_DEBUG|NDEBUG);_CONSOLE;BOOST_LIB_DIAGNOSTIC=1;BOOST_ALL_DYN_LINK=1 C++: Checking of small types: Yes /RTCc Funktionlevel-Linking aktiv: No /Gy- Run time type info: yes / GR systeminternal functions active: yes /Oi Runtime Library: Multithreaded(-Debug)-DLL (/MD|/MDd) test.dll: --------- Preprozessor: WIN32;(_DEBUG|NDEBUG);BOOST_ALL_DYN_LINK=1;BOOST_LIB_DIAGNOSTIC=1;_WINDOWS;_USRDLL;PLUGINDLL_EXPORTS C++: minimal recompilation: No /Gm- complete runtimechecking (Vollständige Laufzeitüberprüfung): Standard Run time type info: yes / GR Runtime Library: Multithreaded(-Debug)-DLL (/MD|/MDd) Now my questions: First Question: Are the above mentioned project settings for the exe and the dll really right and complete? Or is something not needed or missing? Second question: In my real project the dll should be able to provide derivied class dependant MFC Objects (Views/Dialogs) which are then shown in the exe. So: Is that (serialization through basepointer in dll) possible with a MFC extension library or do i need to create a MFC gui dll and a "polymorphic_derived2.dll"? Hope that is understandable ;) Best Regards Georg Gast

3 6

property tree child order
by Gianni Ambrosio 28 Jan '11

28 Jan '11

Hi All, can anybody tell me please if the property tree structure keeps the same child order of the related xml file? Regards Gianni

2 2

[range] Zip range adaptor
by Nathan Crookston 28 Jan '11

28 Jan '11

All, I've been using the boost range library for a few months now, and it's simplified my life considerably. I occasionally want to use something akin to MPL's zip_view and unpack_args with my ranges. For example: <code> const std::vector<int> vec1 = list_of(1)(2)(3)(4)(5)(6); std::vector<int> vec2 = list_of(10)(20)(30)(40)(50)(60); std::vector<int> vec3 = list_of(100)(200)(300)(400)(500)(600); boost::for_each(zip(vec1, vec2, vec3) | strided(2), unpack( std::cout << px::val('(') << arg1 <<", "<< arg2 <<", "<< arg3 << ")\n")); boost::transform(vec1, boost::begin(zip(vec3, vec2)), px::construct<boost::tuple<int,int> >(arg1 + 1, arg1 + 2)); boost::for_each(zip(vec2, vec3), unpack(std::cout << px::val('(') << arg1 << ", " << arg2 << ")\n")); </code> I note that the new algorithms include a two-argument for_each, but it would be nice to have something more extensible. I may have missed it in the documentation or on the list, but I haven't found anything like that. Does anyone know of such an adaptor? Since it's the weekend, I actually implemented code which allows the previous snippet to compile -- if no such adaptor exists I'd be happy to make it available/submit it to boost assuming there's interest. Thanks, Nate

4 7

BGL Properties
by David Doria 27 Jan '11

27 Jan '11

I have two questions: 1) I am trying to iterate through the edges of a graph and output their edge weights. I am confused though. I know how to output the "edges", but they are actually just a (vertex, vertex) pair which defines the edge. So do I index *edgePair.first into the EdgeWeightMap to get the weight of the edge starting from vertex *edgePair.first? Or how else would I get the weight associated with a particular edge? Code snippet: http://stackoverflow.com/questions/4810589/output-bgl-edge-weights 2) I have created a struct, and used it as a template parameter to adjacency_list. However, when I try to add_edge(vertex1, vertex2, property, graph) , the compiler complains "no matching function call". Can anyone see where I've gone wrong? Code snippet: http://stackoverflow.com/questions/4810235/bgl-bundled-properties-add-edge-… Any suggestions on either of these? Thanks, David

3 5

Boost thread: class member problem
by Patricia Hazel Shaw [phs] 27 Jan '11

27 Jan '11

Dear List members, I am trying to make use of threads within a class, but seem to be having problems with the syntax and getting it to compile. The outline of my class related to this thread issue is as follows: class Board{ public: void pressButton(int button); void boxAction(int box); private: boost::thread_group threads; }; void Board::pressButton(int button){ if(button=1){ threads.create_thread(&boxAction,1); } else ... } I have tried various different syntax within the create_thread() but have not been able to figure out from the documentation, or reading through the history of this mailing list, how to correctly do this. Any help you could give me would be greatly appreciated. Patricia Shaw

2 2

[Review][GIL] Boost.GIL IO and Toolbox extensions have been ACCEPTED into Boost
by Mateusz Loskot 27 Jan '11

27 Jan '11

Dear All, The formal review of IO and Toolbox extensions for Boost.GIL [1] ended on December 17th, 2010 [2] The review subject was not a standalone library but a part of whole - an extension to existing Boost.GIL. The review result: ACCEPTED Number of received discussion and feedback posts is ~140. I consider most of them in-topic, significant and also insightful. Reviewers pointed issues already known from previous discussions on the mailing list as well as new topics regarding the design and implementation of the extensions. Also, issues related to the library itself (Boost.GIL) were addressed. Some of them could be considered ideas for future works and improvements. It is remarkable, most (if not all) of the discussions were focused on the IO extension. None of the submitted reviews include comments to the Toolbox extension. Formally, the review concluded with 1 NO and 7 YES votes. Some of the YES votes are considered as conditional and number of changes were requested by the reviewers. The following changes should be addressed before the extensions appear in the Boost mainstream: 1. Documentation is adequate, but requires clean-up and fixing of lots of typos. 2. Additional tests are added to exercise currently untested error cases that result in a longjmp should be added. They should pass on all platforms officially supported by Boost. 3. Make sure the test images are license-free. If the license status is unknown, change them to other license-free images. 4. The requirements for adding new file formats / backends to be made more explicit. This means defining concept for a file format reader/writer, etc. and adding new file formats would constitute providing models for these concepts. 5. Support for reading images whose file format is unknown at compile time. That involves the ability to register file formats / backends, associate them with given extensions and then call the appropriate reader based on the extension of the file name. 6. Support for different backends for the same image formats. It appears that this can be done simply the same way a file format can be extended, i.e. have "png_libpng" and "png_lodepng" tags. 7. Support for efficient reading/writing of parts of images that are too large to fit in memory. There are two ways to proceed: one is to have an input/output iterator that enforces sequential access, and another is to allow for user-driven access at the cost of sometimes severe performance. The reviewers also posted a few suggestions that could improve quality of the two extensions, 1. Name of functions like read_int8, read_int16, read_int32, write_int8 in Device models suggest they return and accept signed integers, but they return and accept unsigned integers. The naming could be improved.. 2. Do some profiling and performance optimization of the most common formats. Add some test cases to measure speed of common scenarios. 3. Make sure the test cases provide complete coverage. For example, set a breakpoint in every method, every switch statement and branch. Run your tests and remove any breakpoints that are encountered. Look at the breakpoints that were not hit and add tests for them. 4. It would be great if Christian and Domagoj could join their efforts to take the best of their libraries (IO extension implementations) to the IO extension included in Boost.GIL and collaborate for the advanced features discussed in reviews. I would like to thank Edd Dawson, Zach Laine, Domagoj Saric, Roland Bock, Lubomir Bourdev, Tom Brinkman, Phil Endecott, Kenny Riddile for reviews and others who participated in discussions. Thanks also go to Christian Henning for great work. I would like conclude recalling short comment Lubomir Bourdev included in his review. In my opinion, it is a good summary of the Boost.GIL IO and Toolbox review and generally all discussions on this subject: *** The problem with I/O is that you can never declare success. All we can hope for is push the boundary as much as we can, and leave the rest for the next update. *** [1] http://lists.boost.org/boost-announce/2010/11/0273.php [2] http://lists.boost.org/boost-announce/2010/12/0279.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

1 0

[unittest] How to only ignore child terminate?
by Firouzeh Jalilian 26 Jan '11

26 Jan '11

I have a code that is run from the tests that I am running which does child.terminate(). That is considered a system error, therefore, I would have to set catch_system_errors="no" in order to ignore it. But the downside is I miss the rest of system errors I might be interested in. How can I only ignore child.terminate() while running unittests? Thanks in advance

3 2

Aggregate a boost::array, initialize with initializer list -- how?
by Dave Steffen 26 Jan '11

26 Jan '11

Hi Folks, I've got a question about supporting brace initialization syntax. double a[] { 1,2,3 }; ok, always has been. boost::array<int, 3> b {{ 1,2,3 }} Needs double braces because there's one member data to be initialized, and we want to initialize that with {1,2,3}. Fine. Some compilers let you drop one set of braces; GCC 4.4 does, but produces a warning. Now, I make a class: template<size_t N> Vector { public: ... boost::array<double, N> data; }; Vector<3> v {{{1,2,3}}} Still OK: again in principle, I need three sets of braces. However, I'd like my Vector::data member to be private, but as soon as I do that, Vector isn't a POD any more, and the brace initialization no longer works. (I'm not sure if this is in line with the standard, or is a GCC 4.4 limitation.) No problem, std::initializer_list to the rescue: template<size_t N> Vector { public: Vector(std::initializer_list<double> i) : data{i} {} ... private: boost::array<double, N> data; }; Alas, boost::array has no constructor that takes an initializer_list: error: no matching function for call to ‘boost::array<double, 3ul>::array(std::initializer_list<double>&)’ note: candidates are: boost::array<double, 3ul>::array(const boost::array<double, 3ul>&) /usr/local/Boost/1.44/boost/array.hpp:57:17: note: boost::array<double, 3ul>::array() scons: *** [fast/Test/testVector.o] Error 1 Having poked through the standard, I can't see any way to convince the compiler to turn an initializer_list back into the semantic equivalent of a brace initializer. Does anyone know how to do this? Does boost::array need a constructor that takes initializer_lists? Thanks! -- Dave Steffen, Ph.D. - Software Engineer Numerica Corporation <http://www.numerica.us> 4850 Hahns Peak Drive, Suite 200 Loveland, Colorado 80538 main (970) 461-2000 x 227 Email: dave.steffen(a)numerica.us fax (970) 461-2004

2 2