- Boost - lists.boost.org

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