- Boost - lists.boost.org

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