- Boost - lists.preview.boost.org

[1.47.0] Regression in type_traits, is it too late to revert?
by John Maddock 26 Jun '11

26 Jun '11

There's a regression in type_traits caused by the addition of compiler-intrinsic support for Clang - this got reverted on Trunk after a flurry of discussion a while back: http://lists.boost.org/Archives/boost/2011/06/182844.php. Unfortunately it appears it never got reverted on the release branch. Can we please revert this? Thanks, John.

3 3

Interest in multi-dimensional array class templates.
by Brian Smith 25 Jun '11

25 Jun '11

The file maps.zip in the containers directory in Boost's vault contains a library with classes for the development of multi-dimensional array applications. Also included are scalar and fixed-size vector and matrix class templates with an expression template implementation of operators. The multi-dimensional array's can be fixed-size statically or dynamically allocated, or dynamically allocated and resizeable. Vectors and matrices can be statically or dynamically allocated and written in block form. The notation follows that provided by the STL and other Boost libraries. The classes lack tests using Boost's test framework and the documentation is rather sparse. The intention would be to remedy both issues if interest is sufficient to warrant it. Regards Brian

8 36

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

25 Jun '11

Hello Phil, > Hi Alejandro, > > Alejandro Cabrera wrote: >> 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) > At first glance, this looks very good. Well done. > > Bloom filters are essentially a quite simple concept, and I suggest > that you should stick to that i.e. resist any temptation to add lots of > extra features. Having said that, I think you should look at e.g. > std::set<> and std::unordered_set and see what you can do to make your > class closer to them. I can think of: > > - empty() > - clear() (Ah, you do have this, but not documented?) I accidentally skipped documenting this. Thank you for pointing this out. > - a constructor that takes a range, e.g. > int a[] = { 1,2,3,4,5 }; > bloom_filter<int> b(a,a+5); > std::list<int> l; > bloom_filter<int> c(l.begin(),l.end()); > - insert(begin,end) similarly I hadn't considered various ways to construct the Bloom filter. I assumed users would always want to start with an empty Bloom filter, but this would make using the Bloom filter more flexible. > - swap() I overlooked swap. I'll add this. > - You have a size() which is (confusingly?) different from those > containers' size(); it's more like capacity() I guess. (Similarly I > think I would rename count() to maybe bit_count().) I agree that using size() as I do is confusing, versus what size() has come to mean for standard containers. This would better be named something like bit_count(). I'll reconsider the name. > There is a trade-off between the size of the filter, the number of > values stored, the number of hash functions and the false positive > rate. You might consider adding some sort of compile-time > metafunctions to help the user determine the right size and number of > hash functions, based on their expected number of values stored and > acceptable false positive rate. Similarly, you could add a static > expected_false_positive_rate() method that takes the number of stored > values as a parameter. Given a desired false positive rate, an expected number of elements and an upper-limit on the storage requirement, it is possible to determine both a good Size value and a good number of hash functions. I see now how meta-functions can help alleviate the burden on the user for picking good values. This might take a bit of work to provide as a feature. It would involve ratios to represent the false positive rate as a template parameter to the meta-function. I'll put this feature off 'til version 1.1 or 1.2. Until that time, users will have to determine the best parameters for their application using the documentation guidelines. On that note, I think I should add a section to the tutorial detailing how to choose good parameters. > Sometimes it would be better for size to be a run-time parameter. I have a dynamic Bloom filter in the queue for variants. It's definitely required if I were to develop a scalable Bloom filter that guarantees a certain false positive rate, as detailed in a recent research paper titled "Scalable Bloom Filters". > Sometimes it would be useful to access the underlying data. For > example, say I have a spell check dictionary or a URL block-list; I > might want to compile that list into a bloom filter and ship that as a > binary file. For that I'd want to be able to use it as an adaptor on > top of an underlying container that I supply: > > // compile: > std::vector<uint32_t> data(100000); > bloom_filter b(data); // acts as a container adaptor > b.insert(...); > file f; > f.write(data.begin(),data.end()); > > // use: > memory_mapped_file f("dictionary.bloom"); > bloom_filter b(f); > if (b.contains(url)) .... I'm not sure how this would work. Could you elaborate further in this regard? Currently, as I understand, there's two components of interest. The first is to be able to access the underlying Bloom filter data for serialization/deserialization purposes. This should be easy enough to do given a function that exposes the Bloom filter data. The other component that I'm picking up on is to be able to construct a Bloom filter using various sources. Range construction will be added that semantically behaves as an insertion for each element in the range. However, I'm not sure how to support construction from a memory_mapped_file. > I think it would be sufficient for false_positive_rate() to return a > float. No-one cares about its 19th digit. I preferred greater precision to anticipate user needs. Unless false_positive_rate() were called frequently, I wouldn't expect that the added precision would incur a significant performance penalty. > For some reason I have a mental block about how intersection works. > Union is OK; I can see that > > set a; > set b; > bloom_filter(a) union bloom_filter(b) == bloom_filter( a union b ); > > but it's not clear to me if > > bloom_filter(a) intersect bloom_filter(b) == bloom_filter( a intersect > b ); > > Can you convince me? Intersect intends to leave only the bits shared between two bloom filters on. This also corresponds to the elements that both Bloom filters have inserted. The reason for this is because intersection is only allowed between Bloom filters that use the same hash function set and the same storage size. Assume that both Bloom filters are instantiated with hash functions that return the integer value of the element hashed. Then the following occurs: bloom_filter<int, 4> a; bloom_filter<int, 4> b; bloom_filter<int, 4> c; a.insert(1); a.insert(2); // 0110 b.insert(2); b.insert(3); // 0011 c = a & b; // 0010 At this point, only c.contains(2) will return true. > During the XInt review there was some discussion about whether > is_prime() should be called is_probably_prime(). The same argument > could be made here about whether your contains() should be > probably_contains(). If there were some six-letter word meaning > "probably contains" then I would support using it, but > "probably_contains" is a lot of typing. The wording for contains() is another tricky issue. probably_contains() has the benefit that it points out the probabilistic nature of the data structure. This is very helpful to warn users. I don't think the addition of 9 more characters to type (probably_) should be a problem, since it isn't the type of function that can nest on itself (x.contains(t).contains...). I will tentatively rename the function probably_contains(), and if further comments indicate that this adds some level of confusion, I'll reconsider the name again. > Regarding hash functions: I believe I have read that some care is > needed when you use essentially the same hash function but with > different seeds i.e. are the results really independent? It would be > be more obviously correct to have a set of hash functions that use > entirely different algorithms. Unfortunately this is hard. I've left the hashing component open to extension exactly because of this reasoning. The Bloom filter data structure does rely greatly on the use of good hash functions. However, the definition of "good" depends on the context. It might be that a CRC32 is perfect for some applications, but a murmurhash3 is better for others, and some applications might even require a cryptographically secure hash. Since the intent of the project is not to develop great hash functions, I'm inclined to leave the option of boost::hash_value as the default, though it might be best to default to an mpl::vector containing a single hash function instead of two, since as you stated, the results aren't independent. > Performance: it would be great to see some benchmarks for different > types against std::set and std::unordered_set. In particular it would > interesting to look at string keys of different lengths: both the bloom > filter and the unordered_set always have to look at every byte of the > string to compute the hash, while a std::set need only look at the > string's unique prefix. You mention things like web caches, and so I > guess getting some real-world benchmark data would be simple enough. > One hashing option for strings is to hash substrings. > I suspect that a benchmark on at least strings would be useful to demonstrate how the bloom_filter compares against std::set and std::unordered_set, assuming that most users will be hashing data (file names, URLs, etc.). I'll add benchmarks to my queue of things todo, but I want to make sure the interface is close to stable before I do commit to writing benchmarks. > Anyway, good work so far. > > > Regards, Phil. > Thank you for taking the time to comment so thoroughly on the Bloom filter project!

2 1

SVN Ignore for Bin dirs
by Joshua Boyce 25 Jun '11

25 Jun '11

Is it possible for somebody to add an svn:ignore for dirs like Bin, Stage, Dist, etc on the Boost trunk? Not a big deal, but I pull down Boost using svn:externals for one of my projects, then build it as part of my build script, and it's a little annoying having all the built files pop up in the commit list with no way to set them to ignore without having to do it manually on every checkout. Unless someone knows an SVN trick I can use in my project to work around this? (Though I can't see a reason using svn:ignore in Boost would be a problem...)

3 4

Assign V2 - first impression
by Christian Holmquist 25 Jun '11

25 Jun '11

Hi all, I've been using assign v1 for a long time, and I find it sometimes convenient to have at hand but I don't consider it a crucial tool. To have a v2 of the same library is to me..surprising.:) Very well, I compared the introduction of v1 and v2 to get a feeling for the difference V1: > The purpose of this library is to make it easy to fill containers with data > by overloading operator,() and operator()(). These two operators make it > possible to construct lists of values that are then copied into a container: A parenthesis-separated list: > map<string,int> m; > insert( m )( "Bar", 1 )( "Foo", 2 ); V2: > This second version of Boost.Assign is a new design, with optional support > for C++0x. Its core utility is a compact interface for executing the > repetitive tasks of assigning or inserting elements in a container, such as > follows > boost::for_each( > cal | do_csv_put<2>( "jan", 31, "feb", 28, "mar", 31 ), > std::cout > << lambda::bind( &p_::first, lambda::_1 ) << ':' > << lambda::bind( &p_::second, lambda:: _1 ) << ' ' > ); // prints jan:31 feb:28 mar:31 To my taste, I prefer V1 insert( m )( "Bar", 1 )( "Foo", 2 ); over V2 m | do_csv_put<2>( "Bar", 1, "Foo", 2) Even if I would find V2's syntax to be more tasty to the eye, i don't see that motivating enough for a new library at this point. Very well, continuing to understand the V2 library.. This example captures the basic features of this library: It maps arguments to a suitable data-element, p_( k, x ), and invokes a > container's modifier, insert. These semantics vary by container category. Operator | returns the modified container, thereby facilitating integration > with range algorithms. There is a function, csv_put, that achieves the same > as above, but without returning the container. Why is operator | used at all, if there are two separate functions? It doesn't look compelling to me and I'm perfectly fine with separating my statements, one for the assign part and one for the for_each part. In fact, the first example from the documentation would benefit from doing that, since it would be much more readable. cal | do_csv_put<2>( "jan", 31, "feb", 28, "mar", 31 ); boost::for_each(cal, long-lambda-expression..) Now it looks even more odd with the operator |. Additional features include: > Options for overriding default semantics, and macros to create custom > options > What are the default semantics? > A functor analogue of csv_put, put, for constructing a sequence of elements > from variadic argument lists > Two functions, csv_deque<> and deque<>, which are the analogues of those > just described, but which generate a container. You lost me here. I needed to read those sentences a few time before I think I understand what you mean. Functionality that is adjunct to or independent of what precedes is itemized > below: > Surely, this can be written smoother, no? =) > Chaining ranges, with special consideration for those created using the ref > functionalty (below) > I don't know what the docs are talking about at this point. Chaining ranges in the assign library? That sounds to the uneducated mind like a job for boost.range > Conversion from ranges to containers > This sentence doesn't make sence to me. std::container(range.begin(), range.end()) is supported by all containers. > A framework, whose identifiers are in namespace ref, for generating an > array of reference wrappers, for short, a reference-array. > I do not understand this part. What kind of container are we attempting to populate here? > Functionality is defined in namespace boost::assign::v2, thereby avoiding > any clash with the prior version [1]. Ok. Maybe V2 could show a compelling use-case that V1 lacks? I get the feeling V2 shows features I don't understand how to use, or didn't knew that I needed. Cheers, - christian

7 38

Re: [boost] Is there interest in an alternative to the Singleton anti-pattern?
by Ben Robinson 25 Jun '11

25 Jun '11

> > > I look forward to your feedback on the Singularity Pattern. The > unittests > > in Vault/Singularity/singularity_unittest.cpp are great to study first to > > see how Singularity is meant to be used. > > I have some remarks: > > 1) class single_threaded - if you remove user defined destructor and > constructor, it will become a POD type and compillers will do better > optimizations > > I completely agree. Done. Thank you. > 2) singularity_state, singularity_instance and singularity classes can > be combined together if you remove > BOOST_PP_REPEAT(BOOST_SINGULARITY_ARGS_MAX, > BOOST_PP_DEF_CLASS_TYPE_DEFAULT, _) from singularity and put this > templates directly for create functions. If you do so, code like: > > singularity<Horizon, single_threaded, int, Event*, Event&>::create(3, > &event, event); > > will look much better, just like: > > singularity<Horizon, single_threaded>::create(3, &event, event); > > Then, FRIEND_CLASS_SINGULARITY macro will be much shorter > > You suggestion simplifies the interface by implicitly determing the types for the user, rather than requiring them to manually specify them. But in addition, by only generating create(...) overloads that pass by reference or pointer (not by value which the user could have done before), we prevent the undesirable situation where a user would pass an object by value into Singularity which would then pass by value into their constructor. Now, all arguments which are passed by value are accepted by their reference, and then passed either by value, or by reference, into the constructor, whichever is present. A class obviously cannot provide both a value, and a reference constructor for the same type, so there are no ambiguity problems. An excellent suggestion. One detail, I still require the singularity_state and singularity_instance structs, because state should not depend on the threading model, and instance should not depend on the access model (see point 5 below). The only downside is that I must generate 2^(n+1)-1 function overloads if I am to support constructors up to a maximum of n arguments. I am basically permuting receiving the typed arguments by reference or by address. I have implemented Singularity without the BOOST_PP meta generating functions for now up to three arguments. Once the design is finalized, I will once again generate the create() functions based on BOOST_SINGULARITY_ARGS_MAX. 4) May be, it would be much better to derive from singularity. Then > the code will look just like this: > Horizon::create(3, &event, event); > or like: > Horizon< single_threaded >::create(3, &event, event); > I did not need to implement this suggestion, as implementing #2 also allowed this usage pattern. As such, Singularity is now usable as both a factory, or as a base class. I have unit tests and code comments demonstrating both usage patterns. This makes Singularity now far more usable, and general purpose. > 5) It would be great, to have a get() function in singularity, that > returns reference > > One of the selling points of Singularity is that it did not provide global access to an instance. However, I can see situations where this would be desirable, and also providing global access will make transitioning from Singleton much easier. Therefore, I have created an additional policy argument, which has a default value of "local_access", causing get() to throw an exception. However, if you instantiate Singularity with "global_access", you can now access the instance, provided create() has already been called and destroy() has not. > It's just what I saw in a 15 minutes of review. I will make a more > deep look a little bit later. Any comments are welcomed. > > > Best regards. > Antony Polukhin > Keep the feedback coming. I was going to post updated source and both AsFactory and AsBaseClass unit tests, to the Vault, but apparently the Vault is now deprecated. You can email me at icaretaker(a)gmail.com if you would like to see the new code. Here is an example of the new usage pattern: // Usage as a Factory: typedef singularity<Horizon, single_threaded, local_access> HorizonSingularityType; // same as singularity<Horizon> Horizon & horizonA = HorizonSingularityType::create(3, &event, event); HorizonSingularityType::destroy(); // Usage as a Base Class: class Horizon : public singularity<Horizon, multi_threaded, global_access> Horizon & horizonB = Horizon::create(3, &event, event); Horizon::destroy(); Thank you, Ben Robinson, Ph.D.

1 0

[graph] Bron Kerbosch Documentation
by Joel Young 24 Jun '11

24 Jun '11

Trac ticket 693 discusses the inclusion to trunk of the Bron Kerbosch cliques code from SOC 2007: https://svn.boost.org/trac/boost/ticket/693 Is there any documentation for this code in the boost::graph docs? I'm drawing a blank. First problem is that the example code is using typedef undirected_graph<Actor> Graph; which itself seems horribly documented. When I try to use a "real" undirected graph, I get compile errors stating that /usr/include/boost/graph/graph_concepts.hpp:455:13: error: no matching function for call to ‘renumber_vertex_indices(boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_name_t, unsigned int>, boost::property<boost::edge_weight_t, unsigned int> >&)’ Any tips? Thanks! Joel

2 2

Is there interest in e_float: Multiple-precision float and special functions?
by Christopher Kormanyos 24 Jun '11

24 Jun '11

Is there interest in my e_float library for potential inclusion in boost? e_float is a portable C++ system for multiple-precision floating-point calculations and calculations of special functions. The e_float library supports 30 to 300 decimal digits of precision. It has an extendable architecture featuring a uniform C++ mathematical layer which can be used with any suitably prepared big-number back end such as GMP, MPFR, etc. The e_float system implements many high precision special functions and extends some of these to very large parameter ranges not available from other systems. Interoperability with Microsoft's CLR, Python (via Boost.Python) and Mathematica are supported. The e_float library is well-tested and has high performance. Further details can be found in my original work published in the ACM: Christopher Kormanyos, "Algorithm 910: A Portable C++ Multiple-Precision System for Special-Function Calculations", ACM Trans. Math. Soft. 37, 4, 2010, article 45. http://portal.acm.org/citation.cfm?id=1916469 e_float is potentially suited for boost because: * It provides a uniform, standardization-capable interface to multiple precision mathematics. * It has a sound mathematical foundation (published in the ACM). * It has been programmed from the ground up using modern C++ programming idioms. * It uses a layered architecture that hosts any number of big-number back ends. * It is highly portable, robust and durable. * It has a broad test suite developed in conjunction with code coverage analyses. * It is extendable. Additional functions, parameter ranges and test cases can be added. * It provides interfaces to very high level languages. Thank you for your feedback. Sincerely, Chris.

9 25

[Review] The 'Type Traits Introspection' library Review starst next friday, july 1st
by Joel falcou 24 Jun '11

24 Jun '11

According to the schedule, review for the Type Traits Introspection library by Edward Diener will run from friday, July 1st to monday, july 10 2011. =========== What is it? =========== The TTI library, which is an abbreviation for the 'Type Traits Introspection' library, allows a programmer to introspect at compile time the inner elements of a C++ type. The introspection process depends on specifying the name of the inner element by different macros for different types of elements, and then using a generated metafunction to determine whether that element exists within the enclosing type. The inner elements which can be introspected are type, class template, member data, member function, static member data, and static member function. The TTI library is based on the type_traits_ext portion of the Concept Traits Library, with improvements and additions, and also reproduces functionality ( without changing existing code ), for the purposes of completeness, from Boost.MPL regarding introspection of types and templates. The purpose of the library is to provide a consistent set of interfaces for doing compile-time introspection of a type, which other template metaprogrammers can use in their code. If you are at all interested in compile-time introspection of types, please take a look at the functionality of this library. =================== Getting the library =================== The library is available at http://svn.boost.org/svn/boost/sandbox/tti/ Note that this repository will be updated up to next thursday by Edward. =================== Writing a Review =================== The reviews and all comments should be submitted to the developers list, and the email should have "[TTI] Review" at the beginning of the subject line to make sure it's not missed. Please explicitly state in your review whether the library should be accepted. The general review checklist: - 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.

1 0

Re: [boost] Is there interest in an alternative to the Singleton anti-pattern?
by Ben Robinson 24 Jun '11

24 Jun '11

Antony, Thank you for your interest. The Singularity Pattern (as I am calling it) is policy based, and allows you to supply the threading model as a template parameter. If you choose the default policy of single_threaded, there is no thread safety, but there is also no overhead in using a mutex and using a volatile pointer. If you choose the multi_threaded policy, you get thread safety. The user of Singularity can also create a multi threaded policy of their own, implemented using the mutex of their choice, should their platform not support the boost::mutex. I am currently working as a real-time, embedded C++ developer, and therefore I often need to disable exceptions on small microcontrollers, and don't need/can't afford thread safety. That is why in addition to using a policy to control the threading model, I have implemented Singularity to use assert instead of exceptions, if BOOST_NO_EXCEPTIONS is defined. I look forward to your feedback on the Singularity Pattern. The unittests in Vault/Singularity/singularity_unittest.cpp are great to study first to see how Singularity is meant to be used. Thank you, Ben Robinson, Ph.D. My interest is piqued. Is your solution thread safe? Best regards, Antony Polukhin

2 1

Re: [boost] Is there interest in an alternative to the Singleton anti-pattern?
by Ben Robinson 24 Jun '11

24 Jun '11

Matt, I am glad your interest is piqued (and I learned it is not spelled peaked). I have posted the source file, and a Boost Test unittest file in the Vault in the folder Singularity. Commenting on your first and second point, the Singularity Pattern (as I am calling it) is flexible enough to allow constructing the class with any supplied constructor. It is true you can construct a Singleton using the default constructor, and pass in dependencies via member functions, but you cannot pass in references this way. Singularity provides this flexibility which Singleton does not. I agree with you that the lifetime of Singleton is difficult to manage. The lifetime of a Singularity is bracketed by the calls to create() and destroy(), just like any other object created with new() and delete(). The difference being that new() can create any number of a objects, and Singularity::create() will only allow one. I look forward to your feedback on the pattern. I recommend looking at the usage in the Singularity/singularity_unittest.cpp file before studying the implementation. Thank you, Ben Robinson, Ph.D. On 6/23/2011 1:08 AM, Ben Robinson wrote: > The Singleton pattern does have its uses because it guarantees a single > instance of a class. However, it suffers from three weaknesses: > > 1) Encapsulation: Singleton provides global access to the class. Some may > view this as a feature, but advocates of unit testing, and dependency > injection would disagree. > 2) Initialization: Singleton restricts the class to the default constructor. > This makes Singleton unusable for classes which require non-default > constructors. > 3) Lifetime: Singleton introduces lifetime management complexities (for a > detailed discussion, see Chapter 6 of Modern C++ Design by Andrei * > Alexandrescu*). > > I have formalized what I believe is a novel design pattern, which guarantees > a single instance of a class, but which does not suffer 1-3 above. And > unlike Monostate, this pattern I propose does instantiate a genuine instance > of any class, using any one of its available constructors. I hope this > inquiry peaks your interest. I've often wondered about singleton's bad rap (other than the difficulty of making them reliable in C++). I use a singleton from the boost vault for hiding implementation details of globally accessible interfaces (e.g. an interface to access information about elements of the periodic table when I don't hard-code all the constants). This usage is unit testable as long as the implementation details can be thoroughly tested through the interface. It could support DI too if the dependencies are given to the singleton's methods instead of at construction. I don't understand weakness #2. My usage of singletons makes initialization an implementation detail. Construction is not part of the singleton's interface because constructing it different ways from different parts of the program would mean having more than a single instance. #3 is a indeed a bitch with C++. The boost vault solution I use makes it quite easy to chain singletons though. Nevertheless, my interest is piqued. Thanks, -Matt

4 3

[1.47.0][range] boost::irange break change
by Akira Takahashi 24 Jun '11

24 Jun '11

Hi. https://svn.boost.org/trac/boost/ticket/5544 This ticket is break change. Please write history document, and release note. example: #include <iostream> #include <boost/range/irange.hpp> #include <boost/range/algorithm/for_each.hpp> void disp(int x) { std::cout << x << std::endl; } int main() { boost::for_each(boost::irange(0, 9, 2), disp); } 1.46.1 result: 0 2 4 6 1.47.0 result: 0 2 4 6 8 >>======================== Akira Takahashi mail : faithandbrave(a)gmail.com blog : http://d.hatena.ne.jp/faith_and_brave/

2 1

[1.47] permission to merge doc change
by Eric Niebler 23 Jun '11

23 Jun '11

A minor and trivial doc-only change. Can I get another release manager's approval, please? https://svn.boost.org/trac/boost/changeset/72722 -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

[1.47] Beta build of PDF docs available
by John Maddock 23 Jun '11

23 Jun '11

A beta build of the PDF documentation for Boost-1.47 is available from http://sourceforge.net/projects/boost/files/boost-docs/1.47.0/boost_1_47_pd… As ever, only that subset of libraries that uses Quickbook/Boostbook/Docbook for documentation is included in the build. If library authors can take a look at let me know of any SNAFU's that would be great. New libraries added this time around are chrono, ratio, phoenix and geometry. Regards, John.

3 2

[1.47.0] Beta 1 Release Notice
by Beman Dawes 23 Jun '11

23 Jun '11

Boost release 1.47.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/ New Libraries: Chrono, Geometry, Phoenix and Ratio. Updated Libraries: Accumulators, Asio, Config, DateTime, Dynamic Bitset, Foreach, Function, Function Types, Graph, Iterator, Lexical Cast, Logic, Math, Meta State Machine, MultiIndex, Proto, Spirit, Tokenizer, Utility, Wave For details of what's in the release, see http://beta.boost.org/users/news/version_1_47_0. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. There have been reports of build issues with MinGW/CGG and 64-bit Windows/VC++. These are being investigated and hopefully should be cleared up before the final release Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

4 4

Is there interest in an alternative to the Singleton anti-pattern?
by Ben Robinson 23 Jun '11

23 Jun '11

The Singleton pattern does have its uses because it guarantees a single instance of a class. However, it suffers from three weaknesses: 1) Encapsulation: Singleton provides global access to the class. Some may view this as a feature, but advocates of unit testing, and dependency injection would disagree. 2) Initialization: Singleton restricts the class to the default constructor. This makes Singleton unusable for classes which require non-default constructors. 3) Lifetime: Singleton introduces lifetime management complexities (for a detailed discussion, see Chapter 6 of Modern C++ Design by Andrei * Alexandrescu*). I have formalized what I believe is a novel design pattern, which guarantees a single instance of a class, but which does not suffer 1-3 above. And unlike Monostate, this pattern I propose does instantiate a genuine instance of any class, using any one of its available constructors. I hope this inquiry peaks your interest. Thank you, Ben Robinson, Ph.D.

3 2

[typeof] deducing type at class level
by lcaminiti 23 Jun '11

23 Jun '11

Hello all, Is there any way to use BOOST_TYPEOF at class level? For example: struct vect { size_t size(); typedef BOOST_TYPEOF(size()) size_type; // can I make this work somehow? }; If not with Boost.Typeof, can I do this with C++0x? Thanks! --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-typeof-deducing-type-at-class-leve… Sent from the Boost - Dev mailing list archive at Nabble.com.

7 8

[review][assign] Formal review of Assign v2 ongoing
by John Bytheway 22 Jun '11

22 Jun '11

A reminder that the formal review of the Assign v2 library upgrade by Erwann Rogard is ongoing, and is scheduled to continue until June 24th. Please consider looking at the library and submitting a review. About Assign v2 =============== Assign v2 is an upgrade of Boost.Assign (1.0) that redefines its functionality, with optional C++0x support and new features. It is a compact interface for executing the repetitive tasks of assigning or inserting container elements. For example, std::map<std::string, int> map; // Inserts each pair ("jan", 31),...,("may", 31) in map: csv_put<2>(map, "jan", 31, "feb", 28, "mar", 31, "apr", 30, "may", 31); Please see the change log (linked below) for more detail on the motivation for this library and pointers for navigating the documentation. Where to get it =============== The documentation is online at: <http://svn.boost.org/svn/boost/sandbox/assign_v2/libs/assign/v2/doc/html/in…> With the change log at: <http://svn.boost.org/svn/boost/sandbox/assign_v2/libs/assign/v2/doc/html/bo…> The Assign v2 source can be found in the Boost sandbox at: <http://svn.boost.org/svn/boost/sandbox/assign_v2/> or downloaded from: <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=assign…> Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) with '[assign]' in the subject. Or if you don't wish to for some reason, you can send them privately to me. If so, please let me know whether or not you'd like your review to be forwarded to the list. All reviews are appreciated, even if you don't have time for an in-depth study. The Assign v2 library consists of several largely independent components: Reference containers and chaining, container modification and generation, and conversion of ranges to containers. If you wish, feel free to review and even vote on these separately. For your review you may wish to consider 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. More detail on the review process is available at: http://www.boost.org/community/reviews.html John Bytheway Review Manager

7 17

[accumuators][1.47] docs build
by John Maddock 22 Jun '11

22 Jun '11

I'm not sure if this is likely to cause issues or not, but the accumulators docs, generate some file names in ALL_UPPER_CASE.hpp which is against our filename policy. Cheers, John.

2 1

[interprocess] Possible bug in offset_ptr
by Lars Hagstrom 22 Jun '11

22 Jun '11

Hi, I reported a problem to the clang project about a problem I had with some release-compiled boost code. They're claiming it is a problem in offset_ptr, where the pointer arithmetic causes undefined behaviour according to the C++ standard. See: http://llvm.org/bugs/show_bug.cgi?id=10119 This seems like a fairly major thing, if it is true. Cheers Lars

2 2

[quickbook][phoenix] Can't build Phoenix as a PDF.
by John Maddock 21 Jun '11

21 Jun '11

Just a heads up that I'm currently unable to build the Phoenix docs (in libs/phoenix/doc) as a PDF for 1.47. The issue is that there are a few anchors: phoenix.preface phoenix.description phoenix.how_to_use_this_manual phoenix._emphasis_role__bold___emphasis____to_joel_s_dear_daughter__phoenix__emphasis___emphasis_ which are placed at <chapter> scope in the Docbook XML - this is legal according to the Docbook DTD, but produces invalid FO when using the latest Docbook XSL stylesheets (results in an <fo:inline> at <fo:flow> scope which isn't legal. Although this is probably a Docbook bug, it's not entirely unreasonable: anchors at <chapter> or <book> scope appear outside any logical page sequence in the FO, hence the error. Am I correct in thinking that these anchors are created by quickbook? Thanks, John.

2 1

[Phoenix] Two sets of docs?
by John Maddock 21 Jun '11

21 Jun '11

Currently Phoenix has it's own docs under libs/phoenix/doc, but there are also docs under libs/spirit/phoenix/doc. Should the latter have been removed now? Trying to work out what to build as PDF's yours, John.

3 3

[release] Release notes
by Daniel James 21 Jun '11

21 Jun '11

Hi, If you haven't done so already, it's a good time to write your release notes. You can either email them to me, or make the changes yourself in subversion. The file is at: http://svn.boost.org/svn/boost/website/public_html/beta/feed/history/boost_… thanks, Daniel

8 9

[BGL] Graph union
by Shaun Jackman 21 Jun '11

21 Jun '11

Hi, Is there a graph adapter that presents a view of the union of two graphs? The union graph would not be modifiable. graph_union<G1, G2> unionGraph(g1, g2); If not, any tips on how to go about implementing this? Cheers, Shaun

2 1

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

21 Jun '11

> On 6/21/2011 12:21 AM, Alejandro Cabrera wrote: >> 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) > I would suggest to you that you briefly explain what a Bloom filter > entails, and why it might be important, when sending your message to > this list. > Thank you for the suggestion. The data structure is introduced below. Briefly, a Bloom filter is a probabilistic data structure that represents a set of elements compactly. Two operations are supported in the most basic variant: insert, contains. An element is inserted by computing k hash values and setting the bits at the locations given by the hash values to 1. Checking whether an element is contained in the Bloom filter is achieved by hashing the element and checking that the bits at those locations are all 1. A Bloom filter may incorrectly tell you that an element is in the set (false positive). If false positives are acceptable, Bloom filters are a powerful data structure to avoid expensive look ups. There exist variants that also support element removal at the cost of an increase in storage requirements and the danger of false negatives - these are not covered by Boost.BloomFilter just yet. Bloom filters have seen use in file systems (avoiding duplicate writes, deduplication), network caches (determining whether to attempt to fetch from cache), databases (does a row/column exist on disk?) and hardware design. Where the primary interest is to compactly represent a potentially very large universe of elements to mitigate latency differences, Bloom filters are a great choice. Further details can be found in the project documentation files.

1 0