- Boost - lists.preview.boost.org

[process] How to run test cases
by Boris 23 Jan '11

23 Jan '11

As Boost.Process 0.3 has been released it would be great if the test cases are run on various platforms. So far I've tested Boost.Process on WinXP with MSVC 9.0, Cygwin with g++ 3.4.4 and Solaris with g++ 3.4.6 and Sun C++ 5.9. To make it as easy as possible for others to run the test cases here's a short description of how to proceed. Nearly all test cases depend on a program called "helpers". This program is built first and is started by many test cases as a child process. In order to find the program "helpers" the test cases must know its location. As there is no way to get the location at runtime it is hardcoded in the file libs/process/test/misc.hpp. As the location differs depending on what compiler is used YOU MUST CHECK FIRST THE PATH IN libs/process/test/misc.hpp! Otherwise most of the test cases will fail as they look for a program "helpers" in the wrong directory. As of today only those paths are correct and have been tested which are set for Windows, Cygwin and Solaris. Only after you have checked and maybe updated the path in libs/process/test/misc.hpp you should try to build and run the test cases: WinXP/MSVC 9.0 ************** With MSVC 9.0 you only need to open the Visual Studio 2008 Command Prompt, change to the directory with the test cases and run bjam: C:\boost_1_36_0\libs\process\test> ..\..\..\bjam.exe -q Cygwin/GCC 3.4.4 **************** On Cygwin it's important to know if the Boost libraries have been built for the POSIX or Windows API. By default Boost libraries on Cygwin use the Windows API. With the Windows API the Boost.Process test cases are not passed successfully though (there are compiler errors where I'm not sure currently if they are a Boost.Process problem and how they could be fixed). If you want to run the test cases on Cygwin you must (re-)build the Boost libraries to use the POSIX API: $ cd ~/boost_1_36_0 $ ./bjam cxxflags=-DBOOST_POSIX_API Afterwards you can run the test cases: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam cxxflags=-DBOOST_POSIX_API -q Solaris/GCC 3.4.6 ***************** At first you have to put the following line in ~/user-config.jam: using gcc : : : <linker-type>sun ; Then start building the Boost libraries: $ cd ~/boost_1_36_0 $ ./bjam --toolset=gcc cxxflags=-mcpu=ultrasparc For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. Afterwards the test cases can be run: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=gcc cxxflags=-mcpu=ultrasparc -q Solaris/Sun C++ 5.9 ******************* Build the Boost libraries with the sun toolset: $ cd ~/boost_1_36_0 $ ./bjam --toolset=sun stdlib=sun-stlport For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. If you run the test cases now you'll get this compiler error for one test case: "../../../boost/asio/detail/socket_ops.hpp", line 218: Error: Cannot assign void* to char*. "../../../boost/asio/detail/socket_ops.hpp", line 229: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 66: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 72: Error: Cannot assign void* to char*. The bug has been reported to the Boost.Asio mailing list. If you want to build that one test case, too, you need to fix the two files in Boost.Asio 1.36.0 yourself. All the test cases can be built and run with: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=sun stdlib=sun-stlport -q

4 9

[Phoenix-3] Is Actor assignable?
by Michel MORIN 23 Jan '11

23 Jan '11

Hi, In Phoenix 3, is Actor assignable? This is necessary for filter_iterator/transform_iterator with Phoenix to be "neat" iterators. (Unfortunately, Actor is not assignable in Phoenix 2.) P.S. After writing this mail, I found this comment (What a coincidence ;-) #4853 (Actor is never assignable regardless of the template parameter) https://svn.boost.org/trac/boost/ticket/4853#comment:2 Comment (by theller): This is fixed in phoenix V3 So the answer to this question is YES. Thank you for great work, Thomas! Regards, Michel

3 18

[asio] cygwin issue
by vicente.botet 22 Jan '11

22 Jan '11

Hi, whiline runnin the asio tests (under cygwin gcc-4.3 Windows XP ) as follows bjam cxxflags="-D__USE_W32_SOCKETS -D_WIN32_WINNT=0x0501" I got a compile error ../../../boost/asio/detail/impl/win_iocp_io_service.ipp: In member function â?~void boost::asio::detail::win_iocp_io_service::do_add_timer_queue(boost::asio::detail::timer_queue_base&)â?T: ../../../boost/asio/detail/impl/win_iocp_io_service.ipp:461: error: no matching function for call to â?~boost::asio::detail::posix_thread::posix_thread(boost::asio::detail::win_iocp_io_service::timer_thread_function&, int)â?T ../../../boost/asio/detail/posix_thread.hpp:38: note: candidates are: boost::asio::detail::posix_thread::posix_thread(const boost::asio::detail::posix_thread&) I have changed the prototype as the one for win_thread and now all the tests are OK. posix_thread(Function f, unsigned int = 0); Best, Vicente

1 0

namespace boost?
by Robert Ramey 22 Jan '11

22 Jan '11

I'm doing a toy project which uses a lot of boost libraries. In the course of doing this, I'm reminded of something that has bugged me for a long time. That is the placement of lots of stuff inside the namespace boost. Now that boost is the size that it is, this can become are real barrier to making things understandable. Currently I'm looking at range and iterator libraries - but I'm no there are lots of offenders. Certain names like join, zip, map, copy, etc. ... apear in multiple libraries. I would like to use "using namespace boost" but then I'm afraid that using something like copy will be ambigiuos Could we agree that the boost namespace (and directory structure) only be used for library names. Some time ago, I caught hell for including just a couple of functions in boost/namespace and directory. But I see tons of stuff in there now. Robert Ramey

27 96

[geometry] fusion adapt is missing
by Akira.T 22 Jan '11

22 Jan '11

Hi, follow code in libs/geometry/example/c09_custom_fusion_example.cpp : #include <boost/geometry/geometries/adapted/fusion.hpp> #include <boost/geometry/geometries/adapted/fusion_cartesian.hpp> But, this header file is missing. Please add file to trunk. == Akira Takahashi Blog : http://d.hatena.ne.jp/faith_and_brave/

3 6

[1.44][serialization] Link error with polymorphic archive and BOOST_CLASS_EXPORT
by Wilson Tim-CTW024 21 Jan '11

21 Jan '11

I've run into a conflict between use of the polymorphic archives and the BOOST_CLASS_EXPORT() macro. It doesn't seem possible to use both without getting a link error. The following code illustrates the problem (yes, I know this code doesn't do anything worth doing, but it's the simplest code that demonstrates the problem): ---------------------- # include <sstream> # include <boost/serialization/export.hpp> # include <boost/archive/polymorphic_binary_oarchive.hpp> class A { public: template<class Archive> void serialize(Archive & ar, const unsigned version) { } }; BOOST_CLASS_EXPORT(A); int main() { A a; std::ostringstream os; boost::archive::polymorphic_binary_oarchive oa(os); oa & a; } ----------------------- This code compiles OK, but a link error is generated. I've put the full link error at the bottom of this post; the gist is an undefined reference to: boost::archive::detail::archive_serializer_map<boost::archive::detail::p olymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::ar chive::binary_oarchive, char, std::char_traits<char> > > >::erase(boost::archive::detail::basic_serializer const*) I can make the error go away by either: 1) Commenting out the BOOST_CLASS_EXPORT 2) Changing the type of the oarchive from polymorphic_binary_oarchive to binary_oarchive. It really looks like there's something missing from the serialization library related to the polymorphic oarchive. Thanks in advance for any help. Tim Wilson Full link error: ---------------- /tmp/ccQvudrk.o: In function `boost::archive::detail::pointer_oserializer<boost::archive::detail::pol ymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::arch ive::binary_oarchive, char, std::char_traits<char> > >, A>::pointer_oserializer()': test_boost_ser_main.cpp:(.text._ZN5boost7archive6detail19pointer_oserial izerINS1_26polymorphic_oarchive_routeINS0_20binary_oarchive_implINS0_15b inary_oarchiveEcSt11char_traitsIcEEEEE1AEC2Ev[_ZN5boost7archive6detail19 pointer_oserializerINS1_26polymorphic_oarchive_routeINS0_20binary_oarchi ve_implINS0_15binary_oarchiveEcSt11char_traitsIcEEEEE1AEC5Ev]+0x4f): undefined reference to `boost::archive::detail::archive_serializer_map<boost::archive::detail:: polymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::a rchive::binary_oarchive, char, std::char_traits<char> > > >::insert(boost::archive::detail::basic_serializer const*)' /tmp/ccQvudrk.o: In function `boost::archive::detail::pointer_oserializer<boost::archive::detail::pol ymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::arch ive::binary_oarchive, char, std::char_traits<char> > >, A>::~pointer_oserializer()': test_boost_ser_main.cpp:(.text._ZN5boost7archive6detail19pointer_oserial izerINS1_26polymorphic_oarchive_routeINS0_20binary_oarchive_implINS0_15b inary_oarchiveEcSt11char_traitsIcEEEEE1AED2Ev[_ZN5boost7archive6detail19 pointer_oserializerINS1_26polymorphic_oarchive_routeINS0_20binary_oarchi ve_implINS0_15binary_oarchiveEcSt11char_traitsIcEEEEE1AED5Ev]+0x24): undefined reference to `boost::archive::detail::archive_serializer_map<boost::archive::detail:: polymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::a rchive::binary_oarchive, char, std::char_traits<char> > > >::erase(boost::archive::detail::basic_serializer const*)' collect2: ld returned 1 exit status

2 2

[1.44][serialization] Link error with polymorphic archive and BOOST_CLASS_EXPORT
by Wilson Tim-CTW024 21 Jan '11

21 Jan '11

(Sorry if this is a duplicate post...I sent it once, didn't see it, so I'm sending again) I've run into a conflict between use of the polymorphic archives and the BOOST_CLASS_EXPORT() macro. It doesn't seem possible to use both without getting a link error. The following code illustrates the problem (yes, I know this code doesn't do anything worth doing, but it's the simplest code that demonstrates the problem): ---------------------- # include <sstream> # include <boost/serialization/export.hpp> # include <boost/archive/polymorphic_binary_oarchive.hpp> class A { public: template<class Archive> void serialize(Archive & ar, const unsigned version) { } }; BOOST_CLASS_EXPORT(A); int main() { A a; std::ostringstream os; boost::archive::polymorphic_binary_oarchive oa(os); oa & a; } ----------------------- This code compiles OK, but a link error is generated. I've put the full link error at the bottom of this post; the gist is an undefined reference to: boost::archive::detail::archive_serializer_map<boost::archive::detail::p olymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::ar chive::binary_oarchive, char, std::char_traits<char> > > >::erase(boost::archive::detail::basic_serializer const*) I can make the error go away by either: 1) Commenting out the BOOST_CLASS_EXPORT 2) Changing the type of the oarchive from polymorphic_binary_oarchive to binary_oarchive. It really looks like there's something missing from the serialization library related to the polymorphic oarchive. Thanks in advance for any help. Tim Wilson Full link error: ---------------- /tmp/ccQvudrk.o: In function `boost::archive::detail::pointer_oserializer<boost::archive::detail::pol ymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::arch ive::binary_oarchive, char, std::char_traits<char> > >, A>::pointer_oserializer()': test_boost_ser_main.cpp:(.text._ZN5boost7archive6detail19pointer_oserial izerINS1_26polymorphic_oarchive_routeINS0_20binary_oarchive_implINS0_15b inary_oarchiveEcSt11char_traitsIcEEEEE1AEC2Ev[_ZN5boost7archive6detail19 pointer_oserializerINS1_26polymorphic_oarchive_routeINS0_20binary_oarchi ve_implINS0_15binary_oarchiveEcSt11char_traitsIcEEEEE1AEC5Ev]+0x4f): undefined reference to `boost::archive::detail::archive_serializer_map<boost::archive::detail:: polymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::a rchive::binary_oarchive, char, std::char_traits<char> > > >::insert(boost::archive::detail::basic_serializer const*)' /tmp/ccQvudrk.o: In function `boost::archive::detail::pointer_oserializer<boost::archive::detail::pol ymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::arch ive::binary_oarchive, char, std::char_traits<char> > >, A>::~pointer_oserializer()': test_boost_ser_main.cpp:(.text._ZN5boost7archive6detail19pointer_oserial izerINS1_26polymorphic_oarchive_routeINS0_20binary_oarchive_implINS0_15b inary_oarchiveEcSt11char_traitsIcEEEEE1AED2Ev[_ZN5boost7archive6detail19 pointer_oserializerINS1_26polymorphic_oarchive_routeINS0_20binary_oarchi ve_implINS0_15binary_oarchiveEcSt11char_traitsIcEEEEE1AED5Ev]+0x24): undefined reference to `boost::archive::detail::archive_serializer_map<boost::archive::detail:: polymorphic_oarchive_route<boost::archive::binary_oarchive_impl<boost::a rchive::binary_oarchive, char, std::char_traits<char> > > >::erase(boost::archive::detail::basic_serializer const*)' collect2: ld returned 1 exit status

2 1

[Process] List of small issues
by Artyom 21 Jan '11

21 Jan '11

Hello, I've made a micro review of Boost.Process, there are small issues I've found: - stream buffer implementation: underflow() you need to check the errno if it is EINTR, returning -1 and getting EINTR is not a problem and thus it should retry. sync(); Same as in underflow() - check for EINTR and retry, but also there is a problem that you do not check that you had fully written the data. For example what I write out << std::flush sync() is called and I expect the all data should be written to device, so if return value is less then the size of the buffer you should retry and write again till buffer is empty, you get error or EOF. - Windows and Unicode. You are using CreateProcessA. I would recommend to always use wide API and convert narrow strings to wide similarly to what boost::filesystem::v3 does, so for example where the global locale as utf-8 facet you would convert narrow strings to wide and run it. Notes: 1. You can also always assume that strings under windows are UTF-8 and always convert them to wide string before system calls. This is I think better approach, but it is different from what most of boost does. 2. I do not recommend adding wide API - makes the code much uglier, rather convert normal strigns to wide strings before system call. - It may be very good addition to implement full support of putback. Additional point: ----------------- I've noticed that you planned asynchronous notification and so on but I think it is quite important to add feature that provide an ability to wait for multiple processes to terminate and have timeout. It can be done using sigtimedwait/sigwait and assigned signal handlers for SIGCHLD Artyom P.S.: Good luck with the review library looks overall very nice.

21 144

Re: [boost] [string] proposal
by Ivan Le Lann 21 Jan '11

21 Jan '11

----- "Matus Chochlik" <chochlik(a)gmail.com> wrote : > Also I've uploaded into the vault file string_proposal.zip Not that I have anything against UTF-8, but is there no way to build this utf8 string class out of an encoding generic one ? Keeping your "utils" vocabulary, I see something like : template <typename encoding_utils> class encoded_string; typedef encoded_string <utf8_utils> string; // and/or utf8_string In your code, that would mean to at least move various typedefs into encoding_utils, such as code point and code unit type. And to rename various methods, of course. Regards, Ivan.

2 1

[1.46] Late changes?
by John Maddock 21 Jan '11

21 Jan '11

I've just fixed this nasty bug which manifests itself as the hypergeometric PDF calculating bogus values on certain FPUs: https://svn.boost.org/trac/boost/ticket/5095 Ignoring the new diagnostic code (not normally executed) the change is pretty trivial: https://svn.boost.org/trac/boost/changeset/68346. Is there likely to be a window where this can be merged to 1.46? Thanks, John.

2 1

geometry moved to trunk
by Barend Gehrels 21 Jan '11

21 Jan '11

hi, Boost.Geometry is moved from sandbox to trunk yesterday. Questions: 1) Will I update the two files libraries.htm and maintainers.txt within $/trunk/libs to add geometry there? 2) How will geometry appear in the trunk regression overviews? There are already many unit tests using Boost.Test and jamfiles handling them. Thanks, Barend

4 6

[assert] static_assert envy
by Beman Dawes 20 Jan '11

20 Jan '11

Whenever I write a BOOST_ASSERT macro, I'm envious of C++0x static_assert because of its ability to supply a clear error message. I'd really like to be able to write a variant of BOOST_ASSERT like this: #include <boost/assert.hpp> int main() { BOOST_EXTENDED_ASSERT(true, "This will not assert"); BOOST_EXTENDED_ASSERT(false, "This will assert"); return 0; } And then get debug mode output like this: ***** Internal Program Error - Assertion Failed ***** extended_assert_test.cpp(6): error in int main(void): This will assert Adding the code below at the end of <boost/assert.hpp> will do just that. It isn't totally ready for prime time, but it would be nice to find out if others would like something similar added to<boost/assert.hpp>. --Beman // experimental code #ifndef NDEBUG # include <iostream> # include <cstdlib> # include <boost/current_function.hpp> namespace boost { namespace assertion { namespace detail { inline void extended_assert_failed(char const * msg, char const * function, char const * file, long line) { std::cerr << "***** Internal Program Error - Assertion Failed *****\n"; std::cerr << file << '(' << line << "): error in " << function << ": " << msg << std::endl; std::exit(99999); } }}} // boost::assertion::detail # undef BOOST_EXTENDED_ASSERT # define BOOST_EXTENDED_ASSERT(expr, msg) \ ((expr)? ((void)0): ::boost::assertion::detail::extended_assert_failed\ (msg, BOOST_CURRENT_FUNCTION, __FILE__, __LINE__)) #else # define BOOST_EXTENDED_ASSERT(expr, msg) #endif

15 39

Are we frozen?
by Marshall Clow 20 Jan '11

20 Jan '11

Is the release branch closed for changes for 1.46.0? If it is, may I have permission to merge change [68291] - which fixes two spelling errors in the parameter library docs? https://svn.boost.org/trac/boost/ticket/4983 -- 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 4

[serialization] de-serialization performance issue
by Brad Higgins 20 Jan '11

20 Jan '11

I have encountered a performance issue with serialization, when used with multi-index followed by a vector<size_t>. I have a reduced program below, which reproduces the issue (using boost 1.44.0). I basically have a class with a multi-index member, and a vector<size_t> member. It serializes OK, but deserialization's performance appears to be O(n^2). It seems to be getting bogged down in basic_iarchive_impl::reset_object_address(), when deserializing the vector. Any thoughts? Thanks, Brad ------------------------------------------- #include <iostream> #include <fstream> #include <sstream> #include <string> #include <vector> #include <boost/multi_index_container.hpp> #include <boost/multi_index/key_extractors.hpp> #include <boost/multi_index/hashed_index.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/serialization/access.hpp> #include <boost/serialization/assume_abstract.hpp> #include <boost/serialization/base_object.hpp> #include <boost/serialization/export.hpp> #include <boost/serialization/nvp.hpp> #include <boost/serialization/vector.hpp> #include <boost/serialization/version.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/archive/text_oarchive.hpp> struct DummyItem { std::size_t ordered_val_; DummyItem( const std::size_t ordered_val) : ordered_val_(ordered_val) {} DummyItem() : ordered_val_(0) {} /** * Boost serialization hook */ friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & boost::serialization::make_nvp("ordered_val", ordered_val_); } }; BOOST_CLASS_VERSION(DummyItem,1) namespace bmi = boost::multi_index; class MultiIndexDummy { public: struct ordered_val_tag {}; typedef bmi::multi_index_container< DummyItem, bmi::indexed_by< bmi::ordered_non_unique< bmi::tag<ordered_val_tag>, BOOST_MULTI_INDEX_MEMBER(DummyItem,std::size_t,ordered_val_) > > > MultiIndexDb; typedef MultiIndexDb::index<ordered_val_tag>::type OrderedVal2Index; bool insert(DummyItem &item) { bool rc = false; OrderedVal2Index &str_idx = db_.get<ordered_val_tag>(); OrderedVal2Index::iterator str_iter = str_idx.find(item.ordered_val_); if (str_idx.end() == str_iter) { std::pair<OrderedVal2Index::iterator,bool> insert_res = str_idx.insert(item); if (insert_res.second) { rc = true; } } return rc; } MultiIndexDb db_; std::vector<std::size_t> vector_ints_; /** * Boost serialization hook */ friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { std::cout << "SERIALIZE db_\n"; ar & boost::serialization::make_nvp("db", db_); std::cout << "SERIALIZE vector_ints_\n"; ar & boost::serialization::make_nvp("vector_ints", vector_ints_); // <- THIS IS SLOW DURING INPUT } }; BOOST_CLASS_VERSION(MultiIndexDummy, 1); int main(int argc, char* argv[]) { const std::string filename("persisted_data.dat"); std::cout << "Start\n"; { MultiIndexDummy mi_map; for (int i=0; i<100000; i++) { DummyItem item(i); mi_map.insert(item); mi_map.vector_ints_.push_back(i); } std::cout << "persist the data\n"; std::ofstream out_file(filename.c_str()); boost::archive::text_oarchive oa(out_file); oa.register_type(static_cast<MultiIndexDummy*>(NULL)); oa << boost::serialization::make_nvp("id", mi_map); } std::cout << "Restore\n"; { MultiIndexDummy mi_map; std::ifstream in_file(filename.c_str()); boost::archive::text_iarchive ia(in_file); ia >> mi_map; // <- THIS IS SLOW } std::cout << "Done\n"; return 0; }

2 2

[fusion] Visual C++ 8.0 compilation errors
by Ralf W. Grosse-Kunstleve 20 Jan '11

20 Jan '11

I'm running nightly local multi-platform builds using the boost trunk. The last two nights the Visual C++ 8.0 build (Windows XP 32-bit) was broken: C:\AUTOBU~3\sources\boost\boost/fusion/sequence/ comparison/less_equal.hpp(48) : error C2039: 'is_native_fusion_sequence' : is not a member of 'boost::fusion::detail' C:\AUTOBU~3\sources\boost\boost/fusion/sequence/comparison/less_equal.hpp(48) : error C2065: 'is_native_fusion_sequence' : undeclared identifier C:\AUTOBU~3\sources\boost\boost/fusion/sequence/comparison/less_equal.hpp(48) : error C2974: 'boost::disable_if' : invalid template argument for 'Cond', type expected C:\AUTOBU~3\sources\boost\boost/utility/enable_if.hpp(59) : see declaration of 'boost::disable_if' C:\AUTOBU~3\sources\boost\boost/fusion/sequence/comparison/less_equal.hpp(48) : error C2988: unrecognizable template declaration/definition C:\AUTOBU~3\sources\boost\boost/fusion/sequence/comparison/less_equal.hpp(48) : error C2059: syntax error : ',' C:\AUTOBU~3\sources\boost\boost/fusion/sequence/comparison/less_equal.hpp(48) : error C2039: 'type' : is not a member of '`global namespace'' boost svn rev. 68202 three nights ago still worked, rev. 68221 was the first I noticed that doesn't. VC 9 and 10 are fine, and so are many Linux and Mac builds. The failure is specific to VC 8. Ralf

2 1

[context] new version - support for Win64
by Oliver Kowalke 20 Jan '11

20 Jan '11

I've uploaded boost.context-0.3.0.zip to boost vault. The new version supports the context-/stack- swapping provided by the OS (ucontext ABI on UNIX, Fiber ABI on Windows) as well a fast context swapping (using assembler). supported platforms: i386, x86_64, arm, mips, ppc OS: UNIX, Windows (32 bit/64 bit) More details can be found in the documentation (included in the archive).

7 28

[Wiki] Changes in information about gcc warnings.
by Patrick Horgan 20 Jan '11

20 Jan '11

I did a first cut at adding information to the wiki https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines for the changes in GCC that let you suppress warnings locally. It's probably not useful to you, since it's only in gcc version 4.x and the ability to push and pop the current state is very recent, in 4.6. Nevertheless it needed documenting. There's a change to the behavior of #pragma GCC system_header as well. It previously had to be at file scope, and now can be anywhere in the file and affects from that point forward. The new pragma: #pragma GCC diagnostic <ignored|warning|error> "-WASPECIFICWARNINGOPTION" used like: #pragma GCC diagnostic ignored "-Wdeprecated-declarations". Prior to 4.6 this also had to be at file scope. As of 4.6 it can be at any line. With both it affects from that point forward. #pragma GCC diagnostic <push|pop> These two just showed up at 4.6 and can be at any line. Without them, the previous pragma is not that useful because if you affect the users flags they will not like you! lol! With them you can do what you really want: #pragma GCC diagnostic push #pragma GCC diagnostic "-Wunitialized" // your code here #pragma GCC diagnostic pop 4.6 is the current development trunk, so consider this a heads up. I'm trying to get from the gcc guys a good description of what preprocessor checks can be done to determine what's available when. When I get it, I'll add it to the wiki. Of course, almost all of the time warnings represent real issues and it's better to change your code to get rid of the warning and make it more correct, than to change your code to have ugly pragmas that suppress the warning. Patrick

9 25

Re: [boost] [general] What will string handling in C++ look like in the future [was Always treat ... ]
by Brent Spillner 20 Jan '11

20 Jan '11

On 1/19/2011 11:33 AM, Peter Dimov wrote: > This was the prevailing thinking once. First this number of bits was 16, > which incorrect assumption claimed Microsoft and Java as victims, then > it became 21 (or 22?). Eventually, people realized that this will never > happen even if we allocate 32 bits per character, so here we are. The OED lists ~600,000 words, so 32 bits is enough space to provide a fully pictographic alphabet for over 7,000 languages as rich as English, with room for a few line-drawing characters left over. Surely that's enough?

6 5

Re: [boost] [1.45][Serialization] fails to cross-compile usingarm-linux-uclibc toolchain
by Alex Potapenko 20 Jan '11

20 Jan '11

Thank you, Robert! Robert Ramey wrote: > > BOOST_STATIC_ASSERT(sizeof(class_id_type) == sizeof(int_least16_t)); > > BOOST_STATIC_ASSERT(sizeof(class_id_reference_type) == > > sizeof(int_least16_t)); > > These should be investigated. before commenting out. It could be > detecting something unexpected in a pre-requisite library. > > Robert Ramey The one thing I'm pretty certain about know is that it is a specifically uclibc issue, since I tried building with four different arm-linux toolchains (two glibc and two uclibc ones), and while the glibc toolchains built fine, both uclibc ones failed the same assertions. How should I proceed with investigation? Thank you, Alex

1 0

Re: [boost] namespace boost?
by Brent Spillner 19 Jan '11

19 Jan '11

On 19/01/11 at 7:58 PM, Dean Michael Berris wrote: >That doesn't make me like the 'lib' name myself. Although cpp-netlib >is there, I'm just not that creative to come up with an alternate name >for it. :D When I first saw the name 'cpp-netlib' I assumed it was a numerical library. ;-)

1 0

Re: [boost] BoostCon 2011 keynote speaker
by Dave Abrahams 19 Jan '11

19 Jan '11

At Sat, 15 Jan 2011 16:56:51 -0600, Hartmut Kaiser wrote: > > Hey all, > > This is to inform you, that Hans Boehm (HP, > http://www.hpl.hp.com/personal/Hans_Boehm/) accepted to give this year's > keynote. I believe this is excellent news for the conference and for all > participants. He will have a lot to say, which directly concerns many C++ > developers. He will give us a topic for his keynote asap at which point we > should add a note to the website. This is awesome news! Hans is a C++ Committee member, probably the primary driving force behind the new C++ memory model that allows concurrency, and is also famous as the developer of a widely-used C++ garbage collector, and a bit less famous for the "rope" data structure. I know he will give a great keynote and I'm eager to hear it. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

Distributed Development Process (was Re: Development Practices (Proposal Progress))
by Dean Michael Berris 19 Jan '11

19 Jan '11

On Thu, Jan 13, 2011 at 9:15 PM, Beman Dawes <bdawes(a)acm.org> wrote: > On Tue, Jan 11, 2011 at 10:36 AM, Dave Abrahams <dave(a)boostpro.com> wrote: >> >> Create a new one... I don't think we want to tweak "the process." I >> think we want to create an alternative process for people who are >> interested in following a more modern, decoupled development model. >> Eventually, if it works, the other one will die of underuse. The >> thing is that you have to make sure that your proposal doesn't clash >> with the way we do things now: for example, it can't create >> significant new work for the release managers. >> > tl; dr; -- feedback on https://svn.boost.org/trac/boost/wiki/DistributedDevelopmentProcess would be very much appreciated! > Excellent points! > > For example, I'd very much like to move both the libraries I maintain and my > release management work to Git. I've been using it for a while now on > various projects, including one very small (three contributors) distributed > project, and find Git preferable by a wide margin. But others will want to > stick with SVN at least for awhile. Because Git can track a Subversion > repository, it is probably possible to use both without undue trouble. > I have the same experience -- and I've worked with larger teams that have been using Git exclusively with wonderful results. It's the difference between a concurrent lock-free queue and one that has a critical section on all the member functions. One invites a lot less friction and enables more fluid workflows while the other, not so much. > While I'm leery of anything that would "create significant new work for the > release managers" on an ongoing basis, I am willing to put in some extra > work during a transition. > Cool. :) > Areas where I personally don't want any big changes yet are the Boost build > and regression testing systems. Alternatives for either of these systems > don't appear anywhere near ready for prime time WRT Boost. > Right, I haven't gotten thinking about that part yet, but I think others are already working on that front. :) > The formal review system needs a drastic rework to make it more parallel and > remove bottlenecks, but I don't have anything beyond vague feelings about > how to do that. > Yes and I intend to address that in this document: https://svn.boost.org/trac/boost/wiki/DistributedDevelopmentProcess I haven't gotten to the part on the specifics yet but I think it would be good to get feedback on what's already there. :) -- Dean Michael Berris about.me/deanberris

3 10

review request: addition to type_traits library of has_operator_xxx
by Frédéric Bron 19 Jan '11

19 Jan '11

I would like to propose to your review the following addition to the type_traits library, available at the following addresses: https://svn.boost.org/trac/boost/browser/sandbox/type_traits http://dl.free.fr/lRm4VL6WP/type_traits.tar.bz2 The purpose of the addition is to add type traits to detect if unary and binary operators can be applied to given types. For example, is "x<y" or "!x" or "x+y" meaningful? If required, the return type of such an expression is checked to know if it is convertible to a given type. Default behaviour is to not check the return type. The following traits are added: // binary operators: template < typename LHS, typename RHS=LHS, typename RET=void > == has_operator_equal_to != has_operator_not_equal_to > has_operator_greater >= has_operator_greater_equal < has_operator_less <= has_operator_less_equal + has_operator_plus - has_operator_minus * has_operator_multiplies / has_operator_divides % has_operator_modulus && has_operator_logical_and || has_operator_logical_or & has_operator_bit_and | has_operator_bit_or ^ has_operator_bit_xor // unary operators: template < typename RHS, typename RET=void > + has_operator_unary_plus - has_operator_unary_minus ! has_operator_logical_not This new version reflects the discussions we had on the list: http://thread.gmane.org/gmane.comp.lib.boost.devel/194625 In particular about the check or not of the return type. All operators are now included and not only comparison binary operators. Example: has_operator_less<LHS, RHS, RET>::value_type is the type bool. has_operator_less<int> inherits from true_type. has_operator_less<int, int, std::string> inherits from false_type. has_operator_unary_minus<int, long> inherits from true_type. has_operator_unary_minus<double, int> inherits from true_type. has_operator_unary_minus<int, std::string> inherits from false_type. Documentation is accessible at libs/type_traits/doc/html/index.html in the archive. Regards, Frédéric PS: tested with g++ 4.4.5 on i686-linux.

14 53

[1.45][Serialization] fails to cross-compile using arm-linux-uclibc toolchain
by Alex Potapenko 19 Jan '11

19 Jan '11

Building boost 1.45 on Debian using arm-linux-uclibc toolchain fails to compile serialization lib, due to static assertions in basic_binary_?archive.hpp's at: BOOST_STATIC_ASSERT(sizeof(tracking_type) == sizeof(bool)); BOOST_STATIC_ASSERT(sizeof(class_id_type) == sizeof(int_least16_t)); BOOST_STATIC_ASSERT(sizeof(class_id_reference_type) == sizeof(int_least16_t)); It appears to be some uclibc issue, since it builds fine using glibc toolchains. Is it safe to simply comment out these assertions? Thanks in advance, Alex

2 1

Re: [boost] [context] Implementation comments
by Andrzej Krzemienski 19 Jan '11

19 Jan '11

>>> Why is boost::thread implemented with move-semantics? >> Boost.Context is much more low level than Boost.Thread. > why? thread and context are resources - I don't see context more low > level than thread Hold on. I understand that that you are saying that context is the same level as thread. On the other hand in the reply to my question (about using boost::function) you said > boost.context is intended to be the basis of such things like coroutines > (see boost.coroutine) and fibers (see boost.fiber). Which somehow implied that Context is lower-level than Coroutine or Fiber. If you really treat Context the same level as Thread, I would suggest passing function<void()> as trampoline function. If you can afford using pimpl, you can easily change function<void()> to void(*)(void*) and void* parameters: void call( void* arg) { auto ptr = static_cast< function<void()>* >( arg ); ptr->operator(); } function<void()> trampoline = ...; context_impl( call, &trampoline ); Using function<void()> makes it easier to understand for thread users and makes the interface similar to thread, task, etc... Regards, &rzej

2 2