July 2008 - Boost - lists.preview.boost.org

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

Why no non-null smart pointers?
by Ross MacGregor 29 Apr '14

29 Apr '14

I just created a very small smart pointer libary for our project. It will contain two types of shared pointers: SharedHandle and NullableSharedHandle. SharedHandle will be a shared pointer that cannot be null by ensuring a non-null construction while NullableSharedHandle will basically be a typedef for boost::shared_ptr. I firmly believe that code can be made more reliable by minimizing the use of nullable pointers. To this end, I think it is important that we start using non-null pointer types. Ideally the compiler would be able to understand a non-null pointer and catch bugs at compile time, but I think we can still improve things with a few runtime checks. If we make sure that a shared pointer is constructed with a non-null pointer and ban any reset() type methods, we guarentee that it points to something. This can be beneficial for the following reasons: 1. Any function that uses this type will no longer be burdened with precondition checks to make sure variables of this type are not null. 2. It's type is simply more explicit and better explains its function. 3. Moving the non-null check to the creation phase will reduce the possibility of encountering null pointer exceptions at runtime (assuming there are many more pointer references than constructor calls). So my little pointer library seems to make a lot of sense, but if so why hasn't this simple smart pointer variation made it into boost yet? Has this been discussed somewhere already? My search on non-null smart pointers is not revealing much discussion on the topic. Regards, Ross

9 16

[interprocess] message_queue hangs when another process dies
by Sergei Politov 03 Nov '11

03 Nov '11

Hi, I have found the following problem with message_queue on win32 (MSVC 2008 + Windows Vista). Suppose we have 2 processes, one sends messages to queue, another reads them. When reading process dies (for instance using End process) during message_queue.receive the another process hangs in send. As I found during investigation, it tries to lock interprocess mutex, but it is already locked by dead process. So this message queue instance becomes unusable. I attached the example. Steps to reproduce: 1) Start "mq.exe s" (i.e. with argument s) It outs: sender: $PID 2) Start mq.exe without arguments. It outs: receiver: $PID 0 1 2 3 4 This time sender outs: send done: 3) At this point the message queue is empty and receiver waits for messages. End it with Task Manager. 4) Enter some number in sender console and press Enter. 5) The sender hangs in message_queue.send Best Regards, Sergei

6 13

[asio] read_until -- possibly misleading documentation?
by Richard Smith 15 Apr '10

15 Apr '10

The documentation for Boost.ASIO (which is otherwise very comprehensive) says of the boost::asio::read_until set of overloads: | Read data into a streambuf until a delimiter is | encountered. <http://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/reference/read_unt…> What the function actually does is to read blocks of data into the streambuf, and stop when the delimiter is found. This means that frequently data beyond the delimiter will be read into the streambuf. (And this is elaborated in more detail on the individual function's pages, if a reader looks there.) I appreciate that this behaviour is compatible with the documentation, but someone less familiar with ASIO could easily assume that the function will read as far as the delimiter and no further. (And I have just spent a fair amount of time debugging a piece of code where the author had made this assumption.) Could we change the summary documentation to read something like: | Read data into a streambuf at least until a delimiter is | encountered. The implementation may read beyond the | delimiter, but will not block when doing so. While I'm on the subject of ASIO documentation, I can't see any documentation on whether the service_name parameters to the basic_resolver_query constructors are allowed to be port numbers (e.g. "80") or whether they have to be symbolic names (e.g. "http"). Port numbers work, at least on Linux, but it's not clear whether this is something that I should be relying on. Similarly for IPv4 and IPv6 addresses in the host_name parameter. Richard Smith

3 2

Proposed addition to the iterator library for iterating over all tuples.
by Alex Mendes da Costa 19 Jun '09

19 Jun '09

Hi folks: I quite often have to write code to do the following: Given N sequences, generate all the N-tuples s.t. the i'th element in each tuple is drawn from the i'th sequence. For example, if sequence S1 is { 1, 2, 3 } and sequence S2 is { 10, 20 }, I need to generate these tuples: (1, 10), (2, 10), (1, 20), (2, 20). I think this problem could be solved elegantly with a iterator similar to zip_iterator. I have some questions: (1) Is there already a way to do this in boost? (2) If not, would this be a worthwhile addition to the iterator library? (3) If so, could I contribute code for this, or must the existing library owners write it? (4) If so, how would I go about getting my code added? Most of the docs seem to be about submitting entire libraries, rather than extensions to existing libraries. Thanks, Alex

4 18

[mpl] is there a or_seq like logical metafunction?
by vicente.botet 17 Jun '09

17 Jun '09

Hello, I needs calculate the mlp::or_ of a sequence of nullary logical metafunction. This seams quite simple. I have do the following: <code> template <typename Seq> struct or_seq; template <typename Seq, long N> struct or_seq_aux : mpl::or_< typename mpl::front<Seq>::type, or_seq<typename mpl::pop_front<Seq>::type> > {}; template <typename Seq> struct or_seq_aux<Seq, 1> : mpl::front<Seq>::type {}; template <typename Seq> struct or_seq : or_seq_aux<Seq, mpl::size<Seq>::value> {}; </code> Is there a boost or_seq like logical metafunction? Is there a better way to do it? I would be extremely interested in any suggestions. Best regards --------------------------- Vicente Juan Botet Escriba

5 34

Proposed templated integer_sort
by Steven Ross 25 Apr '09

25 Apr '09

Would there be interest in an integer_sort call that is faster than std::sort? Spreadsort is an in-place hybrid radix-based and comparison-based algorithm with better worst-case and average-case (roughly 20-50%) performance than introsort on random integer data. The worst-case advantage is algorithmic, with Spreadsort taking the better of O(n(square_root(bit_sizeof(data) - log(n)))) and O(nlog(n)) time. For 32-bit integers, that's O(n(square_root(32 - log(n)))), so for a log(n) of 16 (65536 items), it's 4n (plus a small constant times n), vs 16n for introsort. For larger n, the advantage vs. pure comparison-based algorithms increases. In effect, Spreadsort smoothly transitions from pure MSB Radix sort to std::sort with its data cut up by a couple iterations of MSB Radix sort (reducing the size of the log(n) factor), depending upon the distribution and size of the data. I could write a templated version of Spreadsort for the Boost library if there is interest. It would work for anything that supports the << and - operators. It could also handle standard floats sorted as integers. Functors supporting << and - could make it more general. Multi-dimensional sorting is also sped up by Spreadsort. I could also write a similar string_sort, that should also be significantly faster than std::sort. This would look much like postal sort, just using introsort after a certain number of iterations. Is this of interest? http://sourceforge.net/projects/spreadsort

15 118

Profiling template instantiations
by Steven Watanabe 12 Feb '09

12 Feb '09

AMDG Over the last few days, I've been working on a tool that counts the number of class template instantiations in a translation unit. To use it from a jamfile import profile_templates : : directory of the tool ; template-profile result : some_file.cpp : <include>some_directories ; If everything works, this will create a file with the extension .tp which will contain the number of times each class template was instantiated, with the most common templates at the top. I've put a zip of a rough version in the vault. http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… Caveats: I've only tested with Visual C++ 9.0 and gcc 3.4.4 on cygwin so far. Other compilers won't work, yet. Other versions of these compilers may or may not work. It may be necessary to add link=static to the bjam command line. In Christ, Steven Watanabe

6 20

Re: [boost] Profiling template instantiations (Steven Watanabe)
by PORKOLAB Zoltan 12 Feb '09

12 Feb '09

Hi Steven, We have created a framework for debugging/profiling template metaprograms in 2006. It might give you a few tips. It works based on the same idea you have. We instrument all template codes, both at the begining and at the end of each template we insert a special piece of code emitting warning messages of a well-defined form. Before instrumentation we create an XML file to remember the template positions in the source file. When we parse the warning, using this information we can reconstruct the instantiation stack knowing the original line numbers, identifiers, etc.. At the end we produce another XML for possible front-ends. The framework uses boost::spirit and boost::wave. We have also implemented and tested a visual studio plug-in. An overview of the whole idea: http://gsd.web.elte.hu/templight/ There is also a GPCE article about the framework, you can find it here: http://portal.acm.org/citation.cfm?id=1173746&coll=portal&dl=ACM&CFID=47731… or here: http://gsd.web.elte.hu/contents/articles/gpce06.pdf You can download both the VS binaries and the source from: http://people.inf.elte.hu/pocok Please feel free to use the code or any of the ideas. For technical question you can find Jozsef: jmihalicza(a)gmail.com or me. Regards, Zoltan

4 3

[thread/interprocess] could we improve recursive_mutex constructor
by vicente.botet 24 Jan '09

24 Jan '09

Hi, the recursive_mutex constructor initialize/set/destroy the pthread_mutexattr_t every time. I'm wondering if we can improve the efficiency storing this on a static variable which will be initialized once. What could be the better way to initialize this static variable? Note: the same applies to interprocess mutexes. recursive_mutex() { // begin code that can be initialized only once pthread_mutexattr_t attr; int const init_attr_res=pthread_mutexattr_init(&attr); if(init_attr_res) { throw thread_resource_error(); } int const set_attr_res=pthread_mutexattr_settype(&attr,PTHREAD_MUTEX_RECURSIVE); if(set_attr_res) { throw thread_resource_error(); } // end code that can be initialized only once int const res=pthread_mutex_init(&m,&attr); if(res) { throw thread_resource_error(); } // begin code that can be removed BOOST_VERIFY(!pthread_mutexattr_destroy(&attr)); // end code that can be removed } Regards, Vicente

2 2

manipulators for filtering_stream s
by Roland Schwarz 22 Jan '09

22 Jan '09

Surprisingly I was not able to find on the net code that would give me a smart way to indent a stream. So I wrote a little filter based on the boost iostreams library. My first attempt was: boost::iostreams::filtering_ostream out; indent_filter ind(4); out.push(ind); out.push(std::cout); However trying to control it via e.g. ind.in() ind.out() turns out to be problematic interface since, 1) out.push() takes a copy of ind 2) the interface ind.in() is suboptimal. With my attached example it is possible to: #include "indent.hpp" ... boost::iostreams::filtering_ostream out; indent_filter::push(out,2); out.push(std::cout); ... And use it like so: out << "Hello Filter!\n" << indent_in << "this is\n" << "indented\n" << indent_out << "until here\n" ; Which will result in output: Hello Filter! this is indented until here The state is stored in the ios base class of the stream, by way of the pword mechanism. Consequently the filter stream even may be downcast to a basic_ostream, and the indenter will still work. E.g. with out defined as above: ... foo(out); ... void foo(std::ostream& out) { out << indent_in << "out is a downcast filter_stream\n" << indent_out << "end of indentation\n" ; } If you want to try it out, you just need to include the header indent.hpp. If someone thinks the snippet is usable either as an example for the iostreams library or the filter streams manipulator idea is worth generalizing to make it usable for other filters too, I would be glad to hear from you. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at

5 17

[thread] proposal to manage portable and non portable thread attributes
by vicente.botet 22 Jan '09

22 Jan '09

Hello, Boost.thread has already a non portable interface to get the thread handle class thread { public: ... typedef np_native_handle_type native_handle_type; native_handle_type native_handle(); ... }; Boost.Thread do not allow to pass thread attributes on the thread constructor. I supose that this is due to portable issues. Could we identifiy which attributes are portable and which one not? The portable attributes (as stack size, ...) can be grouped on a thread_attributes class. In order to be able to pass whatever attribute to the thread constructor we can add the setting of non portable attributes to this thread_attributes class, and making the thread constructor take a thread_attributes in addition to the existing parameters. class thread { public: class thread_attributes { // portable attributes public: // set/get of attributes // .. #if defined(BOOST_THREAD_PLATFORM_WIN32) // ... window version #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) private: pthread_attr_t native_attributes; public: set_np_attributes(const pthread_attr_t* h); // ... other #else #error "Boost threads unavailable on this platform" #endif }; thread(const thread_attributes*p, F f,A1 a1); ... }; The portable application needing some specific configuration can construct portable threads using the following schema thread::thread_attributes attr; // set portable attributes // ... #if defined(BOOST_THREAD_PLATFORM_WIN32) // ... window version #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) // ... pthread version pthread_attr_t native_attributes; pthread_attr_init(&native_attributes); pthread_attr_setstacksize(&native_attributes, 1000000); attr.set_np_attributes(&native_attributes); #else #error "Boost threads unavailable on this platform" #endif thread th(attr, f,ctx); What do you think? Vicente

3 3

[swap] How to fix ADL barrier for XL, Intel, GCC, Sun and Como?
by Niels Dekker - mail address until 2008-12-31 19 Dec '08

19 Dec '08

The boost::swap utility from Joseph Gauterin has an ADL barrier against infinite recursion or ambiguity, as recommended by Steven Watanabe and David Abrahams, last year at the mailing list: "Re: [boost] Koenig lookup swap." http://lists.boost.org/Archives/boost/2007/08/125938.php Last Friday I added "test_adl_barrier" to test this ADL barrier. Unfortunately it fails on many compilers, including XL (AIX), Intel (version 9 and 10), GCC, Sun and Como: http://www.boost.org/development/tests/trunk/developer/utility-swap_.html While I usually use MSVC, and for that specific compiler, the ADL barrier appears successful! Do you know how to fix the ADL barrier for the other compilers? I'm afraid we'll need to have #if BOOST_WORKAROUND statements in there... FYI, the boost::swap utility is at: http://svn.boost.org/svn/boost/trunk/boost/utility/swap.hpp The ADL barrier test is at: http://svn.boost.org/svn/boost/trunk/libs/utility/swap/test/test_adl_barrie… Kind regards, -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

5 26

[proto][design]why unary_expr,binary_expr; but no nullary_expr?
by Larry Evans 14 Dec '08

14 Dec '08

Although there's unary_expr<Tag,*>, binary_expr<tag.*,*> in traits.hpp there's no nullary_expr<Tag>. I realize this would be a replacement to the current terminal template but with a user specified tag. After all, if a user specified tag for n-ary (where n>0) expressions *is* desirable, why is a user specified tag for 0-ary expressions *not* desirable? On case where this would be useful is for algebraic morphisms where n-ary ops in a source algebra are mapped to n-ary ops in a target algebra. This *includes* 0-ary ops. An op would be the equivalent to proto tags. I think this could be done by another transform similar to the pass_through transform but allowing transformation of the tag. Currently pass_through just uses the source tag in the target expression. It seems like it should be pretty easy to allow transformation on the tag also.

2 3

[integer] Promotion of endian library code from vault
by Neil Mayhew 01 Oct '08

01 Oct '08

On 2006-07-22 12:21:01, Beman Dawes wrote: > [boost] [integer] endian-0.6 posted w/ names changed > endian-0.6.zip has been posted in the integer directory of the file > vault at http://boost-consulting.com/vault/ This code is still in the vault, but I'd like to see it in the main part of boost. What needs to be done to make this happen? The endian library is exactly what I've been looking for, and I would really like to use it in my work, but I can't justify that to my colleagues if it's not an official part of boost. I would hate to become yet another person that reinvents this particular wheel. However, I notice there was a lot of discussion <http://lists.boost.org/Archives/boost/2006/07/108125.php> about PODs vs constructors, because of unions, so maybe not enough consensus was reached? There were some interesting proposals but no agreed-upon solution. In which case, I suspect that people will need to copy the code and each hack it to suit their own purposes, which is not what boost is all about. I have two use cases from my own work: TrueType fonts, and Mac HFS+ file systems. Both of these are big-endian file formats that need to be read into memory and processed, so (FWIW) I would support the POD approach. Currently, I can't use the code as-is because of the need to use the types in unions. References: http://lists.boost.org/Archives/boost/2000/03/2495.php http://lists.boost.org/Archives/boost/2006/05/105621.php http://lists.boost.org/Archives/boost/2006/06/105695.php http://lists.boost.org/Archives/boost/2006/06/105779.php http://lists.boost.org/Archives/boost/2006/06/105968.php http://lists.boost.org/Archives/boost/2006/06/106655.php http://lists.boost.org/Archives/boost/2006/07/108125.php http://lists.boost.org/Archives/boost/2006/07/108202.php --Neil

9 37

[BENUM] Any interest in auto-generated enum-to/from-string functions, without longer/more-complex usage?
by Tony D 15 Sep '08

15 Sep '08

Anyone think this functionality belongs in boost? (I have working code) ENUM(X, B = N, C, D = B + C }; // or whatever X x1 = C; cout << x1 << '\n'; // outputs "C\n" X x2("D"); // construct from string... if (x2 == D) { will do } Tony __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

4 3

[thread_pool]: formal review request
by Oliver Kowalke 12 Sep '08

12 Sep '08

Hello, I'd like to request a review of my thread_pool library - it is available at the boost vault/Concurrent Programming. The library provides: - thread creation policies: determines the managemnt of worker threads - fixed set of threads in pool - create workerthreads on demand (depending on context) - let worker threads ime out after certain idle time - channel policies: manages access to queued tasks - bounded channel with high and low watermark for queuing tasks - unbounded channel with unlimited numer of queued tasks - rendezvous syncron hand-over between producer and consumer threads - queueing policy: determines how tasks will be removed from channel - FIFO - LIFO - priority queue (attribute assigned to task) - smart insertions and extractions (for instance remove oldest task with certain attribute by newst one) - tasks can be chained and lazy submit of taks is also supported (thanks to Braddocks future library). - returns a task object from the submit function. The task it self can be interrupted if its is cooperative (means it has some interruption points in its code -> this_thread::interruption_point() ). Oliver -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/61691…

6 9

[spirt] question regarding BOOST_SPIRIT_THREADSAFE and BOOST_SPIRIT_SINGLE_GRAMMAR_INSTANCE
by Robert Ramey 05 Sep '08

05 Sep '08

I've just discovered the existence of these manifest constants in spirit and checked the documentation and code to determine what they do. Of course figuring what spirt code does and how it does is not easy to get right for the casual observer so feel free to correct and any mis-conceptions / conclusions that I 've got. My general conception is that parsing can be consider as various quasi - independent phases. a) specification of grammar - source code preparation b) compiliation c) instantiontion/construction of grammar definition d) usage of c) to parse a text string e) destruction of instance. >From this I want to conclude that phase d) does not change the grammar definition so so that in a multi-threading environment, the invocation of the scoped_lock would be limited to phases c) and e). That is, I want to believe that the following example adapted from the spirit documentation would work: const my_grammar g; // note addition of const if (parse(first, last, g, space_p).full) cout << "parsing succeeded\n"; else cout << "parsing failed\n"; The reason I ask is that the serialization library uses spirit to parse xml archives. Recently, I made changes to make the library thread-safe. I did this without using mutexes/locks by confine all non-const operations to construction and destruction and using static object constructed/destructed at pre-main and post main time time. Although the jury is still out on this, I believe it will make the serialization library thread safe without the need for using threading primitives and libraries. I never realised that spirt wasn't thread-safe. I would like this approach to include xml_archives. So my quesion is: Can I instantiate my xml grammar as a static variable at pre-execution time and permit it to be used by mulitipe threads without locking? Robert Ramey

7 13

Proto<markus>::review()(proto::accept);
by Markus Werle 30 Aug '08

30 Aug '08

Hi! I think Proto should be accepted for inclusion into boost. A general purpose Expression Template library is hard to write. Proto is the most sophisticated and closest approach to perfection available today. - What is your evaluation of the design? Proto is well-designed in many aspects, though I got the impression that some beauty and purity was sacrificed on the altar of compile-time efficiency, but that's OK. (And yes, I hate BOOST_PP_MACROS!) Proto catches the most important issues of a general purpose expression template library, I especially like the way how expression storage and expression evaluation is strictly separated and the way I can add my own functionality. Proto covers the most important aspects of an ET library, sometimes in very elegant ways. Proto's design adressed compile time issues. That's a value in itself. OTOH: Transforms leave me with mixed feelings. I am not very good at catching ideas without good step-by-step documentation and I got messed up with grammars vs. transforms. This part of proto is new and it looks like a candidate for rework. I'd like to have an extra review in half a year only on the grammar and transform part of proto (*)[comment below]. That's a DSEL all by itself and I guess that interface may have some pitfalls. Larry Evans has worked that out in detail. There may be issues in the naming convention used there, e.g. I am unsure whether and_ is the appropriate name for what it does. - What is your evaluation of the implementation? None. Not enough time. Steven Watanabe did it for us all. Code looks clean. For my taste too many levels of nested namespaces, but that's the boost trend at the moment. I may appreciate this style later in my life, once I understand why you need it. - What is your evaluation of the documentation? The quality varies from excellent to hard to read. I agree with all what David writes about the docs. There is some potential for improvement, but that should not hinder the inclusion into boost: we need a community effort here since Eric's skill level probably is way too high in order to have some feeling for why the unaware might have problems with parts of the doc. The teacher should be one step ahead, not too far ahead. - What is your evaluation of the potential usefulness of the library? We really, really need this. Better today than tomorrow. The whole world is waiting for this to come. And C++ again rocks - Did you try to use the library? A couple of hours, but only for some of the examples. - With what compiler? VC8, Intel 10.1 - Did you have any problems? Nope. Eric-faster-than-lightning fixed those before I could run into them ... - How much effort did you put into your evaluation? I read the docs three times and worked through some details. I investigated the type representation of expressions by reading purposely generated compiler error messages and tried to figure out the design. - Are you knowledgeable about the problem domain? I had several attempts to write some kind of ET library on my own, some parts published at daixtrose.sourceforge.net. I also planned to write something like proto myself, but due to lack of time and programming skills I lost the race before it began. (rm -rf /work/markus/ideas/expresion_templates_revisited) Eric, thanks for the time saved by the publication of proto. Markus P.S. This review is short, sorry. I had some unexpected tasks to do the last week which hindered further investigation. I'll put some more effort into this in the future. (*) I'd like to have an extra review on _every_ boost library in a 2-year-cycle. By this boost::multi_array could probably be forced to model assignable like any other STL container and ::_1 from boost::bind will move into its own namespace - just to mention my two favourite change requests ...

3 3

Re: [boost] UTF-8 conversion etc. (Sebastian Redl) (Sebastian Redl)
by Graham 28 Aug '08

28 Aug '08

>> As I said to Phil, Rogier and I completed a Unicode character library >> for >> >> Release under boost, but never submitted it to Boost as we had intended >> to >> >> release it with a string library built on it, and never had time to do >> the >> >> second part of the work. >> >Post it, and we'll do the second part. It's open-source. > >Sebastian Sebasian, As requested, I have posted a Unicode character support library in the boost vault as Unicode_lib.zip. Please feel free to use this under the boost license. It would be great if somebody had the time to develop the existing character support to ad the string wrappers that we had intended to - but ran out of time doing. It should be well documented, but if you want any questions answered, please feel free to ask and I'll try and help! Thanks. Yours, Graham

6 7

[smart_ptr] make_shared usage
by Daniel Frey 21 Aug '08

21 Aug '08

Hi, I have a question on make_shared. Consider a class which intends to force all instances to be handled via a shared_ptr. I used to do this by putting the ctors into the private section and adding static create()-methods in the public section. Example: class X { private: X( int, double ); public: static shared_ptr<X> create( int i, double d ) { return shared_ptr<X>( new X( i, d ) ); } }; Replacing the returned expression with make_shared<X>( i, d ) wouldn't work, since it requires a public ctor. Is there any solution to this or do I have to make a decision between efficiency and a safe interface for X? Regards, Daniel

7 17

[integer] Recent changes introduced failures on many platforms
by Markus Schöpflin 20 Aug '08

20 Aug '08

The two tests integer_mask_test and integer_test have been broken by the recent commits to integer on nearly all platforms. (Probably all but Windows) The error message is: In file included from ../libs/integer/test/integer_test.cpp:29: ../boost/integer.hpp:154:39: error: invalid suffix "ui64" on integer constant ../libs/integer/test/integer_test.cpp:115:39: error: invalid suffix "ui64" on integer constant ../libs/integer/test/integer_test.cpp:215:39: error: invalid suffix "ui64" on integer constant Regards, Markus

8 27

[shared_ptr][exception] Support for disabled RTTI
by Daniel James 18 Aug '08

18 Aug '08

Using boost with RTTI disabled was recently discussed on the user list, and I had a quick look into it. It seems that shared_ptr added support for the BOOST_NO_TYPEID macro in 1.35: http://svn.boost.org/trac/boost/ticket/1108 But because it now depends on the new exception library, which requires RTTI, it no longer works. Would it be possible to support the macro in Boost.Exception? Daniel

5 8

[asio]: extending asio
by Andreas Pokorny 17 Aug '08

17 Aug '08

Hello, I would like to add more asynchronous event sources to asio, like: - input events for mouse, keyboard and joystick .. - window exposure, move, resize events in some generic form, - generic "quit" events - file alteration With directFB/X11/Unix/Linux most of that can be done directly through select or epoll. But since reading the message and parsing events is mostly done by a third party library, I would only need the reactor part for these. Is this possible with asio? According to msdn it seems to be possible to create so called event objects for direct input devices. I am no win32 expert so I do not know if one can combine that with completion ports? Regards Andreas Pokorny

7 16

contradictory information in FS docs?
by Noah Roberts 12 Aug '08

12 Aug '08

"Class basic_directory_iterator is an important component of the library. It provides an input iterator over the contents of a directory, with the value type being class basic_path." That seems to be correct. "The expression itr->path().leaf() == file_name, in the line commented // see below, calls the leaf() function on the path returned by calling the path() function of the directory_entry object pointed to by the iterator." But that claims the object pointed to the iterator is something other than basic_path and appears to be quite in error. itr->path() fails to compile. Documentation is same for both 1.34 and 1.35 - tested on 1.34. This appears in both the front page and the docs for directory iterator. The find_file function doesn't actually compile if copied verbatim. Need to remove all calls to path() on the iter and replace with "*itr".

2 2

proposal: interval containers; boost examples and more
by Joachim Faulhaber 11 Aug '08

11 Aug '08

Dear boost developers, after encouraging feedback by Paul A Bristow, Vicente Botet and Luke Simonson to my proposal on interval containers from end of May (http://lists.boost.org/Archives/boost/2008/05/137301.php) I started to boostify my interval template library (ITL). Even though there is a lot left to be done for the ITL to become fully boost compliant I'd like to report on some aspects of my current work. (1) As suggested by Paul A Bristow I have prepared some new examples that are using boost::date_time as instance types for the interval containers. * Example boost_party.cpp is a boostified instance of the introductory example party.cpp that demonstrates the 'aggregate on overlap' mechanism of interval maps (see: http://www.herold-faulhaber.de/itl/boost__party_8cpp.html) * Example month_and_weeks_grid.cpp demonstrates how different time grids can be merged in split_interval_sets by intersection (see: http://www.herold-faulhaber.de/itl/month__and__week__grid_8cpp.html) * Example man_power.cpp shows how calculations on interval_sets and maps can be obtained using set type operations. In the example the available man power in a small company is calculated accounting for weekends, holidays vacations etc. (see: http://www.herold-faulhaber.de/itl/man__power_8cpp.html) * Example user_groups shows how interval maps can be unified or intersected (see: http://www.herold-faulhaber.de/itl/user__groups_8cpp.html) (2) In the course of boostification of my code I have reviewed the design and completed the interval container classes as follows: * interval_set * split_interval_set * separate_interval_set (added) * interval_map (added) * split_interval_map You can see an overview these interval containers and some basic characteristics in the ITL's documentation here: http://www.herold-faulhaber.de/itl/interval__container__conduct_8h.html The major addition here is the class template interval_map. In contrast to a split_interval_map that preserves all interval borders that may emerge due to insertion and intersection operations, an interval_map keeps itself always minimal: Whenever two neighbouring interval-value pairs ([a,b), v), ([b,c),v) emerge, they will be joined to ([a,c),v). (3) Reviewing the overall design of the interval containers I have separated the meaning of insert/add and erase/subtract, which had been confounded in the previous version of the ITL. This has consequences especially for interval maps: As a design decision I'd like to choose that interval maps are addable and subtractable objects having operators += and -= that implement these properties. Addition and subtraction is then defined via element addition (add(value_type&)) and element subtraction (subtract(value_type&)). At a general level I can define add<inplace_op>(value_type&) and subtract<inplace_op>(value_type&)as member function templates, that implement aggregation on overlap (aggovering) not only for inplace_plus (+=) but also for arbitrary aggregate operations (inplace_op). It turned out, that function insert (std::insert semantics) can be expressed by the general add template (as well as erase can expressed by the subtract member function template): add<inplace_identity>(value_type&) is equivalent to insert(value_type&) subtract<inplace_erasure>(value_type&) is equivalent to erase(value_type&) In addition we can also define 'plain' element add and subtract by means of these templates: add(value_type&) can be defined as: add<inplace_plus>(value_type&) subtract(value_type&) can be defined as: subtract<inplace_minus>(value_type&) So for the ITL container classes I do provide now insert and erase that covers the std::semantics and I provide add and subtract that is the basis for addability and subtractability of itl::maps and itl::interval_maps. You can find an overview over all insert/erase and add/subtact functions and their relationships to std::semantics in the ITL's documentation here: http://www.herold-faulhaber.de/itl/interval__container__design_8h.html I find these design and semantical questions quite rich, and sometimes surprising ;-) and I have found many more aspects and properties while reviewing the ITL's design. I am planning to prepare a more detailed article about these topics in the next months to come. (4) I have prepared a new release 2.0.1 of the ITL for the current state that can be downloaded from: http://www.sourceforge.net/projects/itl Documentation is availabe online also from here: http://www.herold-faulhaber.de/itl The code is well tested using the Law Based Test Automaton (LaBatea) and is protabel for gcc 3.4.4 and msvc 8.0 sp1. I am sorry the ITL is still not in the boost standard directory structure. This will be one of the next steps on my todo list. (5) Concerning boostification of ITL there is still a lot to be done. Besides reviewing of the overall design reported above, I have removed virtual functions from all interval container classes using the curiously recurring template pattern (CRTP). To prevent you repeating advices that already found their way into my todo list I am listing it roughly as appendix to this posting. Cheers Joachim Faulhaber --- Boostification todo list: - Extracting a subset of the ITL as boost proposal - Providing the code in boost directory structure - Replacing own metaprogramming code by boost::mpl,fusion etc. - Using boost::value_initialized for generic initialisations - Further minimizing of class template interfaces and... - Providing more operators and functions as itl::global algorithms - Providing as much std::semantics as possible for interval containers (viewed as set<interval<T>> or map<interval<T>,U>) - Adapting testcode to boost testing standards - Improving documentation especially for issues of design and complexity - Providing boost style documentation - Preparing a proposal on the addition of open interval bounds to boost::interval

4 6

web service client based on boost?
by Gregory Dai 09 Aug '08

09 Aug '08

Anyone tried building a web service client based on existing boost library components such as asio? Like to share, or brag :-) about your experience? A web service server is probably more involved. Doing a client should be a nice first step, and helps build a common foundation forward. Thanks, Greg

5 10

Re: [boost] data_binding
by Brian Davis 06 Aug '08

06 Aug '08

>Stjepan Rajko writes: > I have tried to tackle the value/domain transformation problem a while > back, inspired by Brook Milligan's (CC-d) probability library (which > can nicely transition probability values between linear and log > domains). > Brook Milligan also worked on a generic domain transformation library, > so he might comment on this as well. There is also the Boost.Units > library which might offer transformations for some cases. >Thanks, Stjepan. I've continued to refactor that, actually, to make >it support the more generic problem under discussion here. So far it >is mostly done. I think the only issues are some silly overloading >resolution issues that have little to do with the basic ideas. For >the discussion I'll outline my approach. The goal I have/desire is to preform type transformations and allow the programmer to specify these transformations in a generic way For type T1 and T2 allow the programmer to specify f(T1 t1, T2 t2 ) and g(T1 t1, T2 t2 ) where f and g are transformation functions from T1 -> T2 and T2->T1 respectively. Overloading operator= and specifying f(T1 t1, T2 t2 ) := t2 = t* 1/2 and g(T1 t1, T2 t2 ):= t1 = t2*2 allowing the programmer to type float t1; float t2; bind_values<float ,float > t1t2ValueBinder( t1, t2 ); t1 = 12; printf( "%f", t2 ); // produces output of 6 Transformations shall allow chaining/cascaded to be specified. int a; int b; float c; boost::uint32_t d; bind_values<int,int> abBinder( a, b ); bind_values<int,float> abBinder( b, c ); bind_values<float,boost::uint32_t> abBinder( c, d ); // a->b->c->d a = 12; printf( "%f", d ); // produces output of 6 Transformations shall allow for fanout int a; int b; float c; boost::uint32_t d; boost::uint32_t e; boost::uint32_t f; bind_values<int,int> abBinder( a, b ); bind_values<int,float> abBinder( a, c ); bind_values<float,boost::uint32_t> abBinder( c, d ); bind_values<float,boost::uint32_t> abBinder( c, e ); bind_values<float,boost::uint32_t> abBinder( c, f ); // a-+->b // | // +->c-+->d // | // +->e // | // +->f // a->b->c->d a = 12; printf( "%f", f ); // produces output of 12 as f and g default to 1 to one mapping a = 12; printf( "%f", f ); // produces output of 12 as f and g default to 1 to one mapping printf( "%f",e); // produces output of 12 as f and g default to 1 to one mapping f=32; printf( "%f", a ); // produces output of 32 as f and g default to 1 to one mapping printf( "%f",f ); // produces output of 32 as f and g default to 1 to one mapping printf( "%f",c ); // produces output of 32 as f and g default to 1 to one mapping Transformations shall support bidirectional and unidirectional updates. >The basic observation that motivates this is that in some (many?) >situations there exist a group of related types that clearly have >common semantics in the application domain but may impose different >constraints in their implementation. Yes. Agreed >Indeed, some operations may not >be practical or feasible for some of the types but could be for others >and there may exist transformations from one to another. Where if there exists no clear transformation... the programmer shall be allowed to specify one. >In the case >of probabilities think of two types, one for a probability and one for >its logarithm with appropriate operators defined for each domain and > the interconversions. Another example involves the representation of > polynomials, which can be in terms of coefficients or in spectral > terms that ease their multiplication. In this case, it may be > completely undesirable to implement a polynomical multiplication for > the coefficient representation. Yes so some types can not be automatically transformed. My example provides absolutely no support for this except for 1 to 1 translation... for disparate types it is... well... compiler errors waiting to happen if no translation functions are supplied. > Conceptually then, the Domain library seeks to create a framework for > implementing sets of such types that work smoothly together, and > enable the compiler to make choices about how to handle mixed domain > operations (e.g., adding a probability and a log probability) or > operations that must be performed in another domain (e.g., multiplying > two polynomials represented as coefficients). I think these are most > of the salient points, all of which are currently supported. The software engineer shall be allowed to specify a transform is the compiler cannot automatically figure it out. How difficult is it to specify new types and tranforms.... Are we talking about the types like thoes defined by the section titled "A Deeper Look at Meatafunctions - 3.1 Dimensional Analysis" in "C++ Template Metaprogramming" by David and Aleksey? If so ... ouch... could be quite painful to specify new types and conversions... What is your approach? > - Allow definition of families of types (domains) based upon each > member of a family sharing common semantics in the application > domain. Providing type conversions across known domains where they exist. Yes sounds great. > - Allow implementation (or not) of any within-domain operators that > make sense in the application domain. Yes sounds great with the exception of the "operators portion"... like every one in boost using operators for new purposes (think Spirit - and I don't mean this in a bad way) we are running out of operators which provide meaningful schematics... Food for thought: Wouldn't it be nice if we had our compilers be able to compile unicode source files ... call them .ucpp... and define new operators in the C++ language... then we would be able to utilize these new operators to write code which looks ascetically pleasing and readable. Another benifit could be easier support internationalization of software. I'll digress. > - Allow implementation (or not) of any appropriate interdomain type transformations. > - Decouple the domain type information from the value types used to > represent the internal domain-specific information. This I also provided for in my simple example. Though kinda a cheesy example as "domain" is completely specified by the programmer and there is no automatic domain logic . > - Allow specification of a default value type for any domain type so > that unspecified templates (i.e., T<>) provide meaningful results. > - Allow specification of which domains are interconvertible as a > series of pairwise conversions. so you have a chain a->b->c->d change a and b, c, and d are changed... correct? This was in my example Should also allow for fanout // a-+->b // | // +->c-+->d // | // +->e // | // +->f and avoid recursion. a->b->c->a->a->b->c->a... you get the idea > - Allow specification of which domains support which operations so > that the compiler can seek an appropriate domain for arguments that > may (or may not) be directly usable. What happens when and operation cannot be found in a domain, but the programmer can or needs to specify one? Is it extensible? > The goal is to clearly define all these points of extension so that > the "real" types (e.g., probabilities or polynomials) can be > constructed on top of the Domain library, thereby simplifying the > specification of domain families for any application or library. The easier it is to provide new specifications for types and their transformations the better.... you'll never think of every domain and translation. Need to supply a clear path to adding new types, domains, and translations. > I have been using this to refactor the Probability library as a proof > of concept. As mentioned, most of what the old version could do, the > new one will also do. > There are a few issues with overloads that are > confusing to me, so help is welcome. How do I obtain the code and where is the problem? > Thus, I am certain that there is > some merit in this approach to a generic domain solution. However, I > am also certain that there are other ideas out there that could > improve this. Gerneric domain is exactly what I am after. We have type T1, T2, T3,....TN and we have to translate between them... What's the easiest way to specify this for the programmer? > Because of the interaction in development between the two libraries > (Domain and Probability) I haven't quite finished everything. I'll > try to roll them up for viewing shortly, though. > I look forward to continuing discussion, receiving input, and > discovering how these ideas might be put to use in other contexts. Context.... Let me speak to context... Let's say your one of thoes down to earth engineer types... you got to get your product out... you have all this incoming and out going data at multiple layers of the software form hardware<->driver<->user space lib<->executable<->network<->client and you have to translate between types for each interface... Bitfields... don't get me started on bit fields... Why is a bit such a degenerative type in C++ (try typeid(bit.in_a_bitfield).name() and wonder why you get back unsigned... would be nice to get the position info of where the bit or bits are withing a bit field) ... I'll digress again... any way you want to easily specify type conversions at each layer. You've received the event in the past and called the appropriate conversion routine after conversion routine and thought to yourself.. Hey is there any way to get rid of all of these calls to conversion functions in my callback routine... they're kinda making the code messy. Sure would be nice if I had a data_binding library where I could specify the types and specify the conversion functions and when the value arrives just set it and have the conversion take place bidirectionally. Then you write it up... think to yourself who might be able to use this... maybe those boost guys :-) Hope my input is helpful. Brain

4 12

[1.36.0 beta] Beta release available on SourceForge
by Beman Dawes 06 Aug '08

06 Aug '08

New libraries: Accumulators, Exception, Units, Unordered. Updated Libraries: Assign, Foreach, Interprocess, Intrusive, Math, Multi-index Containers, PtrContainer, Spirit, Thread, Xpressive, plus a bunch more. Many thanks to Daniel James, Rene Rivera, Marshall Clow, Eric Niebler, the testers, and all the others who helped to get this beta release together. The beta period will be approximately one week. Please post bug reports here, but also let us hear about success stories too! --Beman

3 3

[sandbox][move] Regular requirement
by Michael Marcin 06 Aug '08

06 Aug '08

I'm using the current move library in the sanbox by daniel james (which I believe is the 4th move emulation library I've used now). It seems to be very good so far and makes writing code that handles both move and copy a breeze. I hope this gets finalized and ready for review soon because a consistently used move emulation library would be a great aid to writing efficient libraries that work well together. However the documentation says that objects have to model the Regular concept in order to model the Movable concept. This seems unfortunate as Regular puts a lot of requirements on types that don't seem necessary to gain moving. It requires Assignable which requires a copy constructor and it requires EqualityComparable which seems unnecessary. As a matter of fact I'm currently using the library with types I derive from boost::noncopyable on msvc 2008 and it is working wonderfully. Can the Movable concept be relaxed to require only what is truly necessary? Thanks, Michael Marcin

3 3

fixed pt binary lib
by Neal Becker 06 Aug '08

06 Aug '08

I have the beginning of a fixed-pt binary lib. Fixed-pt is popular in DSP applications. It is integer arithmetic, but keeping track of the binary pt. It is built on top of constrained_value. It is small, so I include it here:

8 22

variant invariant
by Emil Dotchevski 05 Aug '08

05 Aug '08

Reading boost::variant's documentation: "If any bounded type is nothrow default-constructible (as indicated by boost::has_nothrow_constructor), the library guarantees variant will use only single storage and in-place construction for every bounded type in the variant. Note, however, that in the event of assignment failure, an unspecified nothrow default-constructible bounded type will be default-constructed in the left-hand side operand so as to preserve the never-empty guarantee." Do I read correctly that in an attempt to assign one variant object to another, the left-hand object _might_ silently change its type? This makes it very difficult for the user to enforce some useful invariants for types that have boost::variant members, which in my mind is very important. Wouldn't it be better to guarantee that operator= either succeeds or doesn't change the observable state of the left-hand side operand, even at the cost of memory allocation? In that case the other behavior may still be provided through a separate function. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

7 18

Why I hate subversion
by Eric Niebler 02 Aug '08

02 Aug '08

U boost/indirect_reference.hpp U boost/parameter.hpp svn: In directory 'boost' svn: Can't move 'boost/.svn/tmp/foreach.hpp.2.tmp' to 'boost/foreach.hpp': Permission denied ericne@ericne-xps ~/boost/org/trunk $ svn up svn: Checksum mismatch for 'boost/.svn/text-base/enable_shared_from_this.hpp.svn-base'; recorded: '12d8c5183a709a7699c13b312073c36c', actual: 'c89a6b23045ff8c89d2de74213d1649a' Does this ever happen to anybody else? I get this random corruption of my local subversion repository about once a month. -- Eric Niebler Boost Consulting www.boost-consulting.com

11 15

[unnullable_ptr] Proposal for a new library
by Angel Tsankov 02 Aug '08

02 Aug '08

Hello, Is there any interest in a class template which acts like a pointer and guarantees at compile time and at no CPU or memory cost (except when a call to any of its methods is not inlined) that the pointer is not null? One of the applications that I have found for this template is in defensive programming to eliminate the chances that dereferencing a pointer will result in undefined behaviour (when the pointer is null). Using this template is superior to any alternative method (that I know) to achieve the same result, since: (*) it consumes no CPU (in contrast to null checks); (*) the class template instances are copy constructible and copy assignable (in contrast to references which can also be used to guarantee unnullability); (*) it is natively supported by the language and provides a 'real' guarantee (in contrast to 'design by contract'); (*) supports the natural syntax for access to the wrapped resource (in constrast to boost::ref). Regards, Angel Tsankov

13 35

[shifted_ptr] STL support works at 90% (...!)
by Phil Bouchard 02 Aug '08

02 Aug '08

I've finalized the ad extremum idea of STL support of smart pointers such as shifted_ptr which is a good example to use because of the distinct types it is using as pointer types (T *, shifted<T> *, shifted_allocator::pointer, etc.). I have 2 patch files that can be used as an example to add support for real smart pointers using Gcc's STL. These are located in the bits/ folder. These are Gnu related but I wanted to share this here for objectivity. I have added special contructors in shifted_ptr that takes raw pointers (T *) instead of the type safe shifted<T> *. This is temporary until I add the proper casts inside the STL code. What else? I simplified shifted_allocator and fixed abominable bugs in shifted_ptr created by these temporary constructors added. Now I'm pretty dang happy about it... There are still some I need to fix and some more are yet to be found but it should be much easier now. Once again I am using shifted_ptr_test2.cpp as my main test application. Later, -Phil

1 2

Possible library submissions: fuzzy logic library, new container
by Alex Shafir 01 Aug '08

01 Aug '08

I am trying to determine if there might be any interest in a couple of possible library submissions. Both ideas were very useful and instrumental for many C++ development projects that I was doing for the last years. The fuzzy logic library is a simple, pure C++, optimized for speed, practical implementation of the fuzzy logic calculations that DOES NOT attempts to comply with the FCL(Fuzzy Control Language) standard (like IEC 1131). It CANNOT load FCL files. Instead similar to the Boost Spirit framework it provides a syntax that enables fuzzy logic rules to be written exclusively in C++. Compiled fuzzy model specifications are immediately executable. A snippet of what this syntax currently looks like is at the end of this message. The other idea is the “sparse array” container. Working for securities trading industry I used it innumerable number of times. It is useful in situations where there is a set of entities identified by integer(unsigned) numbers. Most often the numbers are identity keys in a database, a protocol field ids, etc. The potential range of the numbers makes it impractical to use a C++ array or the STL <vector>. On the other hand the average percentage of the keys that are really used in an application relative to the potential range is often less then 5% and there are huge holes of unused keys between zero and max(used key). The data elements or pointers to objects are kept in a structure similar to a balanced B-tree. Elements are directly accessed by an index operator. Access involves only a few arithmetic and redirection operations. When storing a new element that is outside of the range provided by exiting data structure the structure bilds itself up extending the indes range enough to accommodate a new index value. Existing data are never physically moved like in the STL vector. So, all references/pointers/iterators referencing existing elements are never invalidated. Feel free to comment. Fuzzy model syntax sample: ======================================== #include "TestModel.h" using namespace Fuzzy; // test model definition TestModel::TestModel(string file): Model(file), angle(-1), velocity(-1), speed(-1) { // fuzzy variables definitions created by the base class (Fuzzy::Model) // Input/Output methods; Input/Output arguments are refs // to double scalar variables Var& Angle = Input(angle); Var& Vlcty = Input(velocity); Var& Speed = Output(speed); // membership functions definitions created by fuzzy variables // Term method; Term method takes curve name as an argument; // cureve names are defined in the Fuzzy::Model curve definition // file MemFun& AngleNegHigh = Angle.Term("AngleNegHigh"); MemFun& AngleNegLow = Angle.Term("AngleNegLow"); MemFun& AngleZero = Angle.Term("AngleZero"); MemFun& AnglePosLow = Angle.Term("AnglePosLow"); MemFun& AnglePosHigh = Angle.Term("AnglePosHigh"); MemFun& VlctyNegHigh = Vlcty.Term("VelocityNegHigh"); MemFun& VlctyNegLow = Vlcty.Term("VelocityNegLow"); MemFun& VlctyZero = Vlcty.Term("VelocityZero"); MemFun& VlctyPosLow = Vlcty.Term("VelocityPosLow"); MemFun& VlctyPosHigh = Vlcty.Term("VelocityPosHigh"); MemFun& SpeedNegHigh = Speed.Term("AngleNegHigh"); MemFun& SpeedNegLow = Speed.Term("AngleNegLow"); MemFun& SpeedZero = Speed.Term("AngleZero"); MemFun& SpeedPosLow = Speed.Term("AnglePosLow"); MemFun& SpeedPosHigh = Speed.Term("AnglePosHigh"); // these are the model rules; syntax is pretty strightforward; // rules look like operator >> where lhs is the condition and // rhs is the conclusion; // lhs and rhs have to be in parens if they contain more then // one term because of the c++ operators precedence rules; // conclusion may be a comma separated list of output terms // in parens ((AngleZero and VlctyZero)or(AnglePosLow and VlctyNegLow)or(AngleNegLow and VlctyPosLow)) >> SpeedZero; ((AngleZero and VlctyNegLow)or(AngleNegLow and VlctyZero)) >> SpeedNegLow; ((AnglePosLow and VlctyZero)or(AngleZero and VlctyPosLow)) >> SpeedPosLow; ((AngleZero and VlctyNegHigh)or(AngleNegHigh and VlctyZero)) >> SpeedNegHigh; ((AnglePosHigh and VlctyZero)or(AngleZero and VlctyPosHigh)) >> SpeedPosHigh; } TestModel::~TestModel() { } void TestModel::run(double a, double v, double &s) { // we assign scalar variables to class members angle = a; velocity = v; speed = s; // then run the model // it should be pretty fast as it all designed to preallocate // all the needed large objects in the model constructor Model::run(); // and assign the values of output variables s = speed; }

3 2

dll-path feature
by brook＠biology.nmsu.edu 01 Aug '08

01 Aug '08

It seems that I need to use the dll-path feature to add an -rpath directive to the linker when my boost libraries are installed. This seems to be described (mostly) fairly clearly at http://www.boost.org/boost-build2/doc/html/bbv2/faq/dll-path.html What is not clear is where the feature should be invoked. My attempt to modify Jamroot to add <dll-path> to the boost-install rule failed in the sense that not rpath information makes it into the installed libraries. (The rest of this snippet is the original.). rule boost-install ( libraries * ) { package.install install : <dependency>/boost//install-headers $(install-requirements) : # No binaries : $(libraries) : # No headers, it's handled by the dependency ; install stage : $(libraries) : <location>$(BOOST_STAGE_LOCATE) <dll-path>/path/to/add/via/rpath ; local c = [ project.current ] ; local project-module = [ $(c).project-module ] ; module $(project-module) { explicit stage ; explicit install ; } } So, how is one supposed to invoke the <dll-path> feature in order to have -rpath added to the linking of libraries during their installation? Thanks for your help. Cheers, Brook

3 4

[release] xpressive bug fix
by Eric Niebler 01 Aug '08

01 Aug '08

What are the chances that I'll be able to merge a bug fix to the release branch? This one: http://svn.boost.org/trac/boost/ticket/2157 just came in, and I've already fixed it on trunk. Assuming that the next cycle of the trunk tests don't show anything amiss, would I be permitted to merge the fix? The bug will not cause crashes, but it will lead to incorrect results when matching the end-of-line assertion ($) against internal line breaks, which is fairly common usage scenario. I have high confidence in the fix. These are the relevant changesets: http://svn.boost.org/trac/boost/changeset/47899 http://svn.boost.org/trac/boost/changeset/47901 -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 3

1.36 documentation
by Daniel James 01 Aug '08

01 Aug '08

Hello everyone, Since the generated documentation isn't currently included in the snapshots, I've temporarily made it available here: http://www.calamity.org.uk/1.36/ Hopefully, the documentation should be integrated with the beta site soon after the beta release. Daniel

9 19

[swap] End-user allowed to add overloads to boost namespace?
by Niels Dekker - mail address until 2008-12-31 31 Jul '08

31 Jul '08

Is any end-user allowed to add her own overloads of existing Boost functions to the boost namespace? The boost::swap utility from Joseph Gauterin (recently moved to the trunk) allows the user to customize boost::swap for her class, by providing a swap function for her class within the namespace of the class. Internally boost::swap does the idiomatical "using std::swap; swap(left,right);", to allow finding such a user-provided swap function by argument-dependent lookup (ADL) <svn.boost.org/svn/boost/trunk/boost/utility/swap.hpp> Unfortunately some compilers don't fully supported ADL, as is shown by the mixed test results of swap/test/specialized_in_global.cpp and swap/test/specialized_in_other.cpp, at http://www.boost.org/development/tests/trunk/developer/utility-swap_.html ADL failures appear to occur for GCC 3.3.1 (PathScale), Intel C++ 8.1, MSVC 7.1 (2003), and Borland (up to 5.9.3). Once the boost::swap utility would be used by other Boost libraries, end users might want to add a custom overload of swap for their classes to the boost namespace. Especially when users would have to deal with lacking ADL support of their compiler. Would it be okay for them to do so? Or are there some moral objections, or technical issues, regarding a user-provided overload within the boost namespace? Kind regards, Niels PS Volodya, thanks for fixing swap/Jamfile.v2! -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

6 14

boost versus Apple's gcc 4.2
by Mat Marcus 31 Jul '08

31 Jul '08

On the boost users list, there was a discussion about some issues arising with boost versus gcc-4.2 on Apple systems. One interesting issue arises from the fact that Apple decoupled the gcc compiler version from the lib version. They "own" libstdc++, which they've kept at version 4.0 even when the 4.2 compiler. This breaks some assumptions in boost headers. I am reposting on the main developer list: ### Peter Dimov wrote: > Is the new Apple GCC documented somewhere? I wasn't able to find anything > related to a new assembler syntax or -fasm-blocks. Can you ask Apple to > explain the issue? Stock g++ 4.2.x compiles the code, so the problem must be > Apple-specific. Ok, I've got a little bit more information on the Apple gcc 4.2 situation. Here is a snippet from an email dialog between a user and an apple compiler engineer: user appears below with with prefix ">>" apple compiler engineer appears below with with prefix ">" >> Thank you very much for the detailed reply. >> Based on your information I deduce: >> >> 1) Using gcc 4.2 with 4.0 (c++) libraries is a supported >> configuration by Apple > > Right. > >> I then conclude that the C++ ABI is fully compatible between 4.0 and >> 4.2 > > Right. [snip, then user hypothesizes as to why there are problems with boost under gcc 4.2/libstdc++ 4.0 on current Apple systems] >> This is the case because boost assumes that a 4.2 compiler implies >> 4.2 libraries in flies such as boost/detail/atomic_count_gcc.hpp: >> >> #if (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 2)) >> # include <ext/atomicity.h> >> #else >> # include <bits/atomicity.h> >> #endif > > Yes, this is a bug or faulty assumption in boost. [snip] > The 4.2 library issue is a bug in Boost, not a problem with > our compiler. I'd suggest raising the issue on one of the boost > mailing lists and see what they say. Comments? Mat

4 4

[1.36 beta] Beta release candidate available
by Beman Dawes 31 Jul '08

31 Jul '08

Release candidate tarballs for the 1.36 beta are available at http://boost.cowic.de/rc/ Special thanks to Daniel James for generating the docs. Hopefully we can get the doc generations problems fixed quickly so that we can get back on a nightly release snapshot generation running again. I'd like to get feedback before uploading these to SourceForge. Please post a reply indicating success or problems encountered, being sure to indicate your platform and which file you downloaded. Thanks, --Beman

5 8

The --toolset option
by Vladimir Prus 31 Jul '08

31 Jul '08

Okay, now it's my turn to propose something to sneak into 1.36.0 at the last minute. Fortunately, it's only documentation change. For quite a while, both getting-started, and bjam --help mentioned --toolset option. This in practice, resulted in folks getting wrong analogy and trying to use --variant=debug --link=shared, etc. We agreed (on Boost.Build list), in principle, that we better remove --toolset from documentation, and use 'toolset=' instead -- which has exactly the same effect. So, I would like to commit the following Jamroot change to HEAD and merge to release branch. Any objections? I also would like to see the issue filed against getting-started: http://svn.boost.org/trac/boost/ticket/2050 fixed, and can provide a patch assuming release manager is fine with having this doc tweak merged into release branch, too. Opinions? Thanks, Volodya

3 2

range_ex: status?
by Mathias Gaunard 30 Jul '08

30 Jul '08

I'm writing some piece of software working that does a lot of data structures traversal and that really needed filtering of traversal etc. I thought I'd get that from Boost.Range, but I was surprised to see Boost.Range provides very little: all the good stuff (the range-based algorithms and adaptors) are in another library, range_ex, which isn't in the main distribution yet. Will this library be included in Boost soon? It's really great. As for the open issues, here are my opinions: - Output ranges: don't adaptors already output ranges? - Two input ranges, or a range and an iterator?: two ranges can do more - For any algorithm foo(container, args...), if foo(args...) is valid then it should be called - Null-termination of C-style strings: Isn't that up to Boost.Range to decide whether it's a range or not?

18 104

add new category in libs/libraries.htm
by Emil Dotchevski 30 Jul '08

30 Jul '08

Any opinions on adding a new category in libs/libraries.htm, Error Reporting, containing static_assert and the exception lib? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

4 12

[getting started][1.36] Please rebuild and merge.
by Daniel James 30 Jul '08

30 Jul '08

Please can somebody rebuild the getting started guide in trunk? Beman, is it be okay to merge this into the release branch? I've only updated the version numbers: http://svn.boost.org/trac/boost/changeset/47870/ I've also added a note to the release procedure wiki pages so hopefully this won't be missed in the future. thanks, Daniel

3 4

[hash] Broken link in docs
by John Maddock 30 Jul '08

30 Jul '08

While building the docs in /doc/ I see: Writing unordered/buckets.html for section(unordered.buckets) ID recommended on table: Methods for accessing the hash and equal... Writing unordered/hash_equality.html for section(unordered.hash_equality) ID recommended on table: Interface differences. Error: no ID for constraint linkend: unordered.rationale.equality_operator. ID recommended on table: Complexity Guarantees Writing unordered/comparison.html for section(unordered.comparison) Writing unordered/rationale.html for section(unordered.rationale) Looks like a broken link? John.

2 1

remove_pointer and pointers to members?
by John Maddock 29 Jul '08

29 Jul '08

Folks, I'm trying to decide how to fix this bug report: https://svn.boost.org/trac/boost/ticket/2011 Basically what should: remove_pointer<int (foo::*)>::type be? Should it produce an int, or have no effect? TR1 explicitly says that it has no effect, so I guess I vote to stick with that behaviour. In which case, anyone object to a remove_member_pointer trait that transforms: int (foo::*) --> int int (foo::*)(double) --> int (double) etc. It's also tempting to add a "member_object" trait at the same time that transforms: int (foo::*) --> foo int (foo::*)(double) --> foo thoughts? Thanks, John.

5 9

Test machines available
by Ruediger Berlich 29 Jul '08

29 Jul '08

Hi there, I was wondering whether there would be a need for additional systems for automated, nightly builds. My employer would agree to make a few (3-4) machines available, with Linux-based operating systems. This would be a VMWare ESX-based setup, although on high-performance hardware (8-core blades). I would personally be most interested in a test environment with the OpenSUSE 11 64 bit / g++ 4.3.1 combo. It might be possible to also have an OpenSolaris/Intel installation there, or an installation with Intel's C++ compiler. A pre-condition would be that no external access to the machines is needed, i.e. it would not be possible for Boost members to log in. Instead, I would set up the test environment as needed, and of course it would be possible for these machines to contact the outside world and transmit test results. Thus my question, what needs to be done to set up such a test environment. Note that I cannot give a guaranty for long-term availability, as a) I do not know how much work is involved in running such an environment and b) it might become necessary for the systems to be used in other contexts. If this turns out to be pretty much self-hosting (i.e. the build-environment is self-sustained on a normally configured Linux system), I would aim to ensure that the systems are available for a longer period. Best Regards, Ruediger /*************************************************************************/ The Steinbuch Centre for Computing of Karlsruhe Institute of Technology (the Cooperation of Forschungszentrum Karlsruhe GmbH and Universitaet Karlsruhe TH) will run its annual GridKa School from September 8th to 12th, 2008. Please find further information at http://www.fzk.de/gks08 . /*************************************************************************/ Forschungszentrum Karlsruhe GmbH Sitz: Weberstraße 5 76133 Karlsruhe Amtsgericht Mannheim HRB 100302 Vorsitzende des Aufsichtsrats: Baerbel Brumme-Bothe Vors. der Geschäftsführung: Prof. Dr. Eberhard Umbach

4 10

[1.37] When this will start?
by vicente.botet 29 Jul '08

29 Jul '08

Hi, Release 1.36 will have soon 2 weeks behind schedule. In order to maintain a quarterly release, when do you plan to start the 1.37 release? IMO it is time to start with it (1/08/2008), but without a named branch by release this is impossible. Could you share with us which is the plan to avoid that the quarterly release become a wish? Vicente

2 1

All tools code frozen!
by Rene Rivera 29 Jul '08

29 Jul '08

Since I don't enjoy reverting changes when I don't have the time (I'm in the middle of my own product release). And since Boost is nearing the end of a release cycle. *ALL* tool changes are hereby *FROZEN* except for emergency fixes. Any changes must be approved by Beman or myself. And such changes must include making sure Boost testing runs adequately in *both* a Windows platform and a Unix platform. This means going to the boost-root/status directory and running the tests for *at least one* library, but preferably all of them. Thank you for paying attention. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

8 12

[iostreams] File times on POSIX systems
by Markus Schöpflin 29 Jul '08

29 Jul '08

Hello, currently iostreams has a number of failures on POSIX systems because of the use of the non-existent function futimes(). futimes() conforms to 4.2BSD and is unknown to POSIX, which only has utime() to set file access and modification times. Unfortunately utime() works in term of path names and not file descriptors, and I'm not aware of any suitable replacement, so perhaps the interface for the functionality in question needs to be changed. Regards, Markus

1 1

[spirit] files missing on trunk
by Juergen Hunold 29 Jul '08

29 Jul '08

Hi ! It seems that the files changed/added in revision 47602 (see http://svn.boost.org/trac/boost/changeset/47602 ) are missing from trunk and are causing the regression tests to fail. (at least locally here...) Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

[Serialization] [1.36.0] extended_type_info_typeid::destroy should use boost::serialization::access
by Doug Gregor 28 Jul '08

28 Jul '08

Somewhere between Boost 1.35.0 and 1.36.0, Boost.Serialization lost the ability to (de-)serialize a pointer to a class with a protected or private destructor. The problem is in extended_type_info_typeid::destroy, which tries to delete a pointer directly rather than using boost::serialization::access::destroy. This is unfortunate, because it's breaking a use of the serialization library in VTK. The patch below fixes the problem and passes all regression tests. Okay to commit to trunk and the 1.36.0 branch? - Doug Index: extended_type_info_typeid.hpp =================================================================== --- extended_type_info_typeid.hpp (revision 47849) +++ extended_type_info_typeid.hpp (working copy) @@ -28,6 +28,7 @@ #include <boost/type_traits/is_polymorphic.hpp> #include <boost/type_traits/remove_const.hpp> +#include <boost/serialization/access.hpp> #include <boost/serialization/singleton.hpp> #include <boost/serialization/extended_type_info.hpp> #include <boost/serialization/factory.hpp> @@ -113,7 +114,7 @@ public: } } void destroy(void const * const p) const{ - delete static_cast<T const *>(p) ; + boost::serialization::access::destroy(static_cast<T const *>(p)); } };

2 2

Question about boost.extension
by Noah Roberts 28 Jul '08

28 Jul '08

Does this library address the problems associated with calling conventions when using different compilers? Can I compile an application with one compiler and allow users to provide plugins compiled with another? I have my doubts that this is even possible to solve, but I ask anyway.

2 2

[filesystem] two-minute tutorial uses deprecated functions
by Michael Marcin 28 Jul '08

28 Jul '08

The two-minute tutorial section of the filesystem documentation calls leaf() from a dereferenced directory_iterator. The reference documentation shows that dereferencing a directory_iterator yields a directory_entry but the reference documentation for directory_entry shows no leaf member. Eventually I had to track it down in the source code and found out that leaf does exist but is deprecated and not documented. It is probably bad to have the introduction to a library use undocumented functions. Thanks, Michael Marcin

1 0

data_binding library for boost... Any interest?
by Brian Davis 27 Jul '08

27 Jul '08

I looked through boost and if there is a library or facility for data binding in boost I could not find it... So I created and am submitting a simple example for review. Please take a look and give some feedback. I understand that there is quiet a process of review before a library is included in boost. If there is interest or if there is already on going work on the concept than I am interested in helping. Here goes: Data binding should allow for 1 value of primitive type to be changed in code and have 1 to N values be modified based on the event and optional conversion functions. i.e. fanout should be allowed Data binding should allow for cascading changes. Where a->b->c->d where -> represents a binding link when 'a' changes 'c', 'b', and 'd' should change. Data binding should be recursion save where a->b->c->a where a change in 'a' causes a change in 'c', but will not cause a recursive change in 'a' creating a recursive loop. Data binding would be useful in the dataflow library and for work being done on cppgui or for that fact any UI development. This is my first submittal to this list so please bear with me. I have taken the liberty to add the boost license to this code... so it is boost's if the project so chooses to incorporate or enhance the concept. I am not the originator of data binding concept and make no claim to this. I am only providing a simple example for discussion and hopefull inclusion of data binding concept in boost and ....ultimately modify the C++ compiler to provide for a lighter weight solution (events based on modifications of integral types) - Ouch ... yes I know what I am asking here... see the last part of the example output for why I ask this. // Start snip bind_value.hpp ======================================= // // (C) Copyright Brian Davis. // // Distributed under the Boost Software License, Version 1.0. (See accompanying // file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) // // Revision history: // 19 July 2008 // Created - to support and assist in dataflow and dataflow concepts // // This is not currently part of boost! The only reason for the above copyright is to // keep these concepts part of the boost development. boost::data_binding is not // officially part of boost. The goal of this demo code is to elaborate on data binding // and give a simple implementation and an example on how the concept can be applied within C++. #ifndef BOOST_DATA_BINDING_HPP #include <boost/cast.hpp> #include <boost/function.hpp> #include <boost/bind.hpp> #include <boost/foreach.hpp> #include <vector> namespace boost { namespace data_binding { template < class T1, class T2> class bind_values; template <class T> class value { friend class bind_values< class T1, class T2>; public: typedef boost::function< T& (T&) > set_value_function; std::vector<set_value_function> set_value_functions; T& mv_value; // To prevent infinite recursion on a group of three linked variables a->b->c->a. bool mv_entered; protected: private: public: value( T& invalue ) : mv_value( invalue ){ mv_entered = false; }; // Sets require action event handling to update value of binded type.. gets are transparent value& operator=( T& rhs ) { if( set_value_functions.size() && !mv_entered ) { mv_entered = true; BOOST_FOREACH( set_value_function set_value, set_value_functions ) { mv_value = set_value( rhs ); } } else { // Otherwise simple type cast convert mv_value = boost::numeric_cast<T>( rhs ); } mv_entered = false; return *this; } value& operator=( T rhs ) { if( set_value_functions.size() && !mv_entered ) { mv_entered = true; BOOST_FOREACH( set_value_function set_value, set_value_functions ) { mv_value = set_value( rhs ); } } else { // Otherwise simple type cast convert mv_value = boost::numeric_cast<T>( rhs ); } mv_entered = false; return *this; } void add_set_function( set_value_function set_function ) { set_value_functions.push_back( set_function ); } T& operator&( value<T>& value ) { return value.mv_value; } protected: private: }; template < class T1, class T2> class bind_values { friend class value<T1>; friend class value<T2>; public: typedef T1 type1; typedef T2 type2; typedef boost::function< T1& (T1, T2)> convert_to_function; typedef boost::function< T2& (T2, T1)> convert_from_function; convert_to_function convert_to; convert_from_function convert_from; protected: value<T1>& mv_value1; value<T2>& mv_value2; private: public: bind_values ( value<T1>& value1, value<T2>& value2, convert_to_function convertTo, convert_from_function convertFrom ) : convert_to(convertTo), convert_from(convertFrom), mv_value1( value1 ), mv_value2( value2 ) { // Hook up set for value 1 mv_value1.add_set_function( boost::bind( &bind_values::set_value1, this, _1 ) ); // Hook up set for value 2 mv_value2.add_set_function( boost::bind( &bind_values::set_value2, this, _1 ) ); } bind_values( value<T1>& value1, value<T2>& value2 ) : mv_value1( value1 ), mv_value2( value2 ) { // Hook up set for value 1 mv_value1.set_value = boost::bind( &bind_values::set_value1, _1 ); // Hook up set for value 2 mv_value2.set_value = boost::bind( &bind_values::set_value2, _1 ); } protected: T1& set_value1( T1& value ) { if( convert_from ) { // Convert and set value 2 mv_value2 = boost::numeric_cast<T2>( convert_from( mv_value2.mv_value, value ) ); } else { // Otherwise simple type cast convert mv_value2 = boost::numeric_cast<T2>( value ); } // return the value unmodified to the original container return value; } T2& set_value2( T2& value ) { if( convert_to ) { // Convert and set value 1 mv_value1 = boost::numeric_cast<T1>( convert_to( mv_value1.mv_value, value ) ); } else { // Otherwise simple type cast convert mv_value1 = boost::numeric_cast<T1>( value ); } // return the value unmodified to the original container return value; } private: }; } } // namespace boost::data_binding template <class T> std::ostream& operator<<( std::ostream& os, boost::data_binding::value<T>& rhs ) { os << rhs.mv_value;; return os; } #endif // end snip bind_value.hpp ======================================= // Start snip bind_value_test.hpp ======================================= // // (C) Copyright Brian Davis. // // Distributed under the Boost Software License, Version 1.0. (See accompanying // file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) // // Revision history: // 19 July 2008 // Created - to support and assist in dataflow and dataflow concepts // // This is not currently part of boost! The only reason for the above copyright is to // keep these concepts part of the boost development. boost::data_binding is not // officially part of boost. The goal of this demo code is to elaborate on data binding // and give a simple implementation and an example on how the concept can be applied within C++. #include <iostream> #include <boost/cstdint.hpp> #include <boost/bind.hpp> #include <boost/data_binding/bind_value.hpp> #define MAX_CELSIUS 100 #define MIN_CELSIUS -17.8 #define MAX_RAW_SENSOR_COUNTS 4095 // use of a class is not necessary it is only shown to prove it is possible. It may // make more sense just to have conversion functions class AClass_That_Is_A_Converter { public: protected: boost::data_binding::value<boost::uint32_t> rawCelsiusCountsFromSensor; boost::data_binding::value<float> calibratedCelsiusDataFromSensor; boost::data_binding::value<float> calibratedFahrenheit; boost::uint32_t rawSensorValue; float fahrenheit; float celsius; boost::data_binding::bind_values<float, boost::uint32_t> mv_celsiusToSensorBinder; boost::data_binding::bind_values<float, float> mv_celsiusToFahrenheitBinder; private: public: AClass_That_Is_A_Converter( void ) : rawCelsiusCountsFromSensor(rawSensorValue), calibratedCelsiusDataFromSensor(celsius), calibratedFahrenheit(fahrenheit), mv_celsiusToSensorBinder ( calibratedCelsiusDataFromSensor, rawCelsiusCountsFromSensor, boost::bind( &AClass_That_Is_A_Converter::convertCelsiusRawToCalibrated, this, _1, _2 ), boost::bind( &AClass_That_Is_A_Converter::convertCelsiusCalibratedToRaw, this, _1, _2 ) ), mv_celsiusToFahrenheitBinder ( calibratedCelsiusDataFromSensor, calibratedFahrenheit, boost::bind( &AClass_That_Is_A_Converter::convertFahrenheitToCelsius, this, _1, _2 ), boost::bind( &AClass_That_Is_A_Converter::convertCelsiusToFahrenheit, this, _1, _2 ) ) {} virtual ~AClass_That_Is_A_Converter( void ){} void test( void ) { std::cout << "Starting test of data binding" << std::endl; try { std::cout<< "Note raw temp represents the raw value of an Analog to Digital Converter" << std::endl; std::cout<< "The range is from 0-4095 which represents -17.8 - 100 degrees on the Celsius" << std::endl; std::cout<< "scale and 0 - 212 degrees on the Fahrenheit" << std::endl; std::cout<< "Setting calibratedFahrenheit to 70.0 degrees fahrenheit" << std::endl; std::cout<< "calibratedFahrenheit = 70.0f;" << std::endl; calibratedFahrenheit = 70.0f; std::cout << "What does the celsius value contain? ... should be ~21.1" << std::endl; showValues(); std::cout << "Now change the raw sensor value and see what happens to Celsius and Fahrenheit" << std::endl; std::cout<< "rawCelsiusCountsFromSensor = 4095;" << std::endl; rawCelsiusCountsFromSensor = 4095; std::cout << "Celsius should equal ~100" << std::endl; std::cout << "Fahrenheit should equal ~212" << std::endl; showValues(); std::cout << "Now change celsius see what happens to raw and farenheit" << std::endl; std::cout<< "calibratedCelsiusDataFromSensor = 32.2;" << std::endl; calibratedCelsiusDataFromSensor = 32.2; std::cout << "Fahrenheit should equal ~90 degress" << std::endl; showValues(); std::cout << "Note changing original values will not have any affect in C++ " << std::endl; std::cout << "this makes me sad :-( as a class wrapper and operator overloading" << std::endl; std::cout << "is necessary... without changing the compiler... hint.... hint..." << std::endl; std::cout << "fahrenheit = 10;" << std::endl; fahrenheit = 10; showValues(); std::cout << "No change in values :-( !!!" << std::endl; // Note one to many fanout is possible and the example shows 1 to 2 fanout with Celsius // fanning out to Raw and Fahrenheit values. A more advanced implementation is also possible // which includes the use of the lamda library and place holders. This is just a simple // example which I hope will "prime the pump" for work on a data_binding library with in // the Boost development. Most direct use for this library is within data_flow library. // Another use is within the cppgui library which would allow modification of data to directly // affect values of UI controls and display values. } catch( std::exception& ex ) { std::cout << "Failed with exception: " << ex.what(); } std::cout << "End of data binding test" << std::endl; } void showValues( void ) { std::cout << std::endl; std::cout << "Fahrenheit : " << calibratedFahrenheit << std::endl; std::cout << "Celsius : " << calibratedCelsiusDataFromSensor << std::endl; std::cout << "Raw Temp To/From Sensor A/D converter : " << rawCelsiusCountsFromSensor << std::endl; std::cout << std::endl; std::cout << "fahrenheit : " << fahrenheit << std::endl; std::cout << "celsius : " << celsius << std::endl; std::cout << "rawSensorValue : " << rawSensorValue << std::endl; std::cout << std::endl; std::cout << "====================================================================" << std::endl; } protected: float& convertFahrenheitToCelsius ( float& celsius , float& fahrenheit ) { return celsius = ((fahrenheit - 32.0) * 5.0) / 9.0; } float& convertCelsiusToFahrenheit ( float& fahrenheit, float& celsius ) { return fahrenheit = celsius * (9.0 / 5.0) + 32.0; } float& convertCelsiusRawToCalibrated ( float& calibratedValue, boost::uint32_t& rawValue ) { return calibratedValue = ( MAX_CELSIUS - MIN_CELSIUS ) * (rawValue / MAX_RAW_SENSOR_COUNTS) + MIN_CELSIUS; } boost::uint32_t& convertCelsiusCalibratedToRaw ( boost::uint32_t& rawValue, float& calibratedValue ) { // Raw is from 0 to 4095 ( a 12 bit number of an // Analog to Digital converter // map zero (fahrenheit) to water boiling to raw value of 4095 return rawValue = MAX_RAW_SENSOR_COUNTS * ( calibratedValue - MIN_CELSIUS) / ( MAX_CELSIUS - MIN_CELSIUS ); } private: }; int main(int argc, char **argv) { AClass_That_Is_A_Converter anExampleOfDataBinding; anExampleOfDataBinding.test(); } // end snip bind_value_test.hpp ======================================= // Start snip program output ======================================= Starting test of data binding Note raw temp represents the raw value of an Analog to Digital Converter The range is from 0-4095 which represents -17.8 - 100 degrees on the Celsius scale and 0 - 212 degrees on the Fahrenheit Setting calibratedFahrenheit to 70.0 degrees fahrenheit calibratedFahrenheit = 70.0f; What does the celsius value contain? ... should be ~21.1 Fahrenheit : 70 Celsius : 21.1111 Raw Temp To/From Sensor A/D converter : 1352 fahrenheit : 70 celsius : 21.1111 rawSensorValue : 1352 ==================================================================== Now change the raw sensor value and see what happens to Celsius and Fahrenheit rawCelsiusCountsFromSensor = 4095; Celsius should equal ~100 Fahrenheit should equal ~212 Fahrenheit : 212 Celsius : 100 Raw Temp To/From Sensor A/D converter : 4095 fahrenheit : 212 celsius : 100 rawSensorValue : 4095 ==================================================================== Now change celsius see what happens to raw and farenheit calibratedCelsiusDataFromSensor = 32.2; Fahrenheit should equal ~90 degress Fahrenheit : 89.96 Celsius : 32.2 Raw Temp To/From Sensor A/D converter : 1738 fahrenheit : 89.96 celsius : 32.2 rawSensorValue : 1738 ==================================================================== Note changing original values will not have any affect in C++ this makes me sad :-( as a class wrapper and operator overloading is necessary... without changing the compiler... hint.... hint... fahrenheit = 10; Fahrenheit : 10 Celsius : 32.2 Raw Temp To/From Sensor A/D converter : 1738 fahrenheit : 10 celsius : 32.2 rawSensorValue : 1738 ==================================================================== No change in values :-( !!! End of data binding test // End snip program output ======================================= This was done to assist Sjepan Rajko in his work on the dataflow library (he beat me to it :-) ). Dataflow provides the event model data_binding provides the means to do data conversion between events. Brian.

5 10

[implicit_cast]: No docs?
by Sean Hunt 27 Jul '08

27 Jul '08

implicit_cast doesn't seem to have any documentation anywhere that I can find. Is this intentional, or merely an oversight? Sean Hunt

2 1

[math][bcp] rational.hpp doesn't get processed well by bcp
by Stjepan Rajko 26 Jul '08

26 Jul '08

Hello, boost/math/tools/rational.hpp (in trunk, at least) includes files by constructing a macro, e.g.: # define BOOST_HEADER() <BOOST_JOIN(boost/math/tools/detail/polynomial_horner1_, BOOST_MATH_MAX_POLY_ORDER).hpp> # include BOOST_HEADER() bpc doesn't seem to pick up dependencies that are included in this fashion - is it possible to include something into rational.hpp to serve as a hint to bcp on what all files might be included? Thanks, Stjepan

3 3

How do we handle copyrights here? (Fwd: blanket-permission.txt)
by Daryle Walker 26 Jul '08

26 Jul '08

I noticed that some of my code is showing up in the inspection report. Specifically, "boost/math/common_factor_rt.hpp" and a lot of Boost.Rational. When I looked at the former file, I remembered why I never corrected those files before: I share the copyright for those files with Paul Moore, and I've never been able to find him again. (See my latest attempt below.) Unless someone else here knows how to contact him (if he's still alive), what do we do? Do we special-case those files to be skipped by the inspector? Do we try re- implementing the interface in those files so they won't contain Paul's work? Begin forwarded message: > From: "Paul Moore" <paul.moore(a)centrify.com> > Date: July 25, 2008 2:15:06 PM EDT > To: "Daryle Walker" <darylew(a)hotmail.com> > Subject: RE: [boost] blanket-permission.txt > > That's not me > > -----Original Message----- > From: Daryle Walker [mailto:darylew@hotmail.com] > Sent: Friday, July 25, 2008 11:08 AM > To: Paul Moore > Subject: [boost] blanket-permission.txt > > I got this address from looking at old Boost mailing list posts. If > you're that same Paul Moore, I wonder if you would consider adding > your > name to the BOOST_ROOT/more/blanket-permission.txt list, to allow any > material that has your copyright, in whole or in part, be shifted over > to the Boost Software License. > > I ask this because I noticed that some files I maintain are under a > list > with license check problems. (The Boost files are run over with a > batch > script that looks for such administrative problems.) I wondered why I > never fixed that problem, then when I read the file I remembered > that I > never changed it because I couldn't find you to ask permission. (The > file in particular is "boost/math/ common_factor_rt.hpp", which we > share > copyright on.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

Help with deficient compilers?
by Daryle Walker 26 Jul '08

26 Jul '08

I need help with fixing code in BOOST_ROOT/libs/integer/test/ integer_test.cpp. It works fine on my computer, but other ones are giving errors. I have some guesses on what's wrong, but I need suggestions on what the fixes should be. 1. I have a custom meta-function like: //========================= typedef boost::mpl::vector<unsigned char, unsigned short, unsigned int, unsigned long long> distinct_unsigned_types; typedef boost::mpl::transform< distinct_unsigned_types, boost::make_signed< boost::mpl::_1 > >::type distinct_signed_types; // List the digit counts for each integral type template < typename T > struct digits_of : boost::mpl::int_< std::numeric_limits<T>::digits > { }; typedef boost::mpl::transform< distinct_unsigned_types, digits_of< boost::mpl::_1 > >::type distinct_integral_bit_counts; //========================= I noticed that supplied meta-functions, like boost.make_unsigned, use macros in their implementations, instead of the straight implementation I use in digits_of. Now MPL says that its machinery will make sure that straight implementations work. However, I don't think it's successful on deficient compilers. Maybe I should structure digits_of with all the work-around macros. How? (I don't want to just look at the headers and guess how they work.) 2. I don't think I have SFINAE selection correct: //========================= #ifndef BOOST_NO_SFINAE template < typename ValueT, template<ValueT> class Tmpl, ValueT Value > bool print_out_template( Tmpl<Value> const &, ValueT setting, char const *template_pre_name, char const *template_post_name, typename Tmpl<Value>::type *unused = 0 ) { // Too bad the type-id expression couldn't use the compact form "*unused", // but type-ids of dereferenced null pointers throw by order of C ++ 2003, // sect. 5.2.8, para. 2 (although the result is not conceptually needed). PRIVATE_SHOW_MESSAGE( "This is " << template_pre_name << setting << template_post_name << " specialization, with type '" << typeid(typename Tmpl<Value>::type).name() << "'." ); return true; } template < typename ValueT, typename T > bool print_out_template( T const &, ValueT setting, char const *template_pre_name, char const *template_post_name ) { PRIVATE_SHOW_MESSAGE( "Looking for " << template_pre_name << setting << template_post_name << " specialization? It doesn't exist." ); return false; } #else #error "These tests cannot work without Substitution-Failure-Is-Not- An-Error" #endif //========================= The BOOST_NO_SFINAE guards didn't help, compilers still choked on this code. (I guess I'll remove those guards later.) I think that any type that doesn't have an inner "type" will only choose the false- return case. On my computer, types with an inner "type" will choose the true return case, with that case being given priority. The reports are giving errors where, when given a type with an inner "type", the two cases are considered equal, leading to an ambiguity error. How do I restructure this code? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

Boost.Spirit based C++ parser
by Bruce Trask 26 Jul '08

26 Jul '08

// note to moderator, I am reposting as my original post seemed have ended up buried in "1.36 documentation" thread. Ok to repost below? Hi, I came across this wiki discussion: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSpiritC… Did this ever move forward or materialize? Thanks in advance. Regards, Bruce

1 0

boost::coroutines and boost::asio
by atkinson julian 26 Jul '08

26 Jul '08

Hi, the combination of asio and coroutines would seem to represent a little bit of magic (layering a linear code model over an async event framework and without the attendant issues involved in multithreading). However the coroutine library seems to be exception throwing in an unanticipated way when performing a wait on a future<> during the execution of an asio async operation. I am following the documention and am reasonably familiar with asio from other projects - but have only just worked through some of the examples from the coroutines documention. i am using the vault freeze version of coroutines from 2006 - i understand from perusing these lists that the library author is currently rewritting boost::coroutine around a continuation framework to simplify and in the hope that the library may be an official boost inclusion. Much kudos for contributing to c++ in a significant way ;-) the documentation seems to have some errors http://www.crystalclearsoftware.com/soc/coroutine/coroutine/asio.html - guidance is given to use shared_coroutine in preference to coroutine in asio context although this is not present in the example - asio uses the boost::system error classes in the boost namespace when not freestanding - the example calls wait() on source which is a socket type rather than a future I have attempted to work up an example which looks logical - but cant get around the throw that occurs at /boost/coroutine/detail/context_base.hpp:213 // linux 2.6.23, g++ (GCC) 4.1.2 // g++ -g main.cpp -lboost_coroutine-mt -lboost_system-mt #include <iostream> #include <boost/bind.hpp> #include <boost/ref.hpp> #include <boost/coroutine/coroutine.hpp> #include <boost/coroutine/generator.hpp> #include <boost/coroutine/future.hpp> #include <boost/asio.hpp> namespace coro = boost::coroutines; using namespace coro; typedef boost::asio::io_service service_type; //typedef coro::coroutine< void()> foo_coroutine_type; //typedef coro::coroutine< void( service_type &service)> foo_coroutine_type; typedef coro::shared_coroutine< void( service_type &service)> foo_coroutine_type; void foo( foo_coroutine_type::self &self, service_type &service) { typedef boost::system::error_code error_type; typedef boost::asio::ip::tcp::resolver::query query_type; typedef boost::asio::ip::tcp::resolver::iterator iterator_type; boost::asio::ip::tcp::resolver resolver( service); query_type query( "www.boost.org", 80 ); coro::future< error_type, iterator_type> future( self); resolver.async_resolve( query, coro::make_callback( future)); assert( !future); // wait throws here --> /boost/coroutine/detail/context_base.hpp:213 coro::wait( future); assert( future); error_type &error = future->get< 0>(); if( error) std::cout << "error resolving " << error.message() << std::endl; else { iterator_type ip = future->get< 1>(); while( ip != iterator_type()) std::cout << ip->endpoint() << std::endl; } } int main() { service_type service; foo_coroutine_type cfoo( boost::bind( &foo, _1, boost::ref( service))); cfoo(); // service.post( boost::bind( &foo_coroutine_type::operator(void ), &cfoo)); service.run(); }

4 4

Phoenix in 1.35.0
by Robert Jones 26 Jul '08

26 Jul '08

My understanding of the state of play with Phoenix is that the lovely Phoenix 2.0 is part of the not-yet-released Boost 1.36.0, and that the current release of Boost, 1.35.0 hosts Phoenix 1.2. Phoenix 2.0 has lovely documentation at http://spirit.sourceforge.net/dl_docs/phoenix-2/libs/spirit/phoenix/doc/htm… but the corresponding documentation for V1.2, at http://www.boost.org/doc/libs/1_35_0/libs/spirit/phoenix/index.html is buried inside the Spirit docs, and is not nearly as good as the v2.0 documentation. In particular the v1.2 docs are very quiet about specific include file paths, which have also changed significantly for v2.0. Is there anything I've missed in all this? ----------- Also looking through the documentation of Boost libraries in general, the quality varies widely. Am I correct in believing this is due to whether the various library authors have found time to write quality documentation? Regards, Rob. -- ACCU - Professionalism in programming - http://www.accu.org

6 9

[1.36.0] Beta release imminent
by Beman Dawes 26 Jul '08

26 Jul '08

The plan is to build the 1.36.0 beta release Sunday. Developers who have permission to make last minute fixes and docs updates should commit those changes by midnight Saturday, UTC. --Beman

5 10

circular_buffer update - merge with 1.36?
by Jan Gaspar 26 Jul '08

26 Jul '08

Hi, I have updated the circular_buffer library in the trunk (I was not able to do it earlier as I have been very busy in the past few weeks). Here are the release notes: - Changed behaviour of the circular_buffer(const allocator_type&) constructor. Since this version the constructor does not allocate any memory and both capacity and size are set to zero. - Added new methods is_linearized() and rotate(const_iterator). - Fixed bugs: #1987 Patch to make circular_buffer.hpp #includes absolute. #1919 Default constructed circular buffer throws std::bad_alloc. #1852 Copy constructor does not copy capacity. The tests passed on trunk (I made the update on Wednesday so it was included in the Friday's report). Not sure it is possible at this stage but it would be great if I can merge it into the release. There was a merge done by Thorsten several days ago but it didn't include the documentation changes (I don't blame him, he did the best he could). So now there is a discrepancy between the code and the documentation in the release branch. Jan __________________________________________________________ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

1 0

[spirit2] User experience and concerns
by Zach Laine 25 Jul '08

25 Jul '08

I've been eagerly anticipating the new version of Spirit ever since BoostCon 07. I've been using the code from the release branch to play around with it a bit, and I have a few concerns about its usability. I specifically have been using it to replace some rather ugly parsing code in an existing library. This code parses tagged text for use in a GUI, e.g. "Some text, <i>partially italicized</i>." This is very similar to the mini_xml example in the docs, so I used that as a starting point. There are some key differences between the simple_xml format and my needs, and as soon as I started deviating from the example too far I started having troubles. The differences are: 1) A tag can have parameters, and they don't look exactly like xml attributes, e.g. "<color 255 255 255 127>translucent white text</color>". 2) The "<pre>" tag is special. It turns off recognition of all future tags until the next "</pre>" end-tag is seen. 3) Stray "<" characters in the non-tag parts of the input are fine. 1) and 2) were fairly straightforward to implement as changes to simple_xml, but 3) has so far eluded me. 3) requires that all ">" sequence operators be changed to ">>" in the tagged-text parsing, so that more extensive backtracking can be done to ensure a stray "<" is not actually part of a tag. I'll summarize briefly the problems I had in terms of surprises, counterintuitive interfaces, and compilation failures that left me nonplussed. I've attached the full source (only one file, called "test.cpp"), and there are numerous comments in that code that are more direct and explicit. All my efforts were done with various recent revisions, most recently HEAD at the time of this writing -- 47802. Everything was done on a Linux box with GCC 4.1.2. - Auto-assignment seems to work fine for simple expressions, and fail for only slightly more complicated ones that the user would not expect. See Line 61. - Alternative expressions do not seem to work in a greedy fashion in all cases. See Line 70. - The rules for whether a character parser has an attribute or not are sure to seem arbitrary to everyday users. See Line 83. - In at least one case, a rule whose attribute was explicitly declared to be a type I defined (TaggedText) stubbornly insisted its attribute was std::string. See line 117. - Changing the ">" sequence operators (which seem to work nicely with "%=") to ">>" sequence operators makes the use of "%=" produce compilation errors. This forces one to resort to using semantic actions like in Spirit 1. See Line 124. On a different note, two of the Qi examples do not compile. They are actions and calc3_lexer. I did not try to compile the others (Karma, etc.). All tests (for everything -- not just Qi) pass. Zach Laine

2 1

[concept_check] Problem with concept checks and overloads
by Bruno Lalande 25 Jul '08

25 Jul '08

Hello, Barend and I have been facing a problem while integrating concept checks into the Geometry Library. In order to simplify the problem, I reduced it to a very simple test case: template <typename T> struct foo {}; template <class X> struct DummyConcept { typedef typename X::something something; }; template<typename T> BOOST_CONCEPT_REQUIRES(((DummyConcept<T>)), (void)) func(T&) { std::cout << "first overload" << std::endl; } template<typename T> void func(foo<T>) { std::cout << "second overload" << std::endl; } int main() { func(foo<int>()); return 0; } This code doesn't compile because the compiler tries to check foo<int> against the DummyConcept, even though it's supposed to select the second overload, which doesn't carry any concept requirement. Removing the check makes it compile and a run displays "second overload". If I put back the check and add a "typedef void something" into foo, it compiles and displays the same thing. So I deduce that, more generally, a compiler compiles the return type of every candidate overload before selecting the right one, and that's why we have this issue with concept checking. So I have 2 questions: - would there be any way to differ the check until after the right overload has been selected, thus doing the check only for that overload? - if no, is there a better workaround than replacing BOOST_CONCEPT_REQUIRES by a simple BOOST_ASSERT inside the function? Thanks in advance. Bruno

3 10

Re: [boost] [1.36] release blurb? [plus a tip for the authors]
by JOAQUIN M. LOPEZ MUÑOZ 25 Jul '08

25 Jul '08

_______________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de Daniel James [daniel_james(a)fmail.co.uk] Enviado el: lunes, 21 de julio de 2008 20:46 Para: boost(a)lists.boost.org Asunto: Re: [boost] [1.36] release blurb? > > On 21/07/2008, JOAQUIN M. LOPEZ MUÑOZ <joaquin(a)tid.es> wrote: > > > > I wonder whether we already have some place to begin adding content > > to the 1.36 release notes--you know, listing the new libraries and > > significant updates. > > http://svn.boost.org/svn/boost/website/public_html/beta/feed/history/boost_… > > if you're not comfortable with quickbook, just send what you want to > add to the list. I've just added an entry for multi_index, hopefully I haven't messed anything, would be grateful if you could take a look. Also, I tidied up the previous material in the page according to the following rules, which AFAICS have governed the composition of previous release blurbs: 1. Libraries are listed in alphabetical order. 2. Besides the dedicated entry, the lib name should be added to the [purpose] section at the beginning of the page. Maybe it'd make sense to add these rules as a reminder comment at the beginning of the page (provided Quickbook has some form of comment)? Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 6

Mac OS universal builds: testers needed
by Mat Marcus 25 Jul '08

25 Jul '08

I've made a number of changes to my universal-binary supporting darwin.jam patch (shipping with the Adobe Source Library) in order to address the concerns raised by Rene and others at http://svn.boost.org/trac/boost/ticket/989 : My current version supports invocations like: bjam architecture={combined,x86,power} link={shared,static} address-model={64,32} That is, universal builds are now supported, along with 64 bit builds. I'd like to ask for the help from a few volunteers who'd be willing to test it out, before I submit my patch for consideration. Anyone interested in helping me test it? If so, please contact me off list and I'll send you a couple of boost build files to replace. I still have a bit of cleanup to do. Specifically, on the mac, if a build doesn't specify an -arch parameter, the architecture (and perhaps the address model) of the host machine is used. I'm not really comfortable with the same folder path meaning different things on different machines. So, I plan to do something like the following in darwin.jam (in invented pseudo code) SWITCH(on result of /usr/bin/arch) { # host machine's architecture CASE(ppc) use <architecture>power/<address-model>32 as the default CASE(i386) use <architecture>x86/<address-model>32 as the default CASE(ppc64) use <architecture>power/<address-model>64 as the default CASE(x86_64) use <architecture>x86/<address-model>64 as the default DEFAULT error, unknown arch Thanks, Mat

3 2

[test] Gennadiy, did you notice...?
by Daryle Walker 25 Jul '08

25 Jul '08

This is about the Boost.Test library files just uploaded to our Subversion repository, revision 47797. I like the fact that support headers are now automatically #included, but I noticed that "boost/ test/unit_test_suite.hpp" and "boost/test/test_case_template.hpp" #include each other. (The #include guards prevent infinite recursion.) You may want to fix that. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

[test] Broken header (via indirect #includes)
by Daryle Walker 25 Jul '08

25 Jul '08

I was fixing up a test file, and the compilation failed complaining that "'type' is not a member of 'boost'" within the innards of a "BOOST_AUTO_TEST_CASE_TEMPLATE" line. I figured out that the error was referring to the obscure boost::type class template in "boost/ type.hpp". I included that file, and then the compiler complained saying that "'template_test_case_gen' is not a member of 'boost::unit_test::ut_detail'." Doing a multiple-file search, I realized the true problem. 1. BOOST_AUTO_TEST_CASE_TEMPLATE is #defined in "boost/test/ unit_test_suite.hpp" 2. This template depends on boost::type and boost::unit_test::ut_detail::template_test_case_gen 3. template_test_case_gen is defined in "boost/test/ test_case_template.hpp", which happens to #include "boost/type.hpp" 4. Neither of the appropriate headers are directly #included in "unit_test_suite.hpp" 5. I guess that one or both headers were indirectly #included in "unit_test_suite.hpp", but that indirect header purged the headers I needed, and the author _forgot_ that another header was counting on the old indirect #include. I worked around the problem for now by directly #including "boost/ test/test_case_template.hpp" in my test file. But I shouldn't have to do this. Worse, this has happened before with Boost.Test, in regards to the floating point comparison tests. Those test macros called a function that wasn't in the same header, nor #included; i.e. the user has to add an extra #include for the floating-point test macros to work. The floating-point incident was a deliberate design decision, but I guess that my problem here was caused by accident. The point: DIRECTLY #include everything a macro needs in that macro's header. I'm sick & tired of hunting all the extra headers I need. Worse, I'll have to re-hunt when my test program craps out if/when the author re-arranges all the macros & headers. My point [5] is only a guess because I wasted two hours searching the trac/subversion site for where & when the author broke the build. I didn't find it, and I figured that I shouldn't have to. When you fix this, let me know so I can remove the extra #include from my test file. (Apologies in advance if the real problem is that my subversion working copy is severely fried.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 4

[test] RFC: speed up BOOST_CHECK by not formatting the check description if it isn't written anywhere
by Ji�� Pale�ek 25 Jul '08

25 Jul '08

Hello, I have a test that uses many BOOST_CHECKs (~ 10 thousands or so). Running that test is very slow and I have noticed most of the time is spent by formatting the description string to be passed to check_impl, only to be ignored, because I don't want to log successful checks (and they are successful). I have improved this by using some kind of expression template for this (called lazy_output). It works like this: lazy_output is a class that implements an expression template for "x << y << z" expressions. The expression o << a << b << c << (make_lazy_output() << x << y << z) is the same as o << a << b << c << x << y << z which is similar to o << a << b << c << (wrap_stringstream().ref() << x << y << z).ref() The difference is that, in the call f(make_lazy_output() << x << y << z), the data is formatted only if f outputs them to an ostream. This reduced the time needed for running my test from ~12 minutes to ~7 minutes. There is more room for similar (but more complicated) improvements. Any comments or suggestions? Regards Jiri Palecek

3 5

Re: [boost] [Boost-testing] Patch for sigaltstack failure on Leopard with XCode 3.0
by Juergen Hunold 25 Jul '08

25 Jul '08

HI Jeroen ! On Sunday 13 July 2008 17:33:04 Jeroen van der Wulp wrote: > Hello everyone, > The cause seems to be that the implementation of sigaltstack() on > Leopard requires the ss_size of a stack_t structure to be MINSIGSTKSZ at > least. > > The attached patch accomplishes just this. Well, it actually sets the size to BOOST_TEST_ALT_STACK_SIZE. But this should be big enough, shouldn't it ? ;-)) I'm CC'ing Gennadyi and the Boost devel list in case he missed this. I'll take a look at the current regressions for trunk and commit this patch tomorrow evening (CEST) if no one is faster ;-)) Merging Boost.Test to release is another business :-(( Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

[Test] [gcc] more checking for Test tests
by Juergen Hunold 25 Jul '08

25 Jul '08

Hi ! I've just fixed some "-pedantic" warnings from gcc. http://svn.boost.org/trac/boost/changeset/47423 I'd like to raise the warning level for gcc when running the Boost.Test testsuite by always adding "-pedantic". Unfortunately, this will issue errors due to gcc's own stdlib (at least for gcc < 4.2) because of the unprotected use of "long long" from the C99 standard. Thanks to Steven Watanabe for pointing this out. I've had to add "-Wno-long-long" to disable those warnings again. Please find a patch including an explanatory comment attached. Comments ? Wait until 1.36 is out ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

generict container for structure of arrays
by Bradford, Chase 24 Jul '08

24 Jul '08

Over the past few months, I've worked on a generalized structure-of-arrays for use in various scientific applications, and wanted to know if any Boostees had an interest in that sort of container. The library's main goals are 1) Optimized storage by allowing dynamic addition/removal of fields. 2) General performance help (cache coherency, vector processing, etc.) 3) Enabling the use of many types in a single SOA. 4) Provide an interface similar other STL containers 5) Type safety (of course) The library is similar to a tuple of vectors, except all vectors are forced to have the same size, and the members of the tuple aren't fixed. Internally, the data is stored as vectors for each field, but there's also an interface for getting a slice of the data. Chase Bradford

6 10

[phoenix] Using Phoenix V2.0
by Robert Jones 24 Jul '08

24 Jul '08

I'm struggling a little to navigate my way through the Boost svn repository for the correct Phoenix V2.0 files. There seem to be many deprecated locations and shell wrappers. Eg. boost/spirit/phoenix/operators.hpp states it is deprected in favour of boost/spirit/include/phoenix1_operators.hpp which simply #includes boost/home/classic/phoenix/operators.hpp which seems to be the real thing. Which, if any, of these is likely to emerge as the 'correct' long term home for these files? Thanks, Rob. -- ACCU - Professionalism in programming - http://www.accu.org

3 5

[graph] Max Flow Uninitialized Warning in adjacency_list.hpp
by Lex Fridman 24 Jul '08

24 Jul '08

When I try to compile the Edmunds Karp Max Flow example (or any of the other max-flow examples) I get a set of warnings as to m_source or m_target being used uninitialized in adjacency_list.hpp. I'm using gcc 4.2.3. Is there a way to get rid of this warning? Code example: http://www.nabble.com/file/p18596627/main.cpp main.cpp Warning example (this is all one line): /usr/include/boost/graph/detail/adjacency_list.hpp: In function ‘int boost::read_dimacs_max_flow(Graph&, CapacityMap, ReverseEdgeMap, typename boost::graph_traits<G>::vertex_descriptor&, typename boost::graph_traits<G>::vertex_descriptor&, std::istream&) [with Graph = main()::Graph, CapacityMap = boost::adj_list_edge_property_map<boost::directed_tag, long int, long int&, unsigned int, boost::property<boost::edge_capacity_t, long int, boost::property<boost::edge_residual_capacity_t, long int, boost::property<boost::edge_reverse_t, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>, boost::no_property> > >, boost::edge_capacity_t>, ReverseEdgeMap = boost::adj_list_edge_property_map<boost::directed_tag, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>&, unsigned int, boost::property<boost::edge_capacity_t, long int, boost::property<boost::edge_residual_capacity_t, long int, boost::property<boost::edge_reverse_t, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>, boost::no_property> > >, boost::edge_reverse_t>]’: /usr/include/boost/graph/detail/adjacency_list.hpp:270: warning: ‘p.boost::property<boost::edge_capacity_t, long int, boost::property<boost::edge_residual_capacity_t, long int, boost::property<boost::edge_reverse_t, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>, boost::no_property> > >::<anonymous>.boost::property<boost::edge_residual_capacity_t, long int, boost::property<boost::edge_reverse_t, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>, boost::no_property> >::<anonymous>.boost::property<boost::edge_reverse_t, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>, boost::no_property>::m_value.boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>::<anonymous>.boost::detail::edge_base<boost::directed_tag, unsigned int>::m_target’ is used uninitialized in this function -- View this message in context: http://www.nabble.com/-graph--Max-Flow-Uninitialized-Warning-in-adjacency_l… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

[release] nightly generated docs?
by Eric Niebler 24 Jul '08

24 Jul '08

Once upon a time, Boost's docs were built nightly and publicly hosted. Have we fallen out of that practice? Beman, have you tried building the documentation for the release yet? It'd be nice to get a regular build going again so we can work any kinks out of the system. Any volunteers? -- Eric Niebler BoostPro Computing http://www.boostpro.com

5 15

[1.36] release blurb?
by JOAQUIN M. LOPEZ MUÑOZ 24 Jul '08

24 Jul '08

Hi, I wonder whether we already have some place to begin adding content to the 1.36 release notes--you know, listing the new libraries and significant updates. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 10

[test] Fixtures and Documentation
by Dean Michael Berris 24 Jul '08

24 Jul '08

Hi Everyone, I've been using Boost.Test for a while already, and although I do think it's a very powerful library, it is a little unweildy to navigate the documentation of the library. For example, currently in the online documentation, links to the examples don't work correctly and there are areas which lead to "404" messages. The question is really simple though: when using BOOST_AUTO_TEST_CASE, how do I cut down on repetitive code and set up "fixtures"? For example, set up variables that are common in all test case bodies in the same file? I'm pretty confident there should be a way to do this -- and if there is, where do I find documentation on it? For now I'll resort to header-reading to find out how to use the macros, though it would be nice to have a one-stop library reference or guide for Boost.Test. TIA -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

3 7

Re: [boost] [1.36.0] Libraries with unmerged changes?
by Alp Mestan 24 Jul '08

24 Jul '08

Just must write a non-explicit constructor for io::chain taking an io::read_mem. Any reason for it to be dangerous ? -- Alp Mestan --- http://blog.mestan.fr/ --- http://alp.developpez.com/ --- In charge of the Qt, Algorithms and Artificial Intelligence sections on Developpez

1 0

[test] documentatation on patmedia.net disappeared, not up to date on boost.org
by Leo Moisio 23 Jul '08

23 Jul '08

The documentation for Boost.Test on boost.org seems very outdated, but there has been a much more up to date documentation available on http://www.patmedia.net/~rogeeff/html/utf/user-guide.html However it disappeared yesterday or day before that, and I can't find any mirrors anywhere. I'd really like to have this documentation available again. Leo Moisio

9 16

Boost Developers and the Sandbox
by Robert Jones 23 Jul '08

23 Jul '08

Am I correct in thinking that the Boost sandbox in entirely contained on the sourceforge site in the Boost Sandbox project, and that it's not part of, or contained in, the main Boost site? Also, I see the Boost Project has only 130 developers, and the Boost Sandbox Project only 89. This is the entire Boost development community? Or do these people commonly commit on behalf of others? Thanks, Rob. -- ACCU - Professionalism in programming - http://www.accu.org

2 2

OS X Test error
by Jeremy Pack 23 Jul '08

23 Jul '08

I am getting the following error when building any Boost tests on OS X 10.5: ====== BEGIN OUTPUT ====== Test setup error: system_error produced by: ::sigaltstack( &sigstk, 0 ) != -1: Cannot allocate memory EXIT STATUS: 200 ====== END OUTPUT ====== Anyone seen this before? Jeremy Pack

4 8

[shifted_ptr] STL w/ smart pointers
by Phil Bouchard 23 Jul '08

23 Jul '08

Hi, If we look into sandbox/shifted_ptr/bits I've added an archive called "bits.zip". I archived it because of all the barking SVN was doing. By unpacking this file we'll find: stl_list.h list.tcc stl_list.h.patch list.tcc.patch These files are an overriden version of the Gnu Gcc's 3.4.x headers. Why Gcc's? Because SGI headers are outdated by many years. Now if we compile shifted_ptr_test2.cpp with the following then these headers will override system ones which is perfect: g++ shifted_ptr_test2.cpp -I ../../.. My example doesn't work anymore but compiles at least. I will work on the problem but for now we can see the required changes to make STL compliant with smart pointers in the patch files. I think this is great because this can help unobfusticate the standards in this matter and containers using smart pointers means better abstraction and goodbye to a lot of headaches if we start using sorting, multi-indexing, graph, etc. In the code itself I am propagating the allocator all over internal classes (iterators & nodes) and now looks like the following: template<typename _Alloc> struct _List_node_base { typedef typename _Alloc::template rebind<_List_node_base<_Alloc> >::other _Node_Alloc_type; typedef typename _Node_Alloc_type::pointer pointer; typedef typename _Node_Alloc_type::const_pointer const_pointer; typedef typename _Node_Alloc_type::reference reference; typedef typename _Node_Alloc_type::const_reference const_reference; pointer _M_next; ///< Self-explanatory pointer _M_prev; ///< Self-explanatory static void swap(_List_node_base& __x, _List_node_base& __y); void transfer(pointer const __first, pointer const __last); void reverse(); void hook(pointer const & __position); void unhook(); }; Furtermore I took the liberty of mixing the Boost License with GPL because I think these are compatible but feel free letting me know any problem this may create. Regards, -Phil

2 3

Inspection reports updated
by Marshall Clow 23 Jul '08

23 Jul '08

I have updated the inspection reports at: <http://www.idio.com/misc/inspect-release.html> <http://www.idio.com/misc/inspect-trunk.html> Summaries: Release: >20776 files scanned >1625 directories scanned (including root) >838 problems reported > >Problem counts: > 260 files missing Boost license info or having wrong reference text > 188 files missing copyright notice > 1 files with invalid line endings > 0 bookmarks with invalid characters > 2 invalid urls > 113 broken links > 34 unlinked files > 7 file/directory names issues > 44 files with tabs > 116 files with non-ASCII chars > 33 violations of the Boost min/max guidelines > 40 usages of unnamed namespaces in headers (including .ipp files) Trunk: >21573 files scanned >1671 directories scanned (including root) >1532 problems reported > >Problem counts: > 548 files missing Boost license info or having wrong reference text > 294 files missing copyright notice > 1 files with invalid line endings > 0 bookmarks with invalid characters > 2 invalid urls > 119 broken links > 47 unlinked files > 26 file/directory names issues > 320 files with tabs > 71 files with non-ASCII chars > 64 violations of the Boost min/max guidelines > 40 usages of unnamed namespaces in headers (including .ipp files) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

4 8

Re: [boost] Would anybody like a wrapper atomic_shared<T>aroundshared_ptr<T>?
by Talbot, George 23 Jul '08

23 Jul '08

Excellent. I'll wait for this. I'd be willing to be a tester, if that would help. -- George T. Talbot <gtalbot(a)locuspharma.com> > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Peter Dimov > Sent: Wednesday, July 23, 2008 6:37 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Would anybody like a wrapper > atomic_shared<T>aroundshared_ptr<T>? > > Talbot, George: > > > Hi all, > > > > A while back (~2006 I think) I was asking around on this list about > > using boost::shared_ptr<T> to build a composite data structure that can > > be accessed and modified by multiple threads. > > > > Peter Dimov's suggestion at the time was to write a wrapper class for > > boost::shared_ptr<T> that would protect access to the > > boost::shared_ptr<T> with a spinlock. I've done this, and this works > > pretty good in my application. I'm interested in contributing this code > > to BOOST, as it's been quite useful. > > The SVN now contains an implementation of the recently accepted for > inclusion into C++0x > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2674.htm > > This feature be part of the upcoming 1.36. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Would anybody like a wrapper atomic_shared<T> aroundshared_ptr<T>?
by Talbot, George 23 Jul '08

23 Jul '08

Hi! Thanks for responding. > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Dean Michael Berris > Sent: Tuesday, July 22, 2008 9:24 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Would anybody like a wrapper atomic_shared<T> > aroundshared_ptr<T>? > > Hi George, > > On Wed, Jul 23, 2008 at 6:04 AM, Talbot, George <Gtalbot(a)locuspharma.com> > wrote: > > > > A while back (~2006 I think) I was asking around on this list about > > using boost::shared_ptr<T> to build a composite data structure that can > > be accessed and modified by multiple threads. > > > > Peter Dimov's suggestion at the time was to write a wrapper class for > > boost::shared_ptr<T> that would protect access to the > > boost::shared_ptr<T> with a spinlock. I've done this, and this works > > pretty good in my application. I'm interested in contributing this code > > to BOOST, as it's been quite useful. > > > > I have a few questions: > > > > 1) Is there interest in such a donation. It's just one header file, > > and it's wafer-thin... > > I am interested, although I do have some reservations with it not > using the locks already available in Boost.Thread. I would likely convert it to do so. Haven't got around to that yet. > > 2) If so, how does one go about making such a donation? > > (I think it's a little funny that you use 'donation' instead of > contribution... but nonetheless... ;-) ) Sorry....contribution. I'm a bit of a space cadet. ;^) > >From what I gather, this is something that may have to go through a > mini-review. The veterans can answer this question better though. I'm sure, and that would be great, actually. > > 3) My implementation below uses a spinlock to protect things and > > as one might expect, under load my application does spend some > > time in ::pthread_spin_lock(). Is there a way to rewrite this > > class (possibly with friendship of boost::shared_ptr<T>) in a > > lock-free manner? I've attached the code below... > > > > I'm not sure about lock-free approaches, but doesn't shared_ptr<T> > already use atomic operations when built in multi-threaded mode? Yes, but read the Thread Safety page. The guarantee you get from shared_ptr<T> is that two or more separate instances in separate threads that point to the same object and refcount will be handled lock-free and work properly. However it explicitly does not guarantee multiple threads looking at the _same_ instance of shared_ptr<T> can perform operations upon that same instance without some sort of additional guarantees. The purpose of this class is to provide that guarantee. > Another issue I see is the dependence to ::pthread_spin_lock() -- can > you use a shared recursive_mutex instead? How expensive is that in memory and time? I was using ::pthread_spin_lock() because on my x86_64 Linux box, pthread_spinlock_t is a single machine word. Also, it's just a proof-of-concept. I think the "right thing" is to be able to implement the unary bool operators, get() and compare_and_set() via a lock-free algorithm. My problem is that I don't have enough depth of knowledge of the lock-free shared_ptr<T> class in BOOST to be able to work out such an algorithm. I was hoping for a little bit of "pointing in the right direction" from the author(s) of BOOST's lock-free shared_ptr<T> implementation. That said I'd have no problem "falling-back" to using a shared recursive_mutex instead if a lock-free algorithm isn't available on a particular platform. As such, attached below is a rewrite using recursive_try_mutex...This appears similar in execution efficiency to my previous implementation with the spinlock in my stress test. It appears from examining the pthread libraries that the mutex is using about 8 machine words instead of one for the spinlock. Of course, as above, I'd prefer no lock at all; I'll see what I can come up with. Thanks for looking at this. -- George T. Talbot gtalbot(a)locuspharma.com /** \file atomic_shared.h * * \author George T. Talbot * \author Peter Dimov * * \brief This file defines a template class that can wrap * boost::shared_ptr and provide thread-safe atomic * get/set operations on them. * * (C) Copyright Locus Pharmaceuticals, Inc., Peter Dimov 2006. * * Distributed under the Boost Software License, Version 1.0. (See * accompanying file LICENSE_1_0.txt or copy at * http://www.boost.org/LICENSE_1_0.txt) */ #ifndef ATOMIC_SHARED_H #define ATOMIC_SHARED_H #include <boost/shared_ptr.hpp> #include <boost/pointer_cast.hpp> #include <boost/thread/recursive_mutex.hpp> /** atomic_shared<T> wraps boost::shared_ptr<T> with a mutex and a very * restricted set of operations so that a large composite data structure * may be accessed by multiple threads with a minimum of locking contention. * * Threads working on a large composite data structure create their own * private boost::shared_ptr<T> around their own new nodes and then use * compare_and_set() to place their new nodes in the composite data * structure. * * Threads that are viewing the composite data structure may call get() to * get a private copy of the pointer so they can do some work with it. The * intended idiom for modifications to nodes is like so: * * \code * * atomic_shared<const Blah> global_blah; * * void modify_the_global_blah_in_many_threads_with_no_locking() * { * bool done = false; * do * { * boost::shared_ptr<const Blah> my_blah(global_blah.get()); * * boost::shared_ptr<Blah> new_blah(*my_blah); * new_blah->some_modification(); * done = global_blah.compare_and_set(my_blah, new_blah); * } * while (!done); * } * * \endcode * * Threads that just need to do some work looking at the node: * * \code * * void print_the_global_blah_in_many_threads_with_no_locking() * { * boost::shared_ptr<const Blah> my_blah(global_blah.get()); * * my_blah->print(); * } * * \endcode * * Using atomic_shared<T> this way satisfies the Thread Safety portion of * the boost::shared_ptr<T> documentation. */ template<class T> class atomic_shared { atomic_shared& operator=(const atomic_shared&); public: typedef boost::shared_ptr<T> base_ptr; /** construct an empty pointer. */ atomic_shared() : ptr(), mutex() { } /** copy constructor. Since we like to put atomic_shared<> in std::map<> * via std::map<atomic_shared<T> >::insert(std::make_pair(key, value)), * this needs to be here. */ atomic_shared(const atomic_shared& p) : ptr(p.get()), mutex() { } /** construct a protected pointer from a bare one. */ template<class Y> explicit atomic_shared(Y* p) : ptr(p), mutex() { } /** construct a protected pointer from a shared_ptr. */ template<class U> explicit atomic_shared(const boost::shared_ptr<U>& p) : ptr(p), mutex() { } ~atomic_shared() { } /** Is it not null? */ operator bool() const { bool rv; { boost::recursive_try_mutex::scoped_lock l(mutex); rv = ptr; } return rv; } /** Is it null? */ bool operator!() const { bool rv; { boost::recursive_try_mutex::scoped_lock l(mutex); rv = !ptr; } return rv; } /** Right here is the only way to _use_ the pointer. To use what the * pointer is pointing to, you must make a private copy in your * thread. */ inline base_ptr get() const { base_ptr p; { boost::recursive_try_mutex::scoped_lock l(mutex); p = ptr; } return p; } /** Attempt to set the value of the pointer with another pointer, but * only if the pointer is the same as a previously sampled value of * the pointer. * * @param cmp Value of pointer previously retrieved with get(). * @param x New value of pointer. * @return true if the pointer could be set to x (i.e. its value was * still cmp with the mutex locked.) */ template<class Y, class X> bool compare_and_set(const boost::shared_ptr<Y>& cmp, boost::shared_ptr<X>& x) { bool r = false; boost::recursive_try_mutex::scoped_try_lock l(mutex, false); if (l.try_lock()) { r = ptr == cmp; if (r) ptr = x; } return r; } private: base_ptr ptr; mutable boost::recursive_try_mutex mutex; }; // atomic_shared #endif

1 0

[web-site] Documentation links.
by Jurko Gospodnetić 23 Jul '08

23 Jul '08

Hi. A few issues related to the documentation link organization on the new web site: ---- 1. ---- The libraries documentation link list on the http://beta.boost.org/doc/ page (the main link list as well as the one in the menu on the right hand side) should be updated to reference the 1.36.0 release web page as the current release. ---- 2. ---- Could the tool documentation links on http://beta.boost.org/doc/ be better organized somehow? Currently it is not clear that the 'Tools' bullet is a link to a page with all the tool documentation links and user thinks that Boost Jam & Boost Build are the only two documented (or existing) tools. Some ideas: (1) Remove Boost Jam & Boost Build links and leave just the 'Tools' link. (2) Add an 'All tools...' link below the Boost Build link. (3) Integrate the whole http://beta.boost.org/doc/tools.html web page into its parent page at http://beta.boost.org/doc/. My choice would be (3). ---- 3. ---- There is a similar problem with the links on the right side of the http://beta.boost.org/doc/ page where similar ideas apply and my suggestion would be to list all the tools below the Tools parent menu item. I've seen this same suggestion made before in some thread, and recalled it now after actually having to look for some tool documentation and experiencing the problem for myself. Hope this helps. Best regards, Jurko Gospodnetić

2 1

Re: [boost] [pool] segfault (fun with static initialization ordering)
by JOAQUIN M. LOPEZ MUÑOZ 23 Jul '08

23 Jul '08

_______________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de Chris Newbold [Chris.Newbold(a)mathworks.com] Enviado el: viernes, 11 de julio de 2008 16:25 Para: 'boost(a)lists.boost.org' Asunto: Re: [boost] [pool] segfault (fun with static initialization ordering) [...] > Right. The way that singleton_default guarantees that instance() is called during > dynamic initialization is by [analysis of singleton machinery] That's it. > > * Where the problem lies can be found by looking at the usage of > > singleton_pool by fast_pool_allocator: notice that singleton_pool > > is used *only* when fast_pool_allocator::allocate or ::deallocate > > are invoked. So, it is perfectly possible to construct a > > fast_pool_allocator without that forcing the compiler to > > construct the underying singleton_pool *yet*. And this is what's > > happening indeed, the sequence of objects construction we're > > having is this: > > > > 1. owned_base::pool_ begins construction > > 1.1 call of new pool_lii() inside pool::pool > > 1.1.1 a fast_pool_allocator is cted inside pool_lii ctor. > > 1.2 pool_ii ends construction > > 2. pool_ ends construction > > 3. the singleton instance associated to singleton_pool<...>is > > cted before main() because fast_pool_allocator uses it later > > (singleton guarantee). > > I'm not sure I buy this explanation entirely. > > owned_base::pool_ is a global object. As described above, so is object_creator. > The test case consists of a single translation unit, and inside that translation > unit, the declaration of object_creator precedes that of owned_base::pool_ > (because object_creator is declared by a Boost.Pool header which is included > before the application-level code which declares owned_base). > > Following the fairly clear rules about initialization order for namespace-scoped > global objects, I would have expected the compiler to construct object_creator > first (and therefore the pool) before constructing owned_base::pool_. These precedence rules do not apply to class template static data: quoting the standard (latest draft at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf) section 3.6.2: "Dynamic initialization of a non-local object with static storage duration is either ordered or unordered. Definitions of explicitly specialized class template static data members have ordered initialization. Other class template static data members (i.e., implicitly or explicitly instantiated specializations) have unordered initialization. Other objects defined in namespace scope have ordered initialization. Objects with ordered initialization defined within a single translation unit shall be initialized in theorder of their definitions in the translation unit." That is, only *ordered* file-scope objects are subject to the precedence rule you're referring to. Class template static data are not ordered by definition (except if belonging to a full specialization). So, the sequence I proposed above is consistent AFAICS. The following is a case where the precende rule *cannot* be applied for logical reasons: template<typename T> struct foo{ static int x; }; template<typename T> int foo<T>::x=T::x; struct bar { static int x; }; int bar::x=666; static int x=foo<bar>::x; You see, foo<T>::x is defined before bar::x yet it can only be initialized after bar::x has already been constructed. In the original case we're dealing with there are no dependency constraints like this, yet the sequence I proposed a post ago is to the best of my knowledge consistent with the rules of C++ (and we're seemingly observing it in at least a compiler). BTW, have you tried the fix I was proposing? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

Would anybody like a wrapper atomic_shared<T> around shared_ptr<T>?
by Talbot, George 23 Jul '08

23 Jul '08

Hi all, A while back (~2006 I think) I was asking around on this list about using boost::shared_ptr<T> to build a composite data structure that can be accessed and modified by multiple threads. Peter Dimov's suggestion at the time was to write a wrapper class for boost::shared_ptr<T> that would protect access to the boost::shared_ptr<T> with a spinlock. I've done this, and this works pretty good in my application. I'm interested in contributing this code to BOOST, as it's been quite useful. I have a few questions: 1) Is there interest in such a donation. It's just one header file, and it's wafer-thin... 2) If so, how does one go about making such a donation? 3) My implementation below uses a spinlock to protect things and as one might expect, under load my application does spend some time in ::pthread_spin_lock(). Is there a way to rewrite this class (possibly with friendship of boost::shared_ptr<T>) in a lock-free manner? I've attached the code below... Thanks in advance for any help/input you can give. -- George T. Talbot <gtalbot(a)locuspharma.com> /** \file atomic_shared.h * * \author George T. Talbot * \author Peter Dimov * * \brief This file defines a template class that can wrap * boost::shared_ptr and provide thread-safe atomic * get/set operations on them. * * (C) Copyright George T. Talbot, Peter Dimov 2006. * * Distributed under the Boost Software License, Version 1.0. (See * accompanying file LICENSE_1_0.txt or copy at * http://www.boost.org/LICENSE_1_0.txt) */ #ifndef ATOMIC_SHARED_H #define ATOMIC_SHARED_H #include <pthread.h> #include <cerrno> #include <stdexcept> #include <boost/shared_ptr.hpp> #include <boost/pointer_cast.hpp> //#define SPINLOCK_ABORT #ifdef SPINLOCK_ABORT_ON_ERROR #define SPINLOCK_ABORT ::abort(); #else #define SPINLOCK_ABORT #endif /** atomic_shared<T> wraps boost::shared_ptr<T> with a spinlock and a very * restricted set of operations so that a large composite data structure * may be accessed by multiple threads with a minimum of locking contention. * * Threads working on a large composite data structure create their own * private boost::shared_ptr<T> around their own new nodes and then use * compare_and_set() to place their new nodes in the composite data * structure. * * Threads that are viewing the composite data structure may call get() to * get a private copy of the pointer so they can do some work with it. The * intended idiom for modifications to nodes is like so: * * \code * * atomic_shared<const Blah> global_blah; * * void modify_the_global_blah_in_many_threads_with_no_locking() * { * bool done = false; * do * { * boost::shared_ptr<const Blah> my_blah(global_blah.get()); * * boost::shared_ptr<Blah> new_blah(*my_blah); * new_blah->some_modification(); * done = global_blah.compare_and_set(my_blah, new_blah); * } * while (!done); * } * * \endcode * * Threads that just need to do some work looking at the node: * * \code * * void print_the_global_blah_in_many_threads_with_no_locking() * { * boost::shared_ptr<const Blah> my_blah(global_blah.get()); * * my_blah->print(); * } * * \endcode * * Using atomic_shared<T> this way satisfies the Thread Safety portion of * the boost::shared_ptr<T> documentation. */ template<class T> class atomic_shared { /** Initialize a spinlock protecting a shared_ptr<T>. */ static void init(pthread_spinlock_t& l) { int rv = ::pthread_spin_init(&l, PTHREAD_PROCESS_PRIVATE); if (rv) { SPINLOCK_ABORT errno = rv; throw std::runtime_error("can't initialize spinlock"); } } /** Used to lock and unlock a spinlock protecting the shared_ptr<>. * Saves typing. */ struct lock_t { explicit lock_t(pthread_spinlock_t& lock) : m_lock(lock) { if (::pthread_spin_lock(&m_lock)) { SPINLOCK_ABORT throw std::runtime_error("can't lock spinlock"); } } lock_t(pthread_spinlock_t& lock, int) // Assumes already locked. : m_lock(lock) { } ~lock_t() { if (::pthread_spin_unlock(&m_lock)) { SPINLOCK_ABORT } } private: pthread_spinlock_t& m_lock; }; atomic_shared& operator=(const atomic_shared&); public: typedef boost::shared_ptr<T> base_ptr; /** construct an empty pointer. */ atomic_shared() : ptr(), spinlock() { init(spinlock); } /** copy constructor. Since we like to put atomic_shared<> in * std::map<> via * std::map<atomic_shared<T> >::insert(std::make_pair(key, value)), * this needs to be here. */ atomic_shared(const atomic_shared& p) : ptr(p.get()), spinlock() { init(spinlock); } /** construct a protected pointer from a bare one. */ template<class Y> explicit atomic_shared(Y* p) : ptr(p), spinlock() { init(spinlock); } /** construct a protected pointer from a shared_ptr. */ template<class U> explicit atomic_shared(const boost::shared_ptr<U>& p) : ptr(p), spinlock() { init(spinlock); } /** destructor with rudimentary error checking. */ ~atomic_shared() { int rv = ::pthread_spin_destroy(&spinlock); // For debugging, drop us into the debugger if we can't destroy the // spinlock. assert(rv == 0); (void) rv; } /** Is it not null? */ operator bool() const { bool rv; { lock_t l(spinlock); rv = ptr; } return rv; } /** Is it null? */ bool operator!() const { bool rv; { lock_t l(spinlock); rv = !ptr; } return rv; } /** Right here is the only way to _use_ the pointer. To use what the * pointer is pointing to, you must make a private copy in your thread. */ inline base_ptr get() const { base_ptr p; { lock_t l(spinlock); p = ptr; } return p; } /** Attempt to set the value of the pointer with another pointer, but * only if the pointer is the same as a previously sampled value of the * pointer. * * @param cmp Value of pointer previously retrieved with get(). * @param x New value of pointer. * @return true if the pointer could be set to x (i.e. its value was * still == cmp with the spinlock locked. */ template<class Y, class X> bool compare_and_set(const boost::shared_ptr<Y>& cmp, boost::shared_ptr<X>& x) { bool r; { int rv = ::pthread_spin_trylock(&spinlock); switch (rv) { case EBUSY: return false; case 0: break; default: SPINLOCK_ABORT errno = rv; throw std::logic_error("can't pthread_spin_trylock"); } lock_t l(spinlock, 0); // already locked r = ptr == cmp; if (r) ptr = x; } return r; } private: base_ptr ptr; mutable pthread_spinlock_t spinlock; }; // atomic_shared #endif

3 2

Patch for boost.python: Added return value policy return_pointee_value
by Maximilian Matthe 23 Jul '08

23 Jul '08

Hi! I've created a patch that adds a new return value policy to boost.python: return_pointee_value. Roman Yakovenko has "invented" it, I have added it to the current SVN trunk on my PC. I've written documentation for it and also some test cases. David Abrahams encouraged me to send a patch to the boost list, which I do now. There are some issues with the patch (since its my first time, I'm doing something like that): - The test cases are not integrated into the Jamfile in the tests-directory (I dont know bjam very well). - I dont know, wether the tests are OK the way they are done. - I did not add an #include directive to any boost-python header. But some header should include the <boost/python/return_pointee_value.hpp>, but I dont know which one. Ok, that's it for now. I would aprreciate any comments or critic. Max Index: boost/python/return_pointee_value.hpp =================================================================== --- boost/python/return_pointee_value.hpp (revision 0) +++ boost/python/return_pointee_value.hpp (revision 0) @@ -0,0 +1,69 @@ +// Copyright Roman Yakovenko, Maximilian Matthe 2006, 2008. +// Distributed under the Boost Software License, Version 1.0. (See +// accompanying file LICENSE_1_0.txt or copy at +// http://www.boost.org/LICENSE_1_0.txt) +/* + * Generic return value policy for functions returning pointers which should be + * exposed as values. Can be used to return pointers to non-exposed types. + * + * The code is adapted from + * http://mail.python.org/pipermail/c++-sig/2006-November/011568.html . + */ +#ifndef RETURN_POINTEE_VALUE_9_11_2006 +#define RETURN_POINTEE_VALUE_9_11_2006 + +# include <boost/python/detail/prefix.hpp> +# include <boost/python/detail/indirect_traits.hpp> +# include <boost/python/object.hpp> +# include <boost/mpl/if.hpp> +# include <boost/python/to_python_indirect.hpp> +# include <boost/type_traits/composite_traits.hpp> + + +namespace boost{ namespace python{ + namespace detail{ + struct make_value_holder + { + template <class T> + static PyObject* execute(T* p) + { + if (p == 0) + { + return python::detail::none(); + } + else + { + object p_value( *p ); + return incref( p_value.ptr() ); + } + } + }; + + template <class R> + struct reference_existing_object_requires_a_pointer_return_type +# if defined(__GNUC__) && __GNUC__ >= 3 || defined(__EDG__) + {} +# endif + ; + + } //detail + + struct return_pointee_value + { + template <class T> + struct apply + { + BOOST_STATIC_CONSTANT( bool, ok = is_pointer<T>::value ); + + typedef typename mpl::if_c< + ok + , to_python_indirect<T, detail::make_value_holder> + , detail::reference_existing_object_requires_a_pointer_return_type<T> + >::type type; + }; + }; + + +} } //boost::python + +#endif//RETURN_POINTEE_VALUE_9_11_2006 \ No newline at end of file Index: libs/python/doc/v2/reference.html =================================================================== --- libs/python/doc/v2/reference.html (revision 47690) +++ libs/python/doc/v2/reference.html (working copy) @@ -877,7 +877,25 @@ </dd> </dl> </dd> + + <dt><a href= + "return_pointee_value.html">return_pointee_value.hpp</a></dt> + <dd> + <dl class="index"> + <dt><a href= + "return_pointee_value.html#classes">Classes</a></dt> + + <dd> + <dl class="index"> + <dt><a href= + "return_pointee_value.html#return_pointee_value-spec"> + return_pointee_value</a></dt> + </dl> + </dd> + </dl> + </dd> + <dt><a href="return_by_value.html">return_by_value.hpp</a></dt> <dd> Index: libs/python/doc/v2/reference_existing_object.html =================================================================== --- libs/python/doc/v2/reference_existing_object.html (revision 47690) +++ libs/python/doc/v2/reference_existing_object.html (working copy) @@ -80,6 +80,7 @@ "with_custodian_and_ward.html#with_custodian_and_ward-spec">with_custodian_and_ward</a>. This class is used in the implementation of <a href= "return_internal_reference.html#return_internal_reference-spec">return_internal_reference</a>.</p> + <p>This return value policy can only be used with types that were exposed with boost.python before.</p> <h4><a name="reference_existing_object-spec-synopsis"></a>Class <code>reference_existing_object</code> synopsis</h4> Index: libs/python/doc/v2/return_pointee_value.html =================================================================== --- libs/python/doc/v2/return_pointee_value.html (revision 0) +++ libs/python/doc/v2/return_pointee_value.html (revision 0) @@ -0,0 +1,241 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> + + + + +<html> + <head> + <meta name="generator" content= + "HTML Tidy for Windows (vers 1st August 2002), see www.w3.org"> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <link rel="stylesheet" type="text/css" href="../boost.css"> + + <title>Boost.Python - + <boost/python/return_pointee_value.hpp></title> + </head> + + <body> + <table border="0" cellpadding="7" cellspacing="0" width="100%" summary= + "header"> + <tr> + <td valign="top" width="300"> + <h3><a href="../../../../index.htm"><img height="86" width="277" + alt="C++ Boost" src="../../../../boost.png" border="0"></a></h3> + </td> + + <td valign="top"> + <h1 align="center"><a href="../index.html">Boost.Python</a></h1> + + <h2 align="center">Header + <boost/python/return_pointee_value.hpp></h2> + </td> + </tr> + </table> + <hr> + + <h2>Contents</h2> + + <dl class="page-index"> + <dt><a href="#classes">Classes</a></dt> + + <dd> + <dl class="page-index"> + <dt><a href="#return_pointee_value-spec">Class + <code>return_pointee_value</code></a></dt> + + <dd> + <dl class="page-index"> + <dt><a href="#return_pointee_value-spec-synopsis">Class + <code>return_pointee_value</code> synopsis</a></dt> + + <dt><a href= + "#return_pointee_value-spec-metafunctions">Class + <code>return_pointee_value</code> metafunctions</a></dt> + </dl> + </dd> + </dl> + </dd> + + <dt><a href="#examples">Example</a></dt> + </dl> + <hr> + + <h2><a name="classes"></a>Classes</h2> + + <h3><a name="return_pointee_value-spec"></a>Class + <code>return_pointee_value</code></h3> + + <p><code>return_pointee_value</code> is a model of <a href= + "ResultConverter.html#ResultConverterGenerator-concept">ResultConverterGenerator</a> + which can be used to wrap C++ functions, that return a pointer to a C++ object. The + policy implements the following logic: + + <pre> +if return value is NULL pointer: + return None +else: + return bp::object( * return value ) + </pre> + + It passes the value of the pointee to python, thus the conversion for T is used, if + return value is of type T*.</p> + <p>This return_value_policy can therefore be used to return pointers to python, which + types are not known to boost.python but only a conversion for the pointees. Therefore this + policy should be used to return pointers to objects whose types were wrapped with + other tools, such as SWIG (see example).</p> + + <p><b>Please note:</b> This policy does not take ownership of the wrapped pointer. If the + object pointed to is deleted in C++, the python-object will become invalid too, if your custom + conversion depends on the original object.</p> + + <h4><a name="return_pointee_value-spec-synopsis"></a>Class + <code>return_pointee_value</code> synopsis</h4> +<pre> +namespace boost { namespace python +{ + struct return_pointee_value + { + template <class T> struct apply; + }; +}} +</pre> + + <h4><a name="return_pointee_value-spec-metafunctions"></a>Class + <code>return_pointee_value</code> metafunctions</h4> +<pre> +template <class T> struct apply +</pre> + + <dl class="metafunction-semantics"> + <dt><b>Requires:</b> <code>T</code> is <code>U*</code>for some <code>U</code>.</dt> + + <dt><b>Returns:</b> <code>typedef <a href= + "to_python_indirect.html#to_python_indirect-spec">to_python_indirect</a><T,V> + type</code>, where <code>V</code> is a class whose + static <code>execute</code> function constructs a <code>boost::python::object</code> from + the dereferenced parameter of type <code>U*</code>.</dt> + </dl> + + <h2><a name="examples"></a>Example</h2> + <p><b>Example 1:</b> This example demonstrates the trivial use of <code>return_pointee_value</code> for returning + the value that the returned pointer points to: + </p> + <p>In C++:</p> + <pre> +#include <boost/python/module.hpp> +#include <boost/python/class.hpp> +#include <boost/python/return_pointee_value.hpp> +#include <boost/python/return_value_policy.hpp> +#inlcude <wxPython.h> +#include <utility> + +// The function which is going to be wrapped: +int* get_value() +{ + static int val = 42; + return &val; +} + +// Function that returns a NULL-Pointer +int* get_null_value() +{ + return NULL; +} + +// The wrapper +BOOST_PYTHON_MODULE(example) +{ + using namespace boost::python; + // Wrap the functions with return_pointee_value + def("get_value", get_value, return_value_policy<return_pointee_value>()); + def("get_null_value", get_null_value, return_value_policy<return_pointee_value>()); +} + </pre> + <p>In Python:</p> + <pre> +>>> import example +>>> f = example.get_value() +>>> print f +42 +>>> f = 5 +>>> print example.get_value() +42 +>>> assert None is example.get_null_value() + </pre> + <p>Note that the value of the static C++-variable <code>val</code> is not changed when python assigns + a new value to <code>f</code>. This is caused by the logic of <code>return_pointee_value</code>: It returns + the <code>boost::python::object</code> which is constructed from <code>*val</code>.</p> + + <p><b>Example 2:</b> The following example uses return_pointee_value to return an object that is wrapped + with SWIG. I use the wxPython-API because it's easier to understand.</p> + + <p>In C++:</p> +<pre> +#include <boost/python/module.hpp> +#include <boost/python/class.hpp> +#include <boost/python/return_pointee_value.hpp> +#include <boost/python/return_value_policy.hpp> +#inlcude <wxPython.h> +#include <utility> + +// The following code assumes that there is set up a +// working wxWidgets application + +// Function to wrap: +wxWindow* getMainFrame() +{ + return wxGetApp().GetTopWindow(); +} + +// Custom conversion for wxWindow. +struct convert_wxWindow +{ + // Method that does the conversion. Note that it takes a reference to wxWindow, + // not a reference to a pointer. This is needed, because the return value policy + // converts the objects not the pointers. + static PyObject* convert(wxWindow const& o) + { + // Convert the pointer to wxWindow, instead of its value. This is how + // it should be done to convert wxObjects to wxPython. The object will be + // recognized well in python + PyObject* arg = wxPyMake_wxObject(const_cast<wxWindow*>(&o), false); + return arg; + } +}; + +// Wrapper code +using namespace boost::python; +BOOST_PYTHON_MODULE(MyApp) +{ + def("getMainFrame", getMainFrame, return_value_policy<return_pointee_value>()); + + // register the custom converter + // converter for wxWindow, its conversion_struct, false tells boost that + // we do not have a get_pytype() method in it. + to_python_converter<wxWindow, convert_wxWindow, false>(); +} +</pre> + In Python: The example assumes that you call the python function <code>doit</code> from C++: +<pre> +def doit(): + w = MyApp.getMainFrame() + w.Hide() + print "Haha, it's gone!" + w.Show() + return 0 + +</pre> +<p>Note that the returned wxWindow is the same object as the return value of <code>getMainFrame</code> because of +the custom construction for <code>boost::python::object</code> from wxWindow. The conversion just converts the pointer, +not the object itself.</p> + + <p>Revised +  + 22 July, 2008 +  + </p> + + <p><i>© Copyright Maximilian Matthe, Roman Yakovenko 2006, 2008.</i></p> + </body> +</html> + Index: libs/python/test/return_pointee_value.cpp =================================================================== --- libs/python/test/return_pointee_value.cpp (revision 0) +++ libs/python/test/return_pointee_value.cpp (revision 0) @@ -0,0 +1,55 @@ +// Copyright Maximilian Matthe 2008. +// Distributed under the Boost Software License, Version 1.0. (See +// accompanying file LICENSE_1_0.txt or copy at +// http://www.boost.org/LICENSE_1_0.txt) + +#include <boost/python/return_pointee_value.hpp> +#include <boost/python/module.hpp> +#include <boost/python/return_value_policy.hpp> +#include <boost/python/def.hpp> +#include <boost/python/to_python_converter.hpp> + +// Out returned, unkown type +struct IntWrapper +{ + IntWrapper(int v) : val(v) {} + int val; +}; + +// the custom converter +struct convert_IntWrapper +{ + static PyObject* convert(IntWrapper const& w) + { + return boost::python::incref(boost::python::object(w.val).ptr()); + } +}; + +IntWrapper* returnIntWrapper() +{ + static IntWrapper w(42); + return &w; +} + +////////////////////////////////////////////////////////// +float* get_value() +{ + static float value = 0.5f; + return &value; +} + +float* get_null_value() +{ + return NULL; +} + +BOOST_PYTHON_MODULE(return_pointee_value) +{ + using namespace boost::python; + def("returnIntWrapper", returnIntWrapper, return_value_policy<return_pointee_value>()); + + def("get_value", get_value, return_value_policy<return_pointee_value>()); + def("get_null_value", get_null_value, return_value_policy<return_pointee_value>()); + + to_python_converter<IntWrapper, convert_IntWrapper, false>(); +} \ No newline at end of file Index: libs/python/test/return_pointee_value.py =================================================================== --- libs/python/test/return_pointee_value.py (revision 0) +++ libs/python/test/return_pointee_value.py (revision 0) @@ -0,0 +1,25 @@ +# Copyright Maximilian Matthe 2008 +# Distributed under the Boost +# Software License, Version 1.0. (See accompanying +# file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) + +import return_pointee_value + + +def run(args = None): + a = return_pointee_value.returnIntWrapper() + assert a == 42 + assert 0.5 == return_pointee_value.get_value() + assert None is return_pointee_value.get_null_value() + return 0 + +if __name__ == '__main__': + print 'running...' + import sys + status = run() + if(status == 0): + print "Succes..." + else: + print "Failure!" + sys.exit(status) + \ No newline at end of file

2 1

[dataflow] new frameworks and GUI editors + visually edit a BGL graph
by Stjepan Rajko 22 Jul '08

22 Jul '08

Hello, I uploaded some youtube videos of a new visual editor for the Dataflow library. There are three examples, each using a different underlying framework (the visual editor code is generic): visually editing a Dataflow.Signals network (data flows instantly): * http://www.youtube.com/watch?v=7a4HJ4zVPXc visually editing a Dataflow.Managed network (data flows on request): * http://www.youtube.com/watch?v=KwrnSjhJyf4 visually editing a BGL graph (this simple example lets you construct a directed graph and query the number of strongly connected components): * http://www.youtube.com/watch?v=gVLetAAnPrc The latter two examples use proof-of-concept implementations of alternate frameworks built on top of the generic framework that is part of the Dataflow library: Dataflow.Managed is unlike Dataflow.Signals in that doesn't couple data transfer with component invocation. In other words, if producer A is connected to consumer B, when A changes its value B will not be notified immediately. Instead, after any number of values in the network has changed, the network as a whole can be told to update (the network will then notify all components whose inputs have been modified, in the order of a topological sort of the components). Alternatively, components can be invoked individually, which gives them a chance to check their inputs / modify their outputs. The BGL support layer for the Dataflow library is an example of how something that is not strictly a dataflow thing (e.g., a graph) can still satisfy Dataflow concepts (there are Components (vertices) that can be connected), and be used with the framework (e.g., you get a GUI editor for free). If you're interested in playing with this: The new GUI uses GLV (http://mat.ucsb.edu/glv/) which is included with the dataflow library in the sandbox and integrated in the bjam build of the examples. As long as you have glut/freeglut available, it should build using gcc/darwin, MSVC8+, gcc/minGW, and if you are better than me at knowing which X libraries to link with and know how to manipulate a Jamfile, gcc/linux (any GCC version 4.x should work). If you run into any problems, please let me know. The latest code is currently available from the sandbox only, instructions/docs at: http://www.dancinghacker.com/code/dataflow/ Any feedback would be appreciated. Kind regards, Stjepan

3 10

[phoenix] What is its state of play?
by Robert Jones 22 Jul '08

22 Jul '08

Hi I've just started looking at the Boost.Phoenix library, from a cold start, and I'm a bit confused! What version is current atm? It seems to be in flux between v1.2.1 and v2.0. Also, if someone could say a few words about any relationship between Phoenix and Lambda I'd really appreciate it. Does Phoenix replace Lambda, complement or coexist with it? Many Thanks, Rob.

2 1

[boostbook] Windows xsltlproc binary packages
by Daniel James 22 Jul '08

22 Jul '08

Hi, Is the version of xsltproc on the meta-comm site still not working? If it is, and it isn't possible to replace it, I'll change the boostbook documentation to link to the same binaries as the quickbook documentation (patch attached). thanks, Daniel

2 1

[phoenix] Where is the documentation?
by Robert Jones 22 Jul '08

22 Jul '08

Is there any definitive documentation for Phoenix? I've found http://www.boost.org/doc/libs/1_35_0/libs/spirit/phoenix/index.html http://spirit.sourceforge.net/dl_docs/phoenix-2/libs/spirit/phoenix/doc/htm… and various other web references, but I'm unsure if either is authoritative. Also, are any books about it? Alone the lines of Karlsson's book for Lambda? Thanks, Rob.

1 0

Re: [boost] [integer] Recent changes introduced failures on many platforms
by joaquin＠tid.es 22 Jul '08

22 Jul '08

Daryle Walker escribió: > Some of the compilers had weird errors reading in the preprocessor > marker '#' as regular code. I suspect that some compilers don't like > preprocessor selection within a macro-function call, which is what > I'm doing. I'll fix that first and we'll see what happens. > I think that this is in fact illegal according to Cpp rules. Mr. Mensonides or Mr. Kaiser will undoubtedly be able to tell for sure. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[lambda] Binding to templated functions
by Robert Jones 22 Jul '08

22 Jul '08

The Boost.Lambda library continues to delight and frustrate me! I have this code sequence, which is intended to determine whether a predicate is true for all objects pointed to by the second member of all of vector of pairs, #include <utility> #include <vector> #include <algorithm> #include "boost/lambda/lambda.hpp" #include "boost/lambda/bind.hpp" struct S { bool predOfS( ); }; int main( ) { using namespace std; using namespace boost :: lambda; typedef pair<int, S *> Pair; vector<Pair> pairs; bool trueForAll = ( find_if( _1, _2, _3 ) == _2 )( pairs.begin( ), pairs.end( ), ! bind( & S :: predOfS, bind( & Pair :: second, _1 ) ) ); } The last line gives me compile errors. Two things: - I think I need to specicy the template parameters to find_if, but I'm not sure quite what they are! - The error message reckons the last arg to find_if is placeholder<4>, not placeholder<3>, why? Or maybe there's completely different way to do this kind of thing? Thanks, Rob.

2 2

[integer] Proposal: minor addition to cstdint.hpp: largest integer types for value-based template arguments
by Daryle Walker 22 Jul '08

22 Jul '08

I just added some class templates that had declarations like: //======================================== template < intmax_t Value > struct whatever; //======================================== Afterwards, I was looking over some of the Boost.Integer headers and got curious about the BOOST_NO_INTEGRAL_INT64_T setting used within <boost/integer_traits.hpp>. I think we could add two typedefs to <boost/cstdint.hpp> //======================================== #if !defined(BOOST_NO_INT64_T) && defined(BOOST_NO_INTEGRAL_INT64_T) typedef signed long intmaxc_t; typedef unsigned long uintmaxc_t; #else typedef intmax_t intmaxc_t; typedef uintmax_t uintmaxc_t; #endif //======================================== Where "intmaxc_t" is the largest signed integer type that is suitable for integer constant expressions (like value-based template parameters) and "uintmaxc_t" is the unsigned equivalent. They should be the same as "intmax_t" and "uintmax_t" on non-broken compilers. I'd change my code to use the new types, to be safer. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 1

[lambda] Writing pass-through 'standard' algorithms
by Robert Jones 22 Jul '08

22 Jul '08

I encountered this difficulty in the context of passing lambda functors, but on reflection I don't the lambda aspect particularly matters. Consider this templated function template <typename InputIterator, typename Predicate> inline bool all_if( InputIterator first, InputIterator last, Predicate predicate ) { return std :: find_if( first, last, std :: not1( predicate ) ) == last; } Obviously the intent is to enquire if all members of a range satisfy the predicate. Now, as is, this doesn't compile, because it needs ptr_fun() on the predicate, but then a couple of things come up. - ptr_fun( ) requires that it's argument is a pointer-to-function - I'd like my all_if( ) to permit functions or functors, including lambda functors How can this be done? Is it impossible to dress-up a standard algorithm in this way? Thanks, Rob. -- ACCU - Professionalism in programming - http://www.accu.org

3 4

[utility] [C++0x] indices/make_indices
by Daniel Frey 22 Jul '08

22 Jul '08

While playing with GCC 4.3 and variadic templates, I came across the following problem: Say I have to write a function that takes a tuple as a parameter and needs to call another function with the expanded tuple. In code: template< typename... Ts > void f( const std::tuple< Ts... >& tp ) { g( tp... ); } OK, tp... doesn't work. Next try: template< typename... Ts > void f( const std::tuple< Ts... >& tp ) { g( std::get< Ns >( tp )... ); } That doesn't work either, but it's close, except that I only have Ts, not Ns (which need to expand from 0 to sizeof...( Ts ) - 1. Doug Gregor pointed me to N2080, which inspired me to create a light-weight general helper for cases where you need indices instead of types (or both). Here's the code that actually works: template< typename... Ts, std::size_t... Ns > void fimpl( const std::tuple< Ts... >& tp, const indices< Ns... >& ) { g( std::get< Ns >( tp )... ); } template< typename... Ts > void f( const std::tuple< Ts... >& tp ) { fimpl( tp, typename make_indices< sizeof...( Ts ) >::type() ); } with the following helpers: template< std::size_t... Ns > struct indices { }; template< std::size_t N, std::size_t... Ns > struct make_indices { typedef typename make_indices< N - 1, N - 1, Ns... >::type type; }; template< std::size_t... Ns > struct make_indices< 0, Ns... > { typedef indices< Ns... > type; }; While I appreciate any feedback/improvement/... on the specific problem/solution, there's also another issue here: These helpers are useful only for C++0x - I don't see how they could make any sense for the current C++ standard. There seem to be three options: a) Consider them an internal, undocumented implementation detail that other Boost libraries may use. No problem here, could be done today if there is interest. b) Make them part of the MPL. My gut feeling is that this is the wrong place - they don't belong to meta-programming because (as the example shows) they are useful in a variety of contexts. c) Make them a user-visible, documented feature of Boost. They are rather small so I'd compare them to next/prior: Not worth to be a full-fledged Boost library, but maybe part of Boost.Utilities. Thoughts? Regards, Daniel

5 15

Conflict between Boost.Integer and boost/detail/numeric_traits.hpp
by J. van der Wulp 21 Jul '08

21 Jul '08

Hello everyone, There seems to be a problem with using Boost.Integer in combination with anything that uses boost/detail/numeric_traits.hpp (development). The latter also defines a struct with name integer_traits that is not compatible with the one declared in Boost.Integer. The problem can be reproduced by including boost/graph/adjacency_list.hpp first and boost/integer.hpp as in: #include <boost/graph/adjacency_list.hpp> #include <boost/integer.hpp> int main() { return 0; } Swapping the include directives avoids the problem. Regards, Jeroen van der Wulp

2 3

Re: [boost] [Boost-users] [Boost.thread] Exception handling strategy ?
by vicente.botet 21 Jul '08

21 Jul '08

----- Original Message ----- From: "Anthony Williams" <anthony.ajw(a)gmail.com> To: <boost-users(a)lists.boost.org> Sent: Thursday, July 17, 2008 11:21 AM Subject: Re: [Boost-users] [Boost.thread] Exception handling strategy ? > > "Emil Dotchevski" <emil(a)revergestudios.com> writes: > >> Yes this should be easy, I'll do it after 1.36 ships. > > Excellent! If I understood, the MSVC-specific code allows the user to get the current exception without throwing the exception with boost::enable_current_exception(). What is the advantage if we can not profit of this mechanism with other compilers? A few months ago I proposed an intrusive way allowing the user to define which exceptions where wrapped by boost::exception_ptr. IMHO, the exception_ptr emulation (without language support) to transport exceptions between threads is not of real use if the user can not configurate the exceptions that can be thrown by 3pp as the Exception library do already for the STL exceptions. If the Exception library do not allow this, how can the Future library transport every exception between two threads? For recall, my proposal was the following: The exception library defines a macro such as: #define BOOST_EXCEPTION_CATCH_RETURN(EXCP) \ catch( EXCP & e ) { \ return exception_detail::current_exception_unknown_boost_exception(e); \ } The current_exception function has a USER_SLOT used us follows inline exception_ptr current_exception() { try { throw; } catch( exception_detail::cloning_base & e ) { exception_detail::clone_base const * c = e.clone(); BOOST_ASSERT(c!=0); return exception_ptr(c); } catch( std::invalid_argument & e ) { return exception_detail::current_exception_std_exception(e); } // ... as before #ifdef BOOST_EXCEPTION_USER_SLOT #include BOOST_EXCEPTION_USER_SLOT #endif catch( ... ) { return exception_detail::current_exception_unknown_exception(); } } The user can define BOOST_EXCEPTION_USER_SLOT to a file containing one line for each exception that must be transported: BOOST_EXCEPTION_CATCH_RETURN(3pp::exception1) BOOST_EXCEPTION_CATCH_RETURN(boost:lock_error) Of course this has a limitation: it works only if the function using the current_exception is also inlined. Best, Vicente

1 0

data_binding library for boost... Any interest?
by Tom Brinkman 21 Jul '08

21 Jul '08

Unfortunately, posting lots of code on here does not work well. Small snippits of a library work well, but just pasting the file into the message makes it difficult to read. You should just summarize your proposal and put a link to where the code can be found. Try to have a hello-world style example that gives a 5 minute introduction.

1 0

[lambda] Binding to abstract class methods
by Robert Jones 21 Jul '08

21 Jul '08

Is it possible to bind to pure virtual methods? Like this struct S { void methodOfS( ) = 0; }; void f( S & s ) { using namespace boost :: lambda; bind( & S :: methodOfS, _1 )( s ); } My compiler seems to be complaining that s is abstract, which is surely not a real limitation! Thanks, Rob.

2 2

passing ranges or output iterators to virtual functions
by Simon Richter 21 Jul '08

21 Jul '08

Hi, I've written two small class templates that basically "work for me" in the current state, but are not as generic as I'd like. The task at hand: pass a list of objects through a function call with fixed signature (such as a virtual function) without exposing the actual container type used. I'd like to get a bit of feedback on whether these might be a worthwhile addition to Boost (after some cleanup and implementation of features missing so far). I'll start with the simpler class: template<typename T> class output_iterator { class wrapper_base { public: virtual ~wrapper_base(void) throw() { } virtual void operator=(T const &) = 0; wrapper_base &operator*(void) { return *this; } wrapper_base &operator++(void) { return *this; } wrapper_base &operator++(int) { return *this; } }; template<typename O> class wrapper : public wrapper_base { public: wrapper(O o) : o(o) { } virtual void operator=(T const &v) { *o++ = v; } private: O o; }; public: template<typename O> output_iterator(O o) : o(new wrapper<O>(o)) { } output_iterator(output_iterator<T> const &o) : o(new wrapper<wrapper_base &>(*o.o)) { } output_iterator<T> &operator*(void) { return *this; } output_iterator<T> &operator++(void) { return *this; } output_iterator<T> &operator++(int) { return *this; } output_iterator<T> &operator=(T const &v) { *o = v; return *this; } private: std::auto_ptr<wrapper_base> o; }; Basically, that allows code like the following to work: class base { public: virtual ~base(void) throw() { } virtual output_iterator<int> get_some_ints(output_iterator<int>) = 0; }; class derived : public base { public: virtual ~derived(void) throw() { } virtual output_iterator<int> get_some_ints(output_iterator<int>); }; void derived::get_some_ints(output_iterator<int> o) { *o++ = 5; *o++ = 7; return o; } int main(int, char **) { std::list<int> l; derived d; base &b = d; b.get_some_ints(std::back_inserter(l)); // l now contains {5, 7} } The most obvious problem is that it fails for output iterators that do not advance on assignment, but that can be solved easily with a few more virtual functions in the wrapper. Something that is harder to do is that the return value from get_some_ints should be assignable to a type that is equal to int main(int, char **) { int some_ints[4]; int *next = some_ints; derived d; next = d.get_some_ints(next); } It does work if the returned output iterator is stored in an output_iterator<int>, and passing that to another function works as well. Extracting the int * would probably require RTTI. The third problem is that every time the output iterator is copied, memory is allocated, which is freed only when the last copy goes out of scope (there are some failure cases where memory is freed too early, but I think these are invalid uses of the output iterator). The second class attempts to do the same for range: template<typename T> void intrusive_ptr_add_ref(T *e, typename T::enumerator_tag = typename T::enumerator_tag()) { ++e->refcount; } template<typename T> void intrusive_ptr_release(T *e, typename T::enumerator_tag = typename T::enumerator_tag()) { if(!--e->refcount) delete e; } template<typename T> class range { class wrapper_base { public: virtual ~wrapper_base(void) throw() { } class enumerator { public: enumerator(void) throw() : refcount(0) { } virtual ~enumerator(void) throw() { } virtual T &operator*(void) const throw() = 0; virtual enumerator &operator++(void) throw() = 0; virtual bool operator!(void) const throw() = 0; private: unsigned int refcount; template<typename E> friend void intrusive_ptr_add_ref(E *, typename E::enumerator_tag); template<typename E> friend void intrusive_ptr_release(E *, typename E::enumerator_tag); struct enumerator_tag { }; }; virtual std::auto_ptr<enumerator> get(void) = 0; }; template<typename I> class wrapper : public wrapper_base { public: wrapper(I first, I last) : first(first), last(last) { } class enumerator : public wrapper_base::enumerator { public: enumerator(I current, I end) : current(current), end(end) { } virtual ~enumerator(void) throw() { } virtual T &operator*(void) const throw() { return *current; } virtual enumerator &operator++(void) throw() { ++current; return *this; } virtual bool operator!(void) const throw() { return current == end; } private: I current, end; }; virtual std::auto_ptr<typename wrapper_base::enumerator> get(void) { return std::auto_ptr<typename wrapper_base::enumerator>(new enumerator(first, last)); } private: I first, last; }; public: template<typename C> range(C const &container) : r(new wrapper<typename C::const_iterator>(container.begin(), container.end())) { } template<typename C> range(C &container) : r(new wrapper<typename C::iterator>(container.begin(), container.end())) { } template<typename F> F for_each(F f) { std::auto_ptr<typename wrapper_base::enumerator> e(r->get()); while(!!*e) { f(**e); ++*e; } return f; } class iterator : public std::iterator<std::input_iterator_tag, T> { public: iterator(void) : e() { } iterator(std::auto_ptr<typename wrapper_base::enumerator> e) : e(e.release()) { } T &operator*(void) const { return **e; } T *operator->(void) const { return &**e; } iterator &operator++(void) { ++*e; return *this; } bool operator==(iterator const &rhs) const { if(e.get() && !!*e) return rhs.e.get() && !!*rhs.e; return !rhs.e.get() || !*rhs.e; } bool operator!=(iterator const &rhs) const { return !operator==(rhs); } private: boost::intrusive_ptr<typename wrapper_base::enumerator> e; }; iterator begin(void) { return iterator(r->get()); } iterator end(void) { return iterator(); } private: wrapper_base *r; }; Again, this class is pretty much incomplete, but "works for me". The iterator can only implement the input iterator category as it is not possible to compare two non-singular iterators. More constructors could be added that accept other inputs than containers (I can also see the memory leak, although valgrind can't -- the pointer inside the range<T> class should probably be a shared_ptr or intrusive_ptr). Any comments on these so far? Is the general idea useful? Simon

4 4

[web-site] Bad link...
by Jurko Gospodnetić 21 Jul '08

21 Jul '08

Hi. When you click on the link 'Trunk Issues' (http://www.boost.org/development/tests/trunk/developer/issues.html) on the right side of the http://www.boost.org/development/running_regression_tests.html page. you get two frames with the left one just saying 'File not found'. I'm guessing this is some stale link... Best regards, Jurko Gospodnetić

2 1

Patch for Jamroot on the release branch.
by Jurko Gospodnetić 20 Jul '08

20 Jul '08

Hi Beman. Would it be ok to add an 'import generate ;' statement to the main Boost library Jamroot file (see the attached patch)? That is the module where the 'generate' rule used in that file is defined. Although not strictly necessary this does not change anything for the build but will avoid breaking the build once we remove some extra module imports in Boost Build. I already committed the same change to the trunk. Best regards, Jurko Gospodnetić Index: Jamroot =================================================================== --- Jamroot (revision 47611) +++ Jamroot (working copy) @@ -98,6 +98,7 @@ # - handle boost version # - handle python options such as pydebug +import generate ; import modules ; import set ; import stage ;

1 0

[Boost-users] [multi_array] Everyone, please make your value-types Assignable! (was: Re: more on assignability)
by Daryle Walker 20 Jul '08

20 Jul '08

On Jul 17, 2008, at 3:19 PM, Ronald Garcia wrote: > On Jul 11, 2008, at 6:17 AM, Dr Johann A. Briffa wrote: > >> I realize this topic has been discussed before (I've seen at least >> a thread in 2006 and another in 2007), but I believe there is more >> to add. At issue is the decision that multi_array objects cannot >> be assigned [with the operator=() that is] unless the target is >> already the same size as the source. Further, there is no >> documented way to easily resize an existing array to the same size >> and range as some other array. > > Indeed there is no built-in way to easily resize a multi_array to > be the same size as another multi_array. While there is no resize > member function that takes a pointer, there is one that takes a > model of the Collection concept (classes like boost::array and > std::vector are concepts). Based on this interface, here is a stop- > gap non-invasive solution that can resize a multi_array based on > another model of MultiArray (multi_array, multi_array_ref, etc.): [TRUNCATE] Let's define some stuff here: T: some type you created, probably a class type a: an object of type T; it's valid, i.e. meets its invariants b: another object of type T, also valid; any similarities or differences in its state from a's state is unspecified C: the set of all valid states an object of type T may have Let function F: x -> Y, map a T object state x to a (sub)set of C named Y. This function returns the subset of source states that a given state can receive during an assignment. If there exists at least one x in C such that F(x) = Y < C, then type T is _NOT_ Assignable! In other words, the number of assignment- compatibility classes in T must be exactly one for T to be Assignable. Furthermore, an Assignable type requires that the destination object's observable state post-assignment matches the observable state of the source object. The destination's new state can't be the old state quasi-merged with the source's state. (The destination object's old state must appear to be splattered, but remnants could be cached to the new state.) Fortunately, most types are Assignable. What happens if your type isn't? 1. Users can't use objects of that type in standard containers, which assume to be able to freely copy objects as much as they want. 2. Such objects are a pain to work with. Any containing class must write custom assignment operators to add calls to your custom copying routine. Of course, they have to first check if the source and destination objects are in the same assignment-compatibility class, and reconfigure at least one of those two objects if they're not in the same class. The exception would be if the wrapping class always makes sure that every T object it creates is of the same class. Even that is a pain because the user has to manually confirm that invariant every time s/he changes or adds a mutating function. 3. It isn't safe. You are effectively dumping the responsibility of assignment onto your users, who won't have all the information. The user generally has to test compatibility, reconfigure at least one object, then do call the custom copying routine. These steps are distinct, so if one of the mutating steps throws, the user will probably lose his/her old state forever and have a default-valued object. Your assignment routine would have more information available, so it can structure the assignment with roll-back during throws. (This could be moderated with a swap routine that doesn't care about assignment-compatibility classes. You do have a custom swap, right? And it does work irrespective of class, right?!) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 9

[circular_buffer] release branch still not upated!
by Thorsten Ottosen 18 Jul '08

18 Jul '08

Hi Jan, The default constructor for circular_buffer is still not updated in the release branch, and it is the only reason that ptr_container is failing on the release branch: explicit circular_buffer(const allocator_type& alloc = allocator_type()) : m_size(0), m_alloc(alloc) { initialize(max_size()); } The one in trunk reads: explicit circular_buffer(const allocator_type& alloc = allocator_type()) : m_buff(0), m_end(0), m_first(0), m_last(0), m_size(0), m_alloc(alloc) {} Please update as soon as possible, or tell me to do it for you. Thanks -Thorsten

2 4

Boost Build Changes break serialization jamfile and stop regression tests
by Anthony Williams 18 Jul '08

18 Jul '08

Hi, I just tried to run a batch of regression tests against trunk, and found that they failed rather quickly due to bjam aborting with the following error: error: Unable to find file or target named error: 'serialization_test//test_class_info_save_text_archive' error: referred from project at error: '.' This error causes the entire test run to fail before it's even started. It appears this was caused by revision 47536. Please could someone either revert the change or fix the failure. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

3 2

[serialization] Change between 1.33.1 & 1.35
by loic.actarus.joly＠numericable.fr 18 Jul '08

18 Jul '08

1 0

Strange commit failure on release branch.
by John Maddock 18 Jul '08

18 Jul '08

Folks, I'm trying to update the Boost.Math docs on the release branch but I get: Error: Commit failed (details follow): Error: File or directory 'html\math_toolkit\special\expint\expint_i.html' is out of Error: date; try updating Error: The version resource does not correspond to the resource within the Error: transaction. Either the requested version resource is out of date (needs to be Error: updated), or the requested version resource is newer than the transaction root Error: (restart the commit). Now the thing is I *have* made sure that the whole branch is up to date, and in any cases there are no changes to that file in SVN, so I'm stumped. Any ideas anyone? Thanks, John.

2 2

[1.36.0] Libraries with unmerged changes?
by Beman Dawes 18 Jul '08

18 Jul '08

Below is a list of libraries whose header files appear to differ between the trunk and branches/release. The most likely causes are: * Changes that should be merged into branches/release for 1.36.0. If that is the case, developers need to merge those changes right away! * Work in process that should *not* be merged into branches/release for 1.36.0. Please let me know that that is the case so I can stop worrying:-) * Issues with the newly minted script used to generate the report. Please let me know so the script can be improved. Thanks, --Beman archive asio bimap circular_buffer compatibility config date_time detail dynamic_bitset exception filesystem format function function_types fusion gil graph intrusive io iostreams iterator math mpi mpl numeric optional parameter pending pool program_options property_tree python random regex serialization signals spirit statechart system test thread tr1 type_traits units utility

23 94

[test] BOOST_TEST_MAIN,BOOST_AUTO_TEST_CASE and MFC
by Robert Caldecott 18 Jul '08

18 Jul '08

I use the Boost Test library extensively, and to save time, I always define BOOST_TEST_MAIN and add tests using BOOST_AUTO_TEST_CASE. This works fine for most projects, but now I need to test some MFC code. In order for MFC objects to work correctly, I need to make a call to AfxWinInit, but the only way I can see to do this is to define my own init_unit_test_suite function and add tests 'by hand', rather than using BOOST_AUTO_TEST_CASE. Does anyone know of a way I can avoid adding tests by hand? Does the Boost auto main stuff make a call to any init function I can override, so I can squeeze in an MFC init call? Thanks in advance.

2 2

[bind] function_equal with binds holding weak_ptr values
by Sylvester-Bradley, Gareth 18 Jul '08

18 Jul '08

(Apologies for not posting my previous question in plain-text.) Bind can be used with weak_ptr values, but should function_equal work with binds holding weak_ptrs? Since weak_ptr doesn't have operator==, the following results in a compiler error: #include <boost/function_equal.hpp> #include <boost/bind.hpp> #include <boost/weak_ptr.hpp> int h( boost::weak_ptr<void> wp ) { return wp.use_count(); } template < typename F > bool self_equal( F f_ ) { return function_equal( f_, f_ ); } int main( int argc, char * const argv[] ) { self_equal( boost::bind( h, _1 ) ); // OK self_equal( boost::bind( h, boost::weak_ptr<void>() ) ); // compiler error return 0; } Would it be appropriate to use operator< equivalence? I suspect the answer may be "it depends...", but I made the above compile by adding the following: namespace boost { namespace _bi { template<class T> class value< weak_ptr<T> > { public: value(weak_ptr<T> const & t): t_(t) {} weak_ptr<T> & get() { return t_; } weak_ptr<T> const & get() const { return t_; } bool operator==(value const & rhs) const { return !(t_ < rhs.t_) && !(rhs.t_ < t_); } private: weak_ptr<T> t_; }; } } Is that a good or bad idea? Thanks, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

2 2

[bind] function_equal with nested binds
by Sylvester-Bradley, Gareth 18 Jul '08

18 Jul '08

Should function_equal work with nested binds? I expected the following to work but it results in a compiler error: #include <boost/function_equal.hpp> #include <boost/bind.hpp> void f( int ) {} int g( int i ) { return i+5; } template < typename F > bool self_equal( F f_ ) { return function_equal( f_, f_ ); } int main( int argc, char * const argv[] ) { self_equal( boost::bind( f, _1 ) ); // OK self_equal( boost::bind( g, _1 ) ); // OK self_equal( boost::bind( f, boost::bind( g, _1 ) ) ); // compiler error } I made it compile by adding the following: namespace boost { namespace _bi { template<class R, class F, class L> bool ref_compare( bind_t<R,F,L> const & a, bind_t<R,F,L> const & b, long ) { return a.compare(b); } } } Is that OK? Thanks, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

2 2

[flyweight][parameter] is there an interest in this template parameter expresion
by vicente.botet 18 Jul '08

18 Jul '08

Hello, I'm doing a Locally Unique Identifier generator library. The DSL grammar is quite complex, so the use of optional class parameters seams unavoidable. I have started to use the Boost.Parameter Library as the Boost.Flyweight does. The flyweight class that takes 5 optional parameters and is currently declared as follows <code> template< typename T, typename Arg1,typename Arg2,typename Arg3,typename Arg4,typename Arg5 > class flyweight { private: typedef parameter::parameters< parameter::optional< parameter::deduced<tag<> >, detail::is_tag<boost::mpl::_> >, parameter::optional< parameter::deduced<tracking<> >, is_tracking<boost::mpl::_> >, parameter::optional< parameter::deduced<factory<> >, is_factory<boost::mpl::_> >, parameter::optional< parameter::deduced<locking<> >, is_locking<boost::mpl::_> >, parameter::optional< parameter::deduced<holder<> >, is_holder<boost::mpl::_> > > signature; typedef typename signature::bind< Arg1,Arg2,Arg3,Arg4,Arg5 >::type args; typedef typename parameter::binding< args,tag<>,mpl::na >::type tag_type; typedef typename parameter::binding< args,tracking<>,refcounted >::type tracking_policy; typedef typename parameter::binding< args,factory<>,hashed_factory<> >::type factory_specifier; typedef typename parameter::binding< args,locking<>,simple_locking >::type locking_policy; typedef typename parameter::binding< args,holder<>,static_holder >::type holder_specifier; typedef parameter::parameters< parameter::optional< parameter::deduced< detail::unmatched_arg >, mpl::not_< mpl::or_< detail::is_tag<boost::mpl::_>, is_tracking<boost::mpl::_>, is_factory<boost::mpl::_>, is_locking<boost::mpl::_>, is_holder<boost::mpl::_> > > > > unmatched_signature; typedef typename unmatched_signature::bind< Arg1,Arg2,Arg3,Arg4,Arg5 >::type unmatched_args; typedef typename parameter::binding< unmatched_args,detail::unmatched_arg, detail::unmatched_arg >::type unmatched_arg_detected; BOOST_STATIC_ASSERT(( /* You have passed a type in the specification of a flyweight type that * could not be interpreted as a valid argument. */ is_same<unmatched_arg_detected,detail::unmatched_arg>::value)); ... </code> I have made abstraction of the common structure of this code resulting on a 'expr' class. The boost::dsl::expr class has three parameters: * a tag for the expression * a vector of parameters specification, each one been either mandatory or optional, and containing a tag, a predicate stating if a parameter corresponds to the tag, and a default value for the optionals * a vector of the current parameters The parameter associated to a given tag can be obtained using the get template function. For example to get the tracking parameter we can use: typename base_type::template get<tracking<> >::type All the implementation details are encapsulated on the expre class. The flyweight class can then be rewriten as: <code> #define BOOST_FLYWEIGHT_BASE dsl::expr<flyweight<T>, mpl::vector< \ dsl::optional<tag<>, detail::is_tag<mpl::_>, mpl::na >, \ dsl::optional<tracking<>, is_tracking<mpl::_>, refcounted >, \ dsl::optional<factory<>, is_factory<mpl::_>, hashed_factory<> >, \ dsl::optional<locking<>, is_locking<mpl::_>, simple_locking >, \ dsl::optional<holder<>, is_holder<mpl::_>, static_holder > \ >, \ mpl::vector<Arg1,Arg2,Arg3,Arg4,Arg5> > template< typename T, typename Arg1,typename Arg2,typename Arg3,typename Arg4,typename Arg5 > class flyweight : public BOOST_FLYWEIGHT_BASE { typedef BOOST_FLYWEIGHT_BASE base_type; #undef BOOST_FLYWEIGHT_BASE typedef typename base_type::template get< tag<> >::type tag_type; typedef typename base_type::template get< tracking<> >::type tracking_policy; typedef typename base_type::template get< factory<> >::type factory_specifier; typedef typename base_type::template get< locking<> >::type locking_policy; typedef typename base_type::template get< holder<> >::type holder_specifier; // ... }; </code> BOOST_FLYWEIGHT_BASE is used to avoid repeating the long template expression I would like to know if there is an interest in such a class, and if it could be added to the parameters library? Of course, any improvements are welcome. The expr.hpp and expr_pp.hpp files are attached. The class is able to manage with a variable number of parameters (BOOST_DSL_EXPR_ARITY) when BOOST_DSL_EXPR_PP is defined or up to 3 otherwise. Best Regards Vicente Juan Botet Escriba P.S. The variadic template code is not correct.

4 7

[ptr_container] Two release branch tests failing on all platforms
by Beman Dawes 18 Jul '08

18 Jul '08

See http://beta.boost.org/development/tests/release/developer/ptr_container.html These tests aren't failing on trunk, yet it doesn't look like there are any unmerged changes pending. Presumably that means some dependency has unmerged changes. We need to clear these failures ASAP. Thanks, --Beman

1 1

[functional/hash] Failing link_ext_test on Windows both trunk and release
by Beman Dawes 18 Jul '08

18 Jul '08

link_ext_test has a link failure on Windows both trunk and release. See http://beta.boost.org/development/tests/release/developer/functional-hash.h… We need to clear this ASAP. --Beman PS: The error is an unresolved external to "test_main" in Boost.Test, so this may be a Jamfile problem rather than a problem with the library's actual code.

2 1

Re: [boost] Is our subversion server/archive 1.5 yet?
by Douglas Gregor 18 Jul '08

18 Jul '08

On Sun, 2008-06-29 at 16:12 -0400, Daryle Walker wrote: > Last week, a was bouncing around sites and found out that Subversion > 1.5.0 has gone final. I've downloaded it because I want to try its > built-in merging support (to fix up Boost.Integer in a branch). Has > our subversion system been updated to 1.5? No, we're still using Subversion 1.4 on the server. > Obviously, if the client and server use subversion versions 1.x and > 1.y respectively, the transactions will proceed as the lower of those > versions. Therefore, both individual clients and the server must be > at least the 1.5 level to use built-in merging. There's another > requirement, though: if the server is upgraded to 1.5, the > repositories it manages aren't automatically upgraded. If a > repository isn't upgraded to the 1.5 format, then the server will act > in 1.4-compatibility mode as needed. > > Is there a schedule for these upgrades to be done (if not done > already)? Is it possible to tell from the client side which mode a > server/repository uses? I actually don't know how to tell from the client-side which version of Subversion the server is running. As for the upgrade... we're looking into Subversion 1.5, but it appears to be a nontrivial process to perform the upgrade and migrate svnmerge.py merge information appropriately, so we need to read more, do some test runs, check that other projects haven't run into serious problems, etc. So much depends on the Subversion repository that we need to be careful. When we're ready to move, we'll send out an e-mail to the mailing list. - Doug

6 8

[fusion] pair documentation issues
by Steven Watanabe 17 Jul '08

17 Jul '08

AMDG The documentation of fusion::pair has a number of problems http://www.boost.org/doc/libs/1_35_0/libs/fusion/doc/html/fusion/support/pa… template <typename First, typename Second> struct first; Should be template<class Pair> struct first; Similarly for second. Also, there is a missing ` in the expression semantics table, which looks horrible as a result. In Christ, Steven Watanabe

2 1

[system] documentation bug, error_code::value_type
by Arvid Norberg 17 Jul '08

17 Jul '08

The boost.system documentation mentions a value_type typedef in boost::system::error_code several times in: http://www.boost.org/doc/libs/1_35_0/libs/system/doc/reference.html#Class-e… In ther header file there is no such typedef, just an int is used. I've filed a ticket here: http://svn.boost.org/trac/boost/ticket/2125 -- Arvid Norberg

1 0

[lambda] Composing lambda expressions
by Robert Jones 17 Jul '08

17 Jul '08

Given a bit of code like this, struct S { bool pred( ) const; }; typdef vector<pair<string, S *> > V; V :: const_iterator i; i -> second -> pred( ); I'd like to rewrite the last line as a lambda expression. Looking at the documentation, I think this is done with bind( & S :: pred, bind( & V :: value_type :: second, _1 ) )( * i ); which works. But I'd rather be writing something like ( _1 -> second -> pred )( * i ); Am I right in thinking that Boost.Lambda just doesn't work like this, and the frst form is how it's done? Thanks, Rob.

3 4

[fusion] constructing all elements of the fusion vector with the same argument
by Stjepan Rajko 17 Jul '08

17 Jul '08

Hello, I recently ran into a need to initialize a fusion vector with a single argument which is then used to construct all of the vector elements. For example, something that would allow: fusion::vector<int, float, double> ones(initialize_all_with(),1); // at_c<0>(ones) == 1 // at_c<1>(ones) == 1.0f // at_c<2>(ones) == 1.0; I hacked fusion::vector so that the above works. Is this addition of interest to anyone else? There is another (perhaps more elegant) solution in implementing a new fusion "array" Sequence (one where all element types are identical) which can construct all elements from a single constructor argument, and then using that sequence to do the above initialization. E.g., fusion::vector<int, float, double> ones(fusion::array<int, 3>(1)); ... or (another solution) a make_array function that returns a fusion::vector: fusion::vector<int, float, double> ones(fusion::make_array<3>(1)); It would be great if one of these solutions (or a different solution) were added to fusion. I can take a stab at putting something together, if any of them are acceptable. That is, unless this is already possible in some way that I can't see at the moment :-) Regards, Stjepan

5 12

Possible MingW ASIO bug with Boost 1.35.0 g++ 4.2.1
by Jason Turner 17 Jul '08

17 Jul '08

Some ASIO test code is crashing in a way that I do not understand. GDB is unable to debug it (no stack available on crash) and the error is a rather obtuse "This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information." Test code which crashes: #include <boost/asio/ip/address.hpp> #include <iostream> int main() { std::cout << boost::asio::ip::address::from_string("1.1.2.3") << std::endl; } By changing the asio file included, the code no longer crashes: #include <boost/asio.hpp> #include <iostream> int main() { std::cout << boost::asio::ip::address::from_string("1.1.2.3") << std::endl; } This is windowsxp professional, gcc version 4.2.1-dw2. I'm unable to test this on Linux at the moment, so I do not know if it affects other platforms. -Jason -- http://emptycrate.com Games, Programming, Travel & other stuff

2 2

[iochain] mutable_buffer issues
by Robert Dailey 17 Jul '08

17 Jul '08

Assume the following code, which I wrote in an attempt to test very basic functionality of Boost.Iostream: namespace io = boost::io; void foo() { std::vector<boost::uint8_t> data; io::source<io::iobyte> src( io::chain( io::read_mem( data ) ) ); io::iobyte rcvbuffer; const io::mutable_buffer<io::iobyte> mutbuffer( &rcvbuffer, sizeof( rcvbuffer ) ); src.read( mutbuffer ); } The first issue I have is with mutable_buffer. Notice how it requires a template argument that *must* be the exact type passed into the io::source template parameter, in this case io::iobyte. Passing any other type in here results in lots of compiler errors on MSVC 9. Basically my biggest issue with this is that I can't pass an "int" into the mutable_buffer here if I want to read 4 bytes, because the type passed in must match io::iobyte. In my opinion, mutable_buffer should accept *any* type and just read in the number of bytes requested. Without this I fail to see the usefulness of mutable_buffer. The second issue has to do with the type of the first parameter in io::source::read(). Notice it takes a "const mutable_buffer&". Why is it taking a const mutable_buffer if the buffer is mutable? This seems conceptually wrong. I would expect it to take a "mutable_buffer&".

1 1

[math][constants] Documentation?
by Michael Marcin 17 Jul '08

17 Jul '08

I found the math constants library in the 1.35.0 release and it looks like it will be useful to me. I can't find it documented anywhere however. It is not in a detail folder so I assume it is a public library. I've found documentation for a Math Constants library on yahoo groups from what looks like the initial review of this library. http://lists.boost.org/Archives/boost/2003/06/48724.php Is this the same library? Where did the documentation go? Thanks, Michael Marcin

3 2

[iochain] Suggestion for chain
by Robert Dailey 17 Jul '08

17 Jul '08

Hi, Currently I'm doing this: namespace io = boost::io; std::vector<boost::uint8_t> data; io::source<io::iobyte> src( io::chain( io::read_mem( data ) ) ); Notice how I have to specify io::chain() explicitly. Would it be possible for it to be implicitly constructable from a stub? This would allow me to clean up the code a bit to this: namespace io = boost::io; std::vector<boost::uint8_t> data; io::source<io::iobyte> src( io::read_mem( data ) ); Doing this results in compiler errors right now. Finding the solution to the problem (as obvious as it seems) took a long time for me.

1 0

[asio] SSL documentation
by Michael Marcin 17 Jul '08

17 Jul '08

The ASIO documentation leaves a lot to be desired when it comes to its SSL support. All the SSL related classes have 1 line of meaningless documentation in the reference section. There is 1 SSL related example with no comments in it. There is no mention of SSL in the Tutorial or Design sections. Has anyone written some documentation, a blog, or even a newsgroup post about the SSL portion of ASIO? Thanks, Michael Marcin

2 2

[iochain] Overloaded >> and << operators?
by Robert Dailey 17 Jul '08

17 Jul '08

Hi, Reading through the documentation for the Boost.Iochain library, I do not see that any default >> and << operators have been provided. I would expect to be able to use these to stream data out of a stream and into a stream, respectively. An example of the >> operator would be below: template< typename t_type > source& operator>> ( source& stream, t_type& data ) { stream.read( data ); return stream; }

1 0

[1.36.0] Beta plans
by Beman Dawes 17 Jul '08

17 Jul '08

According to the schedule, a 1.36.0 beta release is due today. I'm going to delay the beta because there are still too many release regression test failures. See http://beta.boost.org/development/tests/release/developer/summary.html. Developers with release test failures need to redouble efforts to clear those failures. I'll start pester individuals where there doesn't seem to be any movement. The good news is that the number of failures is dropping fairly quickly as backed up merges for several important libraries takes effect, so I don't expect the delay to last more than a few days. Thanks, --Beman

1 0

Boost with Intel/VS
by Adam Black 17 Jul '08

17 Jul '08

Am trying to use boost::circular_buffer. I am using the Intel Compiler v10.1 and am building via VS 2008. Read as the Intel Compiler is bolted up to VS. I am getting the following error: ..\boost_1_35_0\boost/mpl/aux_/integral_wrapper.hpp(80): error: expected an operator 1> operator AUX_WRAPPER_VALUE_TYPE() const { return static_cast<AUX_WRAPPER_VALUE_TYPE>(this->value); } 1> ^ 1> 1>..\boost_1_35_0\boost/mpl/aux_/integral_wrapper.hpp(80): error: identifier "L" is undefined 1> operator AUX_WRAPPER_VALUE_TYPE() const { return static_cast<AUX_WRAPPER_VALUE_TYPE>(this->value); } This is my first foray into boost. I have tried using the Windows install of boost as well as manually changing BOOST_COMPILER_CONFIG "boost/config/compiler/intel.hpp" in boost/config/user.hpp From what I've gleaned thus far that should have solved my issue. But it hasn't. I'm at a loss and as time is short I am going to throw this out there for any tips or suggestions. Thank you.

2 2

Separate Boost newsgroups for individual Boost libraries
by Edward Diener 17 Jul '08

17 Jul '08

I would like to suggest that Boost have separate NGs for each individual library. I also think, for each individual library, a separate user and developer NG should exist. While this will lead to many more NGs, it will make it much easier for users/developers to have concerns addressed for a particular Boost library, and to have the implementor of that library address those concerns. Also of course it will make it easier for people interested, or working with, a particular Boost library, to go to the appropriate NG to read about any issues brought up regarding that library. This is especially important as more Boost library are developed. If a post deals with issues that can not constrained to a single library, it can go to the current 'user' or 'devel' NG as appropriate.

5 5

[smart_ptr> C++0x unique_ptr ?
by Loïc Joly 17 Jul '08

17 Jul '08

Hello, I was wondering whether there was any plan to implement a unique_ptr in boost, that would replace scoped_ptr, and would default to scoped_ptr on compilers lacking move semantic? Best regards, -- Loïc

9 21

Fwd: [GIL] Point concept
by Felipe Magno de Almeida 17 Jul '08

17 Jul '08

---------- Forwarded message ---------- From: Felipe Magno de Almeida <felipe.m.almeida(a)gmail.com> Date: Thu, Jul 10, 2008 at 3:28 AM Subject: [GIL] Point concept To: boost-users(a)lists.boost.org Hi, PointNDConcept is defined as having axis_value member functions. But the GIL code in the boost trunk doesn't comply with this requirement. A free axis_value function is just useless, because it can't be found by ADL when template parameters are passed explicitly. Also, member template axis doesn't model Metafunction. Am I missing something? Regards, -- Felipe Magno de Almeida -- Felipe Magno de Almeida

3 3

[1.36.0] Libraries with unmerged changed - more accurate results.
by Beman Dawes 17 Jul '08

17 Jul '08

Below is a more accurate list of headers and libraries whose header files appear to differ between the trunk and branches/release. The most likely causes are: * Changes that should be merged into branches/release for 1.36.0. If that is the case, developers need to merge these changes right away! * Work in process that should *not* be merged into branches/release for 1.36.0. Please let me know that that is the case so I can stop worrying:-) * Although it seems to be working much better, there still may be issues with the script used to generate the report. Please let me know so the script can be improved. Thanks, --Beman Headers: any.hpp concept_check.hpp enable_shared_from_this.hpp intrusive_ptr.hpp lexical_cast.hpp make_shared.hpp memory_order.hpp operators.hpp pointer_cast.hpp pointer_to_other.hpp rational.hpp scoped_array.hpp scoped_ptr.hpp shared_ptr.hpp smart_cast.hpp static_assert.hpp static_warning.hpp swap.hpp tokenizer.hpp weak_ptr.hpp Libraries: asio bimap circular_buffer config date_time detail filesystem function function_types graph interprocess intrusive iostreams iterator math mpl numeric optional parameter pool program_options property_tree python regex serialization signals spirit statechart system test tr1 type_traits units utility

9 20

[any] small buffer optimizations?
by Thorsten Ottosen 16 Jul '08

16 Jul '08

Hi, As eplained in http://www.codeproject.com/KB/cpp/dynamic_typing.aspx boost::any is not exactly optimal w.r.t. efficiency. Diggins implementation avoid allocation for objects smaller or equal to sizeof(void*). Personally I think this is too small a buffer; Boost.Function uses at least two words; I think it might be worth to go for 3 words. Would anyone be interested in implementing this? best regards -Thorsten

4 3

Help with Access Violation in simple serialization
by Tiago da Silva 16 Jul '08

16 Jul '08

Hi there, I am having some serious problems when trying to instantiate either a boost::archive::xml_oarchive or a boost::archive::text_oarchive: everytime I receive an "Unhandled exception at XXX (msvcr90d.dll) in XXX : Access violation writing location" I have simplified a test case up to this: structure I want to save (in whatever.h): typedef struct s_pt { int x; int y; bool operator< (const struct s_pt &spt2) const { return (x < spt2.x) && (y < spt2.y); } bool operator== (const struct s_pt &spt2) const { return (x == spt2.x) && (y == spt2.y); } template<class Archive> // turns into a serializable component void serialize(Archive &ar, const unsigned int version) { using boost::serialization::make_nvp; ar & make_nvp("x", x); ar & make_nvp("y", y); } } POINT2D; saving routine in main.cpp std::ofstream ofs("savedProject.imag3d"); boost::archive::xml_oarchive oa(ofs); const structs::POINT2D p = {111, 222}; oa << boost::serialization::make_nvp("p2d", p); but I get this error in boost::archive::xml_oarchive oa(ofs); I have tried already both xml_oarchive and text_oarchive... but the demo.cpp provided by http://www.boost.org/doc/libs/1_35_0/libs/serialization/doc/index.html involving the bus routes works!!! what am I doing wrong??? I use Visual Studio 2008. Thanks in advance, Tiago

3 7

[GIL] 3d image support
by Falco Hirschenberger 16 Jul '08

16 Jul '08

Hi, As I read from the documentation, GIL supports N-dimensional image concepts but lacks an Implementation of 'PointNDConcept', 'RandomAccessNDImageViewConcept', 'RandomAccessNDImageConcept' and 'RandomAccessNDLocatorConcept' for 3d images. Has anybody implemented these as extension to GIL or is it on the TODO list? What do you think will be the effort to implement them? Is it a no-brainer by just implementing the concepts similar to the 2d counterparts or will there be some difficulties from the design? Greetings, Falco

3 2

[1.35.0] Serialization demo.cpp problem
by Scott Woods 16 Jul '08

16 Jul '08

Hi, Just trying to get a comparison going between several different techniques for serialization. After downloading 1.35.0 and using the beautiful auto-installer it was looking pretty good. Trying to compile demo.cpp hasnt gone quite so well; Deleting intermediate files and output files for project 'demo - Win32 Debug'. --------------------Configuration: demo - Win32 Debug-------------------- Compiling... demo.cpp c:\program files\boost\boost_1_35_0\boost\serialization\utility.hpp(50) : error C2989: 'is_bitwise_serializable<struct std::pair<T,`template-parameter258'> >' : template class has already been defined as a non-template class c:\program files\boost\boost_1_35_0\boost\serialization\utility.hpp(50) : error C2988: unrecognizable template declaration/definition c:\program files\boost\boost_1_35_0\boost\aligned_storage.hpp(59) : fatal error C1506: unrecoverable block scoping error Error executing cl.exe. demo.exe - 3 error(s), 0 warning(s) I've searched the mail arachives. There have been a few issues around demo.cpp but they seem unrelated. Anyone know whats going on? Windows XP, Microsoft Visual C++ 2005. Thanks, Scott

1 0

[statechart] test failures on the release branch
by Richard Webb 15 Jul '08

15 Jul '08

Merging the changes in Function to the release branch has caused some failures in the statechart tests (e.g. http://tinyurl.com/6hmxod) So i guess that Statechart needs to be merged as well now? Thanks, Richard Webb

2 2

Re: [boost] Bind question, is there any way to implicitly go through a reference_wrapper?
by Michael Goldshteyn 15 Jul '08

15 Jul '08

"Peter Dimov" <pdimov(a)pdimov.com> wrote in message news:00c501c8e6b1$b3a11f60$6607a80a@pdimov2... > > It doesn't because of the mem_fn behavior that bind inherits. The > argument is not a reference to Crayon and so is assumed to be a smart > pointer to Crayon. mem_fn then tries to invoke get_pointer() on it to obtain a Crayon*. > You should be able to make it compile by adding a get_pointer overload > for > reference_wrapper: > > namespace boost > { > > template<class T> T* get_pointer( reference_wrapper<T> const & r ) { > return r.get_pointer(); > } > > } That would be an awesome addition, since reference_wrapper is an oft-used part of boost and there's really no reason for it not to be automatically traversed, making bind constructs that involve it a little simpler. Thanks, Michael Goldshteyn

1 0

[extension] factory_map::get() suggestion
by Robert Dailey 15 Jul '08

15 Jul '08

Currently, there is no typedef to provide a convenient way to create variables of the return type of boost::extensions::factory_map::get(). For example, right now I have to do this: factory_map fm; std::map<int, factory<word> > & factory_list = fm.get<word, int>(); It would be ideal to do this instead: factory_map fm; factory_map::type& factory_list = fm.get<word, int>(); Could this be done?

5 10

Bind question, is there any way to implicitly go through a reference_wrapper?
by Michael Goldshteyn 15 Jul '08

15 Jul '08

Here is a contrived example that illustrates the issue: #include <boost/bind.hpp> #include <boost/ref.hpp> #include <string> // Define a simple class for our example class Crayon { public: explicit Crayon(const std::string &color=std::string()):m_color(color) {} const std::string &GetColor() const {return m_color;} private: std::string m_color; }; int main(int argc, char *argv[]) { using namespace std; using namespace boost; Crayon cr("blue"); boost::reference_wrapper<const Crayon> crefCr(cr); // This compiles std::string color(boost::bind(&Crayon::GetColor,_1)(cr)); // This also compiles, using an explicit get on crefCr std::string colorFromConstRef(boost::bind(&Crayon::GetColor,boost::bind(&boost::referenc e_wrapper<const Crayon>::get,_1))(crefCr)); // This doesn't compile, however, even though the reference_wrapper class template has // an overloaded operator T& () const function std::string colorFromConstRef2(boost::bind(&Crayon::GetColor,_1)(crefCr)); }

2 1

Re: [boost] [thread_pool]: formal review request
by Oliver Kowalke 15 Jul '08

15 Jul '08

> Do you have formal documentation? > Emil Dotchevski > Reverge Studios, Inc. > http://www.revergestudios.com/reblog/index.php?n=ReCode documentation should be included in the archive Oliver -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx

1 0

version 0.2.1 of Mirror available
by Matus Chochlik 15 Jul '08

15 Jul '08

Hi there, a new version of the Mirror reflection library is available in both the vault and the sandbox. This version includes multiple important changes and many things were rewritten from scratch. Just to mention some of them: - nearly all of the registering and reflection macros have (hopefully ;) ) become more user friendly and some more universal. - more complex types like multi-dimensional arrays and functions/ pointers-to-function/references-to-functions are now supported by the typename returning functions base_name() and full_name(), which were also completely rewritten. And are now returning C++ strings. - registering of typedefined types - support for registering attributes with types derived from typedef-ined types some of the examples have been cleaned up (the rest are to follow). the examples were successfully compiled with msvc-9.0 EE on Vista g++ 4.2.1/4.3.0 on OpenSuSE 10.3 Linux g++ 4.2.1. on FreeBSD 7.0 Any comments are welcome Best regards, -- ________________ ::matus_chochlik

2 3

SOCI 3.0.0 - The Database Access Library
by Maciej Sobczak 15 Jul '08

15 Jul '08

Hi, After more than one year and a half from the last release I'm pleased to announce the availability of the next major SOCI release (3.0.0). The SOCI library is a C++ database access library that during the last years was recognized for its innovative interface, ease of use and high quality. The main project website is: http://soci.sourceforge.net/ The 3.0.0 release brings many improvements and new features. Some of them were suggested here during previous discussions on database interfaces. Some of them will be explained in more detail below. The most important of the new library features include: * Naming and coding convention compliant with Boost. * Integration with Boost types: optional, tuple, fusion and gregorian::date. Please see <http://soci.sourceforge.net/doc/boost.html> for details. * Dynamic backend loading. The advantages and potential uses of this feature have been discussed here previously. An example code establishing the new connection to the database might look like: soci::session sql("postgresql://dbname=my_database"); As a result, the SOCI library will try to locate the dynamically loadable plugin (called backend) for PostgreSQL and handle all further database-related activity. This feature exists not instead, but in addition to the statically-bound interface that was available in previous releases. * Multithreaded connection pool. * Improved integration and conversion system for user-defined datatypes. Actually, integration with Boost types has been implemented with the help of this conversion system. It is non-intrusive and based on traits, which means that neither SOCI nor user-defined types need to be modified to integrate them. This system is also composable, which means that user-defined datatypes can wrap one another without special arrangements. For example, boost::tuple can contain boost::optional<Employee> even though all three conversion traits can be defined separately. * Extended the set of basic datatypes with long long. * Additional simplified interface (of the extern "C" type) for integration with other programming languages. It is expected that bindings for other languages will be created as external projects with the potential advantage of reducing the total number of libraries used in multi-language projects and increasing conceptual coherency of database-related operations. Boost.Python and similar solutions can be helpful here. The 3.0.0 release includes the following backends: * Oracle * PostgreSQL * MySQL They were tested on a variety of platforms, please see the documentation pages devoted to each backend for details. Other backends (ODBC, SQLite, Firebird) exist in the CVS repository and are provided "as is" for those who are willing to experiment with them and accept the cost of using less-tested and unsupported code. It is very likely that future releases of the library will officially include some of these additional backends. It is also possible that other database servers will be targeted with dedicated backends. An extensive HTML documentation is available both on the project website and as part of the distribution. In particular, the doc/structure.html page explains the structure of the library and provides instructions how to build it. ------ This release is also a good motivation for reviving the discussion on the future Boost database library. As you have seen during the last couple of years, SOCI is one of the very few (should I say "the only one"?) projects that actually move forward and that are now culturally consistent with Boost. The extensive out-of-the-box integration with the Boost datatypes, Boost license and compliant naming conventions, already make SOCI the natural choice in those projects that use Boost libraries. As a natural consequence of this, the following question has to be asked: What is the future of database interfacing from the Boost community point of view? Proposing SOCI as a candidate library for Boost might be a possible answer to this question, but it is not obvious in a wider perspective. Some of the SOCI users do not use Boost for various reasons and this justifies retaining SOCI as a separate entity (note: even though SOCI offers extensive integration with Boost, it does not mandate it and SOCI can be compiled without any reference to Boost). Most likely solution is to keep SOCI orbiting around Boost in terms of coding conventions and seamless interfacing, as it does today, so that benefits for all interested parties can be retained. Your comments and suggestions considering the above are very welcome. Final note: SOCI does not use bjam. If this is considered as missing from the Boost point of view, contributions from experienced bjam users would be needed. Cheers, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com

9 20

[filesystem] Following symlinks
by Scott McMurray 15 Jul '08

15 Jul '08

Suppose I want to add to simple_ls so it tells me the target of a symlink like ls -l does. else if ( fs::is_symlink( dir_itr->status() ) ) { ++other_count; std::cout << dir_itr->leaf() << " -> " << symlink_path(*dir_itr) << "\n"; } I haven't found any function to put in place of symlink_path. Is there one? It can't be a path decomposition, and the only other functions that return paths are current_path, initial_path, and the complete functions, so I don't think there is. ~ Scott

1 0

[filesystem] Resolving a path ?
by Loïc Joly 15 Jul '08

15 Jul '08

Hello, I'd like to know if there is in boost::filesystem a way to "resolve" a path. For instance, I have a path that is built from : "c:\foo1\foo2\..\bar1\bar2" And I'd like to obtain: "c:\foo1\bar1\bar2" Best regards, -- Loïc

4 5

[extension] Suggestion: Loading shared libraries from memory
by Robert Dailey 15 Jul '08

15 Jul '08

Hi, I'm not a huge expert on shared libraries, however I was wondering if there's a portable way to support loading libraries from a memory buffer instead of from the file system. If this is possible, could it be added as a feature to Boost.Extension? Thanks for reading!

3 3

[rfc] dual-mode regression testing
by joaquin＠tid.es 15 Jul '08

15 Jul '08

Hello, As it stands now, most testing force goes to the trunk of SVN, which is good. The problem is that there are few regression runners running against the release branch, and I think we have a trade off: a regression runner volunteer will choose to work on either the trunk or the release branch, but taking care of both is possibly too much of a hassle. It is assumed that the release branch is much cleaner and thus needs less attention, but it's better to be safe than sorry wrt this. My proposal is then: why not modify the regression tool code so that it operates by default in *dual mode*, i.e. it automatically downloads two tarballs (trunk & release) to different folders, test them separately and upload the results to the appropriate destinations? From the point of view of a volunteer, setting this to work is as simple as having it running only against one branch, and the only drawback is that resource consumption doubles, but this might be acceptable to a fair number of people. Comments? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[parameter][accumulators] test failures on release branch
by Richard Webb 15 Jul '08

15 Jul '08

(reposting this in it's own thread, to make sure it doesnt get lost). The release branch parameter/accumulator tests are showing a large number of failures due to a missing #include <boost/type_traits/is_convertible.hpp> in boost/parameter/aux_/tagged_argument.hpp e.g. http://tinyurl.com/642sgq Thanks, Richard Webb

2 1

Re: [boost] [pool] segfault (fun with static initialization ordering)
by joaquin＠tid.es 15 Jul '08

15 Jul '08

Chris Newbold escribió: >> From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] >> On Behalf Of JOAQUIN M. LOPEZ MUÑOZ >> Sent: Friday, July 11, 2008 11:35 AM >> >> BTW, have you tried the fix I was proposing? >> > > Not yet. I'm on vacation this week, but I will try it as soon as possible. My only concern is whether referencing singleton_default from the constructor for fast_pool_singleton will guarantee proper initialization ordering. > > 3.6.2 doesn't really shed any light on how ordered and unordered initialization may be coupled. There isn't, for example, any expressed guarantee that non-locals will be initialized prior to first reference. > There is no such guarantee indeed, but the fix does NOT rely on initialization rules for non-local objects, but on the initialization rules for *local* objects with static storage duration (6.7/4): the singleton is a local static object inside the function singleton_default<T>::instance(), which is explicitly invoked inside fast_pool_allocator ctors via singleton_pool<...>is_from() (if you apply the fix, that is). The non-local object involved in singleton_default<T>, namely singleton_default<T>::create_object is there to guarantee that singleton_default<T>::instance() is invoked, and thus the singleton created in dynamic initialization time *if no one has done it before*. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

a new release of Join - asynchronous concurrency library
by Yigong Liu 15 Jul '08

15 Jul '08

Hello, I just uploaded a new version of Join library to Vault under Concurrent Programming. Based on the feedback from list, the following changes are made: . add schedulers as actor's template policy class . add timed synchronous calls . add doc and samples for port based API . add more doc about Join internals. For people who are not familiar with the librayr. Here is a simple description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. website and download: http://channel.sourceforge.net Any comments and suggestions are highly appreciated. Thanks Yigong

1 0

Streaming Lambda functions
by Robert Jones 14 Jul '08

14 Jul '08

Is it possible to invoke user defined streaming operators within boost lambda functions? In this style #include <iostream> #include <map> #include "boost/lambda/lambda.hpp" using namespace std; ostream & operator << ( ostream & ostrm, pair<string, string> const & input ); ostream & operator << ( ostream & ostrm, map<string, string> & inputs ) { using namespace boost :: lambda; for_each ( inputs.begin( ), inputs.end( ), ostrm << _1 << '\n' ); return ostrm; } Is this basically undoable, or am I doing it wrong? Also, does the online Comeau compiler understand the boost include directives? Thanks, Rob.

5 14

z/OS supported
by Dr. Franz Fehringer 14 Jul '08

14 Jul '08

Hello all, Is z/OS (recent version assumed) with USS (Unix System Services) a supported configuration with respect to the boost library components? Cheers Franz

2 1

Re: [boost] Bind question, is there any way to implicitly go through a reference_wrapper?
by Michael Goldshteyn 14 Jul '08

14 Jul '08

Sorry, post got garbled, here it is again: #include <boost/bind.hpp> #include <boost/ref.hpp> #include <string> // Define a simple class for our example class Crayon { public: explicit Crayon(const std::string &color=std::string()):m_color(color) {} const std::string &GetColor() const {return m_color;} private: std::string m_color; }; int main(int argc, char *argv[]) { using namespace std; using namespace boost; Crayon cr("blue"); boost::reference_wrapper<const Crayon> crefCr(cr); // This compiles std::string color(boost::bind(&Crayon::GetColor,_1)(cr)); // This also compiles, using an explicit get on crefCr std::string colorFromConstRef(boost::bind(&Crayon::GetColor,boost::bind(&boost::referenc e_wrapper<const Crayon>::get,_1))(crefCr)); // This doesn't compile, however, even though the reference_wrapper class template has // an overloaded operator T& () const function std::string colorFromConstRef2(boost::bind(&Crayon::GetColor,_1)(crefCr)); }

1 0

unmerged changes in boost function
by Emil Dotchevski 14 Jul '08

14 Jul '08

I can see that the new allocator semantics in boost::function have not been merged into the release branch. I would volunteer to do the merge but it seems like there are some other changes that I'm not familiar with. Doug, how should this be handled? I would hate 1.36 to go out without the new allocator support for boost::function as I already have code that depends on it. :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 1

[function][release] outdated boost/function/detail/prologue.hpp header causing regressions in MSVC++ 9.0
by joaquin＠tid.es 14 Jul '08

14 Jul '08

Hello, Just in case this is going unnoticed: Boost.Function is having regressions at the release branch for MSVC++ 9.0, see for instance: http://tinyurl.com/5h2wl5 Seems the problem is simply that function_template.hpp was last merged to the branch release later than boost/function/detail/prologue.hpp (merged at 41356) so that the release does not have revisions 44030 and 44056 of this last header, resulting in the lack of a necessary inclusion of <boost/type_traits/is_void.hpp>. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

base64 filter works incorrect if sorce string length % 3 != 0
by Игорь Палагута 14 Jul '08

14 Jul '08

Hello, I have the following code: #include <boost/archive/iterators/binary_from_base64.hpp> #include <boost/archive/iterators/base64_from_binary.hpp> #include <boost/archive/iterators/insert_linebreaks.hpp> #include <boost/archive/iterators/remove_whitespace.hpp> #include <boost/archive/iterators/transform_width.hpp> #include <string> #include <exception> #include <iostream> int main() { using namespace boost::archive::iterators; typedef insert_linebreaks< base64_from_binary< transform_width< std::string::const_iterator, 6, sizeof( char ) * 8 > > ,72 > to_base64_type; typedef transform_width< binary_from_base64< remove_whitespace< std::string::const_iterator > >, sizeof( char ) * 8, 6 > to_binary_type; std::string hello_ = "hello"; std::string base64_hello_( to_base64_type( hello_.begin() ) , to_base64_type( hello_.end() ) ); std::cout << base64_hello_ << std::endl; try { std::string hello_recovered_( to_binary_type( base64_hello_.begin() ) , to_binary_type( base64_hello_.end() ) ); std::cout << hello_recovered_ << std::endl; } catch ( const std::exception& e_ ) { std::cerr << e_.what() << std::endl; } return 0; } During base64 decode we have following exception: "attempt to decode a value not in base64 char set". We have the problem because source string hello_ = "hello", has length % 3 != 0, otherwise we don't have this exception. As I know in this case we should add appropriate number of special symbol like '='. I can add '=' manually, but boost base64 decode can't process them, and we also have exception If we have insert_linebreaks/remove_whitespace filter perhaps we also should have some symmetric filter for text padding? Do we have padding filter in boost? Or perhaps it will be in future? Thanks

2 1

detecting ODR violations
by Steven Watanabe 14 Jul '08

14 Jul '08

AMDG I've been trying to work out a way to cause an explicit error if configuration macros are defined differently in different translation units. I really wish I could cause a link error, but the best I've been able to come up with so far is a runtime error // test_odr.hpp #ifndef TEST_ODR_HPP_INCLUDED #define TEST_ODR_HPP_INCLUDED #include <iostream> #include <cstdlib> #ifndef SOME_MACRO #define SOME_MACRO true #endif template<bool> struct test_odr { static bool value; }; template<bool b> bool test_odr<b>::value = SOME_MACRO; namespace { struct test_odr_impl_t { test_odr_impl_t() { if(test_odr<true>::value != SOME_MACRO) { std::cerr << "Error: SOME_MACRO defined differently in two translation units.\n"; std::abort(); } } }; test_odr_impl_t test_odr_impl; } #endif // test_odr1.cpp #include "test_odr.hpp" int main() {} // test_odr2.cpp #define SOME_MACRO false #include "test_odr.hpp" Comments? Any better ideas? In Christ, Steven Watanabe

3 3

[intrusive] Problem with EDG base compilers in strict Ansi mode.
by Markus Schöpflin 14 Jul '08

14 Jul '08

Hello, currently any_test and doc_any_hook fail on Tru64/CXX with the following errors: cxx: Error: ../boost/intrusive/detail/any_node_and_algorithms.hpp, line 276: class template "boost::intrusive::any_algorithms<VoidPointer>" has no member "unlink_not_available_for_any_hooks" (notmember) any_algorithms<VoidPointer>::unlink_not_available_for_any_hooks(); -----------------------------------^ cxx: Error: ../boost/intrusive/detail/any_node_and_algorithms.hpp, line 283: class template "boost::intrusive::any_algorithms<VoidPointer>" has no member "swap_nodes_not_available_for_any_hooks" (notmember) any_algorithms<VoidPointer>::swap_nodes_not_available_for_any_hooks(); -----------------------------------^ AFAICT this is the only EDG based compiler which tests in strict Ansi mode, adding -strict_ansi to the other EDG based compilers (acc for example) would probably lead to the same error. Attached patch contains a proposed fix for this. It checks for __EDG__ and __STD_STRICT_ANSI to enable the fix and works for me locally. The patch should replace the compile error by a link error, because in strict Ansi mode EDG doesn't allow you to refer to non-existing names. OK to apply? Regards, Markus Index: detail/any_node_and_algorithms.hpp =================================================================== --- detail/any_node_and_algorithms.hpp (revision 46676) +++ detail/any_node_and_algorithms.hpp (working copy) @@ -269,6 +269,11 @@ static bool unique(const_node_ptr node) { return 0 == node->node_ptr_1; } + +#if defined(__EDG__) && defined(__STD_STRICT_ANSI) + static void unlink(node_ptr); + static void swap_nodes(node_ptr l, node_ptr r); +#else static void unlink(node_ptr) { //Auto-unlink hooks and unlink() call for safe hooks are not @@ -282,6 +287,7 @@ //what algorithm they must use from unlink them from the container any_algorithms<VoidPointer>::swap_nodes_not_available_for_any_hooks(); } +#endif }; } //namespace intrusive

2 8

[thread] lockable traits and concepts classes adding proposal
by vicente.botet 14 Jul '08

14 Jul '08

Hello boosters , While writtig a generic library I have needed some lockable traits and concepts to be chacked with BCCL. If you think that these classes are of general use it will be a pleasure for me, if Anthony accepts, to included them on the Boost.Thread library. Otherwise I will left them in my Sync library. For the moment all is defined in a sync (as synchronization) namespace and directory but this is without importance. Attached a short introduction (in quickbook format- sorry I can not attach the html file) as well as the header files (which should with gcc 3.4 on cygwin) Of course all this is subject to discusion, naming and file structure changes, ... For each one of the mutex in the thread library, we need to * make the mutex inherit from the helper lock_traits_base or * have nested typedefs or * specialize each one of the traits templates As an external library I have do this in a non-intrusive way as for example: template<> struct timed_interface_tag<boost::mutex> { typedef hasnt_timed_interface_tag type; }; template<> struct reentrancy_tag<boost::mutex> { typedef non_recursive_tag type; }; template<> struct category_tag<boost::mutex> { typedef exclusive_lock_tag type; }; template<> struct scope_tag<boost::mutex> { typedef multi_threaded_tag type; }; But if included in the Thread library it will be better to use one of the intrusive methods. I have also defined other classes that could be of general interest. * A make_lockable class will make Lockable/ShareLocakble/UpgradeLocable the derived class depending on the Lock parameter. This class could be the base of a monitor class. It can be used as follows: class X : public make_lockable<boost::mutex> { } X x; unique_lock<X> lock(x); * a ..._synchronization_family set of classes that can be used as follows: template <class SyncFamily> message_queue; typedef message_queue<thread_synchonization_family> my_mt_message_queue; typedef message_queue<null_synchonization_family> my_st_message_queue; The null_synchonization_family needs a null_mutex and a null_condition classes. There is already something similar in Boost::Interprocess. * To finish, I'm working on a filter_matching_lockables meta-function which take as parameter a vector of lockables types and will filter the lockables types not satisfying a list of traits. The use shoul be somthing like typedef filter_matching_lockables<vector<boost::mutex, boost::recursive_mutex, ...>, mpl::and_<is_exclusive_lock<_>, mpl::not_<is_recursive_lock<_> > >::type candidates. and a find_best_lock which choose between the lockables given as parameter the best one following a given criteria. Of course, there is yet a lot of work to do, add lock concepts, lockable and lock concept traits, document, tests, document, tests ... between others. As you see there is nothing new, neither complex, only some helper classes making easier the construction of higher abstraction levels, and that currently are missing in boost. Have a good code reading and please let me know what do you think. _____________________ Vicente Juan Botet Escriba

3 6

Re: [boost] Newbie Trying to Build Boost Libraries on 64-bit MS WindowsVista
by Beverly Pope 14 Jul '08

14 Jul '08

>From what I've been reading, the -sTools option is an older way of doing things and I've had a lot of trouble building with 64-bit. I'll try using --address-model=64. I'll try ignoring the warnings, per your suggestion. I searched on the web and found that for Python 2.5, and found that: int ilow = 0, ihigh = INT_MAX; should be changed to: Py_ssize_t ilow = 0, ihigh = PY_SSIZE_T_MAX; It compiled after that change. I now have a problem with it finding a library, but I'll look at it some more before posting about that. Thanks very much for your help. Bev Date: Tue, 8 Jul 2008 13:56:57 -0500 From: "Stephen Nuchia" <snuchia(a)statsoft.com> Subject: Re: [boost] Newbie Trying to Build Boost Libraries on 64-bit MS WindowsVista To: <boost(a)lists.boost.org> Message-ID: <E763352EB1BA7547BBBC18A6980EBCB20171B05F(a)crm.tulsa.statsoft.com> Content-Type: text/plain; charset="iso-8859-1" > From: Beverly Pope [mailto:countryone77@yahoo.com] ??? I'm not familiar with the -sTools trick, I use --address-model=64 to get 64-bit builds. I've not built with Python so I can't address those errors in detail but I am familiar with the error message from other source codes. ? ? > 1) I see numerous (21360) warnings I have not investigated but I suspect it is impossible to suppress this warning in the header that is responsible for it without leaving it suppressed outside that header. I recommend ignoring it. > 2) When building the libraries, I get the following errors [...] > error C2664: '_PyEval_SliceIndex' : cannot convert parameter > 2 from 'int *' to 'Py_ssize_t *' >??????? Types pointed to are unrelated; conversion requires > reinterpret_cast, C-style cast or function-style cast [...] This error message is triggered by a code flaw that is at least potentially very dangerous. ... -swn

1 0

boost::iterator_range header surgery
by MaximYanchenko 14 Jul '08

14 Jul '08

Hello, I found that the input/output and comparison functions for iterator_range are inside the header boost/range/iterator_range.hpp. Actually, this causes problems, as I can't provide custom printing and custom comparison: I have my own container printing engine and it worked perfectly well with all standard containers, but failed to compile with iterator_range due to operator<< ambiguity. (Of course, I can just disable instantiation of my printing stuff for iterator_range, but this is definitely not what I want to have.) And, I have no such problems with, say, boost::tuple, as it has separate headers for printing and comparison: #include "boost/tuple/tuple_comparison.hpp" #include "boost/tuple/tuple_io.hpp" There are also other boost libraries that provide a separate "XXX_io.hpp" header. So my proposal is: 1. Move operator<< to a separate header "boost/range/iterator_range_io.hpp" 2. Move comparison operators to a separate header "boost/range/iterator_range_comparison.hpp" This will also serve for boost unification, which is the Right Thing that greatly simplifies usage of any library collection. However, two problems arise here: 1. Backward compatibility. Current programs expect that everything is automatically included. I see two solutions: - Include "boost/range/iterator_range_io.hpp" and "boost/range/iterator_range_comparison.hpp" into "boost/range/iterator_range.hpp" under a define like BOOST_RANGE_1_34_COMPATIBILITY_MODE. This will give the same layout as we have in Boost.Tuple, but I don't want to introduce extra macros if they can be easily avioded. - Make one extra header "boost/range/iterator_range_core.hpp", and have "boost/range/iterator_range.hpp" just including everything. This will the hierarchical layout similar to other libraries like Boost.Spirit. In this case, maybe it worth moving all three new headers to a subdirectory. 2. Again, backward compatibility, but from another point of view. Boost.Range has the unspecified_bool_type() conversion operator. I personally don't see a strong need in it, as it's just a negation of empty(). Also, no standard containers (which are ranges) offer this kind of conversion. So I don't expect wide use of it, and maybe it's worth removing it from the class at all and leave empty() only. Anyway, for now it's here, so if you move operator<< away, iterator_range will continue to be printed, but now, due to this conversion, it will be just "0" or "1", depending on the range emptiness. This is the problem not only for Boost.Range, but also for other types that offer this kind of conversion and separate printing, for example, consider this simple program with Boost.Optional: #include <boost/optional/optional.hpp> boost::optional<char> o('o'); #include <iostream> void without_io() { std::cout << "without_io: " << o << '\n'; } #include <boost/optional/optional_io.hpp> void with_io() { std::cout << "with_io: " << o << '\n'; } int main() { without_io(); with_io(); } So, whether we change Boost.Range header leayout or not, this unspecified_bool_type() problem should be solved anyway, for several boost classes. I discussed this with Alex Nasonov, and he proposed a patch for boost::optional: https://svn.boost.org/trac/boost/ticket/2103 But this is not the only use of unspecified_bool_type, so most probably we will need a common solution. Thanks, Maxim P.S. Please write personal e-mails to gmail.com.

4 4

[swap] unbreak tests
by Vladimir Prus 14 Jul '08

14 Jul '08

I've checked in the below. The libs/utility/swap/Jamfile.v2 has the same content present twice (complete with copyright notices). This is not good, because if you ask Boost.Build to built two targets with the same name, the same set of sources, and otherwise identical, Boost.Build asks "wazzup?". I suspect this duplicate content is a consequence of how the "patch" program handles file addition, but anyway, it's nice idea to actually run library's test before touching the library. - Volodya

2 1

Specifying symbols, that have to be exported from shared library
by Alexander Arhipenko 14 Jul '08

14 Jul '08

Hi guys! Without any doubt, any shared library should export as less symbols as possible. First, this will decrease loading time of dynamic shared object. Second, it could eliminate some binary compatibility issues in the future. Boost libraries that are built as shared libraries (e.g., filesystem, datetime) explicitly specify symbols that have to be exported, but only when BOOST_HAS_DECLSPEC defined. So, only when building with toolsets msvc and borland (correct me if I'm wrong), this 'export' functionality is used. As we know, gcc allows not to export any symbol from shared library (if compiler flag -fvisibility=hidden is used) except ones declared with __attribute__((visibility("default"))), e.g.: class __attribute__((visibility("default"))) exported_class {//... As for me, it will be nice to exploit explicit symbols export in boost (if compiler allows this). In our software team, we use following macroses: SFI_DSO_EXPORT, SFI_DSO_IMPORT that are defined as: #if defined SFI_CC_GNUC # define SFI_DSO_EXPORT __attribute__((visibility("default"))) # define SFI_DSO_HIDE __attribute__((visibility("hidden"))) # define SFI_DSO_IMPORT #endif #if defined SFI_CC_MSVC # define SFI_DSO_EXPORT __declspec(dllexport) # define SFI_DSO_HIDE # define SFI_DSO_IMPORT __declspec(dllimport) #endif //etc... And some library use only them: //config.hpp #if defined SFI_ALIB_BUILD_SHLIB # define SFI_ALIB_DECL SFI_DSO_EXPORT #elif defined SFI_ALIB_USE_SHLIB # define SFI_ALIB_DECL SFI_DSO_IMPORT #else # define SFI_ALIB_DECL #endif Finally, here's the question. What do you think about having something like BOOST_DSO_EXPORT/*IMPORT in boost? Regards

6 10

Where are the previous versions in the repository?
by Daryle Walker 13 Jul '08

13 Jul '08

When checking one of my tickets, I noticed that the <http:// svn.boost.org/trac/boost/browser/tags/Version_1_34_1/boost/boost/ typeof/int_encoding.hpp> link had gone bad. Looking at <http:// svn.boost.org/trac/boost/browser/tags>, I notice that _all_ of the tags for previous releases are gone. Why? (If they've been moved instead, let us know where they've gone.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

[data_time, 1.36, fix-proposal] Compile-time error, gcc 4.3.1
by Ruediger Berlich 13 Jul '08

13 Jul '08

Hi there, when compiling my application with the current trunk version of Boost 1.36 (OpenSUSE 11, gcc 4.3.1, 64 bit), I get the following compiler error: /opt/boostinclude/boost/date_time/tz_db_base.hpp:161: error: declaration of ‘typedef class boost::date_time::dst_adjustment_offsets<typename time_zone_type::time_duration_type> boost::date_time::tz_db_base<time_zone_type, rule_type>::dst_adjustment_offsets’ /opt/boostinclude/boost/date_time/time_zone_base.hpp:76: error: changes meaning of ‘dst_adjustment_offsets’ from ‘class boost::date_time::dst_adjustment_offsets<typename time_zone_type::time_duration_type>’ This can be easily amended with a minimal change in boost/date_time/tz_db_base.hpp - see below for a change that works for me. As I cannot see that it can do any harm to other parts of Boost, I'm wondering whether it could still find its way into the upcoming Boost release. 161c161 < typedef dst_adjustment_offsets<time_duration_type> dst_adjustment_offsets_tdt; --- > typedef dst_adjustment_offsets<time_duration_type> dst_adjustment_offsets; 349c349 < dst_adjustment_offsets_tdt adjust(time_duration_type(0,0,0), --- > dst_adjustment_offsets adjust(time_duration_type(0,0,0), 356c356 < adjust = dst_adjustment_offsets_tdt( --- > adjust = dst_adjustment_offsets( Best, Ruediger

1 0

Autolinking when an autolinked function/class is never used
by Edward Diener 12 Jul '08

12 Jul '08

I think it is an error when an end-user uses a Boost library which may need a separate DLL built, never uses a function/class which is implemented in that separate DLL, and yet the Boost header files for that library bring in autolinking. Is this considered an error in the development of a Boost library ? What is invariably happening when this situation occurs is that a header file which has autolinking code ( #pragma comment(lib,"somelib") in VC++ for example ) is included for functions/classes which are not in the autolinked library at all. This is because the Boost developer has not placed all the autolinked functionality for a particular library in its own header file, preferring instead to place declarations in logically related header files. While the latter is understandable as far as organization of a library is concerned it destroys the ability of that library to enforce autolinking only when the end-user requires it. Despite the fact that library developers, of Boost libraries which are not completely header only, go for orthogonality when creating their header files I would like to see things changed so that using a library which does not require the built library to be linked in when using functionality of that library does not being in autolinking. I realize that there are macros of the BOOST_SOMELIB_NO_LIB around to turn off autolinking but this places a burden on the end user which should not be there. I was recently using the date/time library for the first time, used functionality which I was pretty sure was not in the built library based on the documentation, yet autolinking code was brought in to force me as an end-user to specify the location of the import library. When I defined BOOST_DATE_TIME_NO_LIB in my project settings, everything linked fine without specifying the import library, so obviously the DLL was not needed. Nobody wants to distribute a shared library with their code when it is unnecessary.

4 5

[preprocessor] #elif behaviour in gcc 4.4
by Daniel James 12 Jul '08

12 Jul '08

Hello, A recent change to the development version of the gcc preprocessor changes the way it processes '#elif' directives and breaks a common use of the preprocessor library. We've already had reports of this causing problems in MPL, and it might also affect: variant, function_types, python, fusion, xpressive and phoenix. Details of the change are at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36320 With this change, the argument to an '#elif' directive is processed even if a previous '#if'/'#elif' directive was true. This causes the example use of BOOST_PP_ITERATION_DEPTH to break: http://www.boost.org/doc/libs/1_35_0/libs/preprocessor/doc/ref/iteration_de… In this example, the first time the header is included, BOOST_PP_ITERATION_DEPTH is not yet defined, so it causes the develoment gcc to fail when the #elif directives are evaluated (which are skipped with existing versions, because the first #if directive evaluates to true). Looking at the standard, I think their interpretation is correct (although I'm not familiar with it and could be missing something) but it isn't clear that this was the intent of the authors. Any opinions on this? I think it's quite easy to work around, we can replace: #if !BOOST_PP_IS_ITERATING // .... #elif BOOST_PP_ITERATION_DEPTH() == 1 // .... #elif BOOST_PP_ITERATION_DEPTH() == 2 // .... #endif with: #if !BOOST_PP_IS_ITERATING // .... #else # if BOOST_PP_ITERATION_DEPTH() == 1 // .... # elif BOOST_PP_ITERATION_DEPTH() == 2 // .... # endif #endif So that the calls to BOOST_PP_ITERATION_DEPTH are skipped - or we could just include the necessary header before including the file. But it does seem a pity that any code which uses this technique might need to be changed for gcc 4.4. We should probably write to them about this (it doesn't look like they realised this would be a problem), but I'm writing here first in case anyone has any ideas. Daniel

2 1

Re: [boost] [pool] segfault (fun with static initialization ordering)
by JOAQUIN M. LOPEZ MUÑOZ 12 Jul '08

12 Jul '08

________________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de JOAQUIN M. LOPEZ MUÑOZ [joaquin(a)tid.es] Enviado el: viernes, 11 de julio de 2008 17:35 Para: boost(a)lists.boost.org Asunto: Re: [boost] [pool] segfault (fun with static initialization ordering) _______________________________________ > The following is a case where the precende rule *cannot* be applied > for logical reasons: > > template<typename T> > struct foo{ > static int x; > }; > > template<typename T> > int foo<T>::x=T::x; > > struct bar > { > static int x; > }; > > int bar::x=666; > > static int x=foo<bar>::x; Please disregard this example, it is flawed because bar::x is statically initialized an because ultimately the compiler is not required to perform the dependency analysis suggested above. I've been playing with the following: #include <iostream> #if defined(CASE1) struct bar{static int x;}; static int f(){return 666;} int bar::x=f(); template<typename T>struct foo{static int x;}; template<typename T>int foo<T>::x=T::x; #elif defined(CASE2) template<typename T>struct foo{static int x;}; template<typename T>int foo<T>::x=T::x; struct bar{static int x;}; static int f(){return 666;} int bar::x=f(); #endif int main() { std::cout<<"bar::x: "<<bar::x<<std::endl; std::cout<<"foo<bar>::x: "<<foo<bar>::x<<std::endl; } Using GCC in Cygwin the output is the same for both CASE1 and CASE2: bar::x: 666 foo<bar>::x: 666 Using MSVC++ 8.0 I observed a light-shedding behavior: When compiling with a fresh project, the output is the same for CASE1 and CASE2 and coincides with GCC: bar::x: 666 foo<bar>::x: 666 But after that I changed the code to the following: #elif defined(CASE2) template<typename T>struct foo{static int x;}; template<typename T>int foo<T>::x=T::x; struct bar{static int x;}; static int x=foo<bar>::x; // NEW LINE static int f(){return 666;} int bar::x=f(); #endif This forces foo<bar>::x evaluation to be done at a prior monent and the result is (for CASE2): bar::x: 666 foo<bar>::x: 0 Now, the funny thing is that if I revert to the original code (i.e. I delete the line comented as // NEW LINE) then MSVC++ 8.0 outputs the following both for CASE1 and CASE2 bar::x: 666 foo<bar>::x: 0 which is different than my early runs! The compiler seems to reuse some intermediate files from prior compilations that set a particular initialization order: confirming this hypothesis, if I clean the project and rebuild again then we're back at the original output for both CASE1 and CASE2: bar::x: 666 foo<bar>::x: 666 So, you see how one cannot actually rely on any particular initialization order for class template statis data. The standard explicitly leaves this initialization order unspecified (see the rest of 3.6.2). With respect to the rest of my previous post I maintain the explanation for the problem with pool you're having and contend that referring to singleton_pool<...> inside fast_pool_allocators ctors is the proper fix. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Suggestion: keep the trunk stable
by Daryle Walker 12 Jul '08

12 Jul '08

Based on reading the various posts on releasing Boost 1.36.... Maybe we should promote the idea that the trunk of our Subversion repository should be as stable as possible as an official policy. I think a lot of open source projects do this; because it brings a big benefit: fast turn-around times for releases. With a stable trunk, the release manager makes a branch for release from the trunk, has everyone help in testing and making sure the branch is otherwise fully stable, then ship out the final version of that branch. After that, the changes on that branch have to be merged into the trunk to make it more stable. (And the branch can be removed.) Realize that the release branch preparation is _only_ for stabilization (i.e. bugs); anyone who was late for adding a new OR revised feature has to wait for the next release cycle. I think we're trying to do releases every three months, here's a possible timeline: 1. For the first two months, we're just updating the trunk with bug- fixes, revised features, and new features/libraries. Bug-fix releases come out during this time as needed. Any fix has to be based on a commit on the trunk. The bug release manager just makes a branch off the last bug release tag (or the last major release tag if we're doing the first bug release) and applies the selected bug fix change-sets, then ships after the group's testing. (The branch is re- merged then removed.) The release team would (generally) do the bug- fix incorporation; the libraries' developers did their parts by adding the fixes in the trunk in distinct change-sets. Hopefully, this would take a week for branching and fix-merging, then another week or so for testing. 2. Work on the trunk has to be kept stable. Incorporate changes into the trunk in distinct steps that do not break the build. Huge changes, like ones that could cause merge & conflict hell, especially if done during release time, should be kept on a branch until ready to be incorporated. Branchers should keep their branch current with the trunk as far as unrelated files (and pieces of related files) are concerned. (Alternatively, if a big change can be broken into steps that individually don't break the build, then that should work too.) Note when a distinct step is committed, it's not just code; the corresponding documentation and tests for that step need to go in too. 3. For the last month, work on the next major release begins. If we follow the always-stable-trunk ideal, then this will be like case [1]. We pick a deadline. On the deadline day, the release manager branches off the trunk on the most stable revision around that time. There's a week-long period where incomplete big changes either need to be finished to an acceptable cut-off (which may be 100% if it was nearly done) or get back-tracked to a previous acceptable cut-off. The release team and the library developer discuss which focused revision the cut-off will be cherry-picked from (either backward or forward). The remainder of the procedure happens like [1], probably even to the point of the short completion times (1 to 2 weeks). 4. The branches here are transitory. They should be created as needed and removed when they're not necessary. The major release branch would be called "release" and the bug fix branch called "bug- release". They may be around simultaneously. There should be a special branch called "hotness" (or whatever) that is an alias to the "trunk" most of the time, but to "release" or "bug-release" when those branches exist. (If both exist, "bug-release" takes priority; but bug releases have to be quick so the release isn't bogged down.) Our test crew can just park on "hotness" and make sure to update and test regularly, preferably on automatic. The branch points will be tagged ("1_37_origin", "1_37_0", "1_37_1", "1_38_origin", etc.) so we don't forget them, of course. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

Is there a helper function for boost::fusion::vector just as std::make_pair to std::pair?
by Peng Yu 11 Jul '08

11 Jul '08

Hi, Is there a helper function for boost::fusion::vector just as std::make_pair to std::pair? boost::fusion::vector<very_loooooooooooooooooong_type,...,very_loooooooooooooooooong_type> v(...,,...); Suppose I have the above case, where the declaration is very long, I would like a helper function to simplify the above definition. Thanks, Peng

3 2

[serialization][portable-binary archive] Data not byte-swapped across architectures
by Jon Kroll 11 Jul '08

11 Jul '08

Hello: I am attempting to use the boost serialization portable-binary archive. The 2 architectures I am working on are: 1. Intel on MS-Windows/Mac OS X 2. PowerPC on Mac OS X The attached sample code shows that an integer I serialize on PPC and then unserialize on Intel is not byte-swapped. And similarly, an integer I serialize on Intel is not byte-swapped on PPC. It does not appear to be a OS issue, because the data is unserialized properly from a MS-Windows Intel system to a Mac OS X Intel system, and vise versa. Another manifestation of this occurs when I serialize a large container, like a vector for example. The code has an exception because the size of the container is not byte-swapper. I can provide example code for this as well. This experience leads me to believe either: 1. The portable binary is not functioning properly with Mac OS X PPC or 2. I am not using the portable-binary archive properly, either configuration or code. Advise on this issue would be greatly appreciated. Best regards, Jon Kroll Ann Arbor Michigan ========================================================================= BUILD: Windows: MS-Visual Studio 2005 Mac OS X: g++ test_portable_binary.cpp portable_binary_iarchive.cpp portable_binary_oarchive.cpp -o test_portable_binary -I/Volumes/..../boost_1_35_0/ -L/Volumes/..../boost_1_35_0/stage/lib/ -lboost_serialization-mt-1_35 CODE: ======================================================== #include "boost/archive/portable_binary_oarchive.hpp" #include "boost/archive/portable_binary_iarchive.hpp" #include <vector> #include <sstream> #include <fstream> #include <iostream> #include <string> namespace { bool isIntelArch() { char endianTest[2] = { 1, 0 }; return (*(short *) endianTest == 1); } bool isPPCArch() { return !isIntelArch(); } } int main(int argc, char* argv[]) { if (false) // generate test file { std::string fileName; if (isPPCArch()) fileName = "PPC_portableBinaryLargeInt.ser"; else if (isIntelArch()) fileName = "Intel_portableBinaryLargeInt.ser"; int val = 16000; // 0x3E80 std::ofstream os(fileName.c_str(), std::ios::binary); portable_binary_oarchive oa(os); oa & val; return 0; } int unserializedVal = 0; { std::string fileName; if (isPPCArch()) fileName = "Intel_portableBinaryLargeInt.ser"; else if (isIntelArch()) fileName = "PPC_portableBinaryLargeInt.ser"; std::ifstream is(fileName.c_str(), std::ios::binary); portable_binary_iarchive ia(is); ia & unserializedVal; } if (0x3E80 == unserializedVal) { return 0; // This is the correct result! } if (0x803E == unserializedVal) { return -1; // This is an error, the value is not byte-swapped } if (0 == unserializedVal) { return -1; // This is an error, nothing got unserialized } return 0; }

2 4

Concept based overloading and the ODR
by Steven Watanabe 11 Jul '08

11 Jul '08

AMDG I'm looking at two recent posts: http://comments.gmane.org/gmane.comp.lib.boost.devel/177370 http://comments.gmane.org/gmane.comp.lib.boost.user/37476 Either of these is fine by itself, but putting them both together makes it very easy to cause silent ODR problems. For example in translation unit a.cpp we #include "boost/tuple/tuple_io.hpp" and translation unit b.cpp we forget. Then, along comes boost::any which detects operator<< in translation unit a.cpp, but uses its default in translation unit b.cpp. Ka-Boom. This is not a huge problem at the moment, because it's quite difficult to make the detection bullet-proof, but I'm very concerned because C++0x concepts are supposed to make such overloading easy. In Christ, Steven Watanabe

2 6

How to convert a vector of base classes to template based code?
by Peng Yu 11 Jul '08

11 Jul '08

Hi, The following program uses virtual functions. Essentially I need to go through all the pairs in 'v'. Since I have already know what are in v at compile time. I would like to convert the dynamic polymorphism to template. Therefore, the runtime would be better. I think this should be done with the help of boost::mpl. But I'm not sure how to do it. Would you please help me? Thanks, Peng #include <iostream> #include <vector> #include <boost/shared_ptr.hpp> struct shape { virtual void show_me() const = 0; virtual ~shape() { } }; struct square : public shape { void show_me() const { std::cout << "square"; } }; struct circle : public shape { void show_me() const { std::cout << "circle"; } }; struct triangle : public shape { void show_me() const { std::cout << "triangle"; } }; int main() { std::vector<boost::shared_ptr<shape> > v; { boost::shared_ptr<shape> s(new square); v.push_back(s); } { boost::shared_ptr<shape> s(new circle); v.push_back(s); } { boost::shared_ptr<shape> s(new square); v.push_back(s); } { boost::shared_ptr<shape> s(new triangle); v.push_back(s); } for(std::vector<boost::shared_ptr<shape> >::const_iterator it = v.begin(); it != v.end(); ++ it) { for(std::vector<boost::shared_ptr<shape> >::const_iterator it2 = it + 1; it2 != v.end(); ++ it2) { (*it)->show_me(); std::cout << " vs. "; (*it2)->show_me(); std::cout << std::endl; } } }

3 5

Review Wizard Status Report for May 2008
by Ronald Garcia 11 Jul '08

11 Jul '08

========================================== Review Wizard Status Report for May 2008 ========================================== News ==== December 7, 2007 - Forward Library Accepted - Awaiting SVN December 16 - Unordered Containers Library Accepted - In SVN December 21 - Factory Library Accepted - Awaiting SVN January 13, 2008 - Switch Library Accepted Provisionally - Awaiting submission for mini review January 18 - Singleton Library Rejected - Awaiting resubmission, John Torjo has already volunteered to manage the next review January 30 - Flyweight Library Accepted - Awaiting SVN February 13 - Logging Library Rejected - Awaiting resubmission for new review, John Torjo has already resubmitted and Gennadiy Rozental has again volunteered to manage the review February 27 - Floating Point Utilities Library Accepted - Awaiting SVN March 14 - Proto Library Accepted - Exists as a component in Xpressive, but not yet as a separate library April 20 - Egg review completed - Results pending May 7 - Scope Exit Library Accepted - Awaiting SVN Older Issues ============ The binary_int library, accepted in October 2005 has not yet been submitted to SVN. The authors are strongly encouraged to contact the review wizards The Quantitative Units library, accepted in April 2007 has not yet been submitted to SVN The Globally Unique Identifier library, accepted provisionally in May 2007 has not yet been submitted for mini-review and full acceptance The Time Series Library, accepted in August 2007 has not yet been submitted to SVN The Accumulators library, accepted in February 2007 is in SVN The Exception library, accepted in October 2007 is in SVN The Scope Exit review report had not been submitted by the review manager. John Phillips stepped in as substitute review manager and produced a report For libraries that are still waiting to get into SVN, please get them ready and into the repository. The developers did some great work making the libraries, so don't miss the chance to share that work with others. Also notice that the review process page has been updated with a section on rights and responsibilities of library submitters. For the Scope Exit review, we would like to publicly apologize to Alexander Nasonov for how long this has languished without a report. The review wizards will work to make sure this doesn't happen any more. General Announcements ===================== As always, we need experienced review managers. In the past few months there have been a large number of reviews, but the flow of high quality submissions is just as big, so manage reviews if possible and if not please make sure to watch the review schedule and participate. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants or library contributors. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "garcia at cs dot indiana dot edu" and "phillips at mps dot ohio-state dot edu" respectively. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report before we do that, please email Ron or John. If you're a library author and plan on submitting a library for review in the next 3-6 months, send Ron or John a short description of your library and we'll add it to the Libraries Under Construction below. We know that there are many libraries that are near completion, but we have hard time keeping track all of them. Please keep us informed about your progress. Review Queue ============ * Finite State Machines * Property Map (fast-track) * Graph (fast-track) * Lexer * Thread-Safe Signals * Boost.Range (Update) * Shifted Pointer * DataFlow Signals * Logging * Futures (Braddock Gaskill) * Futures (Anthony Williams) * Join (Yigong Liu) * Pimpl (Vladimir Batov) -------------------- Finite State Machines --------------------- :Author: Andrey Semashev :Review Manager: Martin Vuille :Download: `Boost Sandbox Vault <http://tinyurl.com/yjozfn>`__ :Description: The Boost.FSM library is an implementation of FSM (stands for Finite State Machine) programming concept. The main goals of the library are: * Simplicity. It should be very simple to create state machines using this library. * Performance. The state machine infrastructure should not be very time and memory-consuming in order to be applicable in more use cases. * Extensibility. A developer may want to add more states to an existing state machine. A developer should also be able to specify additional transitions and events for the machine with minimum modifications to the existing code. Property Map (fast-track) ------------------------- :Author: Andrew Sutton :Review Manager: Jeremy Siek :Download: http://svn.boost.org/svn/boost/sandbox/graph-v2 :Description: A number of additions and modifications to the Property Map Library, including: * A constant-valued property map, useful for naturally unweighted graphs. * A noop-writing property map, useful when you have to provide an argument, but just don't care about the output. * See `ChangeLog <http://svn.boost.org/trac/boost/browser/sandbox/ graph-v2/libs/property_map/ChangeLog>`__ for details. Graph (fast-track) ------------------ :Author: Andrew Sutton :Review Manager: Jeremy Siek :Download: http://svn.boost.org/svn/boost/sandbox/graph-v2 :Description: A number of additions and modifications to the Graph Library, including: * Two new graph classes (undirected and directed) which are intended to make the library more approachable for new developers * A suite of graph measures including degree and closeness centrality, mean geodesic distance, eccentricity, and clustering coefficients. * An algorithm for visiting all cycles in a directed graph (Tiernan's from 1970ish). It works for undirected graphs too, but reports cycles twice (one for each direction). * An algorithm for visiting all the cliques a graph (Bron&Kerbosch). Works for both directed and undirected. * Derived graph measures radius and diameter (from eccentricity) and girth and circumference (from Tiernan), and clique number (from Bron&Kerbosch). * An exterior_property class that helps hides some of the weirdness with exterior properties. * run-time and compile-time tests for the new algorithms. * a substantial amount of documentation * Graph cores, implemented by David Gleich (@Stanford University) * Deterministic graph generators - capable of creating or inducing specific types of graphs over a vertex set (e.g., star graph, wheel graph, prism graph, etc). There are several other specific types that could be added to this, but I haven't had the time just yet. Lexer ----- :Author: Ben Hanson :Review Manager: Eric Neibler :Download: `Boost Sandbox Vault <http://boost-consulting.com/vault/ index.php? action=downloadfile&filename=boost.lexer.zip&directory=Strings%20-% 20Text%20Processing&>`__ :Description: A programmable lexical analyser generator inspired by 'flex'. Like flex, it is programmed by the use of regular expressions and outputs a state machine as a number of DFAs utilising equivalence classes for compression. Thread-Safe Signals ------------------- :Author: Frank Hess :Review Manager: Need Volunteer :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?&direction=0&order=&directory=thread_safe_signals>`__ :Description: A thread-safe implementation of Boost.Signals that has some interface changes to accommodate thread safety, mostly with respect to automatic connection management. Boost.Range (Update) -------------------- :Author: Neil Groves :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?action=downloadfile&filename=range_ex.zip&directory=>`__ :Description: A significant update of the range library, including range adapters. Shifted Pointer --------------- :Author: Phil Bouchard :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?&direction=0&order=&directory=Memory>`__ :Description: Smart pointers are in general optimized for a specific resource (memory usage, CPU cycles, user friendliness, ...) depending on what the user need to make the most of. The purpose of this smart pointer is mainly to allocate the reference counter (or owner) and the object itself at the same time so that dynamic memory management is simplified thus accelerated and cheaper on the memory map. DataFlow Signals ---------------- :Author: Stjepan Rajko :Review Manager: Needed :Download: http://dancinghacker.com/code/dataflow/ :Description: Dataflow is a generic library for dataflow programming. Dataflow programs can typically be expressed as a graph in which vertices represent components that process data, and edges represent the flow of data between the components. As such, dataflow programs can be easily reconfigured by changing the components and/or the connections. Logging ------- :Author: John Torjo :Review Manager: Gennadiy Rozental :Download: http://torjo.com/log2/ :Description: Used properly, logging is a very powerful tool. Besides aiding debugging/testing, it can also show you how your application is used. The Boost Logging Library allows just for that, supporting a lot of scenarios, ranging from very simple (dumping all to one destination), to very complex (multiple logs, some enabled/some not, levels, etc). It features a very simple and flexible interface, efficient filtering of messages, thread-safety, formatters and destinations, easy manipulation of logs, finding the best logger/filter classes based on your application's needs, you can define your own macros and much more! Futures ------- :Author: Braddock Gaskill :Review Manager: Needed :Download: http://braddock.com/~braddock/future/ :Description: The goal of the boost.future library is to provide a definitive future implementation with the best features of the numerous implementations, proposals, and academic papers floating around, in the hopes to avoid multiple incompatible future implementations in libraries of related concepts (coroutines, active objects, asio, etc). This library hopes to explore the combined implementation of the best future concepts. Futures ------- :Author: Anthony Williams :Review Manager: Needed :Download: http://www.justsoftwaresolutions.co.uk/files/ n2561_future.hpp (code) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/ n2561.html (description) :Description: This paper proposes a kind of return buffer that takes a value (or an exception) in one (sub-)thread and provides the value in another (controlling) thread. This buffer provides essentially two interfaces: * an interface to assign a value as class promise and * an interface to wait for, query and retrieve the value (or exception) from the buffer as classes unique_future and shared_future. While a unique_future provides move semantics where the value (or exception) can be retrieved only once, the shared_future provides copy semantics where the value can be retrieved arbitrarily often. A typical procedure for working with promises and futures looks like: * control thread creates a promise, * control thread gets associated future from promise, * control thread starts sub-thread, * sub-thread calls actual function and assigns the return value to the promise, * control thread waits for future to become ready, * control thread retrieves value from future. Also proposed is a packaged_task that wraps one callable object and provides another one that can be started in its own thread and assigns the return value (or exception) to a return buffer that can be accessed through one of the future classes. With a packaged_task a typical procedure looks like: * control thread creates a packaged_task with a callable object, * control thread gets associated future from packaged_task, * control thread starts sub-thread, which invokes the packaged_task, * packaged_task calls the callable function and assigns the return value, * control thread waits for future to become ready, * control thread retrieves value from future. Notice that we are in the unusual position of having two very different libraries with the same goal in the queue at the same time. The Review Wizards would appreciate a discussion of the best way to hold these two reviews to produce the best possible addition to Boost. Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?action=downloadfile&filename=Pimpl.zip&directory=&>`__ http://www.ddj.com/cpp/205918714 (documentation) :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Libraries under development =========================== Please let us know of any libraries you are currently developing that you intend to submit for review.

3 4

Interest in properties library?
by Sergey Sadovnikov 11 Jul '08

11 Jul '08

Hello All, Would there be any interest in another C++ properties implementation? I know that boost sandbox already contains properties library. But I can offer another implementation of such library with some advantages like this: - Simple properties set initialization. Only one call from the constructor: class SomeClass { public: //... SomeClass() : properties__(this) {/*...*/} //... }; - Many kins of properties. Now implemented: Simple properties similar to datamembers. Properties bindable to getter/setter methods of container class. Properties bindable to arbitrary methods. Index properties with up to three levels of indirection. - Properties could be "abstract" and need implementation in derived classes - In-place initialization of simple properties. For example: PROPERTY_I(int, ContainerSize, 10) - Generic runtime access to the properties via names: SomeClassWithProps c; int val; c.properties__.invoke_get("ContainerSize", var(val) = boost::lambda::_1); c.properties__.invoke_set("ContainerSize", 20); - Runtime enumeration of properties: // Property visitor function template<typename P> void PropertyEnumerator(const std::string& propertyName, P SomeClassWithProps::* propInfo) { //... ] // Properties enumeration: SomeClassWithProps::properties__::enum_s(PropertyEnumerator); - Simple serialization of properties: template<typename Ar> void serialize(Ar& ar, const unsigned int ver) { ar & properties__; } - Quite simple definition in class. A piece of code from real project: // Example of abstract properties definition in the base class: class IPlayerCraft : public IAirObject { public: IPlayerCraft() : properties__(this) {;} virtual ~IPlayerCraft(){} // Craft status enum ECRAFTSTATUS { csREADY =0, csFLYING, csREPAIRING, csREFUELING, csREARMING, csTRANSFERING, csMAXCOUNT }; PROPERTIES(IPlayerCraft, // Craft name ABSTRACT_RW_PROPERTY(std::wstring, Name) // Static craft info ABSTRACT_RO_PROPERTY(SCraftInfo const*, Info) // Craft home base ABSTRACT_RO_PROPERTY(IBase const*, HomeBase) // Is craft on the base? ABSTRACT_RO_PROPERTY(bool, IsOnTheBase) // Craft status ABSTRACT_RO_PROPERTY(ECRAFTSTATUS, Status) // Current craft speed ABSTRACT_RO_PROPERTY(TPARAM, Speed) // Craft weapon ABSTRACT_INDEX_PROPERTY(IItem*, CraftWeapon, 1, (CraftSlotCoord)) // Craft weapon ammo ABSTRACT_RO_INDEX_PROPERTY(TPARAM, CraftWeaponAmmo, 1, (CraftSlotCoord)) ); //... }; // Implementation class class PlayerCraft : public IPlayerCraft { public: PlayerCraft(SCraftInfo const*, Player* player); ~PlayerCraft(); PROPERTIES(PlayerCraft, IMPLEMENT_PROPERTY(IPlayerCraft, PROPERTY(std::wstring, Name)) IMPLEMENT_PROPERTY(IPlayerCraft, PROPERTY(SCraftInfo const*, Info)) IMPLEMENT_PROPERTY(IPlayerCraft, RO_PROPERTY(IBase const*, HomeBase, GetHomeBase)) IMPLEMENT_PROPERTY(IPlayerCraft, PROPERTY(bool, IsOnTheBase)) IMPLEMENT_PROPERTY(IPlayerCraft, PROPERTY_I(ECRAFTSTATUS, Status, csTRANSFERING)) IMPLEMENT_PROPERTY(IPlayerCraft, PROPERTY_I(TPARAM, Speed, 0)) IMPLEMENT_PROPERTY(IPlayerCraft, INDEX_PROPERTY(IItem*, CraftWeapon, 1, (CraftSlotCoord), GetCraftWeapon, SetCraftWeapon)) IMPLEMENT_PROPERTY(IPlayerCraft, RO_INDEX_PROPERTY(TPARAM, CraftWeaponAmmo, 1, (CraftSlotCoord), GetCraftWeaponAmmo)) ); // ... IBase const* GetHomeBase() const {return m_HomeBase;} private: // ... IItem* GetCraftWeapon(int slotId) const; void SetCraftWeapon(int slotId, IItem* weapon); TPARAM GetCraftWeaponAmmo(int slotId) const; }; As you can see, properties definition based on boost::preprocessor. It allows to implement quite complex background (with many special abilities) for quite simple front-end. It is assumed what access to the properties in many cases is same as access to the datamember: PlayerCraft craft; std::string craft_name = craft.Name; //... IItem* weapon = craft.CraftWeapon[1]; And there is special access form needs in some cases: craft.Name(); or craft.Name.get(); If there is an interest in such properties implementation I could start prepare code for formal library review. -- Best Regards, Sergey mailto:flex_ferrum@artberg.ru

2 1

Recursive iterator/range adaptors
by Mathias Gaunard 11 Jul '08

11 Jul '08

The traversal library that has been discussed allows tree-like traversal of structures using a functional approach. I suggest an alternative approach: a range-based one. It certainly has limitations: ranges are monomorphic. So you can only do it if is_same< typename range_value<Range>::type, typename range_value< typename range_value<Range> >::type >. However, it would be very practical to use, since you could simply use a foreach loop to perform depth-first search and stop iteration whenever you like. Also, it is lazy and you can combine it easily with other range adaptors (filtering, transforming...) or algorithms. For performance, one would need to provide a way to get the father range of a given range. Maybe that's the occasion to create a new concept. Otherwise iterators will need to have their own stack. Did anyone ever work on that? Does it look like a good idea?

2 3

[pool] segfault
by Phil Bouchard 11 Jul '08

11 Jul '08

I was testing my own "shifted_ptr_test2.cpp" on RHEL 4.5 using Gcc 3.4.6 and the following object declared in "sh_owned_base_nt.hpp" caused a segmentation violation inside its destructor. It doesn't seem to happen on Windows, just Linux: pool owned_base::pool_; // derives from boost::pool<> Thanks, -Phil

3 7

[graph] generating CSR graph from undirected
by Mojmir Svoboda 11 Jul '08

11 Jul '08

hello, i suspect there is something wrong with assign routine in compressed_sparse_row_graph.hpp. when i am constructing directed csr from undirected one via // From any graph (slow and uses a lot of memory) // Requires IncidenceGraph, a vertex index map, and a vertex(n, g) function // Internal helper function template<typename Graph, typename VertexIndexMap> void assign(const Graph& g, const VertexIndexMap& vi, vertices_size_type numverts, edges_size_type numedges) { inherited_vertex_properties::resize(numverts); m_rowstart.resize(numverts + 1); m_column.resize(numedges); it overwrites non-allocated memory, because the number of edges is in fact doubled.. is it an imperfection or am i doing something stupid? have a nice day, mojmir

1 0

Boost DateTime package question
by Mohnish Kodnani 10 Jul '08

10 Jul '08

Hi All, I have a question regarding the boost DateTime package. In our application we have to support storing time from various time zone in UTC and we need to know DST of various timezones. We are currently using standard C runtime libraries for this purpose on various platforms like windows , linux, aix, hpux. My question, Recently there has been a need to store dates prior to epoch in our system and this causes problems since none of the standard C runtime libraries support dates prior to EPOCH. We are also interested in DST settings prior to EPOCH, since in our experiments it looks like Java knows DST till 1942 or in its vicinity, however C only deals with dates after epoch. Our server is in C++ and client in Java, so we have issues here when client sends a date prior to 1942 and we have to store its UTC value, we cannot do this since C runtime mktime like functions dont work. Does Boost DateTime package provide this functionality, if not is that in the plans. >From what I read so far it looks like this package does not have this functionality, but has the functionality to create our own rules, however this is difficult considering all countries around the world, it would be good if we had something similar to C runtime. Please let me know. thanks Mohnish

1 0

[constrained_value] Formal review request
by Robert Kawulak 10 Jul '08

10 Jul '08

Dear Boosters, I'm glad to say the Boost Constrained Value library is finally ready for a formal review. To remind what this library is about, an excerpt from the motivation section of the documentation is attached at the bottom of this message. Jeff, you volunteered to be the review manager - is your proposition still up to date? If so, I'd be thankful if you could do the work. ;-) The code and documentation can be downloaded here: http://rk.go.pl/f/constrained_value.zip The documentation is also available online here: http://rk.go.pl/r/constrained_value The only thing that's missing is test programs - I will try to add them during/after the review. The changes made since previous version: - rewritten the documentation at some points and added tutorial, - no more value generators - direct types or MPL integral constants are used instead, - bounded types use bounds exclusion instead of inclusion (so bounds are included by default in all cases), - changed order and default values of some of template parameters, - removed throw_verbose_exception error policy, - made other minor fixes and improvements. As always, feedback is welcome. Best regards, Robert Kawulak FROM THE MOTIVATION SECTION OF THE DOCUMENTATION: The Boost Constrained Value library contains class templates useful for creating constrained objects. A simple example is an object representing an hour of a day, for which only integers from the range [0, 23] are valid values: bounded_int<int, 0, 23>::type hour; hour = 20; // OK hour = 26; // exception! Behavior in case of assignment of an invalid value can be customized. For instance, instead of throwing an exception as in the example above, the value may be adjusted to meet the constraint: wrapping_int<int, 0, 255>::type buffer_index; buffer_index = 257; // OK: adjusts the value to fit in the range by wrapping it assert( buffer_index == 1 ); The library doesn't focus only on bounded objects as in the examples above -- virtually any constraint can be imposed by using a predicate: // constraint (a predicate) struct is_odd { bool operator () (int i) const { return (i % 2) != 0; } }; // and the usage is as simple as: constrained<int, is_odd> odd_int = 1; odd_int += 2; // OK ++odd_int; // exception! The library has a policy-based design to allow for flexibility in defining constraints and behavior in case of assignment of invalid values. Policies may be configured at compile-time for maximum efficiency or may be changeable at runtime if such dynamic functionality is needed.

4 5

[test][sun-5.7 -5.8][trunk] regressions for Boost.Test starting at revision 47170
by JOAQUIN M. LOPEZ MUÑOZ 10 Jul '08

10 Jul '08

Hello, Recent updates to the trunk version of Boost.Test have resulted in a massive number of regressions for Sun 57 and 5.8, as shown for instance in: http://tinyurl.com/5lm7ha http://tinyurl.com/66qcze The error message is "../boost/test/utils/iterator/input_iterator_facade.hpp", line 56: Error: Multiple declaration for input_iterator_facade. After examining the updates to Boost.Test in the last days I think I found the change that's causing the regressions: http://svn.boost.org/trac/boost/changeset/47170/trunk/boost/test The change in line 26 of boost/test/impl/unit_test_main.ipp causes the header <boost/test/utils/iterator/token_iterator.hpp> to be included where previously that was not the case. This in turns includes <boost/test/utils/iterator/input_iterator_facade.hpp>, which contains the following problematic code (for Sun 5.7-8) around line 25: #if defined(BOOST_NO_MEMBER_TEMPLATE_FRIENDS) || BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x551)) public: #else template <class I, class V, class R, class TC> friend class input_iterator_facade; #endif This perfectly correct friend declaration is not processed properly by Sun 5.7 and 5.8 hence the error. May I ask that the problem be fixed by applying either one of the following? 1. Add a workaround for Sun 5.7-8 at line 35 of boost/test/utils/iterator/input_iterator_facade.hpp 2. Add a !workaround for Sun 5.7-8 at line 26 of boost/test/impl/unit_test_main.ipp Thank you! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[inspect] A few issues in non-ASCII checker
by Gennaro Prota 10 Jul '08

10 Jul '08

Hi, I had a summary look at the changes made to Boost.Inspect (since I last saw it) and noticed a few issues: * the "*A*" marker is used either for broken links, invalid urls etc. *and* non-ASCII chars * "non-ASCII" itself looks like a misleading name: see the string gPunct, defined in ascii_check.cpp * non portable (though widely portable :-)) code: if ( c >= 'a' && c <= 'z' ) return false; if ( c >= 'A' && c <= 'Z' ) return false; if ( c >= '0' && c <= '9' ) return false; If there aren't problems with standard library support I'd suggest replacing the above with if ( std::isalnum( static_cast< int >( c ), std::locale::classic() ) ) Similarly for the subsequent isspace-like tests * again in ascii_check.cpp there's some scaffolding to get a line number from a file position; this is needed in other inspector classes as well, and is done much differently. I think it is worth unifying this part and make it available in one place -- Genny

3 3

public beta test ?
by Ruediger Berlich 10 Jul '08

10 Jul '08

Hi there, I'd like to suggest a public beta test as part of the release procedure. >From what I can see, while the trunk version is available to everybody, there is no formal call for external testing. But this would increase visibility of Boost and would likely reveal a number of additional bugs. Best, Ruediger

2 2

a little imperfection in options_description.cpp example (program options)
by Guido Ziliotti 10 Jul '08

10 Jul '08

// A helper function to simplify the main part. template<class T> ostream& operator<<(ostream& os, const vector<T>& v) { copy(v.begin(), v.end(), ostream_iterator<T>(cout, " ")); /* this is line 21 */ return os; } SHOULD BE REPLACED WITH // A helper function to simplify the main part. template<class T> ostream& operator<<(ostream& os, const vector<T>& v) { copy(v.begin(), v.end(), ostream_iterator<T>(os, " ")); /* this is line 21: "os" replaces "cout" */ return os; }

2 1

[1.36.0] Unmerged SVN Properties
by Beman Dawes 10 Jul '08

10 Jul '08

There are a whole bunch (see below) of messages from the unmerged changes analysis that look like this: Property changes on: tr1/tr1/valarray ___________________________________________________________________ Name: svn:eol-style + native Name: svn:mime-type + text/plain I guess these need to be merged from trunk to branches/release like any other change. --Beman Here is the full list: Property changes on: archive/detail/polymorphic_iarchive_route.hpp Property changes on: archive/detail/polymorphic_oarchive_route.hpp Property changes on: archive/xml_archive_exception.hpp Property changes on: compatibility/cpp_c_headers/cassert Property changes on: compatibility/cpp_c_headers/cctype Property changes on: compatibility/cpp_c_headers/cerrno Property changes on: compatibility/cpp_c_headers/cfloat Property changes on: compatibility/cpp_c_headers/climits Property changes on: compatibility/cpp_c_headers/clocale Property changes on: compatibility/cpp_c_headers/cmath Property changes on: compatibility/cpp_c_headers/csetjmp Property changes on: compatibility/cpp_c_headers/csignal Property changes on: compatibility/cpp_c_headers/cstdarg Property changes on: compatibility/cpp_c_headers/cstddef Property changes on: compatibility/cpp_c_headers/cstdio Property changes on: compatibility/cpp_c_headers/cstdlib Property changes on: compatibility/cpp_c_headers/cstring Property changes on: compatibility/cpp_c_headers/ctime Property changes on: compatibility/cpp_c_headers/cwchar Property changes on: compatibility/cpp_c_headers/cwctype Property changes on: config/warning_disable.hpp Property changes on: detail/lightweight_thread.hpp Property changes on: detail/sp_convertible.hpp Property changes on: detail/sp_counted_base_spin.hpp Property changes on: detail/spinlock.hpp Property changes on: detail/spinlock_gcc_arm.hpp Property changes on: detail/spinlock_nt.hpp Property changes on: detail/spinlock_pool.hpp Property changes on: detail/spinlock_pt.hpp Property changes on: detail/spinlock_sync.hpp Property changes on: detail/spinlock_w32.hpp Property changes on: detail/yield_k.hpp Property changes on: graph/edmonds_karp_max_flow.hpp Property changes on: graph/r_c_shortest_paths.hpp Property changes on: iostreams/detail/execute.hpp Property changes on: iostreams/detail/file_handle.hpp Property changes on: iostreams/detail/file_times.hpp Property changes on: iostreams/detail/functional.hpp Property changes on: iostreams/detail/path.hpp Property changes on: iostreams/filter/grep.hpp Property changes on: make_shared.hpp Property changes on: math/distributions/detail/generic_mode.hpp Property changes on: math/distributions/detail/generic_quantile.hpp Property changes on: math/distributions/non_central_beta.hpp Property changes on: math/distributions/non_central_chi_squared.hpp Property changes on: math/distributions/non_central_f.hpp Property changes on: math/distributions/non_central_t.hpp Property changes on: math/special_functions/detail/lanczos_sse2.hpp Property changes on: math/special_functions/detail/round_fwd.hpp Property changes on: math/special_functions/expint.hpp Property changes on: math/special_functions/modf.hpp Property changes on: math/special_functions/next.hpp Property changes on: math/special_functions/pow.hpp Property changes on: math/special_functions/round.hpp Property changes on: math/special_functions/trunc.hpp Property changes on: math/special_functions/zeta.hpp Property changes on: math/tr1.hpp Property changes on: memory_order.hpp Property changes on: pool/detail/for.m4 Property changes on: pool/detail/pool_construct.inc Property changes on: pool/detail/pool_construct.m4 Property changes on: pool/detail/pool_construct_simple.inc Property changes on: pool/detail/pool_construct_simple.m4 Property changes on: property_tree/detail/exceptions_implementation.hpp Property changes on: property_tree/detail/file_parser_error.hpp Property changes on: property_tree/detail/info_parser_error.hpp Property changes on: property_tree/detail/info_parser_read.hpp Property changes on: property_tree/detail/info_parser_utils.hpp Property changes on: property_tree/detail/info_parser_write.hpp Property changes on: property_tree/detail/info_parser_writer_settings.hpp Property changes on: property_tree/detail/json_parser_error.hpp Property changes on: property_tree/detail/json_parser_read.hpp Property changes on: property_tree/detail/json_parser_write.hpp Property changes on: property_tree/detail/path_implementation.hpp Property changes on: property_tree/detail/ptree_implementation.hpp Property changes on: property_tree/detail/ptree_utils.hpp Property changes on: property_tree/detail/pugxml.hpp Property changes on: property_tree/detail/rapidxml.hpp Property changes on: property_tree/detail/translator_implementation.hpp Property changes on: property_tree/detail/xml_parser_error.hpp Property changes on: property_tree/detail/xml_parser_flags.hpp Property changes on: property_tree/detail/xml_parser_read_pugixml.hpp Property changes on: property_tree/detail/xml_parser_read_pugxml.hpp Property changes on: property_tree/detail/xml_parser_read_rapidxml.hpp Property changes on: property_tree/detail/xml_parser_read_spirit.hpp Property changes on: property_tree/detail/xml_parser_read_tinyxml.hpp Property changes on: property_tree/detail/xml_parser_utils.hpp Property changes on: property_tree/detail/xml_parser_write.hpp Property changes on: property_tree/detail/xml_parser_writer_settings.hpp Property changes on: property_tree/info_parser.hpp Property changes on: property_tree/ini_parser.hpp Property changes on: property_tree/json_parser.hpp Property changes on: property_tree/ptree.hpp Property changes on: property_tree/ptree_fwd.hpp Property changes on: property_tree/ptree_serialization.hpp Property changes on: property_tree/xml_parser.hpp Property changes on: serialization/assume_abstract.hpp Property changes on: serialization/factory.hpp Property changes on: serialization/singleton.hpp Property changes on: serialization/vector_134.hpp Property changes on: statechart/detail/reaction_dispatcher.hpp Property changes on: swap.hpp Property changes on: test/utils/lazy_ostream.hpp Property changes on: tr1/tr1/algorithm Property changes on: tr1/tr1/array Property changes on: tr1/tr1/bitset Property changes on: tr1/tr1/complex Property changes on: tr1/tr1/deque Property changes on: tr1/tr1/exception Property changes on: tr1/tr1/fstream Property changes on: tr1/tr1/functional Property changes on: tr1/tr1/iomanip Property changes on: tr1/tr1/ios Property changes on: tr1/tr1/iostream Property changes on: tr1/tr1/istream Property changes on: tr1/tr1/iterator Property changes on: tr1/tr1/limits Property changes on: tr1/tr1/list Property changes on: tr1/tr1/locale Property changes on: tr1/tr1/map Property changes on: tr1/tr1/memory Property changes on: tr1/tr1/new Property changes on: tr1/tr1/numeric Property changes on: tr1/tr1/ostream Property changes on: tr1/tr1/queue Property changes on: tr1/tr1/random Property changes on: tr1/tr1/regex Property changes on: tr1/tr1/set Property changes on: tr1/tr1/sstream Property changes on: tr1/tr1/stack Property changes on: tr1/tr1/stdexcept Property changes on: tr1/tr1/streambuf Property changes on: tr1/tr1/string Property changes on: tr1/tr1/strstream Property changes on: tr1/tr1/tuple Property changes on: tr1/tr1/type_traits Property changes on: tr1/tr1/typeinfo Property changes on: tr1/tr1/utility Property changes on: tr1/tr1/valarray Property changes on: tr1/tr1/vector Property changes on: utility/swap.hpp

1 0

[extension] Problem with reference types
by Robert Dailey 10 Jul '08

10 Jul '08

I have the following exported factory function in a DLL I'm building on Windows: extern "C" void BOOST_EXTENSION_EXPORT_DECL export_aspects( boost::extensions::factory_map& fm ) { using namespace vfx::aspects; using namespace vfx::messenger; fm.get<Aspect, MessageReader&, unsigned int>()[0].set<Appearance>(); fm.get<Aspect, MessageReader&, unsigned int>()[1].set<Health>(); } As you can see, I am specifying that each class accepts a single construction parameter- a reference to a MessageReader object. However, this isn't compiling because I don't think that it likes reference types. How can I specify that the constructor takes a reference? boost::ref? I would post the compiler warnings & errors I'm getting, however they're exceedingly large. Most of the warnings and errors are coming from std::map, basically complaining that it's trying to create a map of reference types, which can't possibly work. Help is appreciated. As an unrelated note, I would really like to see the template parameters cleaned up. There's at least 5 places I've had to redundantly specify the same 3 template parameters (like in the example above). I already brought this up in another thread, but I can't tell you how important it is. If I ever change the number of construction parameters my Appearance or Health classes take (mapped above), I will have to shift through 5 or more files simply to adjust all of the template parameters to make everything compile.

1 1

[asio] std::ostream request_stream
by simonvifr＠voila.fr 09 Jul '08

09 Jul '08

Good morning, In the examples that illustrate the use of Boost.Asio in more complex applications, there is the "boost_asio/example/http/client/sync_client.cpp" example. In this example, the following code is written : boost::asio::streambuf request; std::ostream request_stream(&request); request_stream << "GET " << argv[2] << " HTTP/1.0\r\n"; request_stream << "Host: " << argv[1] << "\r\n"; request_stream << "Accept: */*\r\n"; request_stream << "Connection: close\r\n\r\n"; I would like to use the POST method with parameters instead of GET method, and to set the "Content-Type" property. But I do not how to do. Could you tell me more about using the POST method and setting the "Content-Type" property ? Could you also tell me where I can find documentation about it ? Thank you for your response, Regards. ____________________________________________________ Sur le mail Voila, vous pouvez personnaliser l’anti-spam ! http://mail.voila.fr

1 0

An elegant way to initialize an instance of boost::any with a C-style string constant
by Ferdinand Prantl 09 Jul '08

09 Jul '08

Hello, I would like to improve usage of boost::any with text (char*) constants. This would be the goal: boost::any foo("foo"); boost::any bar; bar = "bar"; Currently the compiler (MSVC 2008 in my case) complains about it: ...\boost\any.hpp(117) : error C2536: 'boost::any::holder< ValueType>::boost::any::holder<ValueType>::held' : cannot specify explicit initializer for arrays There are more ways to make it compiled, all of them either with an extra cast or object construction: boost::any foo(static_cast<const char *>("foo")); boost::any foo((const char *) "foo"); boost::any foo(std::string("foo")); Supposing there is no way to persuade the compiler to consider the constant not to be an array but just a pointer I would suggest adding support for arrays to boost::any. I am sorry if it has been discussed already. I found just one thread without a conclusion (http://lists.boost.org/Archives/boost/2003/01/43460.php) I asked about it in boost.users and got a nice proposal from Niels Dekker (http://thread.gmane.org/gmane.comp.lib.boost.user/37189/focus=37414) I replaced the member "held" in holder<> by a wrapper specialized for arrays: template<typename ValueType> struct wrapper { ValueType data; explicit wrapper(const ValueType & value) : data(value) {} }; template<typename ElementType, std::size_t NumberOfElements> struct wrapper<ElementType[NumberOfElements]> { typename remove_const<ElementType>::type data[NumberOfElements]; explicit wrapper(const ElementType (& value)[NumberOfElements]) { std::copy(value, value + NumberOfElements, data); } }; A new constructor in boost::any makes use of it: template<typename ElementType, std::size_t NumberOfElements> any(const ElementType (& value)[NumberOfElements]) : content(new holder<ElementType[NumberOfElements]>(value)) {} This solution is more complicated but it makes the instance of boost::any own the copy of array just like its for scalar objects. Alternatively, instead of wrapping a copy of the array, I could store just a pointer to it without any other changes in bost::any (I want to use just constants in my example): template<typename ElementType, std::size_t NumberOfElements> any(const ElementType (& value)[NumberOfElements]) : content(new holder<const ElementType*>(value)) {} I am attaching a patch to any.hpp from boost 1.35.0. I could provide a test for it too. What do you think about it? Shall I create a feature request for it? Thank you, Ferda

4 5

Re: [boost] How do you make MPL-compatible template meta-functions?
by joaquin＠tid.es 09 Jul '08

09 Jul '08

Hi Daryle Daryle Walker escribió: > Here's what I'm trying (to redo integer_test.cpp) [...] > BOOST_STATIC_ASSERT > ( (boost::is_same<distinct_integral_bit_counts, > boost::mpl::list_c<int, 8, 16, 32, 64> >) ); > } > I think there are two problems with this: 1. You're passing a *type* (boost::is_same<...>) to BOOST_STATIC_ASSERT when you should be passing a numeric contanst. Append ::value to the type. 2. Even with the correction above the thing won't work because is_same<T,Q> checks for strict equality of the types T and Q; in your case distinct_integral_bit_counts is *not* the same type as boost::mpl::list_c<...>, but only has the same components. You can use boost::mpl::equal to test this: BOOST_STATIC_ASSERT ( (boost::mpl::equal<distinct_integral_bit_counts, boost::mpl::list_c<int, 8, 16, 32> >::value) ); } Other than that, your type_to_digit_count is perfectly lambda-cabable AFAICS. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 4

[Iostreams] Support std::codecvt<char> and std::codecvt_base::noconv in boost::iostreams::code_converter
by Ferdinand Prantl 09 Jul '08

09 Jul '08

Hello, I found two problems when using boost::iostreams::code_converter with char as source (internal) type for the conversion. Firstly, I was not able to use facets parameterized with char extracted from std::locale and secondly, my test run in an endless loop if the facet returned std::codecvt_base::noconv from do_in() or do_out(). I would like to use the boost::iostreams::code_converter in a class parametrized either for char or wchar_t using the default std::codecvt. This code works for wchar_t: namespace io = boost::iostreams; class test { io::stream<io::code_converter<xxxodevice, io::default_codecvt> > output; ... }; However I cannot make in templated like this without inheriting from std::codecvt and pasing the inherited type to io::code_converter instead of std::codecvt: template <class C> class test { io::stream<io::code_converter<xxxodevice, std::codecvt<C, char, std::mbstate_t> > output; ... }; The compiler complains about the usage of std::codecvt: error C2248: 'std::codecvt<_Elem,_Byte,_Statype>::~codecvt' : cannot access protected member declared in class 'std::codecvt<_Elem,_Byte,_Statype>' io::detail::codecvt_holder<Codecvt> in codecvt_holder.hpp stores a copy of Codecvt but std::codecvt defines only protected destructor: template<typename Codecvt> struct codecvt_holder { ... Codecvt codecvt_; }; Standard std::codecvt specialized for wchar_t is solved by its explicit specialization storing the pointer: struct default_codecvt { typedef wchar_t intern_type, from_type; typedef char extern_type, to_type; typedef std::mbstate_t state_type; }; template<> struct codecvt_holder<default_codecvt> { ... const codecvt_type* codecvt_; }; Obviously it supports the most usual usage with an instance extracted from std::locale which owns it: typedef std::codecvt<wchar_t, char, std::mbstate_t> codecvt_type; ... = &std::use_facet<codecvt_type>(locale); What about facets not converting from sequence of wchat_ts but chars? If I imbue such facet to a locale I am not able to extract it and use it in io::code_converter: template <class C> class test { io::stream<io::code_converter<xxxodevice, std::codecvt<C, char, std::mbstate_t> > output; void imbue(std::locale const & locale) { output.imbue(locale); } }; I helped it by converting io::detail::default_codecvt and the specialization of io::detail::codecvt_holder for it in codecvt_holder.hpp to this: template <class C> struct basic_default_codecvt { typedef C intern_type, from_type; ... }; template <class C> struct codecvt_holder<basic_default_codecvt<C> > { typedef std::codecvt<C, char, std::mbstate_t> codecvt_type; ... }; typedef basic_default_codecvt<wchar_t> default_codecvt; Now I was able to compile my slightly modified code: template <class C> class test { io::stream<io::code_converter<xxxodevice, io::detail::basic_default_codecvt<C> > output; void imbue(std::locale const & locale) { output.imbue(locale); } }; After being able to compile it a simple output code run endlessly. I found out that the facet in the default locale did not convert but it did not return true from always_noconv() from some reason. io::code_converter can cope with it - it copies the input buffer to the output one but it does not increase the pointer to the next character in the output buffer nor does it decrease the total bytes processed in io::code_converter::write. I am not sure about the behavior of the coverter if the facet returns std::codecvt_base::noconv. Currently it copies the buffer if internal type is the same as external one (both char) otherwise it does nothing (?). Should it not copy or assert if they are diferent? At least the writing should succeed if there was no conversion done and the characters were copied. I tried to modify the code accordingly and it succeeded then. I am attaching a patch to code_converter.hpp and codecvt_holder.hpp from boost 1.35.0. I could provide a test for it too. Thank you, Ferda

1 0

[Iostreams] What about making code_converter from boost::iostreams flushable?
by Ferdinand Prantl 09 Jul '08

09 Jul '08

Hello, I would like to wrap an output stream buffer (std::streambuf) with boost::iostreams::code_converter to be able to use it both raw and with ont-the-fly encoding by the boost::iostreams::default_facet. namespace io = boost::iostreams; xxxstream stream; stream << "raw"; io::stream<io::code_converter<xxxodevice> > wrapper(*stream.rdbuf()); wrapper << L" and converted"; stream << " and another raw"; Running the code writes "raw and another raw and converted" instead of "raw and converted and another raw" to the stream. I found that first in destructor of io::code_converter is the conversion buffer flushed causing the output. I could create a new instance of io::code_converter for every output and always close it: namespace io = boost::iostreams; xxxstream stream; stream << "raw"; { io::stream<io::code_converter<xxxodevice> > wrapper(*stream.rdbuf()); wrapper << L" and converted"; } stream << " and another raw"; But I would feel better being able to reuse the io::code_converter. (Actually, I have it as a private field in a class now.) I would like to make the io::code_converter flushable to be able to combine the output more conveniently: namespace io = boost::iostreams; xxxstream stream; stream << "raw"; io::stream<io::code_converter<xxxodevice> > wrapper(*stream.rdbuf()); wrapper << L" and converted" << std::flush; stream << " and another raw"; I added the support to io::code_converter rather that inheriting from it. What do you think about it? Would you accept it to boost or is it better to make flushable my inherited class? I am attaching a patch to code_converter.hpp from boost 1.35.0. I could provide a test for it too. Thank you, Ferda

1 0

[Iostreams] code_converter from boost::iostreams fails with bidirection device
by Ferdinand Prantl 09 Jul '08

09 Jul '08

Hello, I would like to wrap an input/output stream buffer (std::streambuf) with boost::iostreams::code_converter to be able to use it both raw and with ont-the-fly encoding by the boost::iostreams::default_facet. namespace io = boost::iostreams; xxxstream stream; stream << "raw "; io::stream<io::code_converter<xxxiodevice> > wrapper(*stream.rdbuf()); wrapper << L"and converted"; I created a device wrapping std::streambuf. Pure input device (using io::source_tag) and pure output device (using io::sink_tag) were working. Combined device (using io::bidirectional_device_tag) failed with access violation in destructor (flushing and closing) of the io::code_converter in code_converter.hpp: template<typename Device, typename Codevt, typename Alloc> std::streamsize code_converter<Device, Codevt, Alloc>::write (const char_type* s, std::streamsize n) { buffer_type& buf = out(); ... std::codecvt_base::result result = // buf.eptr() was null here cvt().out( buf.state(), s + total, s + n, nint, buf.eptr(), buf.end(), next ); ... } I wondered how it is possible that the output buffer was not initialized. I learnt that the buffer was intentionally skipped in code_converter.hpp: template<typename Device, typename Codecvt, typename Alloc> struct code_converter_impl { ... void open(const Device& dev, int buffer_size) { ... // following condition is false for bidirectional if (can_write::value && !is_double::value) { buf_.second().resize(buffer_size); buf_.second().set(0, 0); } ... } ... }; The reason is the definition of a bidirectional device in categories.hpp: struct bidirectional : virtual input, virtual output, detail::two_sequence {}; It is detected in the io::code_converter turning off the initialization: typedef is_convertible<device_category, two_sequence> is_double; It means that I cannot use io::code_converter with io::bidirectional combining both io::input and io::output tags. Unfortunately I was not able to use these both explicitely: // original: typedef io::bidirectional_device_tag category; struct category : io::device_tag, io::input, io::output {}; The compiler complained about it with a message I was not able to fix: error C2784: 'std::basic_ostream<_Elem,_Traits> &boost::operator <<( std::basic_ostream<_Elem,_Traits> &,const boost::shared_ptr<Y> &)' : could not deduce template argument for 'std::basic_ostream< _Elem,_Traits> &' from 'boost::iostreams::stream<Device>' So far, I found just one working solution without changing boost sources - using two objects; one for reading, another one for writing: xxxstream stream; stream << "raw "; io::stream<io::code_converter<xxxidevice> > inwrapper(*stream.rdbuf()); io::stream<io::code_converter<xxxodevice> > outwrapper(*stream.rdbuf()); outwrapper << L"and converted"; However, I would like to use one object if it was possible. In my case, all writing is always finished before reading and vice versa. Encoding states in std::codecvt would not overlap. What would you suggest as a solution for input/output devices in io::code_converter? 1. Stick with the two objects - one for input, one for output. 2. Fix io::code_converter to accept devices with io::bidirectional tag. Either initialize both buffers or reuse the input one. 3. Use different tag than io::bidirectional. Which one? 4. Maybe I am wrapping std::streambuf in a wrong way. Is there another? I am attaching a simple example of a stripped source demonstrating the issue on std::stringstream. Thank you, Ferda

1 0

[Boost.Log1]: Bug in boost/log/detail/ts_posix.hpp
by Jens Seidel 09 Jul '08

09 Jul '08

Hi, I know that version 1 of John's logging library was never accepted and is probably not wildly used anymore nevertheless I found a nasty bug in it. It's strange but even after applying valgrind I found initially not the reason (probably I just assumed John's code is OK and it's something else) and it took some time until I resolved it. OK, for all users of this lib here is the patch: boost/log/detail/ts_posix.hpp: @@ -51,7 +51,7 @@ mutex & operator = ( const mutex & Not_Implemented); mutex( const mutex & From); public: - mutex() : m_mutex() { + mutex() : m_mutex(), m_count(0) { pthread_mutexattr_t attr; int res = pthread_mutexattr_init(&attr); assert(res == 0); I haven't checked whether this occurs in version 2 as well. Jens

3 3

Fusion Question
by Tom Brinkman 09 Jul '08

09 Jul '08

Heres a link to a simple unit test that demonstrates the layout library. http://www.reportbase.com/unit_test.hello.html

2 1