- Boost - lists.boost.org

[release][1.47] Release branch open + schedule
by Daniel James 05 Apr '11

05 Apr '11

Hello everyone, It's been over a week since the release, so it's time to open the release branch. Since we're running late, and we haven't discussed the changes to the schedule, and I think it helps people to pace their development, we should probably decide on a schedule for this release pretty quickly, and then discuss the schedule for future releases later. We discussed having longer betas, 4 weeks was suggested. If we do that this time, it'll leave a very small window for merging to release, so I think 3 weeks might be better. Something like: 4th April: Release branch closed for beta (bug fixes only). 11th April: Beta target date. 2nd May: Release target date. Note: That's just a proposal, not the actual schedule. It isn't up to me. That's still a tight schedule, maybe a shorter beta or a delayed release would be better. Any thoughts? Daniel

4 7

Re: [boost] [Filesystem] Linking problem with 1_46_1
by Max Moorkamp 05 Apr '11

05 Apr '11

> Max Moorkamp wrote: >> > Hi, >> > >> > I have recently upgraded to boost 1_46_1 and since then I am >> > experience linking problems with the filesystem library. >> > >> > I have performed a standard install using ./bootstrap.sh; bjam; bjam >> > install under Ubuntu 10.04 with the default gcc (4.4.3). >> > I can boil the problem down to this test program: >> > >> > #include<boost/filesystem.hpp> >> > #define BOOST_FILESYSTEM_VERSION 3 >> > #define BOOST_FILESYSTEM_NO_DEPRECATED >> > >> > int main() >> > { >> > boost::filesystem::copy_file("a", "b"); >> > } >> > >> > compiling this with >> > >> > g++ test.cpp -lboost_system -lboost_filesystem >> > > It might be as simple as the order you link to the libraries. The boost > filesystem library depends on the boost system library, so you should > probably put "-lboost_system" after "-lboost_filesystem" on the command > line to link your program. That was my first thought, but the linking error does not come from boost_system, plus all of g++ test.cpp -lboost_filesystem -lboost_system g++ test.cpp -lboost_system -lboost_filesystem g++ test.cpp -lboost_filesystem give the same /tmp/cc9OO6P2.o: In function `boost::filesystem3::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&)': test.cpp:(.text._ZN5boost11filesystem39copy_fileERKNS0_4pathES3_[boost::filesystem3::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&)]+0x2a): undefined reference to `boost::filesystem3::detail::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&, boost::filesystem3::copy_option::enum_t, boost::system::error_code*)' collect2: ld returned 1 exit status Regards Max -- Max Moorkamp IFM-GEOMAR Wischhofstr. 1-3 24148 Kiel Tel.: Germany - 431 - 600 2570 FAX.: Germany - 431 - 600 2915

1 0

[lexical cast] Performance improvements
by Antony Polukhin 05 Apr '11

05 Apr '11

Working with Boost Lexical Cast library found that some casts are working really slow. For example, cast from short to int is done via cast from short to char[], and cast from char[] to int. Cast from char* to string is done via string() constructor call and string`s append function call (instead of string constructor call with char array as a parameter). So I wrote patch to Boost Lexical Cast library, that returns Target directly constructed from Source in cases, when: 1) Source and Target are arithmetics (and not char or wchar_t), and all values of Source are in range of Target 2) Source and Target are both char or both wchar_t 3) Source is array of CharT and Target is std::basic_string<CharT, ...> 4) Source and Target are std::basic_string with same template parameters It gives performance boost more than 10 times in case 1) , about 7 times in case 2), and about 1.5 times in cases 3) and 4). Existing tests for Boost Lexical Cast library cover considered cases. Patch was successfully tested on Intel 11.1.072, g++-4.4.5, VC++9 compilers. P.S.: I`m a newbie here, so where shall I send this patch? Shall I test it on other compilers?

5 5

[Filesystem] Linking problem with 1_46_1
by Max Moorkamp 05 Apr '11

05 Apr '11

Hi, I have recently upgraded to boost 1_46_1 and since then I am experience linking problems with the filesystem library. I have performed a standard install using ./bootstrap.sh; bjam; bjam install under Ubuntu 10.04 with the default gcc (4.4.3). I can boil the problem down to this test program: #include <boost/filesystem.hpp> #define BOOST_FILESYSTEM_VERSION 3 #define BOOST_FILESYSTEM_NO_DEPRECATED int main() { boost::filesystem::copy_file("a", "b"); } compiling this with g++ test.cpp -lboost_system -lboost_filesystem results in this error message /tmp/ccBuSw7s.o: In function `boost::filesystem3::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&)': test.cpp:(.text._ZN5boost11filesystem39copy_fileERKNS0_4pathES3_[boost::filesystem3::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&)]+0x2a): undefined reference to `boost::filesystem3::detail::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&, boost::filesystem3::copy_option::enum_t, boost::system::error_code*)' collect2: ld returned 1 exit status I had a look at this thread http://boost.2283326.n4.nabble.com/Filesystem-problems-with-g-std-c-0x-td26… but adding or removing -std=c++0x does not change anything. I also tried to see whether any special compiler options were used during the build of boost, so here is the line for operations.hpp "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/filesystem/build/gcc-4.4.3/release/link-static/threading-multi/v3/src/operations.o" "libs/filesystem/v3/src/operations.cpp" There is nothing there that strikes me as special, any ideas anyone. Regards Max -- Max Moorkamp IFM-GEOMAR Wischhofstr. 1-3 24148 Kiel Tel.: Germany - 431 - 600 2570 FAX.: Germany - 431 - 600 2915

3 2

[trac] Phoenix Component
by Thomas Heller 04 Apr '11

04 Apr '11

Hi, Can someone please add a Phoenix component to trac and add me and JdG as maintainer? Thanks, Thomas

3 3

[GSoC] coerce (previously construe_cast)
by Jeroen Habraken 04 Apr '11

04 Apr '11

Hi, Some time ago I've announced construe_cast as a library which builds upon boost.spirit to create a cast-like operator aiming to provide an alternative to lexical_cast providing greater speed and flexibility. It has since been renamed to boost.coerce (it's the last rename, I promise) and it has found its way to the boost sandbox where development will continue. For the original email I'd like to point you to http://boost.2283326.n4.nabble.com/construe-cast-call-for-interest-and-feed…. Due to an internship I haven't been able to get much done on this project lately. I would still very much like to see this through and because of this I would like to propose this as a GSoC project. There is quite a bit to be done to get this to the level expected from a potential boost library, however I believe I can get it in a state where it can be reviewed within the timespan set for the GSoC. The request for feedback stands, and please be expecting my proposal! Regards, Jeroen Habraken

4 4

[serialization]Can I pass the grandparent class to BOOST_SERIALIZATION_BASE_OBJECT_NVP?
by Takatoshi Kondo 04 Apr '11

04 Apr '11

Hi, I'd like to check that my approach is correct or not. Condition: There are three classes A, B and C. The class A is the base class of B. The class B is the base class of C. Requirements: 1.The class A and B shouldn't depend on the serialization library. 2.The class C should be serialized via the base class A (Polymorphic). My approach: Applying non intrusive version serialize function to the class A and B. In the class C, using the macro BOOST_SERIALIZATION_BASE_OBJECT_NVP with the argument A (not B). I skip the class B in the class hierarchy on purpose. If I pass it B instead of A, the following exception would be occurred. "unregistered void cast struct C<-struct A" I believe that my approach is correct. (using A) But I suspect that it might work correctly by accident. #include <boost/serialization/serialization.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/serialization/nvp.hpp> #include <boost/serialization/export.hpp> #include <fstream> struct A { virtual ~A() {} }; // non intrusive serialize namespace boost { namespace serialization { template<class Archive> void serialize(Archive& /*ar*/, A&, unsigned int const /*version*/) {} }} struct B : public A {}; // non intrusive serialize namespace boost { namespace serialization { template<class Archive> void serialize(Archive& /*ar*/, B&, unsigned int const /*version*/) {} }} struct C : public B { friend class boost::serialization::access; template<class Archive> void serialize(Archive& ar, unsigned int const /*version*/) { ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(A); // My approach // ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(B); } }; BOOST_CLASS_EXPORT(C) int main() { { std::ofstream ofs("test.xml"); C c ; A* a(&c); boost::archive::xml_oarchive oa(ofs); oa << boost::serialization::make_nvp("a", a); } { std::ifstream ifs("test.xml"); boost::archive::xml_iarchive ia(ifs); A* a; ia >> boost::serialization::make_nvp("a", a); assert(dynamic_cast<C*>(a)); delete a; } } Regards, Takatoshi Kondo

3 2

[local] files organization
by Vicente Botet 04 Apr '11

04 Apr '11

Hi, While installing Boost.Local I observed that there are 3 directories under Boost to update; detail, local and utility. To make easier the update, it will be worth to move all the detail and utility parts under the local directory. local/ detail/ preprocessor/ keyword/ variadic_macro_data utility/ BTW, if you just copy files from other libraries waiting from them to be released, shouldn't you preserve the copyright (VMD)? Shouldn't the utility identity go to the detail/preprocessor directory? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/local-files-organization-tp3424684p34246… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Re: [boost] [lexical-cast] version of lexical_cast in 1.46.1 is quite older than in trunk
by Antony Polukhin 04 Apr '11

04 Apr '11

> "SergV"<serge-voropaev(a)yandex.ru> wrote in message > news:loom.20110329T052451-354@post.gmane.org... > We discovered lexical_cast from 1.43 and 1.46.1 versions do not work in > our > program. But version of lexical_cast from trunk work very well. Version > information: > 1.46.1 - rev. 56161 13.09.2009 > trunk - rev.65279 5.09.2010 > > 1) Is there any reason that release does not include last version > lexical_cast > from trunk? > 2) May be there are a lot of such forgotten files in trunk? There is also some mess with tickets for lexical_cast : some tickets are in bug database for months (and even years). > On Wed, 2011-03-30 at 18:16 +0300, Matthew Chambers wrote: >> Does that mean lexical_cast is orphaned? I'd like to see lexical_cast have optimized conversions for >> string->number and number->string (template specializations using strtol/strtod; or optionally using >> the spirit-based construe_cast). Being able to pass ios flags to control the format (i.e. boolalpha) >> would be nice too [...] >> Which reminds me - lexical_cast error messages are not very >> informative[...] > >Agreed. This should be added as well[...] > >-Matt I can take care about some of this issues, but if lexical_cast is orphaned and not maintained any more it`ll be just wasting time. - Antony

4 3

Re: [boost] [MSM] feature request stop(const event& event_)
by Christophe Henry 03 Apr '11

03 Apr '11

Hi Richard, >> While big improvements were made, there will always be a limit, >> especially with VC9. Did you try with VC10? It'd be interesting to know. >I will try this for you when I will have a spare 10 minutes. >I did use for some time VC10 in the past and I did not observe too >much difference in the heap usage during compilation Thanks. I personally didn't notice big improvements either :( >The public start has a limitation that I can't tell during runtime what >event is triggering the start e.g I can't specify the initial event in >runtime for the initial transitions. > >I want to use start to cause the same behavior as an entry transaction >causes on a composite state machine. I just committed a new version into the trunk (70961) where you will find: - a stop() method - like for the initial event, you have the possibility to define your own event by adding a typedef inside the front-end: typedef my_final_event final_event; - a start and stop method with an event as parameter. I'm not sure it's a great idea as you have the typedef but we can give it a try. Please notice that this version calls on_entry so you shouldn't do it yourself. I didn't update the doc yet, I'll do it for 1.47. Regards, Christophe

2 1