- Boost - lists.preview.boost.org

How to use BCP
by William Voorhees 17 Aug '11

17 Aug '11

I'm updating a small C program to take in a options from either environment variables, or a config file and having long heard of boost as a great resource decided to give the program_options module a try. Since the utility is small and I don't have any current plans for other boost functionality it doesn't make sense to include the full BOOST library, so I tried to use bcp to get only the files I'm interested in. I was able to get a subset of boost code that I should be able to use with bcp, however I don't know how to compile the program_options library for linking in my code. >From a bit of googling it looks like bjam is the build tool, but it doesn't seem to be included with the subset of files I have. How would I go about incorporating boost so that all of the necessary source and associated utilities are included for an end user to build from. I should be able to issue a series of simple commands (looks like ./bootstrap.sh and make) to build and install my library with statically linked in boost. -Will Voorhees

3 5

Re: [boost] [Containers Library Review] The review of the Containers library by Ion Gaztanaga starts today
by Ion Gaztañaga 17 Aug '11

17 Aug '11

El 17/08/2011 12:20, Diederick C. Niehorster escribió: > Some performance tests might be nice here too (and the code for > generating them should be incorporated in the distribution), comparing > to std:: libraries shipped with the popular compilers. It'll help sell > your library and it'll serve as a nice benchmark later as vendors > update their standard library implementations. At least, I'd be > interested in such information and if test code is avaiable, I could > easily run the testcases myself. This is a good idea, but it'd require a huge amount of work if we think about an extensive benchamark framework. Maybe some basic tests?

1 0

[Containers Library Review] The review of the Containers library by Ion Gaztanaga starts today
by John Maddock 17 Aug '11

17 Aug '11

The review of the containers library by Ion Gaztanaga starts today, to summarize the library: "Boost.Container library implements several well-known containers, including STL containers. The aim of the library is to offers advanced features not present in standard containers or to offer the latest standard draft features for compilers that comply with C++03. In short, what does Boost.Container offer? * Move semantics are implemented, including move emulation for pre-C++0x compilers. * New advanced features (e.g. placement insertion, recursive containers) are present. * Containers support stateful allocators and are compatible with Boost.Interprocess (they can be safely placed in shared memory). * The library offers new useful containers: o flat_map, flat_set, flat_multiset and flat_multiset: drop-in replacements for standard associative containers but more memory friendly and with faster searches. o stable_vector: a std::list and std::vector hybrid with random-access iterators that offers iterator stability in insertions and erasures. o slist: the classic pre-standard singly linked list container." Documentation from the library may be viewed online here: file:///M:/data/boost/sandbox/move/libs/container/doc/html/index.html The source may be accessed from the "move" directory of the sandbox SVN or downloaded from http://www.drivehq.com/web/igaztanaga/boost_container.zip. Note that this download contains a copy of the accepted, but not yet release, Boost.Move library - extract the zip over a copy of Boost-1.47 to get a full working copy. Review comments might like to answer the following questions: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Regards, John Maddock.

10 18

Re: [boost] [containers review] A reminder that the containers review ends tomorrow
by John Maddock 17 Aug '11

17 Aug '11

The containers library review is now officially over. However, there are still a few drips a drabs of reviews coming in.... are there any more still pending? Thanks, John.

3 2

Re: [boost] [gsoc] Request Feedback for Boost.Ustr Unicode String Adapter
by Stewart, Robert 16 Aug '11

16 Aug '11

Yakov Galka wrote: > On Fri, Aug 12, 2011 at 15:04, Matus Chochlik > <chochlik(a)gmail.com> wrote: > > On Fri, Aug 12, 2011 at 1:08 PM, Yakov Galka > > <ybungalobill(a)gmail.com> rote: > > > On Fri, Aug 12, 2011 at 12:00, Matus Chochlik > > > <chochlik(a)gmail.com> wrote: > > >> On Fri, Aug 12, 2011 at 9:57 AM, Daniel James > > >> <dnljms(a)gmail.com> wrote: > > >> > On 11 August 2011 12:57, Artyom Beilis > > >> > <artyomtnk(a)yahoo.com> wrote: > > > >> // by default expect UTF8 > > >> text(const std::string& str) > > >> { > > >> assert(is_utf8(str.begin(), str.end())); > > >> store(str); > > >> } > > > > > > What you are doing is, in fact, forcing the assumed > > > encoding of std::string to UTF-8. You just said you > > > think it's a bad idea. > > > > No, I'm proposing to implement a *new* class that > > will store the text in UTF8 encoding and if during > > the construction no encoding is specified, then it > > is assumed that the particular std::string is already > > in UTF8. > > > This is *very* different from imposing > > an encoding on std::string which is already > > used in many situations with other encodings. > > i.e. my approach does not break any existing code. > > Sorry, your arguments start to look non-constructive to me. > Correct me where I'm wrong in the following reasoning. > > (1) You object to UTF-8 strings in boost interface because > someone may pass something other than UTF-8 there and it's > going to be undetected at compile time: > > namespace boost { void func(const std::string& a); } // UTF-8 > boost::func(non_utf_string); //oops > > You're proposing a `text` class that is meant to somehow > overcome this problem. So you change the boost interface > to accept `text` but user code is left unchanged...: > > namespace boost { void func(const text& a); } > boost::func(non_utf_string); //oops, the std::string default > constructor is called. > > Yes, you can make this constructor explicit, so the above code > stops compiling and the user must write explicitly: > boost::func(text(non_utf_string)); > > But then there is nothing in your proposal that makes > std::string utf-8 encoded by 'default'. Default == implicit. As soon as the client did a cast, the client made the claim that non_utf_string met the requirements of the text class' constructor. The problem is that of the client misusing the class by an ill-advised cast. What's more, I think Soares indicated a debug-build validation that the argument indeed was UTF-8. I don't see a problem in that design, once the constructor is explicit. > > Besided it does not harm you in any way > > It does. I already use UTF-8 for all my strings, even on > windows, and I don't want the code-bloat of all these > conversions (even if they're no-ops). What code bloat do you get from NOPs? Sure, there is more compilation time for the compiler to parse the text code and then for the optimizer to streamline it into a NOP, but even that is very likely negligible. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

3 2

[Review] Lockfree review: today (July 28th) is the last day
by Hartmut Kaiser 16 Aug '11

16 Aug '11

All, Today is the last day of the review of Tim Blechmann's Lockfree library. If you're interested in this library, please consider contributing a review! If you need more time, please contact me privately. Please see the original (slightly corrected) announcement below: ----------------------------------------------------- About the library: Boost.Lockfree provides implementations of lock-free data structures. Lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. Lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. The following data structures are provided: - boost::lockfree::fifo, a lock-free fifo queue - boost::lockfree::stack, a lock-free stack - boost::lockfree::ringbuffer, a wait-free single-producer/single-consumer ringbuffer. The library is accessible from here: http://tim.klingt.org/boost_lockfree.tar.gz. Boost.Lockfree depends on C++0x atomics. They are not well supported with current compilers yet. For this reason Boost.Lockfree depends on the *unreviewed* Boost.Atomic library, that emulates C++0x atomics for C++98. This review is about Boost.Lockfree and not about Boost.Atomic, although it is included in the tarball and the git repository. If Boost.Lockfree will be accepted, it won't be merged into trunk before Boost.Atomic is accepted. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

6 7

Re: [boost] [gsoc] Request Feedback for Boost.Ustr Unicode String
by Joe Mucchiello 16 Aug '11

16 Aug '11

>> text t6(pq_some_func(), textenc::libpq()); >> > You don't need it. You're proposing a design that tries to solve a > non-existing problem. There is no such diversity of encodings in the > interfaces. I don't know what is libpq, but it either uses UTF-8 in which > case you write: > > string t6 = pq_some_func(); > I think the point here that you don't need to know the encoding of libpq. If the policy is that you use this text class and that to use it you convert it using the standard text constructor that takes the listed tag. For libraries that use UTF-8 the conversion is a no-op. Adapting a new library to the "boost way" just involves adding a new tag to the textenc namespace and, if necessary, writing a new pair conversion routines.

2 1

[1.44][serialization] Link error with polymorphic archives and BOOST_CLASS_EXPORT
by Ralph Tandetzky 15 Aug '11

15 Aug '11

Hi, I discovered a problem, that has been previously discussed in a post from 2011-01-21 which has the same title. No concluding answer was given there, so I post the problem again. Essentially, the following code compiles but doesn't link: -------------------------- #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; } -------------------------- Removing the line with "BOOST_CLASS_EXPORT(A)" or turning the "polymorphic_binary_oarchive" into a "binary_oarchive" removes the linker error. With Visual Studio 10 the following error message occurs: main.obj : error LNK2001: unresolved external symbol "public: static void __cdecl boost::archive::detail::archive_serializer_map<class boost::archive::detail::polymorphic_oarchive_route<class boost::archive::binary_oarchive_impl<class boost::archive::binary_oarchive,char,struct std::char_traits<char> > > >::erase(class boost::archive::detail::basic_serializer const *)" (?erase@?$archive_serializer_map@V?$polymorphic_oarchive_route@V?$binary_oarchive_impl@Vbinary_oarchive@archive@boost@@DU?$char_traits@D@std@@@archive@boost@@@detail@archive@boost@@@detail@archive@boost@@SAXPBVbasic_serializer@234@@Z) 1>main.obj : error LNK2001: unresolved external symbol "public: static bool __cdecl boost::archive::detail::archive_serializer_map<class boost::archive::detail::polymorphic_oarchive_route<class boost::archive::binary_oarchive_impl<class boost::archive::binary_oarchive,char,struct std::char_traits<char> > > >::insert(class boost::archive::detail::basic_serializer const *)" (?insert@?$archive_serializer_map@V?$polymorphic_oarchive_route@V?$binary_oarchive_impl@Vbinary_oarchive@archive@boost@@DU?$char_traits@D@std@@@archive@boost@@@detail@archive@boost@@@detail@archive@boost@@SA_NPBVbasic_serializer@234@@Z) Is there something wrong with the serialization library? Regards, Ralph Tandetzky.

2 2

Review Request: Singularity
by Ben Robinson 15 Aug '11

15 Aug '11

Hello, I would like to thank the Boost community for their invaluable feedback regarding the features and implementation details of Singularity. Singularity has been greatly refined and I am now requesting a formal review. I have compiled and run Singularity on 4 different compilers: GCC 4.5, MSVC++ 2010, the CL2000 TI compiler targeting the 2803x processor, and the Green Hills compiler targeting the Cortex-A8 ARM processor. The documentation, implementation and Boost unittests are available on GitHub at https://github.com/icaretaker/Singularity. Please note, that I have also implemented Singularity in C++11 using perfect function forwarding in the /cpp11 subdirectory, but that is not part of the submission, unless Boost is accepting C++11 libraries at this time. I will now include an excerpt of the documentation file "singularity.htm" which is part of the GitHub download: Introduction<file:///C:/home/ben/workspace_boost/boost/source/common/libs/singularity/singularity.htm#singularity.introduction> The Singularity Design Pattern allows you to restrict any class to a single instance. Singularity gives you direct control over the lifetime of the object, and does not require you to grant global access to the object, nor limit you to a single constructor for that object. Motivation<file:///C:/home/ben/workspace_boost/boost/source/common/libs/singularity/singularity.htm#singularity.motivation> The ability to restrict a class to a single instance is an important technique. While the commonly used Singleton Design Pattern achieves the desired goal, it introduces three undesirable limitations, namely: 1. Lifetime: Singleton introduces lifetime management complexities. The undefined destruction order of multiple singletons is just one example. 2. Scope: Singletons are always globally accessible. Accessibility should be orthogonal to restrictions on the number of instances. 3. Initialization: Singletons typically restricts the class to the default constructor. This makes Singleton difficult for classes which require non-default constructors. Like Singleton, Singularity restricts a class to a single instance. However Singularity does not suffer from lifetime, scoping and initialization problems. The following are the advantages of Singularity over Singleton: 1. The lifetime of the single object is bounded by calls to create() and destroy(). This lifetime is managed similiarly to objects bounded by calls to new() and delete(). 2. Singularity does not force global access to the instance. If global access is required, then a globally accessible get_global() function can be enabled upon creation of the instance. 3. Singularities of objects can be created using any available constructor for that object. Thank you, Ben Robinson, Ph.D.

2 1

Re: [boost] [containers review] A reminder that the containers review ends tomorrow
by John Maddock 14 Aug '11

14 Aug '11

> Just a quick reminder that the containers lib review ends tomorrow - there > have been lots of good comments, but not so many reviews - so now's your > chance ;-) If there are any reviews pending that are likely to be late > please let me know so we can extend the review period. This review was sent to me privately, posted here for comment: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Review of Boost.Contianer by Zoltán Tóth I am not an expert of C++ containers topic, but use them daily in my algorithm programming job. C++ 1998 STL containers have serious deficiencies, I would say especially node-based STL containers are not usable at all for performance-critical algorithms due to their memory allocator treatment/requirements. I have written own implementations for STL vector, set, list, ., because I was not satisfied with STL containers. Therefore a replacement of those in Boost could be a terribly useful library. I did not try to use the library. I just quickly read the documentation, and found that it is very poor. Here are the deficiencies I have found in the documentation: 1. One of the most important reason to replace the STL containers is the treatment of custom memory allocators. However the documentation tells only a single sentence about it: "Containers support stateful allocators and are compatible with Boost.Interprocess (they can be safely placed in shared memory). " 1. It does not specify how the containers are swapped: are the allocators swapped with the container? 2. Most STL implementations have been supporting stateful allocators for years now. So it is not big news. However I am not satisfied with the way they might do it. For example Visual Studio's STL implementation require the allocator type to have a template copy constructor. Such allocator types are difficult to be implemented in efficient, threads-friendly way. (This is the reason I have implemented my own set implementation instead of STL::set) The documentation does not tell whether this library have a similar requirement. If no, that would be big news. 2. The documentation says: "All containers offered by Boost.Container can be used in recursive data structures, something that is not guaranteed by the standard". To understand the value of this feature better I as a user would like to know more about this topic. Please insert links or own text here that explain why does the standard not guarantee this. Is there any danger or difficulty in it? If yes: how does this library overcome them. IMHO Boost.Containers should not (yet) be accepted (because of the lack of a detailed documentation).

3 2

[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

[fusion] pop_back doesn't work on fwd sequences
by Eric Niebler 12 Aug '11

12 Aug '11

The documented requirement of pop_back are wrong. The docs say that pop_back works on Forward Sequences, however the following does not compile: // ERROR fusion::list<int, int> l(1, 2); fusion::pop_back(l); The problem is that the implementation of pop_back uses prior, which only works on Bidirectional Sequences. That's merely a doc problem, but this is a more serious problem: // ERROR fusion::pop_back(fusion::pop_back( fusion::push_back(fusion::push_back(fusion::nil(), 1), 2))); A sequence created by push_back is a Forward Sequence, which means you can't call pop_back on it. I think that's a serious shortcoming. Fusion needs something like MPL's Back Extensible and Front Extensible concepts. http://www.boost.org/doc/libs/1_47_0/libs/mpl/doc/refmanual/back-extensible… Unfortunately, this would likely require a redesign of the whole (push|pop)_(front|back) mechanism. -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 21

[Containers] Review
by Phil Endecott 12 Aug '11

12 Aug '11

Dear All, Following are some comments about Ion's proposed Boost.Containers. I have not really reviewed the code, but frankly that doesn't seem necessary: Ion knows what he's doing, much of this code has already been in Boost for a while as part of Interprocess, and much of it is designed to implement standard interfaces. I'll confine my comments to a few words about the documentation, and some observations about the "flat" containers. Regarding the documentation, I believe that it would benefit from: - The "Acknowledgements" page is currently empty. There are various (c) notices in the source referring to sources from which parts of the code may have come. This page should clarify these sources, including any cases where the original code has now all been replaced, and assert that the licenses are all in order. It should also point out the history of the code in Boost, i.e. that parts were previously in Boost.Interprocess, so that anyone with previous exposure to the Interprocess containers is not confused. - A few lines of rationale for stateful allocators would be useful, i.e. pointing out that although the std::allocator has a typedef for pointer the containers can assume it is T*, and the implications of that. (I dealt with all this back in about 2004, and it took me a long time to get up-to-speed with the issues.) - Similarly, some rationale for string (and pointing out how it differs from std::string in the common implementations) would be useful. (Now, I can't even find where it says that it is non-COW. I know that I've seen that written somewhere. A page specifically about string shown on the top-level table of contents would be appropriate.) - The Doxygen reference docs seem to jump to the header docs from the table of contents; I think it would be more useful to jump primarily to the classes. Is this the same issue that I saw in the last review? Regarding the "flat" containers, I've previously posted about this in a couple of threads on this list. I have used this sort of structure in two applications recently: - In the first case, I store read-only (key,value) data in a binary file. I have a utility that prepares this file offline by inserting into a vector<pair<>>. I then sort it, and save the contents of the vector in the file. In the program that uses the data, I memory-map the file. I then have an adaptor class that takes a pair of pointers to the begin and end of the mapped data and permits read-only access like Ion's flat_multimap<>. - In the second case, I have an insert-only key-value data structure. New data is inserted in batches. I have a vector<pair<>> and insert new data at the end; at the end of each batch, I sort the new values and merge them into the body of the vector using std::inplace_merge. Neither of these cases can be implemented efficiently using the current containers. Doing so would need: - Access to the underlying container, at least for reading. - An "adaptor" version that could wrap a pair of pointers to raw memory, or more generally a pair of iterators, at least for reading. - Some sort of efficient batched insert mode. Regarding the batched insert, we have previously discussed the complexity of inserting a range. Fundamentally, however, I don't think it is acceptable to have efficient insertion ONLY in the case of the insert(begin,end) method: it is too common to want to insert several values in a loop without creating a temporary container. I'm not aware of any established (i.e. std:: or boost::) pattern for doing this: class flat_container { void insert(val); // appends at the end of the vector void commit(); // merges new values into the body of the vector }; - Between calling insert() and calling sort(), what do lookups do? Undefined? Only look at old values? Sort-on-demand? - Is there also an "insert one" method? How are the variants named? - What about erase()? - How about a "batch" or "transaction" object?: flat_container c; { flat_container::insert_batch b(c); b.insert(data1); b.insert(data2); } // b's dtor merges new values. A further interesting case is when the new values are already sorted, because insertion can be more efficient in this case: void insert_sorted(iter first, iter last) { resize vector to make space for new items for each new item in reverse order { find the position where it should be inserted using binary chop move old items after that point forward move the new item in behind them } } I could imagine a general insert_batch and a specialised insert_sorted_batch, for example. Anyway, this is all just food for thought really. It would be interesting to hear from other people who have used data structures like this. In my own code I have taken a rather ad-hoc approach, but that is the nature of custom vs. library development: to be useful, a library needs to try to second-guess the requirements of all potential users, yet do so without becoming too complex for anyone to learn. Hopefully there will be some more discussion about some of this, but as far as the review is concerned we should allow Ion to decide what he eventually commits. Regards, Phil.

6 8

[containers] remarks and questions
by Pierre Morcello 12 Aug '11

12 Aug '11

Hello Ion, This is not a review. I took 3 hours to read the docs, checks some tests, try to check some sources, but I am still not used to read so few comments in the code. I played a little with the library then, tried to encapsulate some std::auto_ptr<X> in the new containers and things like that. Based on that very little experience, I would like to share some thoughts and ask a few questions on the proposed boost.containers library. 1/ I would really appreciate that the docs were more complete, at least for the technical part. => ex : "flat_map : more memory friendly and with faster searches" => In what way? is the algorithm complexity lesser than previous systems? or do you mean that contiguous memory is more cache-friendly? => do you provide different kernel implementations? => is there a paper on the subject? => Is there an evaluated algorithm complexity for the stable_vector? => is memory contiguous like a std::vector? can I use memcpy on several elements? These are just examples of questions that I expect to be answered by the docs. EDIT : I read proposition to embed elements of Joaquin M Lopez Munoz's blog. This is exactly that kind of informations I am looking for. => For the tree class, I can't remember any tree interface in the std. Could you point me to some informations ? Sorry If I miss something obvious. 2/ I was surprised (in a good way) to see some Andrei Alexandrescu's code in the library. Will the Loki licence be shipped now with boost? (This is not a problem for me). 3/ A few tests might be added. ex: Test the fact the vector usually are contiguous in memory. I can write this one if you are interested. 4/ The 'move aware' containers are nice to use but as a drawback We are forced to use macro to define the types using the 'move' semantics. What other container libraries can this work be related to? There are some examples of containers requiring the value_type to support only the "defaut constructor + a swap() function". This is a concept I would really appreciate to see in boost.containers. In that case, I would very happily use this library. Otherwise I think I will stick with other containers classes. 5/ "The aim of the library is to offers advanced features" Is the proposed Boost.containers also an effort towards development of new features for containers? If that is the case, then what are the plans for the future ? Is there a roadmap? To sum up : I am surprised that such a container library was not already integrated in boost. This should be a nice addition. But at the moment I don't think I would use it: my main interest would be for the value_type supporting "defaut constructor + a swap() function" to be added to the library. I also would like more detais in the documentation. In my humble opinion, it would also be easier for exterior people to learn from and to contribute to your library if there were more comments in the code. I congratulate you and the other authors for your work and efforts, and wish you the best for the review. Best regards, Pierre Morcello -- View this message in context: http://boost.2283326.n4.nabble.com/boost-containers-remarks-and-questions-t… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

[preprocessor] ifdef equivalent inside a macro, is it possible?
by damien benoist 12 Aug '11

12 Aug '11

Hi all, Would there be a way to do some "ifdef" inside a macro? Could be in the form of a macro taking 3 args, - 1st being the macro to test the existance of, - 2nd being the value to expand in case 1st arg is a defined macro - 3rd being the value to expand in case 1st arg is not a defined macro Exemple: #define DUMMY_MACRO1 foo1 // next is commented out and not defined // #define DUMMY_MACRO2 foo2 PP_IFDEF(DUMMY_MACRO1, DUMMY_MACRO1, bar1) // would expand to foo1 PP_IFDEF(DUMMY_MACRO2, DUMMY_MACRO2, bar2) // would expand to bar2 Seems impossible to me, but boost/preprocessor does so many things that seemed impossible to me. Maybe someone will have some more magic... Thanks. Damien.

4 11

[proto] RValue reference support?
by John Maddock 12 Aug '11

12 Aug '11

Does proto have any support for rvalue references in terminals? I'm thinking that if you know that you're assigning an expression involving an rvalue-reference as a terminal, then there are some optimizations that can be performed that aren't otherwise possible. Thanks, John.

5 11