August 2011 - Boost - lists.preview.boost.org

[locale] Slides for the lecture on Boost.Locale
by Artyom Beilis 14 Aug '11

14 Aug '11

Hello, I had given a lecture about the Boost.Locale library at the annual Israeli FOSS conference "August Penguin". The slides can be found there: - http://art-blog.no-ip.info/files/August-Pinguin-Boost-Locale.pdf - http://art-blog.no-ip.info/files/August-Pinguin-Boost-Locale.odp I hope the video would be available soon. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

2 2

Introduction
by Andrew Hundt 14 Aug '11

14 Aug '11

Hi everyone, I'm Andrew Hundt and I've been doing C++ development for about 3 years. I've also been following the boost mailing lists for about the last two years. I've occasionally asked questions on this list during that time, but I've never introduced myself. I'm at Carnegie Mellon University in a staff position, and I have some possible contributions based on my work there that I've been hoping to at least gauge interest on. However, I wanted to introduce myself first, so greetings! Cheers! Andrew Hundt

2 1

[uuid][release] Changelog for 1.47.0 does not properly warn about critical bug
by Eric Niebler 13 Aug '11

13 Aug '11

Cross-posting to the developers list, fixing the title. This sounds like a serious bug, possibly worthy of a point release. Can anybody confirm and chime in? On 8/5/2011 4:20 AM, Paul Harris wrote: > Hello, I discovered this bug by accident > https://svn.boost.org/trac/boost/changeset/68866 > which was only linked via the ticket mentioned below, > > The code below demonstrates that ANY wide-character string of the same > length resolves to the same UUID ! > > Thats pretty darn serious, I expected to see a much more serious mention > in the Changelog in boost 1.47.0... for UUID, there was only a mention > of a few tickets > including this one: > https://svn.boost.org/trac/boost/ticket/5145 > which only mentioned a WARNING in the description ! > "Fixed warning: use of logical && with constant operand; switch to > bitwise & or remove constant [-Wconstant-logical-operand]" > > Surely it should say something like "UUIDs for wide character strings > are totally wrong" > > Note also that the Changelog link for UUID goes to Utility, not UUID. > > > The code: > > > #include <boost/uuid/name_generator.hpp> > #include <boost/uuid/nil_generator.hpp> > #include <boost/uuid/uuid_io.hpp> > #include <iostream> > > using namespace boost::uuids; > using namespace std; > > int main() > { > { > cout << "WIDE" << endl; > const wchar_t* a = L"one long string that is something like this > and that blahh"; > const wchar_t* b = L"hello there you long long string that looks > nothing like t"; > > nil_generator nil; > name_generator na(nil()); > name_generator nb(nil()); > > uuid ua = na(a); > uuid ub = nb(b); > > cout << to_string(ua) << endl; > cout << to_string(ub) << endl; > } > > { > cout << "NARROW" << endl; > const char* a = "one long string that is something like this and > that blahh"; > const char* b = "hello there you long long string that looks > nothing like t"; > > nil_generator nil; > name_generator na(nil()); > name_generator nb(nil()); > > uuid ua = na(a); > uuid ub = nb(b); > > cout << to_string(ua) << endl; > cout << to_string(ub) << endl; > } > > return 0; > } > > > > the result: > > $ g++ main.cpp && ./a.out > WIDE > 4ffa48af-9685-5089-97ac-fe6627ead94c > 4ffa48af-9685-5089-97ac-fe6627ead94c > NARROW > 73030b72-a864-5c7b-9963-c0bedff1283e > da8943a6-26c9-5641-bd37-427b1b70d619 > $ > > > The two different wchar_t strings resolve to the same uuid !!! > > What am I doing wrong? > > thanks > Paul -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

[serialization] overloading load_construct_data: no accessible constructor at all
by Griffin Howlett 13 Aug '11

13 Aug '11

Hey, so I'm using the boost::serialization library, and I'm trying to override how a class is constructed, since it has no default constructor. This is demonstrated here<http://www.boost.org/doc/libs/1_47_0/libs/serialization/doc/serialization.h…>. To me it appears the function ONLY takes the `class* t` and then sets it to point to a newly constructed object. If I'm wrong, this is definitely the source of my error. However, the only way to construct my class is by using another classes `create()` function, meaning I need to stray from the code in the example (this is stated in the boost::serialization namespace): `::new(t)my_class(attribute);` I tried simply calling the create function and setting `t` equal to the returned pointer, but this doesn't seem to work because right after the `load_construct_data function`, and in the `serialization function`, the given `myClass&` is not the same as what I set 't' to. *How do I do whatever ::new(t) is doing so the object created using the create function follows through into the serialize/other functions?* [1]: http://www.boost.org/doc/libs/1_47_0/libs/serialization/doc/serialization.h…

2 1

[thread] basic mutex problem
by Greg Rubino 13 Aug '11

13 Aug '11

Hi Boost.Thread maintainer(s)/expert(s)/user(s) like me, I'm having an issue with boost::mutex. I'm not really an expert in concurrency, and there's something wrong with my thread_db library, so I'm having some trouble debugging (for now). I tend to think it's something in my code, but I thought maybe someone on the list would take a look at it. The code is pretty minimal, but let me know if I should reduce it further. I'm leaving out the #includes, because I'm pretty sure those are ok: using namespace std; using namespace boost::phoenix; namespace phoenix_args = boost::phoenix::arg_names; namespace posix_time = boost::posix_time; boost::mutex g_mutex; struct random_activity_planner { random_activity_planner(vector<activity>& a, posix_time::ptime o) : activities(a) , origin(o) {} void operator()() { g_mutex.lock(); posix_time::ptime start(origin + posix_time::seconds(rand() % 1000)); posix_time::ptime end(start + posix_time::seconds(rand() % 1000)); activities.push_back(activity(start, end)); g_mutex.unlock(); } vector<activity>& activities; const posix_time::ptime& origin; }; int main(int argc, char** argv) { if(argc != 2) return 1; size_t activity_count = boost::lexical_cast<size_t>(argv[1]); vector<activity> activities; boost::thread_group random_activity_planners; posix_time::ptime origin(posix_time::second_clock::universal_time()); srand(time(NULL)); for(size_t i = 0; i < activity_count; ++i) { random_activity_planners.create_thread(random_activity_planner(activities, origin)); } random_activity_planners.join_all(); cout << "all activities: " << endl; for_each(activities.begin() , activities.end() , cout << phoenix_args::_1 << endl); vector<activity> schedule; greedy_activity_selector(activities.begin() , activities.end() , back_inserter(schedule)); cout << "scheduled activities: " << endl; for_each(schedule.begin() , schedule.end() , cout << phoenix_args::_1 << endl); return 0; } [END] The problem is that the last "activity" is not being pushed onto the shared vector in the . I'm sure there are some stylistic problems with the code, but its purpose is just to demonstrate an algorithm. At the following for_each() call: for_each(activities.begin() , activities.end() , cout << phoenix_args::_1 << endl); I find out, via a gregorian::bad_year exception, that the final activity has not been initialized. I have omitted the definition for activity, but it's pretty simple. It has only one member (a posix_time::duration that defaults to neg_infin => pos_infin ), which is why I suspect that the final call to random_activity_selector::operator() is not completing before the for_each() call that succeeds it in the source. I thought that join_all() would prevent this from happening. Is there something wrong with my code? I left some stuff out, because I didn't want to inundate the reader with irrelevant details, so please let me know if I left out anything crucial. Also, I am aware that I don't need to be using threads here, but I am, and I don't understand why it's not working. Thanks! Greg

4 6

enable_if and non-template member functions?
by John Maddock 13 Aug '11

13 Aug '11

Folks, I have a problem with enable_if: it works just dandy for template member functions in my class, but I have some *non-template* member functions and constructors that I want to enable only if the template is instantiated with template args that meet certain criteria. Seems like I can't do this with enable_if as it then generates an invalid class definition. I guess I could use base classes, and/or partial specialization, but both involve a lot of code duplication I'd rather not have. Anyone any ideas? Thanks, John.

11 21

[review] a mini-review of containers
by Thorsten Ottosen 12 Aug '11

12 Aug '11

Hi Ion & John, I apologize for not having time to do a full review. I base these comments mainly on the documentation. I have been using the flat_map/flat_set stuff for years, both in my own PhD work and in production code in my company. A. I find the motivation sufficient; I guess the new allocator concept in C++11 would allow one to use interprocess allocators, but as this won't work with older compiler, I can see the need. Also, since the standard does not e.g. guarantee nothrow of default constructors, this library provides an escape route if one wishes to have portable code. The recursive structure is also a nice feature. B. The new containers are very useful. I have not used stable vector before, but I note that boost::ptr_vector provides similar guarantees. C. slist should probably be called forward_list like in the new standard, and should probably be interface compatible with the standard design. D. I skimmed some of the unit-tests. I saw that some sections are commented out. Maybe a little more testing could be done. E. I didn't look at the map/set implementation; do you use the same optimization as Boost.MultiIndex that saves the color in the parent pointer (as a bit). F. I noticed that you use std::reverse_iterator. Why not use boost::reverse_iterator? IIRC, it has some minor benefits. G. flat_xxx. (a) We already discussed the issue of exposing the underlyng container. I think that would be most natural, and provides use with an escape hatch when they need it. (b) I think all these containers should allow one to decide the wrapped sequence. I have several types of sequences I would like to be able to use. Sure it takes some work to handle alocators and such, but it makes these much more useful IMO. (c) At some point, long time ago, I suggested that one should be able to construct a set/map with an already sorted sequence. This was based on actual use cases; one sometimes have access to an already sorted sequence. I think the most elegant way to support this would be to make a new constructor that forwards; that is, use the same approach as boost::optional such that we can say flat_xxx cont( boost::in_place(...) ); ------------------------------------- So, should this library be accepted into Boost? Yes. But I would like to see G.b and G.c addressed first. kind regards Thorsten

2 1

[iostreams] null_sink slower than array_sink
by Daniel Larimer 12 Aug '11

12 Aug '11

I was thinking about using boost::iostreams in place of my own 'array stream', but was surprised by the poor performance. When doing RPC calls, I often use the following pattern: a) calculate buffer space required to serialize arguments b) allocate buffer space c) serialize into buffer I use a stream type with an interface of write(),read(), putc(), getc() etc similar to iostreams. In doing some basic tests serializing a struct I get the following numbers: stringstream: 2.4e6 times/sec stream<array_sink>: 3.2e6 times/sec stream<null_sink>: 1.5e6 times/sec mystream<char*>: 8.7e6 times/sec (fixed size array) mystream<size_t>: 1.07e7 times/sec (similar to null_sink, but tracks bytes written) Perhaps this is the difference between polymorphic and static method calls? In any case, there is no reason for stream<null_sink> to take twice as long as array_sink as there are no memory copies, all write should be no-ops. It would probably be useful to add a size_sink that can be used to track the number of bytes written and thus avoid dynamically resizing buffers.

1 0

[iostreams] basic_buffer int usage
by Judson Weissert 12 Aug '11

12 Aug '11

Hello, I was working with some boost::iostreams code for compressing and uncompressing streams of data when I encountered an interesting type conversion warning. Within buffer.hpp in the iostreams library (boost/iostreams/detail folder), the constructors accept an int buffer_size and assign it to std::streamsize size_. Upon further investigation, I learned that this was intentional as of r27330 (Log msg: "made all buffer size params ints so that int literals can be used without interfering with overload resolution"). Here is some example code that triggers the same warnings I was receiving: // Tested with boost 1.46.1 // Compiler Microsoft VC2010 SP1. // Compiled with cl /EHsc /W3 repro.cpp #include <boost/iostreams/copy.hpp> #include <boost/iostreams/device/array.hpp> #include <boost/iostreams/filtering_streambuf.hpp> int main (int, char *[]) { static const char b[] = { 'A', 'B', 'C' }; boost::iostreams::array_source as (b, 3); boost::iostreams::filtering_streambuf <boost::iostreams::input> in; in.push (as); // This line generates a 'std::streamsize' to 'int' warning. // See also boost/iostreams/detail/buffer.hpp boost::iostreams::copy (in, std::cout); return 0; } I am not completely sure what overload resolution is taking place, I only see a default constructor and a constructor that takes a buffer size. What am I missing? I posted approximately a week ago on this topic, but I don't think it made it to the list. Forgive me if this is a repost, I modified the content of the message since I learned more about the subject in the meantime. Thanks, Judson Weissert

2 1

[numeric] Adding numeric_cast_traits.hpp on 08/11 (today) breaks trunk
by Edward Diener 12 Aug '11

12 Aug '11

The addition and integration of numeric_cast_traits.hpp to boost numeric is breaking compiles on the trunk which use numeric. I am attempting to compile quickbook, only to see: gcc.compile.c++ ..\..\bin.v2\tools\quickbook\src\gcc-mingw-4.6.0\release\link-st atic\quickbook.o gcc.compile.c++ ..\..\bin.v2\tools\quickbook\src\gcc-mingw-4.6.0\release\link-st atic\actions.o In file included from ..\../boost/numeric/conversion/numeric_cast_traits.hpp:28: 0, from ..\../boost/numeric/conversion/cast.hpp:34, from ..\../boost/lexical_cast.hpp:40, from src\actions.cpp:19: ..\../boost/numeric/conversion/detail/numeric_cast_traits.hpp:77:31: error: miss ing binary operator before token "(" ..\../boost/numeric/conversion/detail/numeric_cast_traits.hpp:82:31: error: miss ing binary operator before token "(" etc. The same errors occur with msvc-10.0. These changes need to be fixed or reverted. Too many things depend on numeric_cast for this to remain broken.

4 8