- Boost - lists.boost.org

More boostcon videos
by Marshall Clow 30 Jun '11

30 Jun '11

Bartoz (Tuesday): http://blip.tv/boostcon/haskell-the-pseudocode-language-for-c-template-meta… Tony (Wednesday): http://blip.tv/boostcon/lockfree-programming-part-2-data-structures-5258064 Cliff (Wednesday); http://blip.tv/boostcon/design-journeys-with-skoot-a-peer-oriented-generic-… I'm hoping to get about half of the videos up before I go on holidays next week. -- Marshall -- 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

5 5

[phoenix] Implementing phoenix::make_shared<T>(...)
by Pyry Jahkola 30 Jun '11

30 Jun '11

Hi, Thomas and other Boosters! I promised on #boost yesterday to try implementing make_shared<T>(...) for Boost.Phoenix. Well, I got the first version working, it was mostly a find-and-replace task to the existing phoenix::new_<T>(...) implementation. I put the modifications to the current Phoenix trunk version here: https://github.com/pyrtsa/boost-svn/commit/b37cb155ff157199a88e59e44f1d8ede… First, the questions, then some remarks and ideas for improvement: 1) If I've understood correctly, you and Hartmut used Wave to generate the preprocessed headers. What command did you use for them? (Currently, I just added a false condition to the preprocessor #if's to fallback to the Boost.Preprocessor iteration.) 2) Where would you put the new make_shared stuff? The first implementation resides below boost/phoenix/object, but I think we should use another directory for all the smart pointer stuff - especially if we're trying to support all of (boost|std::tr1|std)! How about the following pattern? boost/phoenix/smart_ptr/... for all Boost.SmartPtr support stuff boost/phoenix/tr1/... for TR1 support (alternatively, boost/phoenix/std/tr1) boost/phoenix/std/... for C++0x (with #ifdef guards checking against std version) 3) To my pleasant surprise, I didn't need any hacks to create a functor of type function<shared_ptr<Parent>()> using a Phoenix construct like phx::make_shared<Child>(args), where Child inherits Parent. You'll find a working example in https://gist.github.com/1051564. Nevertheless, I think there's also a need for implementing the Phoenix versions of static_pointer_cast etc. 4) Another feature worth implementing might be phoenix::make_unique<T>(...). 5) We also discussed about an API that allows you to make "deep" copies of pointed objects in Phoenix. I think it might already work using something like phoenix::make_shared<T>(ref(x)) if x is of type T, or phoenix::make_shared<T>(*ref(p)) if p points to T. 6) When we get this far, I'll promise help in the documentation effort too. ;-) -- Pyry Jahkola (pyrtsa @ IRC, Twitter, etc.) pyry.jahkola(a)iki.fi +358 40 7529128

3 2

[1.47.0] Beta 1 Release candidate files available
by Beman Dawes 29 Jun '11

29 Jun '11

Release candidate files for 1.47.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --The release managers PS: I've downloaded and built the Windows 7z file. No problems.

19 34

[1.47.0] permission to merge lexical_cast tests failure markup
by Antony Polukhin 29 Jun '11

29 Jun '11

You can see the changes at https://svn.boost.org/trac/boost/changeset/72798 It adds markup for new versions of some compilers, that continue to fail very strict test. Best regards, Antony Polukhin

2 1

[1.47.0] permission to merge phoenix bugfix
by Thomas Heller 29 Jun '11

29 Jun '11

Hi, I just managed to get my hands on this bug report: https://svn.boost.org/trac/boost/ticket/5626 The bug pointed out a sever failure in the phoenix return type calculation meta programs. The changeset fixing this problem is: http://svn.boost.org/trac/boost/changeset/72794 Please don't be intimidated by the huge number of changed lines. Most of them are due to a regenaration of the (partially) preprocessed header files. The risk of this fix should be relatively low. It just fixes a problem introduced by emulating perfect forwarding which wasn't addressed before. Hope it is not too late for the fix. Thanks, Thomas

2 2

Question about useful libraries
by Denis Shevchenko 29 Jun '11

29 Jun '11

Hello all! I want to ask an important question to the leading developers of Boost. The fact that many programmers write to mailing list of Boost developers about their libraries. And they raised the questions about interest in their libraries and about inclusion their libraries in Boost. But very often proposed library (or library with similar functionality) already exists in Boost, or nobody is interested in a such library. Could you write about the subject areas and technical directions for libraries which would be *REALLY* useful in Boost today? Thanks. - Denis

8 11

Request for Feedback on the Singularity Design Pattern
by Ben Robinson 29 Jun '11

29 Jun '11

The Singularity Design Pattern seeks to address the three weaknesses of the Singleton Design Pattern. Namely: 1) Lifetime: Singleton introduces lifetime management complexities (for a detailed discussion, see Chapter 6 of Modern C++ Design by Andrei * Alexandrescu*). 2) Initialization: Singleton restricts the class to the default constructor. This makes Singleton unusable for classes which require non-default constructors. 3) Encapsulation: Singleton provides global access to the class. Some may view this as a feature, but advocates of unit testing, dependency injection, and context independent objects would disagree. Singularity guarantees a single instance of a class, but does not suffer from 1-3 above. Usage is as follows: // Usage as a Factory: typedef singularity<Horizon, single_threaded> HorizonSingularityType; Horizon & horizonF = HorizonSingularityType::create(value, &event, event); HorizonSingularityType::destroy(); // Usage as a Base Class: class Horizon : public singularity<Horizon, multi_threaded, global_access> Horizon & horizonB = Horizon::create(value, &event, event); Horizon & horizonC = Horizon::get(); Horizon::destroy(); The usage example above shows the three advantages of Singularity over Singleton: 1) Singularity does not permit lazy initialization by design. The lifetime of the single object is bounded by create() and destroy(), and this lifetime is managed just like objects bounded by new() and delete(). 2) Singularities of objects can be created using any available constructor for that object. 3) Singularity prevents global access to the instance by default. However, if this is required, or will help to transition from Singleton, a policy can be supplied which enables a get() accessor to the instance. It is also worth pointing out that thread safety is policy based, and both a single_threaded, and multi_threaded policy are provided. The source files are available here: http://www.mediafire.com/?d8kn5fx2n5d22 I look forward to your feedback. Thank you, Ben Robinson, Ph.D.

3 6

[GSoC] Request for Feedback on Boost.Bloom Filter Project
by Alejandro Cabrera 29 Jun '11

29 Jun '11

Hello all, I'm writing to request feedback, suggestions, and advice from the Boost community. I've been working on a Bloom filter data structure for about a month and a half now. At this point, the following is complete and available in the Boost Sandbox: - working, basic prototype (insert & query operations, union & intersect) - a test suite covering the public interface - five examples - documentation covering many aspects of the project (tested on Chrome 12 and 13, Firefox 4 and 6) Before I proceed to the next phase, I need feedback. Specifically, I need comments on: - code quality: is there anything that stands out about my design, naming convention, or implementation that could use improvement? - documentation quality: was it informative, clear, and easy to understand? Is there anything missing? At this point, there are many directions the Bloom filter project can go, and I need to know which direction would best serve the interests of the community. For this, I would be very interested in hearing about: - desired usage: do you have a project that could use a Bloom filter? What kind of Bloom filter would you need? - compression policy: would you be interested Bloom filters that could be serialized to a compressed form and deserialized back into a decompressed form? - variants: there are a few planned variants listed in the design page of the documentation (future directions). Do any of these seem particularly useful to you? To access the source, visit the sandbox here: http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/ To access the documentation, visit the sandbox here: http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/libs/bloom_filter… All portions of the project assume the canonical Boost release model. Namely: $(BOOST_ROOT)/boost/bloom_filter $(BOOST_ROOT)/libs/bloom_filter Thanks! -Alejandro Cabrera

7 16

Re: [boost] [GSoC] Request for Feedback on Boost.Bloom Filter Project
by Alejandro Cabrera 29 Jun '11

29 Jun '11

Jakub, > Having bloom_filter in boost:: is great idea! It is super useful, we use in > production code (our own implementation (actually we use Bloomier filters > with murmur hash perfect hashing from your wiki reference). > It lets us use very memory and lookup efficient data structure for very > large datasets (think 100 GB file with strings on SSD disk indexed by e.g. > 200 MB Bloomier filter in memory) I've read about Bloomier filters, though those seem a ways off still. I'm building from the most basic to the more complex variants, in general. Your statistics sound amazing, to say the least! Working with very large data isn't something I've had the opportunity to do just yet, though I'm interested and aware of such scenarios, as my research area is in operating systems and storage issues. > Did you considered adding serialization of a bloom_filter to your > implementation? I haven't considered it at length, but there must be a way to encode the type of the Bloom filter uniquely prior to writing out its bits, so that when deserialization time comes, a user wouldn't accidentally instantiate a Bloom filter of the wrong type. The idea I have in mind at the moment is to first serialize the template parameters of the Bloom filter (Type, Size, HashFunctions). The Type and the HashFunctions appear to be the trickiest, since their structure can take on as many possibilities as the type system allows. Writing out the bits should be the easiest part. If you have any ideas in this regard, I'd appreciate it if you shared them. > In general reconstructing hash based containers with series of inserts is > pretty inefficient. I can imagine this to be the case, especially if the containers are storing a very large number of elements. > Use case that I'm talking about: e.g. for you web proxy scenario proxy > service keeps running and downloading, caching URLs and adding them to bloom > filter. Than the process needs to be restarted for some reason. All > documents downloaded and stored on disk will have to be reitereted and their > URLs reinserted to newly created bloom_filter, which makes the startup of > the process slow. > btw I have the same problem with standard containers (except std::vector). > There is no efficient serialization / deserialization for them rendering > them useless for any larger side project (like unordered_set of 1m strings). > > There was a Boost Serialization library in the works. It seems that the last time it was maintained was 7 years ago. I'm not sure what generic, type-safe [de]serialization would look like - it sounds like a project all on its own! I agree that the C++ standard would benefit greatly from a means to [de]serialize data structures, much like Python has the pickle module. Thank you for your feedback, Jakub. -Alej

2 5

[1.47.0] permission to merge filesystem unmerged changesets
by Beman Dawes 28 Jun '11

28 Jun '11

These change sets from the end of May were never merged to release. They include bug fixes, and have been stable in trunk. https://svn.boost.org/trac/boost/changeset/72309 https://svn.boost.org/trac/boost/changeset/72306 https://svn.boost.org/trac/boost/changeset/72278 My apologies for not catching this earlier. OK to merge? --Beman

2 3