November 2009 - Boost-users - lists.preview.boost.org

Boost.Serialization not building
by gast128 30 Nov '09

30 Nov '09

Dear all, we just upgrade to Boost 1.41 and get a compile error in Boost.Serialization: 1>c:\work sdk\boost_1_41_0\boost/archive/shared_ptr_helper.hpp(114) : error C2440: 'return' : cannot convert from 'const boost::serialization::extended_type_info_typeid<T>' to 'const boost::serialization::extended_type_info *' There was already a discussion about this on the newsgroup but no solution was posted: http://thread.gmane.org/gmane.comp.lib.boost.user/52384/focus=52390 The case is easy reproducable: struct Foo { //virtual ~Foo(){} }; struct Foo2 : public Foo { template <class Archive> void serialize(Archive& /*ar*/, const unsigned int /*version*/) { } }; struct Bla { template <class Archive> void serialize(Archive& ar, const unsigned int /*version*/) { ar & BOOST_SERIALIZATION_NVP(m_ptrFoo2); } boost::shared_ptr<Foo2> m_ptrFoo2; }; void F() { std::stringstream sstr; Bla bla; boost::archive::xml_iarchive ia(sstr); ia >> boost::serialization::make_nvp("bla", bla); } Can somebody help? Adding a virtual dtor does remove the problem (and is exactly the difference with 'test_shared_ptr.cpp') but this is unwanted. wkr

2 5

How well does Boost work on Windows CE 6.0 R3?
by Andreas Huber 29 Nov '09

29 Nov '09

Among others, we're considering to use the following Boost libraries on Windows CE 6.0 R3, with MSVC 9.0: date_time exception filesystem regex signals2 system thread For all of these libraries, the msvc-9.0~wm5~stlport5.2 toolset reports at least one test failure on the trunk. So: - Has anybody managed to use these libraries on CE 6.0? - With STLPort or the MS implementation? - If any, what tweaks were necessary? Also, has anybody used the following libs on CE: log (Semashev, proposed) futures (Williams, accepted but not yet added) ? Thanks, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

adding a compiler flag
by Igor R 29 Nov '09

29 Nov '09

Hello, Is it possible to add a c++ compiler flag to bjam line, when building a boost library, or what's the right way to do this? Thanks.

2 2

[1.41][regex] MSVC makefiles
by Chard 29 Nov '09

29 Nov '09

The MSVC makefiles for regex (libs/regex/build) create 1_40 filenames. I assume (at least) one of: - they missed the update. - they're obsolete; just use bjam. - I've missed something.

2 1

program_options
by Dejan 29 Nov '09

29 Nov '09

Hi all, I'm experimenting with program_options and trying to get something like "mandatory options". E.g. # my_prog -a someValue with "-a someValue" as mandatory options. Can I define "something" with program_options. Thanks in advantage Dejan

3 2

boost lambda for processing std::vector
by CR Koudella 29 Nov '09

29 Nov '09

Hi, I am trying to understand if boost.lambda is well suited for the quick processing of an std::vector<double>. I must apologize for my sketchy understanding of the library and this is the reason why I turn to you for your help. Imagine that we are given an std::vector<double>, say, x', of some size and that we need to extend x' somehow to x in order to use it as an argument for some function f. So, say x' = (3,3,3) and x can be obtained by some map as x = (3,1,3,1,3). Ideally, this problem would fit into function composition using bind or lambda::bind. Define g(x) = f[x(x')]. The composition operation is standard. What is not for me is how to write the function x(x') using boost.lambda. It is always possible to write a quick C++ functor that will encode in its state the map defining how to generate x from x'. This would typically proceed by constructing a return std::vector<double> to be populated according to the map. But, can this be done easily with boost.lambda also? I am not sure. I seem to be finding it difficult to formulate expressions that return types such as std::vectors, while operating on the vector elements. I can see that the library is well suited to write small functors on the fly that will operate on container items (as is documented), but when it comes to full containers, I am kind of stuck. Any attempt seems to be leading to complicated script and dead ends, which makes me think that I am better off relegating the case to a small C++ functor written elsewhere in the file. Not sure if you see where I am coming from, but in a functional programming language or a higher level scripting language such as python, this kind of operation is quite easy to do on the fly. What I am trying to figure out is how much of the 'in-place definition of code in c++' should reasonably be handled with boost.lambda. Again, I can clearly see the power of boost.lambda when applied to std::for_each or std::transform, etc..., but I am not sure how to leverage it beyond that and I haven't seen many examples out there trying to do that either. Insights and help greatly appreciated, Many thanks, ChrisK

2 1

Two questions on boost::function
by CR Koudella 29 Nov '09

29 Nov '09

Hi, thank you very much for your help. What you suggest works fine, thanks. I have 'studied' the boost lambda library a bit and get the feeling as it says in the intro to the doc that it is especially meant to write small lambda expressions for use with the STL. I am not actually that interested in this use and am having a bit of time trying to get it to do some other things. Imagine I want to do the following operation [h * (f - g)^2](x), where the x is 'const std::vector<double> &', all functions return double and h(x) = k1 and g(x) = k2, where k1, k2 = const. f is some non-trivial function. I can make this work according to the method you indicate. I am not entirely sure what the optimal is to build the lambda expressions for the constant functions h and g, see below. It seems that I need to drive this step through boost::function, otherwise the code won't compile. // some function f given... // constant h functor const double dh = 4.0; bll::constant_type<double>::type lh(bll::constant(dh)); boost::function<double (const std::vector<double> & vecArg)> bfoh; bfoh = lh; // constant g functor const double dg = 0.5; bll::constant_type<double>::type lg(bll::constant(dg)); boost::function<double (const std::vector<double> & vecArg)> bfog; bfog = lg; // construct h * (f - g)^2 // f - g boost::function<double (const std::vector<double> & vecArg)> bfoDF; bfoDF = bll::bind(f, bll::_1) - bll::bind(bfog, bll::_1); // (f - g)^2 boost::function<double (const std::vector<double> & vecArg)> bfoSF; bfoSF = bll::bind(bfoDF, bll::_1) * bll::bind(bfoDF, bll::_1); // h * (f -g)^2 boost::function<double (const std::vector<double> & vecArg)> bfoWRF; bfoWRF = bll::bind(bfoh, bll::_1) * bll::bind(bfoSF, bll::_1); Other than this, the repetitive use of bll::bind at every stage and generally speaking, the wordiness of the script makes me wonder whether this is the right thing to use or if I am using it as I should. I mean h*(f-g)^2 is a pretty simple operation. Any comments on how to improve the above? In particular on how to build the constant functors h and g? Another question I have is, would it be possible to combine functors with different return types in the same way? Imagine j(x) is now a function that takes in an std::vector<double> and returns an std::vector<double>. Then can it be scaled with a function that takes in an std::vector<double>, but returns a double? BTW, a propos extracting the underlying functor out of a boost::function, yes it isn't ideal, but you might just need to acess the underlying interface at some point. Thanks, ChrisK >

2 1

Re: [Boost-users] [GIL] Performance warning...
by Christian Henning 28 Nov '09

28 Nov '09

Lubomir, looking at the default_channel_converter the channels already arrive as a const reference. All I did was to make sure they are still const references in the channel_converter functions. In all cases the source channels should at least be const. Which allows for more compiler optimizations. I did run the performance test in gil_test suite and the changes were marginal. Some tests were faster some were slower after the change. Christian On Fri, Nov 27, 2009 at 6:13 PM, Lubomir Bourdev <lbourdev(a)adobe.com> wrote: > This was done on purpose. I don't know if it still holds, but it used to be > that a const reference to a simple type like an int or char is slower than > passing the type by value. This is the same reason most STL algorithms take > iterators by value. If you want to make this change it is important to > verify that performance of simple built-in channel types is not adversely > affected. > > Lubomir > > On 11/27/09 12:17 PM, "Christian Henning" <chhenning(a)gmail.com> wrote: > >> Hi Eloi, you're correct and I'll fix that. I can even make it const >> reference. Running the test shows no real difference but that might be >> only because no expensive channels are being used. >> >> I'll commit the changes asap. >> >> Lubomir, please review the changes if your time allows. Affected files >> are channel_algorithm.hpp and gil_concept.hpp. >> >> Thanks, >> Christian >> > >

4 5

GGL Review Results
by Hartmut Kaiser 28 Nov '09

28 Nov '09

Hi all, The review of the Generic Geometry Library is over now. We have had vibrant discussions with regards to the library itself. In addition those stirred up a lot of controversial discussion about the Boosts review process. In this review results I will concentrate on the library at hands. Formally this review ended with 12 YES and 2 NO votes. This result reflects the overall discussion and the general consensus of this library being worth to be included into Boost. Based on this result and the discussions the Generic geometry Library has been formally accepted into Boost. It is worth highlighting that most of the reviewers emphasized the excellent quality of the library design. Here are some quotes: - "The design is very clear. I think it can serve as a standard example of how to cover a big non trivial problem domain using meta-programming, partial specialization and tag dispatch to make it uniformly accessible by a set of generic algorithms." - "The design looks clear enough so that I was able to understand about what was being done. Adding concept checking is a good idea. It also surely is a modern generic design." - "I am quite pleased with the use of tag-dispatching and strategies. I was happy to see this approach taken and by looking at the documentation and source code it seems sound. I believe this approach offers the greatest latitude for a generic library." At the same time the 2 NO votes reflect a couple of shortcomings which still need to be addressed before final inclusion into SVN. Here is a list of contingencies noted by the reviewers: - Robustness: algorithmic robustness and arithmetic stability have been discussed widely. The consensus of the reviewers is that all algorithms need to be robust and that the user should be able to make sure all calculations are arithmetically stable. GGL addresses arithmetic stability by allowing to instantiate all algorithms with arbitrary number types. But it turns out not the entire library has been converted to use this scheme yet. Any design issues that would prevent strong robustness guarantees (without drastic refactoring) in the future should be identified and fixed prior to release. The documentation needs to reflect the actual guarantees and complexities of every algorithm. - Concepts: more refinement needs to be done for the existing concepts. At least 2 users claimed to not have been able to adapt their data structures to the existing scheme. The library aims for defining the concepts and interfaces for future geometry related work in Boost, so these use cases need to be addressed. Users mentioned the missing concept inheritance. This might be a good way to address the current problems of concepts being too fine grained and too difficult to use. What needs to be done at minimum is to enhance the flexibility of the concept mechanism enabling to adapt user provided data structures more easily. The concepts need to be sound even in the light of extensions. - Boolean operations: while the library provides a set of Boolean operations those seem to be not complete and/or robust in terms of clockwise/counterclockwise geometries, closed/open polygons. Robust Boolean operations are a strong requirement, so this should be fixed as reported by at least one reviewer. - Documentation: the documentation of the library is not complete and needs additional effort. Using Doxygen alone as a documentation tool has its (known) shortcomings when it comes to generic libraries. The authors already mentioned to plan to switch to QuickBook after review allowing to have better control over the generated docs. - Testing: several reviewers mentioned the need for a thorough testing framework allowing the verification of the correctness of the algorithms in a wide range of use cases. Different test strategies need to be employed, such as high volume and random tests, known border case tests, tests using different numeric precision types, etc. Minor (non-contingency) issues: - Names of used concepts: currently the library is using mainly terms as established by the OpenGIS Consortium (OGC). This is misleading for users coming from different (non-GIS) domains. It has been suggested to introduce different namespaces for the different geometry domains (GIS, graphics, 3D, etc.) allowing to use the expected terminology established in that particular domain. - Name of the library: the name 'GGL - Generic Geometry Library' is misleading as it is not a generic geometry library but a library using generic programming techniques related to geometry. It has been suggested to use the name Boost.Geometry instead. This is not a requirement imposed by the review results, but I would like to suggest to the authors to consider renaming. - Integration with Boost.Units has been suggested. The library does not need to be completetly integrated with Boost.Units, although it appears to be reasonable to deal with types as exposed by Boost.Units especially for distance and area calculations. - Spatial data structures (such as spatial trees) have been mentioned to be crucial for a geometry related library. While the library can't implement all possible data structures in this field it can (and should) define concepts and interfaces allowing future extensions while maintaining interoperability. - In addition to that the reviewers made a lot of remarks related to different smaller inconsistencies part of which already have been addressed during the review. Barend has a full list of the remaining ones and promised to address all of them. Last but not least I would like to encourage cooperation between the authors of this library and the author of Boost.Polygon as both libraries have their strength' worth combining. In an ideal world and at some point I would like to see both libraries to be merged. But this is obviously not something to expect really soon. At this point I would like to thank all who participated in the review and, certainly, the authors for submitting this excellent library to Boost. Regards Hartmut GGL Review Manager ------------------- Meet me at BoostCon http://boostcon.com

1 0

[serialization] how to serialize map of non-default-constructible?
by ivo.t＠moss-soft.de 28 Nov '09

28 Nov '09

Hi to everybody, I'm pretty new to the list, work for some time with Boost and C++ and have a fair knowledge but am not an expert yet. I try to serialize a map whose type is not default-constructible, and I'm seriously stuck there. I thought the load_construct_data and save_construct_data overrides would help me there, but that seems not to be the case. I tried to create a private default constructor hoping that the map (respectively pair) constructor could access it, due to the boost::serialization::access friend declaration, but that didn't work as well. I really do _not_ want to make a public default constructor. What could I do as a workaround?? Any help would be greatly appreciated!! Btw, I work with Boost 1.39 and Visual Studio 2005. Thank you very much in advance Ivo

3 2