- Boost - lists.preview.boost.org

[concept_check] New failures on RC
by Markus Schöpflin 09 Sep '05

09 Sep '05

A new test called stl_concept_covering has appeared in the concept_check lib on the RC branch. It currently fails for all platforms. Maybe it should have gone to the trunk? Markus

1 0

[filesystem] determine free space
by Simon Richter 09 Sep '05

09 Sep '05

Hi, I just ran across the problem of having to determine how much space was available for a new file that would end up at a certain path. I'd be willing to contribute such a function (convenience.hpp looks like a good place) for Unix, but it would have to be complemented by other OS dependent functions for the other architectures. Anyone interested? Simon

2 1

Re: [boost] [thread] Win32 call_once
by Greer, Joe 08 Sep '05

08 Sep '05

I have continued to think about the call_once() mechanism because many uses I can think of for it could require that it be called a lot. Therefore, I think we want the "normal" path to be as quick as possible. To that end, I was trying to come up with a way to use critical sections instead of named semaphores for the guard. I think I have managed that now, but it also occurs to me that we can test the flag up front to see if it has been set and if it has, we don't need to get any sort of guard. In the case that it hasn't, we can then acquire a guard (of some sort), re-test the flag (in case we have two threads running in parallel), and then execute the function. It looks a little uglier because of the double test, but it would execute faster because most of the time it would never have to get the guard. Hopefully there is something useful here. :) joe

2 1

Boost-Wiki: Hacked...
by Johannes Brunen 08 Sep '05

08 Sep '05

Hi, I just take a look at the Boost-Wiki: BoostGui. The links http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?TableViews http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?OutlineViews http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?TreeViews etc. are all hacked. With best regards Johannes ____________ Virus checked by G DATA AntiVirusKit Version: AVK 16.350 from 06.09.2005 Virus news: www.antiviruslab.com

6 6

[thread] synchronization objects of static storage duration
by Anthony Williams 08 Sep '05

08 Sep '05

Hi all, I've been thinking a lot about synchronization primitives, especially around call_once, but also around mutexes, semaphores and conditions. Ensuring that they are correctly initialized, safely, is a hard problem, especially if we try and allow them to be used both as objects with static storage duration, and with non-static storage duration, or as members of other classes. Firstly, objects with static storage duration must be completely initialized statically, and not require any dynamic initialization. This is because dynamic initialization is not thread safe in general, and exposes the object to potential race conditions on the initialization, unless an alternative synchronization mechanism is used to ensure thread safety. The POSIX spec gives a good example, relating to pthread_mutex_init: "Without static initialization, a self-initializing routine foo() might look as follows: static pthread_once_t foo_once = PTHREAD_ONCE_INIT; static pthread_mutex_t foo_mutex; void foo_init() { pthread_mutex_init(&foo_mutex, NULL); } void foo() { pthread_once(&foo_once, foo_init); pthread_mutex_lock(&foo_mutex); /* Do work. */ pthread_mutex_unlock(&foo_mutex); } With static initialization, the same routine could be coded as follows: static pthread_mutex_t foo_mutex = PTHREAD_MUTEX_INITIALIZER; void foo() { pthread_mutex_lock(&foo_mutex); /* Do work. */ pthread_mutex_unlock(&foo_mutex); }" This requires that the objects are PODs or aggregates of PODs, so that no constructors are run (which would be dynamic initialization); if zero-initialization is not satisfactory, then a static initializer akin to PTHREAD_MUTEX_INITIALIZER can then be used. Secondly, objects of non-static storage duration cannot assume anything about the underlying memory, so they must be initialized dynamically. If the same class type is to be used for both purposes, this cannot be with a constructor, so it must be with an initializer. Whether this is the same as the static initializer is another question. Thirdly, these requirements apply recursively to any class which contains a synchronization primitive as a member: if a class has a constructor, then it is not safe for static initialization. If it does not have a constructor, then it requires an initializer to ensure safe use as an object with non-static storage duration. For such a class with a constructor, the synchronization primitive member must therefore be initialized in the member-initialization list. This implies that there must be a suitable initializer provided, as an aggregate initializer which might suffice for standalone variables cannot be used for member initialization. This implies to me that we probably therefore want two versions of each synchronization primitive. The first is a POD, which is therefore safe for static initialization. The second is non-POD, and has an appropriate default constructor, which is therefore safe for non-static objects. Any object which contains a synchronization primitive as a member must therefore choose which version to use, and therefore limit its own use as a consequence. Section 3.6.2 of the C++ standard allows implementers leeway to statically initialize objects with the result of dynamic initialization if such initialization yields a constant value, and doesn't affect any other object. On specific compilers and platforms where we can be sure that the implementors have taken advantage of this leeway, we can possibly relax some of these guidelines. Also, some compilers and platforms guarantee that dynamic initialization of objects with static storage duration is thread-safe. On such platforms, it is therefore safe for synchronization primitives to be non-POD objects with appropriate constructors, under all circumstances. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk

1 0

[ptr_container] Patch for iterator_test
by Markus Schöpflin 08 Sep '05

08 Sep '05

Attached is a patch which skips some tests for Tru64/CXX which does not yet conform to the resolution for DR#179. (See http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179 for details.) Ok to commit? Markus Index: iterator_test.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/ptr_container/test/iterator_test.cpp,v retrieving revision 1.8 diff -u -w -r1.8 iterator_test.cpp --- iterator_test.cpp 15 Jun 2005 19:32:58 -0000 1.8 +++ iterator_test.cpp 8 Sep 2005 08:41:56 -0000 @@ -47,10 +47,15 @@ ptr_map<int,int>::iterator map_mutable_i = map.begin(); ptr_map<int,int>::const_iterator map_const_i = map.begin(); +#if !BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(70190006)) + // This only works for library implementations which conform to the + // proposed resolution of the C++ Standard Library DR#179. See + // http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179. BOOST_CHECK( map_mutable_i == map_const_i ); BOOST_CHECK( ! ( map_mutable_i != map_const_i ) ); BOOST_CHECK( map_const_i == map_mutable_i ); BOOST_CHECK( ! ( map_const_i != map_mutable_i ) ); +#endif const ptr_map<int,int>& rmap = map; map_const_i = rmap.begin();

2 2

problem with modifying checked out files
by Arkadiy Vertleyb 08 Sep '05

08 Sep '05

Hi All, I am experiencing a strange problem with files checked out from the Boost CVS. The files are checked out as read-only, and even if I remove the read-only flag (attrib -R afile.hpp), I am not able to modify them -- access denied. Does this ring any bell or does it sound like some glitch related to my PC? Thanks, Arkadiy

4 8

[Boost-bugs] [ boost-Bugs-1284336 ] dijkstra_shortest_path doesn't scan the whole component
by SourceForge.net 07 Sep '05

07 Sep '05

Bugs item #1284336, was opened at 2005-09-07 22:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1284336&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Grégoire Dooms (dooms) Assigned to: Jeremy Siek (jsiek) Summary: dijkstra_shortest_path doesn't scan the whole component Initial Comment: Disjkstra Shortest path stops in the middle of the graph. I think this is because of a bug in relaxed_heap. This bug is present in boost 1.33 and boost cvs HEAD. It is however not present in debian boost-graph-dev version 1.32.0-6. I attach a source code which demonstrates the bug. It produces a dot file with the nodes labeled with distances from the source and the arcs labeled with their weight. The bug is present if some nodes have a 2147483647 label. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1284336&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[BGL] brandes_betweenness_centrality failed on medium-size graphs
by Yu Huang 07 Sep '05

07 Sep '05

Hi all, I coded a program recursively cutting graphs based on brandes_betweenness_centrality. But the weird thing is that it succeeds on small graphs(<=8 vertices, <=15 edges) and large graphs(~3500 vertices, ~138,000edges). But failed on medium-size (~37-200 vertices, ~42-350 edges). The failed output is like this: no_of_vertices: 203 no_of_edges: 368 connectivity: 0.0179486 running brandes_betweenness_centrality... *** glibc detected *** double free or corruption (out): 0x080942d8 *** Aborted Actually, I can't say the it succeeds on large graph. I stopped it after ~45 brandes_betweenness_centrality() calls(because it took too long, over-night). But on medium-size ones, the first brandes_betweenness_centrality() is always ok. But failed quickly, mostly 2nd loop, some 3rd, even 5th. Only 0x080942d8 changed from run to run. Others remain same(Am i stupid to say this? of course it won't change). Well, i paste my core function here. The main idea is I remove the edge with max centrality and form a vector of clusters(graphs) from the ancestor graph's components (if after cut, the ancestor has >=2 components, otherwise keep cutting on the ancestor graph). void ClusterByEBC::cut_by_betweenness_centrality(Graph &graph, const int &size_cutoff, const float &conn_cutoff) /* *09-04-05 * cut the graph with the edge of maximum betweenness_centrality */ { int no_of_vertices = num_vertices(graph); int no_of_edges = num_edges(graph); #ifdef DEBUG std::cerr<<"no_of_vertices: "<<no_of_vertices<<std::endl; std::cerr<<"no_of_edges: "<<no_of_edges<<std::endl; #endif if (no_of_vertices>=size_cutoff) { float connectivity = 2.0*no_of_edges/(no_of_vertices*(no_of_vertices-1)); #ifdef DEBUG std::cerr<<"connectivity: "<<connectivity<<std::endl; #endif if (connectivity>=conn_cutoff) { #ifdef DEBUG std::cerr<<"good subgraph "<<std::endl; #endif good_subgraph_vector.push_back(graph); } else { vector<double> edge_centrality(no_of_edges); EdgeCentralityMap ec_map(edge_centrality.begin(), get(edge_index, graph)); //"make_iterator_property_map(edge_centrality.begin(), get(edge_index, subgraph), double())" also works. indirect_cmp<EdgeCentralityMap, std::less<centrality_type> > cmp(ec_map); #ifdef DEBUG std::cerr<<"running brandes_betweenness_centrality... "; #endif brandes_betweenness_centrality(graph, edge_centrality_map(ec_map)); #ifdef DEBUG std::cerr<<"done."<<std::endl; #endif edgeDescriptor e = *max_element(edges(graph).first, edges(graph).second, cmp); centrality_type max_centrality = get(ec_map, e); #ifdef DEBUG std::cerr<<"max_centrality is "<<max_centrality<<std::endl; #endif remove_edge(e, graph); #ifdef DEBUG std::cerr<<"after removal the subgraph has "<<num_edges(graph)<<" edges."<<std::endl; #endif std::vector<int> component(num_vertices(graph)); int no_of_components = connected_components(graph, &component[0]); if (no_of_components==1) //keep cutting { #ifdef DEBUG std::cerr<<"only one component, keep cutting "<<std::endl; #endif cut_by_betweenness_centrality(graph, size_cutoff, conn_cutoff); } else //first get the connected_components into a vector_sub_subgraph and cut them separately { #ifdef DEBUG std::cerr<<"get the connected_components into a vector_graph and cut them separately "<<std::endl; #endif std::vector<Graph> vector_graph = graph_components(graph, component, no_of_components); std::vector<Graph>::iterator g_iterator; for(g_iterator=vector_graph.begin();g_iterator!=vector_graph.end();++g_iterator) { cut_by_betweenness_centrality(*g_iterator, size_cutoff, conn_cutoff); } } } } #ifdef DEBUG else std::cerr<<"Bad graph, too small,"<<no_of_vertices<<"vertices"<<std::endl; #endif } This looks like a hard issue. I searched the mailing list and found one similar message, http://lists.boost.org/MailArchives/ublas/2005/08/0657.php (no one replied). Thanks, Yu

2 3

[BGL] maximum cardinality matching
by Aaron Windsor 07 Sep '05

07 Sep '05

Hello all, I've implemented an algorithm for computing a maximum cardinality matching in an undirected graph for the BGL. A matching in an undirected graph is a set of edges such that no two meet in a common vertex. A maximum cardinality matching has the maximum number of edges over all matchings in the graph. I uploaded the source, some tests, and documentation to the boost sandbox file vault under the directory "maximum_cardinality_matching." Any feedback would be appreciated. I developed and tested under gcc 3.3.3 on cygwin and currently don't have access to any other C++ compilers, so I'd be particularly interested in feedback about whether the tests compile and run correctly under other compilers. Thanks, Aaron Windsor

2 3

Re: [boost] [binary-int] pre-release available
by Scott Schurr 07 Sep '05

07 Sep '05

Greetings, Thanks for all the comments and ideas: Dave Gomboc suggests: nybbles<0011,1010,1100,0100>::value David Abrahams and Jeff Flinn noted that 'nibbles' is the common spelling they have seen. And, personally, I've always seen a 4-bit entity written as nibble. So possible syntaxes for the template based solution, in the order they have been suggested, might be: binary_int<0011,1010,1100,0100>::value bits<0011,1010,1100,0100>::value nybbles<0011,1010,1100,0100>::value nibbles<0011,1010,1100,0100>::value On a different note, Matt Calabrese lofted a preprocessor-based library: BOOST_BINARY_LITERAL( 101 0111 1010 0110 ) This looks way cool. I personally like the way the '::value' is not required. So, how does the boost community decide which of the proposals (template-based or preprocessor-based) to pursue? Thanks for your consideration. Scott Schurr

3 2

Re: [boost] [threads] rework notes
by Russell Kliese 07 Sep '05

07 Sep '05

> > I am really surprised to see everyone agreeing that a header-only > > implementation is preferable. > I completely agree with that sentiment. I also agree. Header only libraries are convenient, but they don't scale well for the reasons that have already been brought up. Compile time is one issue. Also, as the library gets bigger, more and more code will be compiled into each binary that could have rather been precompiled and shared from a shared library. Most people will probably be linking against at least libstdc++ anyway, so it's no big deal to link against another library (although I only have experience with the GNU tools --- maybe the Microsoft tools are a different story). Good to see development on the threads library. In particular, the timed mutexes now seem to be passing some tests I have been doing. Cheers, Russell

1 0

[boost::python] optional<> for default arguments
by Yu Huang 07 Sep '05

07 Sep '05

Hi Dave, I coded a class with three constructors. One has two default arguments. So according to Boost::Python's doc, i used optional<>. Wrapping code is like this class_<ClusterByEBC, bases<cc_from_edge_list> >("ClusterByEBC") .def(init<std::string, int, int, float, optional<int, std::string> >()) .def(init<boost::python::list, int, float>()) .def("run", &ClusterByEBC::run) .def_readonly("cc_list", &ClusterByEBC::cc_list) .def_readonly("cc_vertex_list", &ClusterByEBC::cc_vertex_list) ; When compiling, I got such error. g++ -O2 -fPIC -I ~/script/hhu_clustering/include/arpack++/include/ -I /usr/include/python2.3 -c cc_from_edge_list.cc -o cc_from_edge_list.o cc_from_edge_list.cc: In function `void init_module_cc_from_edge_list()': cc_from_edge_list.cc:472: error: use of `optional' is ambiguous /usr/include/boost/python/init.hpp:62: error: first declared as ` template<class T0, class T1, class T2, class T3, class T4, class T5, class T6, class T7, class T8, class T9, class T10, class T11, class T12, class T13, class T14> struct boost::python::optional' here /usr/include/boost/optional/optional.hpp:371: error: also declared as ` template<class T> class boost::optional' here cc_from_edge_list.cc:472: error: parse error before `,' token cc_from_edge_list.cc:472: error: parse error before `>' token make: *** [cc_from_edge_list.o] Error 1 Here, i found there's another "optional" which was written by Fernando Cacciola. After I replaced "optional" with "boost::python::optional", everything turned fine. Thanks, Yu

1 0

[detail::atomic_count] Plea to use int32_t instead of long
by Joao Abecasis 07 Sep '05

07 Sep '05

Hi! I think the interface of atomic_count should be done in terms of boost::int32_t instead of long. Currently there are 3 independent implementations for atomic_count: * atomic_count_gcc: uses _Atomic_word (32-bit) * atomic_count_win32: uses BOOST_INTERLOCKED_*, currently defined for windows platforms, works on 32-bit types. * atomic_count_pthreads: uses long; however, because it uses a mutex for synchronization, it could use any type for the counter. The reason for bringing this up comes from experimenting atomic_count on a linux x86_64 box with gcc4 (FC4, in case it matters), where long is a 64-bit type, while the counter is 32-bit. I don't know if this also happens on other 64-bit platforms. Regards, João Abecasis

1 0

Boost.Test: trivial compilation fix
by Graham Bennett 06 Sep '05

06 Sep '05

Hi, Attached is a patch to fix a compilation error due to a missing standard library #include, which was exposed when using the RogueWave standard library implementation. It seems to apply correctly to the current CVS. cheers, Graham -- Graham Bennett

2 1

[Format] [Patch] trivial fix to basic_format initialization order
by Nathaniel Smith 06 Sep '05

06 Sep '05

basic_format's std::locale-taking constructors initialize the locale member variable out of order, causing distracting warnings on (at least) g++. Trivial patch against CVS head attached. -- Nathaniel -- "But in Middle-earth, the distinct accusative case disappeared from the speech of the Noldor (such things happen when you are busy fighting Orcs, Balrogs, and Dragons)."

1 0

[scope_guard] New version consideration
by Andrey Semashev 06 Sep '05

06 Sep '05

I've made some reworks and additions to my previously presented version of generalized scope guards. To be short, here are brief changes: - Scope guard creation has moved to make_* functions instead of explicitly creating a scope guard object. - Now not using the Boost.Function to hold functors. The functor type is detected in make_* creating functions. This gave a considerable perfomance gain especially in simple tests where guard creation/destruction takes large amount of the time comparing to the useful work. - Unified scope guard variable declaration, regardless of the type of the guard (destruction guard or construction/destruction guard). In fact only a reference to a base class is declared, so it may be bound to any type of guards returned by the make_* function. As a result users' code shall be simplier. - Several internal changes, including BOOST_NO_EXCEPTIONS awareness, Boost.Preprocessor usage instead of self-made analogues and others. - Basic transactions support. Actually, the construction/destruction guards are created by make_transaction function, so the construction functor has the semantic of action, and the destruction functor - of rollback or undo action. Disarming such guard has the semantic of committing actions. - Added a simple actions trace class (in a separate file). It can be used with scope guards to perform complex transactions. In other words, when executing a complex action that consists of several discardable subactions this trace class allows to massively commit or rollback these subactions. I've tested this version with VC 7.1, ICL 9.0 and GCC 3.4.4 (MinGW version). The sources with some instructions (in .h-files) and a small test, which may be used as an example, are in the Sandbox: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… A few word of what I'm not sure of: - The naming of classes/functions/macroses. They look quite simple to me, but maybe someone has better proposals? Especially it concerns macroses (may be some prefixes?). - It would be great if someone tried it on some other compilers - VC 6, for example. It should work, but I don't have the compiler to be sure. - Is there still interest in this implementation or the multi_index version is finally chosen to be Boost.ScopeGuard? PS: I'm really sorry for such a long delay. I was rather busy for last few weeks.

2 3

[serialization] Boost.Serialization 1.33.0 Breaks Serialization Code inDLLs
by martin.ecker＠tab.at 06 Sep '05

06 Sep '05

Hello, Boost.Serialization 1.33.0 breaks serialization of derived classes referenced via base class pointers when using DLLs on Windows and VC 7.1. It might also affect shared objects on Unix, but I'm not sure how the various Unix loaders handle multiple instances of the same template member function in multiple shared objects. In particular what happens is that objects that are serialized via a base class pointer are no longer deserialized correctly when deserialized in an application that uses the DLL (and not within the DLL itself). Instead they are deserialized as NULL pointers. The problem is that the virtual equal_to and not_equal_to member functions were removed from the extended_type_info base class. These functions were previously used by extended_type_info::operator == and extended_type_info::operator !=. Now operator == simply performs an equal check on the address of the extended_type_info object, whereas the previous version that used equal_to actually did a full compare of the stored type info keys. If DLLs are used and the DLLs themselves contain serialization code and BOOST_CLASS_EXPORT macros, this will fail because the extended_type_info objects are always static objects allocated on the stack of a member template function, e.g. in extended_type_info_typeid_1::get_instance. In a DLL situation this will cause multiple DLLs that include the header file with that template function to have multiple (i.e. separate) copies of that extended_type_info object. Thus, comparing them only via their addresses leads to disaster. The fix is easy. Simply put the old code for extended_type_info::operator == and extended_type_info::operator != back in. Note that I haven't looked any further if there were other changes made to the code that also rely on the addresses of equal extended_type_info objects to be the same. This will also break serialization code in DLLs. I can only say that after I put the old code back in, our system could deserialize its data properly again. Best Regards, Martin TAB Austria Haiderstraße 40 4052 Ansfelden Austria Phone: +43 7229 78040-218 Fax: +43 7229 78040-209 E-mail: martin.ecker(a)tab.at http://www.tab.at

6 23

naming for boost submission
by Dave Gomboc 06 Sep '05

06 Sep '05

> o Are the names 'binary_int' and 'binary_nibble' good names? > Pavel Vozenilek, who has very kindly been my Boost mentor, > suggests 'bits' and 'nibble' may be better names. "nibble" sounds like taking a small bite, and AFAIK, that's precisely why it's called that! But in computing, bite is spelled byte, and similarly, four binary bits make up a nybble (also using a 'y'). At least, AFAIK all my computing magazines from 20 years ago (back when nybbles were less unimportant :-) used this spelling; they were printed in the USA. q.v. http://www.jargon.net/jargonfile/n/nybble.html http://www.geocities.com/oosterwal/puzzle/nybbleq.html but http://en.wikipedia.org/wiki/Nybble forwards to nibble, so I imagine that nibble must be common in some circles. On to your main question: int refers to the acceptable range (short int <= int <= long int), so I think binary_int isn't quite what we're looking for. After trying out a few possibilities, I like the look of nybbles<0011,1010,1100,0100> best. Dave

4 3

Merging fixes from MAIN to RC?
by Markus Schöpflin 06 Sep '05

06 Sep '05

Hello, what is the current procedure when I want to merge a fix from the main branch to the RC branch? Is the procedure outlinet at http://www.boost.org/more/release_procedures.htm still valid? Markus

1 0

for_each combination/permutation - call for interest
by Howard Hinnant 06 Sep '05

06 Sep '05

On and off for the past 7 months (well, mostly off), I've been working on a few combination/permutation algorithms. I was inspired by the CUJ article written by John Dibling in the Feb. 2005 issue titled "Extending the STL". The std::lib currently has next_permutation, perv_permutation. But these functions are lacking in two respects: 1. They only allow the entire sequence to be permuted. They do not allow (for example) the ability to find all permutations of 5 items considered only 2 at a time. Consider 5 items 2 at a time from this sequence 1 : a b c d e Permutations 1 : a b 2 : a c 3 : a d 4 : a e 5 : b a 6 : b c 7 : b d 8 : b e 9 : c a 10 : c b 11 : c d 12 : c e 13 : d a 14 : d b 15 : d c 16 : d e 17 : e a 18 : e b 19 : e c 20 : e d When you know that you need to consider only a few items at a time, std::next_permutation is excessively expensive as it will loop through many more iterations. (e.g. consider the permutations of 5 items 5 at a time leads to a list of 120 - vs 20 sequences). 2. std::next/prev_permutation require a sorted sequence and an ordering predicate. This is not always convenient. In addition to permutations of N objects taken K at a time, other useful algorithms would be: * Circular permutations of N objects taken K at a time. * Combinations of N objects taken K at a time. * Reversible permutations of N objects taken K at a time. * Reversible circular permutations of N objects taken K at a time. Out of these 5 algorithms, today I can only present the first 3. The reversible versions are meant to take a sequence over all permutations where an order, and the reverse order are considered to be the same sequence. E.g. 1 2 3 4 is the same permutation as 4 3 2 1 for a "reversible" permutation. This is handy in situations where you are scoring "distances" between items in the list, and it doesn't matter which direction the list is traveled in. Unfortunately I haven't yet found a way to efficiently compute these "reversible" permutations. --- Interface --- I've followed the advice of John Dibling in the CUJ article except that the functor doesn't receive the entire range, but only the first K elements. For example consider: char array[] = {'a', 'b', 'c', 'd', 'e'}; unsigned size_array = sizeof(array)/sizeof(array[0]); const int k = 3; print p = std::for_each_combination(array, array + size_array, k, print()); This calls the print() functor (say p) like: p(array, array+k); for array permuted such that [array, array+k) will hold each combination of 3 items taken from the total of 5 items. And after the for_each_combination call, array will be in its original order. While always permuting the elements into positions [0, k) may at first seem limiting in how the for_each_* algorithms can be implemented, it offers interesting possibilities for the functors. If a functor knows the total length of the sequence (say N), and receives [array, array+k) as a subsequence representing the current combination/permutation, that functor can then call for_each_* on the remaining sequence [array+k, array+N). This allows for a very complex analysis where one considers all combinations (or permutations) of the first k elements, and then simultaneously considers permutations of the remaining elements for each of the outer combinations. One could use this capability to search for solutions to variations of the traveling salesman problem. Instead of minimizing the route of 1 salesman over N cities. You might want to minimize two salesmen's routes over the same set of cities, each city being visited by one and only one salesman. For example you might consider: For each circular-reversible permutation of 10 cities considered 5 at a time: Compute distance around the 5 city route and add to that: For each circular-reversible permutation of the remaining 5 cities considered 5 at a time: Compute distance around the 5 city route. Record minimum combined distance and routes. Naturally this technique can easily be generalized to M salesmen covering N cites, N/M cites covered by each salesman. Unfortunately I currently lack the circular-reversible permutation algorithm and have to instead use the twice-as-expensive circular permutation algorithm. The three algorithms I do have are here: #include <iterator> #include <algorithm> namespace test { namespace detail { template<class BidirectionalIterator, class Function, class Size> Function permute(BidirectionalIterator first, BidirectionalIterator mid, BidirectionalIterator active, BidirectionalIterator last, Size k, Function f, Size n) { if (k == 0) f(first, mid); else { using std::swap; BidirectionalIterator activep1 = active; ++activep1; BidirectionalIterator p = active; ++p; for (Size i = 0; i < n; ++i, ++p) { if (k == 1) f(first, mid); else f = permute<BidirectionalIterator,Function,Size>(first, mid, activep1, last, k-1, f , n-1); if (i != n-1) swap(*active, *p); } std::rotate(active, activep1, last); } return f; } template<class BidirectionalIterator, class Function, class Size> Function combine(BidirectionalIterator first, BidirectionalIterator mid, BidirectionalIterator active, BidirectionalIterator last, Size k, Function f, Size n) { if (k == 0) f(first, mid); else { Size e = n - k + 1; Size nn = n-1; BidirectionalIterator l2 = last; BidirectionalIterator ap1 = active; ++ap1; BidirectionalIterator apk = active; std::advance(apk, k); for (Size i = 0; i < e; ++i, --nn, --l2) { if (k == 1) f(first, mid); else f = combine<BidirectionalIterator,Function,Size>(first, mid, ap1, l2, k-1, f, nn); std::rotate(active, i < e-1 ? ap1 : apk, last); } } return f; } } // detail template<class BidirectionalIterator, class Function, class Size> Function for_each_permutation(BidirectionalIterator first, BidirectionalIterator last, Size k, Function f) { typedef typename std::iterator_traits<BidirectionalIterator>::difference_type difference_type; Size n = static_cast<Size>(std::distance(first,last)); if (k < 1 || n == 0) return f; if (k > n) k = n; BidirectionalIterator mid = first; std::advance(mid, k); return detail::permute<BidirectionalIterator,Function,Size>(first, mid, first, last, k, f, n); } template<class BidirectionalIterator, class Function, class Size> Function for_each_circular_permutation(BidirectionalIterator first, BidirectionalIterator last, Size k, Function f) { typedef typename std::iterator_traits<BidirectionalIterator>::difference_type difference_type; Size n = static_cast<Size>(std::distance(first,last)); if (k < 1 || n == 0) return f; if (k > n) k = n; BidirectionalIterator mid = first; std::advance(mid, k); BidirectionalIterator f2 = first; ++f2; for (Size i = 0, e = n - k + 1; i < e; ++i, --n, ++first, ++f2, ++mid) f = detail::permute<BidirectionalIterator,Function,Size>(first, mid, f2, last, k-1, f, n-1); return f; } template<class BidirectionalIterator, class Function, class Size> Function for_each_combination(BidirectionalIterator first, BidirectionalIterator last, Size k, Function f) { typedef typename std::iterator_traits<BidirectionalIterator>::difference_type difference_type; Size n = static_cast<Size>(std::distance(first,last)); if (k < 1) return f; if (k > n) k = n; BidirectionalIterator mid = first; std::advance(mid, k); return detail::combine<BidirectionalIterator,Function,Size>(first, mid, first, last, k, f, n); } } // test And here's a demo that exercises all 3 algorithms: // demo #include <iostream> #include <iterator> #include <algorithm> class print { public: print() : i_(0) {} unsigned get() const {return i_;} template <class It> void operator()(It first, It last) { typedef typename std::iterator_traits<It>::value_type value_type; std::ostream_iterator<value_type> out(std::cout, " "); std::cout << ++i_ << "\t: "; std::copy(first, last, out); std::cout << '\n'; } private: unsigned i_; }; int main() { char array[] = {'a', 'b', 'c', 'd', 'e'}; unsigned size_array = sizeof(array)/sizeof(array[0]); const int k = 3; std::cout << "Consider " << size_array << " items " << k << " at a time from this sequence\n"; print()(array, array + size_array); { std::cout << "Permutations\n"; print p = test::for_each_permutation(array, array + size_array, k, print()); std::cout << "--- Total of " << p.get() << " calls ---\n"; std::cout << "Sequence left in orginal order\n"; print()(array, array + size_array); std::cout << '\n'; } { std::cout << "Circular Permutations\n"; print p = test::for_each_circular_permutation(array, array + size_array, k, print()); std::cout << "--- Total of " << p.get() << " calls ---\n"; std::cout << "Sequence left in orginal order\n"; print()(array, array + size_array); std::cout << '\n'; } { std::cout << "Combinations\n"; print p = test::for_each_combination(array, array + size_array, k, print()); std::cout << "--- Total of " << p.get() << " calls ---\n"; std::cout << "Sequence left in orginal order\n"; print()(array, array + size_array); std::cout << '\n'; } } The output should be: Consider 5 items 3 at a time from this sequence 1 : a b c d e Permutations 1 : a b c 2 : a b d 3 : a b e 4 : a c b 5 : a c d 6 : a c e 7 : a d b 8 : a d c 9 : a d e 10 : a e b 11 : a e c 12 : a e d 13 : b a c 14 : b a d 15 : b a e 16 : b c a 17 : b c d 18 : b c e 19 : b d a 20 : b d c 21 : b d e 22 : b e a 23 : b e c 24 : b e d 25 : c a b 26 : c a d 27 : c a e 28 : c b a 29 : c b d 30 : c b e 31 : c d a 32 : c d b 33 : c d e 34 : c e a 35 : c e b 36 : c e d 37 : d a b 38 : d a c 39 : d a e 40 : d b a 41 : d b c 42 : d b e 43 : d c a 44 : d c b 45 : d c e 46 : d e a 47 : d e b 48 : d e c 49 : e a b 50 : e a c 51 : e a d 52 : e b a 53 : e b c 54 : e b d 55 : e c a 56 : e c b 57 : e c d 58 : e d a 59 : e d b 60 : e d c --- Total of 60 calls --- Sequence left in orginal order 1 : a b c d e Circular Permutations 1 : a b c 2 : a b d 3 : a b e 4 : a c b 5 : a c d 6 : a c e 7 : a d b 8 : a d c 9 : a d e 10 : a e b 11 : a e c 12 : a e d 13 : b c d 14 : b c e 15 : b d c 16 : b d e 17 : b e c 18 : b e d 19 : c d e 20 : c e d --- Total of 20 calls --- Sequence left in orginal order 1 : a b c d e Combinations 1 : a b c 2 : a b d 3 : a b e 4 : a c d 5 : a c e 6 : a d e 7 : b c d 8 : b c e 9 : b d e 10 : c d e --- Total of 10 calls --- Sequence left in orginal order 1 : a b c d e Note that the functor (print() in this case) can be stateful, and that state is accumulated from call to call, and returned back to the client. In this case the state is a simple line number counter. Anyway, I offer these up on the chance they might be useful, and on the chance that someone might help complete the library to compute "reversible" permutations, which may indeed be quite useful (as in the traveling salesman problem, and variations of it). -Howard

2 1

Regression tests: patch for compiler_status
by Graham Bennett 05 Sep '05

05 Sep '05

Hi, We have had problems with the compiler_status program which we've attempted to fix with the attached patch. Currently compiler_status tries to compute a path relative to the Boost root directory by simply erasing the same amount of characters as the root dir from the path string. In our environment this does not work since the Boost root directory given to compiler_status contains some symlinks, and is different to the canonical location given by the initial_path() function. The fix is to build up the relative path by removing components from the initial path until it becomes equivalent to the Boost root. There may well be a better way to do this using Boost.Filesystem, but it does seem less fragile than the string erase. The patch also adds a little more error handling. Thanks, Graham. -- Graham Bennett

1 0

[boost thread rework] New version uploaded to Boost Vault
by Ion Gaztañaga 05 Sep '05

05 Sep '05

Hi to all, I've just finished implementing the lockable objects of Kevlin's proposal based on Boost mutexes and conditions. Since boost mutex operations are private and only available with locks, I haven't found a way to implement Kevlin's interface over boost threads without using some very nasty tricks. If someone has a better idea, let me know. The implementation nearly fills all the proposal of the documentation, so I will wait for new elements so that I can continue with this project. This elements are present in the current version: -> threader and joiner classes -> lockable, try_lockable, condition_lockable -> locker, try_locker -> locking_ptr There are open issues in the paper like timeout handling and new possible lockers, (for example, for conditional_lockable objects). As soon as I get more information I will continue developing it. Regards, Ion

15 57

error in remove_edge() of subgraph
by Yu Huang 05 Sep '05

05 Sep '05

Hi all, I tried a clustering recursively cut the graph based on betweenness_centrality and form the connected components into subgraphs of the original big graph. It's convenient to use subgraph("graph.create_subgraph()"), but the trick is that whenever "remove_edge(e, subgraph)", the subgraph and its ancestor graph is not affected(not like what the doc says). Code sketch is like this: vector<double> edge_centrality(no_of_edges); EdgeCentralityMap ec_map(edge_centrality.begin(), get(edge_index, subgraph)); indirect_cmp<EdgeCentralityMap, std::less<centrality_type> > cmp(ec_map); brandes_betweenness_centrality(subgraph, edge_centrality_map(ec_map)); edgeDescriptor e = *max_element(edges(subgraph).first, edges(subgraph).second, cmp); centrality_type max_centrality = get(ec_map, e); std::cerr<<"max_centrality is "<<max_centrality<<std::endl; remove_edge(e, subgraph); std::cerr<<"after removal the subgraph has "<<num_edges(subgraph)<<" edges."<<std::endl; The last error-reporting sentence lets me find that the edge e is not removed from subgraph at all. Even I tried to remove e from graph("remove_edge(subgraph.local_to_global(e), graph)"), it also fails. I hope somebody could have a check on it. So i gave up the subgraph and directly create graphs(real graph) from the components of the ancestor graph. It worked out. Thanks, Yu

1 0

Repository access and cvs watch
by Thomas Witt 05 Sep '05

05 Sep '05

Hi, AFAICT there is currently no way to make cvs provide writable files when checking out/updating the boost repository. This causes me some grief and I might not be the only one out there. After reading the CVS manual (well the watch part) I have concluded that this is due to the fact that somebody issued a recursive 'cvs watch on' on the boost tree. AFAICS this has not been discussed on the mailing list. This forces a certain usage of cvs on everybody else. I.e. the users have to use 'cvs edit' (or fiddle with file permissions). For now I am strongly opposed to this way of using cvs. In my experience the use of 'cvs edit' does not provide significant benefit while it adds significant overhead to my work. Most users will change the permissions locally and not bother with cvs edit anyway. If there is anybody out there who has different experiences I would be very interested to hear about them. I therefore propose to turn cvs watch off thus giving the user a choice whether she wants read-only or read-write files. Please note that this does not disable the watching of files in general. Every user still can use cvs watch add to watch files and is still guaranteed to get notified about the really interesting events (i.e. those that alter a file in the repository). What did I miss? What do you think? Thomas

16 30

Boost regression notification (2005-09-05 [RC_1_33_0])
by Douglas Gregor 05 Sep '05

05 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-05T16:05:06Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 553 failures in 12 libraries: algorithm/string (2) config (1) foreach (1) iostreams (2) math (3) mpl (1) multi_index (15) program_options (14) regex (64) serialization (433) thread (8) wave (9) |algorithm/string| regex: gcc-3_3-darwin vc-7_1 |config| config_test: intel-9.0-linux |foreach| rvalue_const: vc-7_1 |iostreams| regex_filter_test: gcc-3_3-darwin vc-7_1 |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin |multi_index| test_modifiers: intel-9.0-linux test_serialization: cw-9_4 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-4.0.1-linux gcc-4_0-darwin intel-8.1-linux intel-9.0-linux intel-win32-8_1 intel-win32-9_0 mingw-3_4_2 vc-7_1 |program_options| cmdline_test: vc-7_1 cmdline_test_dll: vc-7_1 options_description_test: vc-7_1 options_description_test_dll: vc-7_1 parsers_test: vc-7_1 parsers_test_dll: vc-7_1 positional_options_test: vc-7_1 positional_options_test_dll: vc-7_1 unicode_test: vc-7_1 unicode_test_dll: vc-7_1 variable_map_test: vc-7_1 variable_map_test_dll: vc-7_1 winmain: vc-7_1 winmain_dll: vc-7_1 |regex| bad_expression_test: gcc-3_3-darwin vc-7_1 captures_example: gcc-3_3-darwin captures_test: gcc-3_3-darwin collate_info: gcc-3_3-darwin vc-7_1 concept_check: gcc-3_3-darwin credit_card_example: gcc-3_3-darwin vc-7_1 grep: gcc-3_3-darwin vc-7_1 icu_example: gcc-3_3-darwin vc-7_1 mfc_example: gcc-3_3-darwin vc-7_1 object_cache_test: gcc-3_3-darwin vc-7_1 partial_regex_grep: gcc-3_3-darwin vc-7_1 partial_regex_match: gcc-3_3-darwin vc-7_1 posix_api_check: gcc-3_3-darwin posix_api_check_cpp: gcc-3_3-darwin vc-7_1 recursion_test: gcc-3_3-darwin vc-7_1 regex_config_info: gcc-3_3-darwin vc-7_1 regex_dll_config_info: gcc-3_3-darwin vc-7_1 regex_grep_example_1: gcc-3_3-darwin vc-7_1 regex_grep_example_2: gcc-3_3-darwin vc-7_1 regex_grep_example_3: gcc-3_3-darwin vc-7_1 regex_grep_example_4: gcc-3_3-darwin regex_iterator_example: gcc-3_3-darwin vc-7_1 regex_match_example: gcc-3_3-darwin vc-7_1 regex_merge_example: gcc-3_3-darwin vc-7_1 regex_regress: gcc-3_3-darwin vc-7_1 regex_regress_dll: gcc-3_3-darwin vc-7_1 regex_replace_example: gcc-3_3-darwin vc-7_1 regex_search_example: gcc-3_3-darwin vc-7_1 regex_split_example_1: gcc-3_3-darwin vc-7_1 regex_split_example_2: gcc-3_3-darwin vc-7_1 regex_timer: gcc-3_3-darwin regex_token_iterator_eg_1: gcc-3_3-darwin vc-7_1 regex_token_iterator_eg_2: gcc-3_3-darwin vc-7_1 static_mutex_test: gcc-3_3-darwin vc-7_1 wide_posix_api_check_cpp: gcc-3_3-darwin vc-7_1 |serialization| test_array_binary_archive: vc-7_1 test_array_binary_archive_dll: vc-7_1 test_array_text_archive: vc-7_1 test_array_text_archive_dll: vc-7_1 test_array_text_warchive: vc-7_1 test_array_text_warchive_dll: vc-7_1 test_array_xml_archive: vc-7_1 test_array_xml_archive_dll: vc-7_1 test_array_xml_warchive: vc-7_1 test_array_xml_warchive_dll: vc-7_1 test_binary_binary_archive: vc-7_1 test_binary_binary_archive_dll: vc-7_1 test_binary_text_archive: vc-7_1 test_binary_text_archive_dll: vc-7_1 test_binary_text_warchive: vc-7_1 test_binary_text_warchive_dll: vc-7_1 test_binary_xml_archive: vc-7_1 test_binary_xml_archive_dll: vc-7_1 test_binary_xml_warchive: vc-7_1 test_binary_xml_warchive_dll: vc-7_1 test_class_info_load_binary_archive: vc-7_1 test_class_info_load_binary_archive_dll: vc-7_1 test_class_info_load_text_archive: vc-7_1 test_class_info_load_text_archive_dll: vc-7_1 test_class_info_load_text_warchive: vc-7_1 test_class_info_load_text_warchive_dll: vc-7_1 test_class_info_load_xml_archive: vc-7_1 test_class_info_load_xml_archive_dll: vc-7_1 test_class_info_load_xml_warchive: vc-7_1 test_class_info_load_xml_warchive_dll: vc-7_1 test_class_info_save_binary_archive: vc-7_1 test_class_info_save_binary_archive_dll: vc-7_1 test_class_info_save_text_archive: vc-7_1 test_class_info_save_text_archive_dll: vc-7_1 test_class_info_save_text_warchive: vc-7_1 test_class_info_save_text_warchive_dll: vc-7_1 test_class_info_save_xml_archive: vc-7_1 test_class_info_save_xml_archive_dll: vc-7_1 test_class_info_save_xml_warchive: vc-7_1 test_class_info_save_xml_warchive_dll: vc-7_1 test_contained_class_binary_archive: vc-7_1 test_contained_class_binary_archive_dll: vc-7_1 test_contained_class_text_archive: vc-7_1 test_contained_class_text_archive_dll: vc-7_1 test_contained_class_text_warchive: vc-7_1 test_contained_class_text_warchive_dll: vc-7_1 test_contained_class_xml_archive: vc-7_1 test_contained_class_xml_archive_dll: vc-7_1 test_contained_class_xml_warchive: vc-7_1 test_contained_class_xml_warchive_dll: vc-7_1 test_cyclic_ptrs_binary_archive: vc-7_1 test_cyclic_ptrs_binary_archive_dll: vc-7_1 test_cyclic_ptrs_text_archive: vc-7_1 test_cyclic_ptrs_text_archive_dll: vc-7_1 test_cyclic_ptrs_text_warchive: vc-7_1 test_cyclic_ptrs_text_warchive_dll: vc-7_1 test_cyclic_ptrs_xml_archive: vc-7_1 test_cyclic_ptrs_xml_archive_dll: vc-7_1 test_cyclic_ptrs_xml_warchive: vc-7_1 test_cyclic_ptrs_xml_warchive_dll: vc-7_1 test_delete_pointer_binary_archive: vc-7_1 test_delete_pointer_binary_archive_dll: vc-7_1 test_delete_pointer_text_archive: vc-7_1 test_delete_pointer_text_archive_dll: vc-7_1 test_delete_pointer_text_warchive: vc-7_1 test_delete_pointer_text_warchive_dll: vc-7_1 test_delete_pointer_xml_archive: vc-7_1 test_delete_pointer_xml_archive_dll: vc-7_1 test_delete_pointer_xml_warchive: vc-7_1 test_delete_pointer_xml_warchive_dll: vc-7_1 test_demo: intel-win32-8_1 vc-7_1 test_demo_auto_ptr: vc-7_1 test_demo_auto_ptr_dll: vc-7_1 test_demo_dll: vc-7_1 test_demo_exception: intel-win32-8_1 vc-7_1 test_demo_exception_dll: vc-7_1 test_demo_pimpl: vc-7_1 test_demo_pimpl_dll: vc-7_1 test_demo_polymorphic: vc-7_1 test_demo_polymorphic_dll: vc-7_1 test_demo_portable_archive: vc-7_1 test_demo_shared_ptr: intel-win32-8_1 vc-7_1 test_demo_shared_ptr_dll: vc-7_1 test_demo_xml: vc-7_1 test_demo_xml_dll: vc-7_1 test_demo_xml_load: intel-win32-8_1 vc-7_1 test_demo_xml_load_dll: vc-7_1 test_demo_xml_save: intel-win32-8_1 vc-7_1 test_demo_xml_save_dll: vc-7_1 test_deque_binary_archive: vc-7_1 test_deque_binary_archive_dll: vc-7_1 test_deque_text_archive: vc-7_1 test_deque_text_archive_dll: vc-7_1 test_deque_text_warchive: vc-7_1 test_deque_text_warchive_dll: vc-7_1 test_deque_xml_archive: vc-7_1 test_deque_xml_archive_dll: vc-7_1 test_deque_xml_warchive: vc-7_1 test_deque_xml_warchive_dll: vc-7_1 test_derived_binary_archive: vc-7_1 test_derived_binary_archive_dll: vc-7_1 test_derived_class_binary_archive: vc-7_1 test_derived_class_binary_archive_dll: vc-7_1 test_derived_class_ptr_binary_archive: vc-7_1 test_derived_class_ptr_binary_archive_dll: vc-7_1 test_derived_class_ptr_text_archive: vc-7_1 test_derived_class_ptr_text_archive_dll: vc-7_1 test_derived_class_ptr_text_warchive: vc-7_1 test_derived_class_ptr_text_warchive_dll: vc-7_1 test_derived_class_ptr_xml_archive: vc-7_1 test_derived_class_ptr_xml_archive_dll: vc-7_1 test_derived_class_ptr_xml_warchive: vc-7_1 test_derived_class_ptr_xml_warchive_dll: vc-7_1 test_derived_class_text_archive: vc-7_1 test_derived_class_text_archive_dll: vc-7_1 test_derived_class_text_warchive: vc-7_1 test_derived_class_text_warchive_dll: vc-7_1 test_derived_class_xml_archive: vc-7_1 test_derived_class_xml_archive_dll: vc-7_1 test_derived_class_xml_warchive: vc-7_1 test_derived_class_xml_warchive_dll: vc-7_1 test_derived_text_archive: vc-7_1 test_derived_text_archive_dll: vc-7_1 test_derived_text_warchive: vc-7_1 test_derived_text_warchive_dll: vc-7_1 test_derived_xml_archive: vc-7_1 test_derived_xml_archive_dll: vc-7_1 test_derived_xml_warchive: vc-7_1 test_derived_xml_warchive_dll: vc-7_1 test_diamond_binary_archive: vc-7_1 test_diamond_binary_archive_dll: vc-7_1 test_diamond_text_archive: vc-7_1 test_diamond_text_archive_dll: vc-7_1 test_diamond_text_warchive: vc-7_1 test_diamond_text_warchive_dll: vc-7_1 test_diamond_xml_archive: vc-7_1 test_diamond_xml_archive_dll: vc-7_1 test_diamond_xml_warchive: vc-7_1 test_diamond_xml_warchive_dll: vc-7_1 test_exported_binary_archive: vc-7_1 test_exported_binary_archive_dll: vc-7_1 test_exported_text_archive: vc-7_1 test_exported_text_archive_dll: vc-7_1 test_exported_text_warchive: vc-7_1 test_exported_text_warchive_dll: vc-7_1 test_exported_xml_archive: vc-7_1 test_exported_xml_archive_dll: vc-7_1 test_exported_xml_warchive: vc-7_1 test_exported_xml_warchive_dll: vc-7_1 test_list_binary_archive: vc-7_1 test_list_binary_archive_dll: vc-7_1 test_list_ptrs_binary_archive: vc-7_1 test_list_ptrs_binary_archive_dll: vc-7_1 test_list_ptrs_text_archive: vc-7_1 test_list_ptrs_text_archive_dll: vc-7_1 test_list_ptrs_text_warchive: vc-7_1 test_list_ptrs_text_warchive_dll: vc-7_1 test_list_ptrs_xml_archive: vc-7_1 test_list_ptrs_xml_archive_dll: vc-7_1 test_list_ptrs_xml_warchive: vc-7_1 test_list_ptrs_xml_warchive_dll: vc-7_1 test_list_text_archive: vc-7_1 test_list_text_archive_dll: vc-7_1 test_list_text_warchive: vc-7_1 test_list_text_warchive_dll: vc-7_1 test_list_xml_archive: vc-7_1 test_list_xml_archive_dll: vc-7_1 test_list_xml_warchive: vc-7_1 test_list_xml_warchive_dll: vc-7_1 test_map_binary_archive: vc-7_1 test_map_binary_archive_dll: vc-7_1 test_map_text_archive: vc-7_1 test_map_text_archive_dll: vc-7_1 test_map_text_warchive: vc-7_1 test_map_text_warchive_dll: vc-7_1 test_map_xml_archive: vc-7_1 test_map_xml_archive_dll: vc-7_1 test_map_xml_warchive: vc-7_1 test_map_xml_warchive_dll: vc-7_1 test_mi_binary_archive: vc-7_1 test_mi_binary_archive_dll: vc-7_1 test_mi_text_archive: vc-7_1 test_mi_text_archive_dll: vc-7_1 test_mi_text_warchive: vc-7_1 test_mi_text_warchive_dll: vc-7_1 test_mi_xml_archive: vc-7_1 test_mi_xml_archive_dll: vc-7_1 test_mi_xml_warchive: vc-7_1 test_mi_xml_warchive_dll: vc-7_1 test_mult_archive_types: vc-7_1 test_mult_archive_types_dll: vc-7_1 test_multiple_ptrs_binary_archive: vc-7_1 test_multiple_ptrs_binary_archive_dll: vc-7_1 test_multiple_ptrs_text_archive: vc-7_1 test_multiple_ptrs_text_archive_dll: vc-7_1 test_multiple_ptrs_text_warchive: vc-7_1 test_multiple_ptrs_text_warchive_dll: vc-7_1 test_multiple_ptrs_xml_archive: vc-7_1 test_multiple_ptrs_xml_archive_dll: vc-7_1 test_multiple_ptrs_xml_warchive: vc-7_1 test_multiple_ptrs_xml_warchive_dll: vc-7_1 test_no_rtti_binary_archive: vc-7_1 test_no_rtti_binary_archive_dll: vc-7_1 test_no_rtti_text_archive: vc-7_1 test_no_rtti_text_archive_dll: vc-7_1 test_no_rtti_text_warchive: vc-7_1 test_no_rtti_text_warchive_dll: vc-7_1 test_no_rtti_xml_archive: vc-7_1 test_no_rtti_xml_archive_dll: vc-7_1 test_no_rtti_xml_warchive: vc-7_1 test_no_rtti_xml_warchive_dll: vc-7_1 test_non_default_ctor2_binary_archive: vc-7_1 test_non_default_ctor2_binary_archive_dll: vc-7_1 test_non_default_ctor2_text_archive: vc-7_1 test_non_default_ctor2_text_archive_dll: vc-7_1 test_non_default_ctor2_text_warchive: vc-7_1 test_non_default_ctor2_text_warchive_dll: vc-7_1 test_non_default_ctor2_xml_archive: vc-7_1 test_non_default_ctor2_xml_archive_dll: vc-7_1 test_non_default_ctor2_xml_warchive: vc-7_1 test_non_default_ctor2_xml_warchive_dll: vc-7_1 test_non_default_ctor_binary_archive: vc-7_1 test_non_default_ctor_binary_archive_dll: vc-7_1 test_non_default_ctor_text_archive: vc-7_1 test_non_default_ctor_text_archive_dll: vc-7_1 test_non_default_ctor_text_warchive: vc-7_1 test_non_default_ctor_text_warchive_dll: vc-7_1 test_non_default_ctor_xml_archive: vc-7_1 test_non_default_ctor_xml_archive_dll: vc-7_1 test_non_default_ctor_xml_warchive: vc-7_1 test_non_default_ctor_xml_warchive_dll: vc-7_1 test_non_intrusive_binary_archive: vc-7_1 test_non_intrusive_binary_archive_dll: vc-7_1 test_non_intrusive_text_archive: vc-7_1 test_non_intrusive_text_archive_dll: vc-7_1 test_non_intrusive_text_warchive: vc-7_1 test_non_intrusive_text_warchive_dll: vc-7_1 test_non_intrusive_xml_archive: vc-7_1 test_non_intrusive_xml_archive_dll: vc-7_1 test_non_intrusive_xml_warchive: vc-7_1 test_non_intrusive_xml_warchive_dll: vc-7_1 test_null_ptr_binary_archive: vc-7_1 test_null_ptr_binary_archive_dll: vc-7_1 test_null_ptr_text_archive: vc-7_1 test_null_ptr_text_archive_dll: vc-7_1 test_null_ptr_text_warchive: vc-7_1 test_null_ptr_text_warchive_dll: vc-7_1 test_null_ptr_xml_archive: vc-7_1 test_null_ptr_xml_archive_dll: vc-7_1 test_null_ptr_xml_warchive: vc-7_1 test_null_ptr_xml_warchive_dll: vc-7_1 test_nvp_binary_archive: vc-7_1 test_nvp_binary_archive_dll: vc-7_1 test_nvp_text_archive: vc-7_1 test_nvp_text_archive_dll: vc-7_1 test_nvp_text_warchive: vc-7_1 test_nvp_text_warchive_dll: vc-7_1 test_nvp_xml_archive: vc-7_1 test_nvp_xml_archive_dll: vc-7_1 test_nvp_xml_warchive: vc-7_1 test_nvp_xml_warchive_dll: vc-7_1 test_object_binary_archive: vc-7_1 test_object_binary_archive_dll: vc-7_1 test_object_text_archive: vc-7_1 test_object_text_archive_dll: vc-7_1 test_object_text_warchive: vc-7_1 test_object_text_warchive_dll: vc-7_1 test_object_xml_archive: vc-7_1 test_object_xml_archive_dll: vc-7_1 test_object_xml_warchive: vc-7_1 test_object_xml_warchive_dll: vc-7_1 test_optional_binary_archive: vc-7_1 test_optional_binary_archive_dll: vc-7_1 test_optional_text_archive: vc-7_1 test_optional_text_archive_dll: vc-7_1 test_optional_text_warchive: vc-7_1 test_optional_text_warchive_dll: vc-7_1 test_optional_xml_archive: vc-7_1 test_optional_xml_archive_dll: vc-7_1 test_optional_xml_warchive: vc-7_1 test_optional_xml_warchive_dll: vc-7_1 test_polymorphic_binary_archive: vc-7_1 test_polymorphic_binary_archive_dll: vc-7_1 test_polymorphic_text_archive: vc-7_1 test_polymorphic_text_archive_dll: vc-7_1 test_polymorphic_text_warchive: vc-7_1 test_polymorphic_text_warchive_dll: vc-7_1 test_polymorphic_xml_archive: vc-7_1 test_polymorphic_xml_archive_dll: vc-7_1 test_polymorphic_xml_warchive: vc-7_1 test_polymorphic_xml_warchive_dll: vc-7_1 test_primitive_binary_archive: vc-7_1 test_primitive_binary_archive_dll: vc-7_1 test_primitive_text_archive: vc-7_1 test_primitive_text_archive_dll: vc-7_1 test_primitive_text_warchive: vc-7_1 test_primitive_text_warchive_dll: vc-7_1 test_primitive_xml_archive: vc-7_1 test_primitive_xml_archive_dll: vc-7_1 test_primitive_xml_warchive: vc-7_1 test_primitive_xml_warchive_dll: vc-7_1 test_private_ctor: vc-7_1 test_private_ctor_dll: vc-7_1 test_recursion_binary_archive: vc-7_1 test_recursion_binary_archive_dll: vc-7_1 test_recursion_text_archive: vc-7_1 test_recursion_text_archive_dll: vc-7_1 test_recursion_text_warchive: vc-7_1 test_recursion_text_warchive_dll: vc-7_1 test_recursion_xml_archive: vc-7_1 test_recursion_xml_archive_dll: vc-7_1 test_recursion_xml_warchive: vc-7_1 test_recursion_xml_warchive_dll: vc-7_1 test_registered_binary_archive: vc-7_1 test_registered_binary_archive_dll: vc-7_1 test_registered_text_archive: vc-7_1 test_registered_text_archive_dll: vc-7_1 test_registered_text_warchive: vc-7_1 test_registered_text_warchive_dll: vc-7_1 test_registered_xml_archive: vc-7_1 test_registered_xml_archive_dll: vc-7_1 test_registered_xml_warchive: vc-7_1 test_registered_xml_warchive_dll: vc-7_1 test_reset_object_address: vc-7_1 test_reset_object_address_dll: vc-7_1 test_set_binary_archive: vc-7_1 test_set_binary_archive_dll: vc-7_1 test_set_text_archive: vc-7_1 test_set_text_archive_dll: vc-7_1 test_set_text_warchive: vc-7_1 test_set_text_warchive_dll: vc-7_1 test_set_xml_archive: vc-7_1 test_set_xml_archive_dll: vc-7_1 test_set_xml_warchive: vc-7_1 test_set_xml_warchive_dll: vc-7_1 test_shared_ptr_132_binary_archive: vc-7_1 test_shared_ptr_132_binary_archive_dll: vc-7_1 test_shared_ptr_132_text_archive: vc-7_1 test_shared_ptr_132_text_archive_dll: vc-7_1 test_shared_ptr_132_text_warchive: vc-7_1 test_shared_ptr_132_text_warchive_dll: vc-7_1 test_shared_ptr_132_xml_archive: vc-7_1 test_shared_ptr_132_xml_archive_dll: vc-7_1 test_shared_ptr_132_xml_warchive: vc-7_1 test_shared_ptr_132_xml_warchive_dll: vc-7_1 test_shared_ptr_binary_archive: vc-7_1 test_shared_ptr_binary_archive_dll: vc-7_1 test_shared_ptr_text_archive: vc-7_1 test_shared_ptr_text_archive_dll: vc-7_1 test_shared_ptr_text_warchive: vc-7_1 test_shared_ptr_text_warchive_dll: vc-7_1 test_shared_ptr_xml_archive: vc-7_1 test_shared_ptr_xml_archive_dll: vc-7_1 test_shared_ptr_xml_warchive: vc-7_1 test_shared_ptr_xml_warchive_dll: intel-win32-8_1 vc-7_1 test_simple_class_binary_archive: vc-7_1 test_simple_class_binary_archive_dll: vc-7_1 test_simple_class_ptr_binary_archive: vc-7_1 test_simple_class_ptr_binary_archive_dll: vc-7_1 test_simple_class_ptr_text_archive: vc-7_1 test_simple_class_ptr_text_archive_dll: vc-7_1 test_simple_class_ptr_text_warchive: vc-7_1 test_simple_class_ptr_text_warchive_dll: vc-7_1 test_simple_class_ptr_xml_archive: vc-7_1 test_simple_class_ptr_xml_archive_dll: vc-7_1 test_simple_class_ptr_xml_warchive: vc-7_1 test_simple_class_ptr_xml_warchive_dll: vc-7_1 test_simple_class_text_archive: vc-7_1 test_simple_class_text_archive_dll: vc-7_1 test_simple_class_text_warchive: vc-7_1 test_simple_class_text_warchive_dll: vc-7_1 test_simple_class_xml_archive: vc-7_1 test_simple_class_xml_archive_dll: vc-7_1 test_simple_class_xml_warchive: vc-7_1 test_simple_class_xml_warchive_dll: vc-7_1 test_split_binary_archive: vc-7_1 test_split_binary_archive_dll: vc-7_1 test_split_text_archive: vc-7_1 test_split_text_archive_dll: vc-7_1 test_split_text_warchive: vc-7_1 test_split_text_warchive_dll: vc-7_1 test_split_xml_archive: vc-7_1 test_split_xml_archive_dll: vc-7_1 test_split_xml_warchive: vc-7_1 test_split_xml_warchive_dll: vc-7_1 test_tracking_binary_archive: vc-7_1 test_tracking_binary_archive_dll: vc-7_1 test_tracking_text_archive: vc-7_1 test_tracking_text_archive_dll: vc-7_1 test_tracking_text_warchive: vc-7_1 test_tracking_text_warchive_dll: vc-7_1 test_tracking_xml_archive: vc-7_1 test_tracking_xml_archive_dll: vc-7_1 test_tracking_xml_warchive: vc-7_1 test_tracking_xml_warchive_dll: vc-7_1 test_unregistered_binary_archive: vc-7_1 test_unregistered_binary_archive_dll: vc-7_1 test_unregistered_text_archive: vc-7_1 test_unregistered_text_archive_dll: vc-7_1 test_unregistered_text_warchive: vc-7_1 test_unregistered_text_warchive_dll: vc-7_1 test_unregistered_xml_archive: vc-7_1 test_unregistered_xml_archive_dll: vc-7_1 test_unregistered_xml_warchive: vc-7_1 test_unregistered_xml_warchive_dll: vc-7_1 test_variant_binary_archive: vc-7_1 test_variant_binary_archive_dll: vc-7_1 test_variant_text_archive: vc-7_1 test_variant_text_archive_dll: vc-7_1 test_variant_text_warchive: vc-7_1 test_variant_text_warchive_dll: vc-7_1 test_variant_xml_archive: vc-7_1 test_variant_xml_archive_dll: vc-7_1 test_variant_xml_warchive: vc-7_1 test_variant_xml_warchive_dll: vc-7_1 test_vector_binary_archive: vc-7_1 test_vector_binary_archive_dll: vc-7_1 test_vector_text_archive: vc-7_1 test_vector_text_archive_dll: vc-7_1 test_vector_text_warchive: vc-7_1 test_vector_text_warchive_dll: vc-7_1 test_vector_xml_archive: vc-7_1 test_vector_xml_archive_dll: vc-7_1 test_vector_xml_warchive: vc-7_1 test_vector_xml_warchive_dll: vc-7_1 test_void_cast: vc-7_1 test_void_cast_dll: vc-7_1 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |wave| test_re2c_lexer: cw-9_4 intel-9.0-linux vc-7_1 test_slex_lexer: cw-9_4 intel-9.0-linux vc-7_1 testwave: cw-9_4 intel-9.0-linux vc-7_1

1 0

Boost regression notification (2005-09-05 [HEAD])
by Douglas Gregor 05 Sep '05

05 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-05T05:00:07Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. typeof Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 89 failures in 11 libraries: foreach (7) graph (4) math (6) mpl (2) multi_index (5) parameter (4) serialization (43) spirit (2) thread (8) typeof (4) wave (4) |foreach| user_defined: cw-8_3 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-6_5-stlport vc-7_0 |graph| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |math| octonion_test: gcc-4_0-darwin gcc-4_0-darwin quaternion_test: gcc-4_0-darwin gcc-4_0-darwin special_functions_test: gcc-4_0-darwin gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin gcc-4_0-darwin |multi_index| test_capacity: gcc-4_0-darwin test_list_ops: gcc-4_0-darwin test_modifiers: gcc-4_0-darwin test_safe_mode: gcc-4_0-darwin test_update: gcc-4_0-darwin |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc test_reset_object_address: vc-7_1 test_reset_object_address_dll: vc-7_1 test_static_warning: vc-7_1 |spirit| traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |typeof| type_emulation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux type_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: gcc-3.3.6-linux intel-9.0-linux

1 0

asio::demuxer at global scope dead-locks?
by Roland Schwarz 05 Sep '05

05 Sep '05

I tried modified the timer1.cpp a little: #include <iostream> #include <asio.hpp> asio::demuxer d; int main() { asio::deadline_timer t(d, boost::posix_time::seconds(5)); t.wait(); std::cout << "Hello, world!\n"; return 0; } by moving the demuxer object to global scope. I have to be honest, I am not through with the documentation yet, but also I did not find a bold mark which prohibits such use. At least the program seems to never end, it seems to hang somewhere in the library clean up code? I can see it waiting for a thread to stop: // Wait for the thread to exit. void join() { ::WaitForSingleObject(thread_, INFINITE); } But this never happens. Is it true indeed, that demuxer s must not be at global scope? Regards, Roland

2 8

[Wiki] approval for editing
by Matt Hurd 05 Sep '05

05 Sep '05

Was going to play with the wiki to see if it would suit my needs for some thread stuff. I get this when clicking on "Edit page". ______________ Editing Denied BOOST WIKI | RecentChanges | Preferences | Page List | Links List Editing not allowed: user, ip, or network is blocked. Contact the wiki administrator for more information. BOOST WIKI | RecentChanges | Preferences | Page List | Links List Search: Disclaimer: This site not officially maintained by Boost Developers ______________ Do I need some kind of authorisation? matt. matt(a)zomojo.com

2 1

[regresssion testing] freeze with gcc3.3.4 and gcc4.01
by Matt Hurd 05 Sep '05

05 Sep '05

I'm still failing to complete a regression test cycle. Gcc goes into never never land compiling for over an hour and doesn't come back. Others seem to run these ok, so I must be doing something wrong. converter_test is the one throwing the wobbly. Any ideas? matt _____________________________________ bjam.log output at the __long__ compile bit mkdir "/zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test/converter_test.test/gcc/debug" gcc-C++-action /zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test/converter_test.test/gcc/debug/converter_test.o set -e "g++" -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -I"/zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test" -I "/zomojo/regression_boost/boost" -o "/zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test/converter_test.test/gcc/debug/converter_test.o" "/zomojo/regression_boost/boost/libs/numeric/conversion/test/converter_test.cpp" "/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug "/zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test/converter_test.test/gcc/debug/converter_test.o"

1 0

asio on Win32 - failing tests
by Roland Schwarz 05 Sep '05

05 Sep '05

I was just about trying out asio on Windows. I compiled as described, and tried to run the checks as: nmake -f Makefile.msc check and received: INFO: deadline_timer_test started INFO: deadline_timer_test ended with exit code 0 INFO: demuxer_test started INFO: demuxer_test ended with exit code 0 INFO: datagram_socket_test started INFO: datagram_socket_test ended with exit code 0 INFO: error_handler_test started INFO: error_handler_test ended with exit code 0 INFO: fixed_buffer_test started INFO: fixed_buffer_test ended with exit code 0 INFO: ipv4_host_resolver_test started FAIL: tests\unit\ipv4_host_resolver_test.cpp(88):test_if_hosts_equivalent(h1, h3) FAIL: tests\unit\ipv4_host_resolver_test.cpp(106):test_if_hosts_equivalent(h1, h7) INFO: ipv4_host_resolver_test ended with exit code 1 Is there anything I am missing? Or is this a known issue? Regards, Roland

3 6

Boost.Python and slightly more tricky inheritance
by Vladimir Pozdyayev 05 Sep '05

05 Sep '05

Greetings. 1. First, about a bug (Boost 1.33.0, MSVC 7.1): After exporting void test1( const char * ) { } void test2( std::string ) { } we get an assertion failure _BLOCK_TYPE_IS_VALID( ... ) on std::strings longer than a dozen of characters: test1( 'hello' ) # OK test2( 'hello' ) # OK test1( 'how do you do, tell me please' ) # OK test2( 'how do you do, tell me please' ) # failure 2a. From `Exposing Classes' tutorial section: "If Base is polymorphic, Derived objects which have been passed to Python via a pointer or reference to Base can be passed where a pointer or reference to Derived is expected." Now, that's a great feature, but I couldn't help noticing that what Boost.Python actually does, is even more useful: not only such pointers can be passed instead of Derived ones, but their Python counterparts _are_ fully qualified Derived representations, with all the methods and everything. Probably worth mentioning in dox that way. 2b. Now, suppose we have one more derived class: class Base { ... }; class Derived: public Base { ... }; class HiddenImplementation: public Derived { ... }; with Derived being no more than an interface. Naturally, we don't want to export HiddenImplementation to Python, but still want to retain automatic conversions from Base* to Derived* whenever pointer to HiddenImplementation object is passed to Python. Any way to do this? Without hack-ins? I was able to trick the system by defining the fake empty implemetation class class HiddenImplementation: public Derived { }; right before the BOOST_PYTHON_MODULE and exporting it out there, but this kind of `solution' really annoys me. And I don't understand why it works, either :) . Oh, and it's only a partial solution, too: we do not have to access the real implementation class, but we still have to export something. Comments? -- TIA, Vladimir mailto:ardatur@mail.ru

3 6

[metamath] Plans for compile time double
by Chris Weed 05 Sep '05

05 Sep '05

Hi, I was wonder what the plans are for the compile time double library, metamath. Is there a plan to develop compile time versions of the functions in math.h, such as sin, cos, pow, abs, etc.? Thanks, Chris

3 7

C++ Committee pre-meeting papers available
by Beman Dawes 05 Sep '05

05 Sep '05

See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/#mailing2005-08 There are several proposals for TR2 additions based on Boost libraries. Filesystem, Interval Arithmetic, Range, String Algorithms, Optional, Numeric Conversion, etc. --Beman

5 6

Boost regression notification (2005-09-04 [HEAD])
by Douglas Gregor 04 Sep '05

04 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-04T05:02:17Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. typeof Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 88 failures in 12 libraries: foreach (6) graph (4) math (6) mpl (2) multi_index (5) parameter (4) serialization (40) spirit (2) thread (9) type_traits (2) typeof (4) wave (4) |foreach| user_defined: cw-8_3 cw-9_4 msvc vc-6_5 vc-6_5-stlport vc-7_0 |graph| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |math| octonion_test: gcc-4_0-darwin gcc-4_0-darwin quaternion_test: gcc-4_0-darwin gcc-4_0-darwin special_functions_test: gcc-4_0-darwin gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin gcc-4_0-darwin |multi_index| test_capacity: gcc-4_0-darwin test_list_ops: gcc-4_0-darwin test_modifiers: gcc-4_0-darwin test_safe_mode: gcc-4_0-darwin test_update: gcc-4_0-darwin |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |spirit| traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux vc-7_1 test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |type_traits| add_const_test: vc-7_1 add_volatile_test: vc-7_1 |typeof| type_emulation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux type_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: gcc-3.3.6-linux intel-9.0-linux

2 1

Re: [boost] another question about asio
by Roland Schwarz 04 Sep '05

04 Sep '05

Sorry for quoting that much, but I am moving a private conversation back to the list. The question was about a small test: int main() { asio::demuxer d; { printer p(d); } d.run(); return 0; } which exited with access violation, and I wanted to know whether cancelation in the destructor would help. Christopher Kohlhoff schrieb: >--- Roland Schwarz <roland.schwarz(a)chello.at> wrote: > > >>I you prefer and if you think others also could benefit from my >>questions, I also can continue on the list. >> >> > >I don't mind either way :) > > > >>So embedding the cancel into printers destructor would help? >> >> > >No, that's not actually the problem. In fact, the deadline_timer >destructor already cancels the operation. > >The problem is that the completion handler (whether cancelled or not) >won't get called until inside demuxer::run() (that's a guarantee that >asio makes). Since the handler refers to the printer object you will >have a problem if the printer is destroyed before the handler gets a >chance to run. > >Basically you must ensure that any object referred to by a completion >handler is alive until the handler is called. > > > >>I assume your asio library is made up along the reactor pattern isn't >>it? >> >> > >No, it's more like proactor (and the win32 implementation uses IO >completion ports for most socket operations). > > > >>What I alsways tried to find out how a reactor is meant to be >>shutdown. Can you shed some light on this? >> >> > >The demuxer shuts down (i.e. the demuxer::run function exits) when >there is no more work to do. "Work" means unfinished asynchronous >operations. > >The cleanest way to shut down an app (unfortunately not shown in any of >my current examples yet) is to cancel all of your operations. The >completion handlers for those operations will be called with an error >code result, and once they have all finished the run() will exit. > > > >>So does the cancel call give me this guarantee? What if another >>callback is scheduled in midst of cancellation? >> >> > >As i mentioned above, cancel doesn't cause the callback to be invoked >immediately. It just causes the operation to finish early, with an >error code. > >There is no problem with callbacks running while doing a cancellation, >provided you respect thread safety rules (e.g. do not access a timer >object from multiple threads simultaneously). > > > >>I hope you don't mind if I put another few lines: >> >>As many others on the list I am eagerly looking to a network library. >>And I like asio as I can tell so far. >> >>But I have a basic question that bothers me: >>Will it be compatible with >>boost::mutex and boost::conditions? >>I.e.: Can I wait on networking events _and_ some conditions >>the same time? >> >> > >This is perhaps an area that needs more investigation. However, in my >and others' experience with asio, once an application is designed to >use an asynchronous programming paradigm, it often has no more need for >mutexes or condition variables at all! > >Instead, everything can be accomplished using a combination of async >operations, demuxer::post() and locking_dispatcher to synchronise >handlers across threads. This is more like a message passing style of >programming. > > > So basically the asio also needs a change in paradigm? It won't be of much use in the traditional threading sense? Regards, Roland

2 1

[Everyone!] VC 7.1: "'detail' : ambiguous symbol"
by Douglas Gregor 04 Sep '05

04 Sep '05

I've been doing battle with VC 7.1 and its "'detail' : ambiguous symbol" error messages for a while. The basic problem is that we have a file with, essentially, "using namespace boost; using namespace boost::spirit;" in it. Since VC 7.1 resolves namespace names a bit strangely, these using directives end up being resolved late in the compilation process, so they make lookups of names like "detail" ambiguous. The most recent of these problems shows up here: http://tinyurl.com/a4d6p Using directives from some Graph code that #includes spirit and shared_ptr has the using directives I mentioned above. All should be well, but somehow VC 7.1 is using these directives later on, so shared_ptr's reference to "detail::" becomes ambiguous. I've been whacking these problems by providing full qualification (::boost::detail) where it concerns my libraries, but now that it's hit shared_ptr I think we might need to fix this another way. A few options come to mind: 1) Make me fix the graph library with a bunch of using declarations instead of the blanket "using namespace boost::spirit;" that causes the problem. But, users might still run into this issue. 2) Keep on qualifying "detail" references until it stops causing problems 3) Stop using "detail" and instead use "[lib]_detail" that is different for each lib. Preferences? Doug

4 3

Boost regression notification (2005-09-04 [RC_1_33_0])
by Douglas Gregor 04 Sep '05

04 Sep '05

<html> <head> <meta http-equiv="refresh" content="1; url=issues-email.txt"> </head> <body> <p>Update in progress (building archive index, done in approximately 5 seconds), please wait...</p> </body> </html>

2 2

Re: [boost] [intel-9.0] --arg_dep_lookup, BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADLand__EDG_ VERSION__=304
by JOAQUIN LOPEZ MU?Z 04 Sep '05

04 Sep '05

----- Mensaje original ----- De: John Maddock <john(a)johnmaddock.co.uk> Fecha: Domingo, Septiembre 4, 2005 11:18 am Asunto: Re: [boost] [intel-9.0] --arg_dep_lookup,BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADLand__EDG_ VERSION__=304 > > John, it'd be great if this change is also merged > > to the RC_1_33_0 branch for the 1.33.1 release. > > I believe it should be already? Well, that's no what I see: MAIN branch: http://tinyurl.com/dxxev RC_1_33_0 branch: http://tinyurl.com/9mjlj ?? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[range] Documentation errors
by Matthias Troyer 04 Sep '05

04 Sep '05

Hi Thorsten, Reading through the Boost.Range documentation in libs/range/doc/ range.html I consistently found refernces to rboost::begin and rboost::end. Since I don't think we have a reverse Boost yet :-) I believe these should be spelled boost::rbegin and boost::rend? Matthias

2 1

[intel-9.0] --arg_dep_lookup, BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL and __EDG_VERSION__=304
by JOAQUIN LOPEZ MU?Z 04 Sep '05

04 Sep '05

A bit of context: * Intel 9.0 has __EDG_VERSION__==304 (under Win32/Linux), whereas prior versions of the compiler have lower values of this macro. * BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL is defined for __EDG_VERSION__<=303, that is, for all Intel compilers up to (and including) 8.1, under Win32/Linux. * Under Win32, all Intel toolset .jams define the compiler option --arg_dep_lookup, which explicitly enables ADL (disabled by default.) I don't know what the situation of ADL is for Intel under Linux, but in any case this switch is *not* used for that OS. Current RC tests for Intel 9.0 under Linux show the problem listed at http://tinyurl.com/8f5g6 One piece of code where the error pops up is like this #if defined(BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL) ::boost::multi_index::detail::swap(i1,get<1>(es2)); #else using std::swap; swap(i1,get<1>(es2)); #endif Given the __EDG_VERSION__ number of this compiler, it is the second preprocessor branch that is compiled, and it fails to use the user-supplied global swap() in favor of std::swap(), hence the error. However, this same tests succesfully passes for Intel 9.0 under Win32 (same __EDG_VERSION__ as the Linux case)!! My conclusions: * The fact that the test passes under Intel 9.0 for Win32, for which BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL is *not* defined, suggests that __EDG_VERSION__<=303 is the right check for setting this macro. * But the same test fails under Intel 9.0 for Linux, which hints at an ADL problem other than that controlled by BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL. Could it be that Intel compilers under Linux also necessitate the --arg_dep_lookup compiler switch (which is currently not set)? This looks like the only sensible conslusion from the facts described. Thanks and sorry for the long post, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 5

Re: [boost] [boost thread rework] New version uploaded to BoostVault
by Greer, Joe 04 Sep '05

04 Sep '05

Yes, but it could have been a class static as easily and have the same performance. In general, named mutexes, semaphores, and events in windows are for ipc use and are therefore much more expensive to create than the anonymous versions and critical sections are much quicker than the handle base apis in low contention situations and as quick in high contention ones. At least, that's what my tests have shown. joe > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Peter Dimov > Sent: Friday, September 02, 2005 12:36 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] [boost thread rework] New version uploaded to > BoostVault > > Greer, Joe wrote: > >> -----Original Message----- > >> Running the test program, the semaphore version gives a timing of 16s > >> compiled > >> with gcc-mingw-4.0.1, and 22s compiled with MSVC 7.1, on my machine. > > The > >> mutex > >> version gives timings of 23s (gcc) and 29s (MSVC), so the semaphore > >> version is > >> clearly faster. > >> > > > > Why use either? I wrote an implantation using critical sections and > > my timings are: > > > > Semaphores: 20 > > Mutex: 27 > > Critical section: 0 > > > > I must be missing something vital. > > You have a local static that is not thread-safe in general. > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

3 2

Boost regression notification (2005-09-03 [RC_1_33_0])
by Douglas Gregor 03 Sep '05

03 Sep '05

<html> <head> <meta http-equiv="refresh" content="1; url=issues-email.txt"> </head> <body> <p>Update in progress (building archive index, done in approximately 4 seconds), please wait...</p> </body> </html>

1 0

[BGL] maximum cardinality matchings
by Aaron Windsor 03 Sep '05

03 Sep '05

Hi, I wanted to "repost" this message: http://tinyurl.com/ak48g since I posted it a few days ago but never saw it come through the mailing list, even though it appears in the archives. Also, I've moved all the code to the directory Algorithms/graph in the vault to reflect the new naming scheme. The top level directory "maximum_cardinality_matching" can now be removed by anyone with the privileges to do so. Aaron

1 0

[1.33.1] Goals, tasks, schedule
by Doug Gregor 03 Sep '05

03 Sep '05

Certain issues that cropped up with the 1.33.0 release that necessitate a 1.33.1 release. 1.33.1 will be for safe bug fixes to 1.33.0 only, focusing on critical issues such as the already-addressed shared_ptr problem. There are two major issues we need to resolve before we can roll a release candidate of 1.33.1: - Include order dependencies in the Serialization library - GCC 4.0 type_info problems This is also a good opportunity to work in support for three compilers that are performing reasonably well now and should be supported by Boost: - Tru64 CXX - Apple GCC 4.0 on Tiger - Intel 9.0 on Linux We'll prepare the release candidate from the RC_1_33_0 branch, hopefully within a week or so, depending on the resolution of these issues. The release candidates will be available for much longer before the final release, up to a month or so, to root out any remaining issues. No new libraries or features may be added to the RC_1_33_0 branch; they should go onto the main branch, and we'll merge fixes from RC_1_33_0 back once we've released. Doug

14 21

windows.h and min/max macros
by Marcin Kalicinski 03 Sep '05

03 Sep '05

Hi All, windows.h header by default defines very annoying macros 'min' and 'max'. Maybe all boost libraries that include windows.h (such as regex) should #define NOMINMAX before including windows.h? (this disables them). I doubt there is anybody using boost that relies on these crappy macros, and they cause havoc among unwary. cheers, Marcin

2 1

[Thread] read_write_mutex bug?
by Matt Hurd 03 Sep '05

03 Sep '05

Hi, Testing my own wrapper on x86_64 bit linux exposed a seeming deadlock on constructing a read_write_lock with a *::write_locked initial state in the constructor... I've distilled it to the plain code below that exhibits the same failure. Using a read_lock state on the same works without deadlock (or safety is this case) as expected. Using a scoped_write_lock worked once but deadlocked mostly. A normal mutex and recursive mutex works as expected. I'm using 1.33. Is this a known bug or am I using the read_write stuff incorrectly? Regards, Matt. matthurd(a)acm.org ____________________________________ my test in question:... void synch_test_019() { static int global_count = 0; static boost::read_write_mutex doobie( boost::read_write_scheduling_policy::writer_priority ); long number_of_threads = 10; static long inner_loop = 1000; ZOMOJO_WORKER_THREAD_BEGIN( inner_loop ) { boost::read_write_mutex::scoped_read_write_lock lk(doobie, boost::read_write_lock_state::write_locked); global_count = global_count + 1; } ZOMOJO_WORKER_THREAD_END( number_of_threads ) BOOST_MESSAGE( "orderly progression = " << inner_loop * number_of_threads ); BOOST_MESSAGE( "concurrent progression from this run = " << global_count ); BOOST_CHECK_PREDICATE(std::equal_to<int>(), (global_count)( inner_loop * number_of_threads) ); } _________________________________________________ The helper macros _________________________________________________ #ifndef ZOMOJO_THREAD_TEST_HELPER_HPP_20050816 #define ZOMOJO_THREAD_TEST_HELPER_HPP_20050816 // A poor man's barrier helper to assist in unit test cases for parallel execution #define ZOMOJO_WORKER_THREAD_BEGIN( LoopIterations ) \ static boost::read_write_mutex m_arbitrary_( boost::read_write_scheduling_policy::writer_priority ); \ struct simple_function_arbitrary_ \ { \ static void do_work_arbitrary_() \ { \ boost::read_write_mutex::scoped_read_lock lk_arbitrary_(m_arbitrary_); \ for (int j_arbitrary_ = 0; j_arbitrary_ < (LoopIterations); j_arbitrary_++) \ { #define ZOMOJO_WORKER_THREAD_END( NumberOfThreads ) \ } \ } \ }; \ \ boost::thread_group pool_arbitrary_; \ \ { \ boost::read_write_mutex::scoped_write_lock lk(m_arbitrary_); \ for (int i_arbitrary_=0; i_arbitrary_ < NumberOfThreads; ++i_arbitrary_) \ { \ pool_arbitrary_.create_thread( simple_function_arbitrary_::do_work_arbitrary_ ); \ } \ } \ \ pool_arbitrary_.join_all(); #endif // ZOMOJO_THREAD_TEST_HELPER_HPP_20050816

4 10

Re: [boost] optional.hpp problem on AIX and fix (forwarded fromboost-users)
by Fernando Cacciola 03 Sep '05

03 Sep '05

Sorry I couldn't get to this before.... What is the proper compiler flag and value for AIX so I can add the BOOST_WORKAROUND? Fernando Cacciola SciSoft

1 0

asio networking proposal 0.3.3
by Christopher Kohlhoff 02 Sep '05

02 Sep '05

Hello all, Thanks to the feedback on the previous thread, I have just released asio 0.3.3. You can download it, or view the documentation online, at http://asio.sourceforge.net. In addition to some general cleanup, the changes include: - dgram_socket has been renamed to datagram_socket - send and recv have been replaced by write and read respectively. Functions called send and receive have been retained on the socket classes with an additonal flags argument. On the datagram_socket, sendto has been renamed to send_to, and recvfrom to receive_from. - timer has been renamed to deadline_timer and redesigned to use Boost.Date_Time classes. - socket_connector has been dropped in favour of connect/async_connect functions on both stream_socket and datagram_socket. - async_get_host_by_address and async_get_host_by_name functions have been added to ipv4::host_resolver. The implementation is simple and only simulates asynchronicity (using one background thread per-demuxer to execute the corresponding blocking call). - The ipv4::host structure has been turned into a class. - The asio::arg namespace has been renamed to asio::placeholders. The bytes_recvd and bytes_sent placeholders have been replaced with bytes_transferred. Similarly, the last_bytes_recvd/sent and total_bytes_recvd/sent have been replaced with last_bytes_transferred and total_bytes_transferred. - The "services" have been made part of the public interface of asio. E.g. for basic_stream_socket there is a stream_socket_service. These services are also templates and have an allocator as the template parameter (although this currently has no effect on the implementation). - Requires Boost 1.33. I still have much to do in terms of examples and design documentation. I think the one remaining design issue to address for now is that of safety (i.e. that some people don't like a void*+size_t interface) and reconciling that with the others' need for efficiency (sending data structures directly and avoiding copying). After pondering for some time, I think I have devised an approach that meets both requirements. The approach is loosely based on Symbian's TPtr/TPtrC classes. Here is an outline of the idea: - Define two new concepts, Buffer and Const_Buffer: class Buffer { public: size_t segment_count() const; void* segment_data(size_t index) const; size_t segment_size(size_t index) const; size_t total_size() const; // sum of all segment sizes Buffer sub_buffer(size_t start) const; Buffer sub_buffer(size_t start, size_t length) const; }; class Const_Buffer { public: size_t segment_count() const; const void* segment_data(size_t index) const; size_t segment_size(size_t index) const; size_t total_size() const; // sum of all segment sizes Const_Buffer sub_buffer(size_t start) const; Const_Buffer sub_buffer(size_t start, size_t length) const; }; These concepts are Assignable and CopyConstructible. I included the support for multiple segments as it provides a neat solution to doing scatter-gather I/O. - Change all read/write/send/receive functions to only take a buffer concept, e.g. template <typename Const_Buffer> size_t send(Const_Buffer b); template <typename Buffer> size_t receive(Buffer b); - Provide helper functions to create buffer objects for various types: impl_defined_buffer make_buffer(void* data, size_t len); impl_defined_const_buffer make_buffer(const void* data, size_t len); template <typename T, size_t N> impl_defined_buffer make_buffer(T[N] data); template <typename T, size_t N> impl_defined_const_buffer make_buffer(const T[N] data); template <typename T> impl_defined_buffer make_buffer(std::vector<T>& data); template <typename T> impl_defined_const_buffer make_buffer(const std::vector<T>& data); // For scatter-gather... impl_defined_buffer make_buffer(void* data0, size_t len0, ..., void* dataN, size_t lenN); impl_defined_const_buffer make_buffer(const void* data0, size_t len0, ..., const void* dataN, size_t lenN); The important thing to note is that the buffer objects do not own the data they represent. They are intended to be cheap-to-copy value objects that simply represent a region of memory. Here are some usage examples: demuxer d; socket s(d); // ... mystruct m = { ... }; s.send(make_buffer(&m, sizeof(m))); char s[] = "Hello world"; s.send(make_buffer(s)); std::vector<char> v(1024); s.receive(make_buffer(v)); Thoughts? I'm not really happy with the name Buffer, but couldn't think of anything else. I'm open to any suggestions. Cheers, Chris

2 2

Boost regression notification (2005-09-02 [HEAD])
by Douglas Gregor 02 Sep '05

02 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-02T05:00:11Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. typeof Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 89 failures in 14 libraries: foreach (8) function (1) graph (4) lambda (2) math (6) mpl (3) parameter (4) random (2) serialization (40) spirit (2) test (1) thread (8) typeof (4) wave (4) |foreach| rvalue_const: gcc-4_0-darwin rvalue_nonconst: gcc-4_0-darwin user_defined: cw-8_3 cw-9_4 msvc vc-6_5 vc-6_5-stlport vc-7_0 |function| lambda_test: gcc-4_0-darwin |graph| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |lambda| bind_tests_simple_f_refs: gcc-4_0-darwin exception_test: gcc-4_0-darwin |math| octonion_test: gcc-4_0-darwin gcc-4_0-darwin quaternion_test: gcc-4_0-darwin gcc-4_0-darwin special_functions_test: gcc-4_0-darwin gcc-4_0-darwin |mpl| integral_c: gcc-4_0-darwin size_t: gcc-4_0-darwin gcc-4_0-darwin |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |random| random_demo: gcc-4_0-darwin random_test: gcc-4_0-darwin |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |spirit| traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |test| token_iterator_test: gcc-4_0-darwin |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |typeof| type_emulation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux type_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: gcc-3.3.6-linux intel-9.0-linux

5 6

Boost regression notification (2005-09-02 [RC_1_33_0])
by Douglas Gregor 02 Sep '05

02 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-02T18:24:06Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 1445 failures in 7 libraries: date_time (24) foreach (2) math (3) mpl (1) multi_index (7) serialization (1405) wave (3) |date_time| testgreg_serialize: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin testgreg_serialize_xml: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin testtime_serialize: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin testtime_serialize_std_config: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin testtime_serialize_xml: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin testtime_serialize_xml_std_config: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin |foreach| rvalue_const: cw-9_5-darwin user_defined: cw-9_5-darwin |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin |multi_index| test_serialization: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin intel-win32-8_1 intel-win32-9_0 mingw-3_4_2 |serialization| test_array_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_array_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_array_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_array_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_array_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_array_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_array_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_array_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_array_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_array_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_binary_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_binary_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_binary_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_binary_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_binary_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_binary_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_binary_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_binary_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_binary_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_binary_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_text_archive: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_text_warchive: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_xml_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_xml_warchive: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_class_info_save_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_class_info_save_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_class_info_save_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_class_info_save_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_class_info_save_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_class_info_save_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_class_info_save_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_class_info_save_xml_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_class_info_save_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_class_info_save_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_contained_class_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_contained_class_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_contained_class_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_contained_class_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_contained_class_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_contained_class_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_contained_class_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_contained_class_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_contained_class_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_contained_class_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_cyclic_ptrs_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_cyclic_ptrs_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_cyclic_ptrs_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_cyclic_ptrs_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_cyclic_ptrs_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_cyclic_ptrs_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_cyclic_ptrs_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_cyclic_ptrs_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_cyclic_ptrs_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_cyclic_ptrs_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_delete_pointer_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_delete_pointer_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_delete_pointer_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_delete_pointer_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_delete_pointer_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_delete_pointer_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_delete_pointer_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_delete_pointer_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_delete_pointer_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_delete_pointer_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_demo: gcc-3_3-darwin gcc-4_0-darwin intel-win32-8_1 test_demo_auto_ptr: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_demo_auto_ptr_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_demo_dll: gcc-3_3-darwin gcc-4_0-darwin test_demo_exception: gcc-3_3-darwin gcc-4_0-darwin intel-win32-8_1 test_demo_exception_dll: gcc-3_3-darwin gcc-4_0-darwin test_demo_fast_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_demo_fast_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_demo_pimpl: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_demo_pimpl_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_demo_polymorphic: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_demo_polymorphic_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_demo_portable_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_demo_portable_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_demo_shared_ptr: gcc-3_3-darwin gcc-4_0-darwin intel-win32-8_1 test_demo_shared_ptr_dll: gcc-3_3-darwin gcc-4_0-darwin test_demo_xml: gcc-3_3-darwin gcc-4_0-darwin test_demo_xml_dll: gcc-3_3-darwin gcc-4_0-darwin test_demo_xml_load: gcc-3_3-darwin gcc-4_0-darwin intel-win32-8_1 test_demo_xml_load_dll: gcc-3_3-darwin gcc-4_0-darwin test_demo_xml_save: gcc-3_3-darwin gcc-4_0-darwin intel-win32-8_1 test_demo_xml_save_dll: gcc-3_3-darwin gcc-4_0-darwin test_deque_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_deque_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_deque_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_deque_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_deque_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_deque_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_deque_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_deque_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_deque_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_deque_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_derived_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_class_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_class_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_class_ptr_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_class_ptr_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_class_ptr_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_class_ptr_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_derived_class_ptr_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_class_ptr_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_derived_class_ptr_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_class_ptr_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_derived_class_ptr_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_class_ptr_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_derived_class_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_class_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_derived_class_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_class_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_derived_class_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_class_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_derived_class_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_class_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_derived_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_derived_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_derived_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_xml_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_derived_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_diamond_binary_archive: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_diamond_binary_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_diamond_text_archive: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_diamond_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_diamond_text_warchive: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_diamond_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_diamond_xml_archive: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_diamond_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_diamond_xml_warchive: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_diamond_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_exported_binary_archive: gcc-3_3-darwin gcc-4_0-darwin test_exported_binary_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_exported_text_archive: gcc-3_3-darwin gcc-4_0-darwin test_exported_text_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_exported_text_warchive: gcc-3_3-darwin gcc-4_0-darwin test_exported_text_warchive_dll: gcc-3_3-darwin gcc-4_0-darwin test_exported_xml_archive: gcc-3_3-darwin gcc-4_0-darwin test_exported_xml_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_exported_xml_warchive: gcc-3_3-darwin gcc-4_0-darwin test_exported_xml_warchive_dll: gcc-3_3-darwin gcc-4_0-darwin test_list_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_list_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_list_ptrs_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_list_ptrs_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_list_ptrs_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_list_ptrs_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_list_ptrs_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_list_ptrs_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_list_ptrs_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_list_ptrs_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_list_ptrs_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_list_ptrs_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_list_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_list_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_list_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_list_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_list_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_list_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_list_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_list_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_map_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_map_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_map_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_map_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_map_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_map_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_map_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_map_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_map_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_map_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_mi_binary_archive: gcc-3_3-darwin gcc-4_0-darwin test_mi_binary_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_mi_text_archive: gcc-3_3-darwin gcc-4_0-darwin test_mi_text_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_mi_text_warchive: gcc-3_3-darwin gcc-4_0-darwin test_mi_text_warchive_dll: gcc-3_3-darwin gcc-4_0-darwin test_mi_xml_archive: gcc-3_3-darwin gcc-4_0-darwin test_mi_xml_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_mi_xml_warchive: gcc-3_3-darwin gcc-4_0-darwin test_mi_xml_warchive_dll: gcc-3_3-darwin gcc-4_0-darwin test_mult_archive_types: gcc-3_3-darwin gcc-4_0-darwin test_mult_archive_types_dll: gcc-3_3-darwin gcc-4_0-darwin test_multiple_ptrs_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_multiple_ptrs_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_multiple_ptrs_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_multiple_ptrs_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_multiple_ptrs_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_multiple_ptrs_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_multiple_ptrs_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_multiple_ptrs_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_multiple_ptrs_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_multiple_ptrs_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_no_rtti_binary_archive: gcc-3_3-darwin gcc-4_0-darwin test_no_rtti_binary_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_no_rtti_text_archive: gcc-3_3-darwin gcc-4_0-darwin test_no_rtti_text_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_no_rtti_text_warchive: gcc-3_3-darwin gcc-4_0-darwin test_no_rtti_text_warchive_dll: gcc-3_3-darwin gcc-4_0-darwin test_no_rtti_xml_archive: gcc-3_3-darwin gcc-4_0-darwin test_no_rtti_xml_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_no_rtti_xml_warchive: gcc-3_3-darwin gcc-4_0-darwin test_no_rtti_xml_warchive_dll: gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor2_binary_archive: gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor2_binary_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor2_text_archive: gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor2_text_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor2_text_warchive: gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor2_text_warchive_dll: gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor2_xml_archive: gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor2_xml_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor2_xml_warchive: gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor2_xml_warchive_dll: gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_non_default_ctor_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_non_intrusive_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_non_intrusive_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_non_intrusive_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_non_intrusive_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_non_intrusive_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_non_intrusive_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_non_intrusive_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_non_intrusive_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_non_intrusive_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_non_intrusive_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_null_ptr_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_null_ptr_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_null_ptr_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_null_ptr_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_null_ptr_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_null_ptr_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_null_ptr_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_null_ptr_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_null_ptr_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_null_ptr_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_nvp_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_nvp_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_nvp_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_nvp_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_nvp_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_nvp_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_nvp_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_nvp_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_nvp_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_nvp_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_object_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_object_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_object_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_object_text_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_object_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_object_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_object_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_object_xml_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_object_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_object_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_optional_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_optional_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_optional_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_optional_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_optional_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_optional_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_optional_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_optional_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_optional_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_optional_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_polymorphic_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_polymorphic_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_polymorphic_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_polymorphic_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_polymorphic_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_polymorphic_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_polymorphic_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_polymorphic_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_polymorphic_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_polymorphic_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_primitive_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_primitive_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_primitive_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_primitive_text_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_primitive_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_primitive_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_primitive_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_primitive_xml_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_primitive_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_primitive_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_private_ctor: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_private_ctor_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_recursion_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_recursion_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_recursion_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_recursion_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_recursion_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_recursion_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_recursion_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_recursion_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_recursion_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_recursion_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_registered_binary_archive: gcc-3_3-darwin gcc-4_0-darwin test_registered_binary_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_registered_text_archive: gcc-3_3-darwin gcc-4_0-darwin test_registered_text_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_registered_text_warchive: gcc-3_3-darwin gcc-4_0-darwin test_registered_text_warchive_dll: gcc-3_3-darwin gcc-4_0-darwin test_registered_xml_archive: gcc-3_3-darwin gcc-4_0-darwin test_registered_xml_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_registered_xml_warchive: gcc-3_3-darwin gcc-4_0-darwin test_registered_xml_warchive_dll: gcc-3_3-darwin gcc-4_0-darwin test_reset_object_address: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_reset_object_address_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_set_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_set_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_set_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_set_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_set_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_set_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_set_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_set_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_set_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_set_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_132_binary_archive: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_132_binary_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_132_text_archive: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_132_text_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_132_text_warchive: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_132_text_warchive_dll: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_132_xml_archive: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_132_xml_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_132_xml_warchive: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_132_xml_warchive_dll: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_binary_archive: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_binary_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_text_archive: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_text_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_text_warchive: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_text_warchive_dll: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_xml_archive: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_xml_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_xml_warchive: gcc-3_3-darwin gcc-4_0-darwin test_shared_ptr_xml_warchive_dll: gcc-3_3-darwin gcc-4_0-darwin intel-win32-8_1 test_simple_class_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_simple_class_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_simple_class_ptr_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_simple_class_ptr_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_simple_class_ptr_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_simple_class_ptr_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_simple_class_ptr_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_simple_class_ptr_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_simple_class_ptr_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_simple_class_ptr_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_simple_class_ptr_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_simple_class_ptr_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_simple_class_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_simple_class_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_simple_class_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_simple_class_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_simple_class_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_simple_class_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_simple_class_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_simple_class_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_split_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_split_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_split_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_split_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_split_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_split_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_split_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_split_xml_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_split_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_split_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_tracking_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_tracking_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_tracking_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_tracking_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_tracking_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_tracking_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_tracking_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_tracking_xml_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_tracking_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_tracking_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_unregistered_binary_archive: gcc-3_3-darwin gcc-4_0-darwin test_unregistered_binary_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_unregistered_text_archive: gcc-3_3-darwin gcc-4_0-darwin test_unregistered_text_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_unregistered_text_warchive: gcc-3_3-darwin gcc-4_0-darwin test_unregistered_text_warchive_dll: gcc-3_3-darwin gcc-4_0-darwin test_unregistered_xml_archive: gcc-3_3-darwin gcc-4_0-darwin test_unregistered_xml_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_unregistered_xml_warchive: gcc-3_3-darwin gcc-4_0-darwin test_unregistered_xml_warchive_dll: gcc-3_3-darwin gcc-4_0-darwin test_variant_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_variant_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_variant_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_variant_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_variant_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_variant_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_variant_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_variant_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_variant_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_variant_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_vector_binary_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_vector_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_vector_text_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_vector_text_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_vector_text_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_vector_text_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_vector_xml_archive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_vector_xml_archive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_vector_xml_warchive: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_vector_xml_warchive_dll: cw-9_4 gcc-3_3-darwin gcc-4_0-darwin test_void_cast: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin test_void_cast_dll: cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin |wave| test_re2c_lexer: cw-9_4 test_slex_lexer: cw-9_4 testwave: cw-9_4

3 2

[boost thread rework] consider user-supplied instrumentation of synchronization primitives
by Matt Gruenke 02 Sep '05

02 Sep '05

Perhaps you might give some thought to how a user could instrument synchronization primitives with tracing/logging? In my experience, the lack of such a facility is a deficiency in boost locks. User-supplied pre/post -acquisition + post-release callbacks might work, or making some of the lock/mutex functions virtual. If callbacks are used, I'm not picky about whether they're template or constructor parameters. It would be useful if they had access to the thread object (don't forget to define some reasonable behavior, for main), or if you provide a TLS (Thread-Local Storage) interface. BTW, TLS can be useful for other things, as well (e.g. building a logging/trace system with a dynamic scoping capability). Matthew Gruenke Software Engineer IntelliVid Corp.

1 0

Re: [boost] [1.33.1][serialization]buginlibs\serialization\src\basic_iarchive.c pp and proposed patch
by JOAQUIN LOPEZ MU?Z 02 Sep '05

02 Sep '05

----- Mensaje original ----- De: JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> Fecha: Viernes, Septiembre 2, 2005 8:16 pm Asunto: Re: [boost] [1.33.1][serialization] buginlibs\serialization\src\basic_iarchive.c pp and proposed patch > Robert Ramey <ramey <at> rrsd.com> writes: > > > > > Joaquín Mª López Muñoz wrote: > > > The recent updates to Boost.Serialization code in RC_1_33_0 > > > can provoke a crash at run-time, as shown for instance > > > in http://tinyurl.com/dwu78 (there are other, compile-time > problems> > that I'm not addressing in tihs post.) > > > > What are these compile-time problems? > > As I'm writting this the report engined seems to be stuck, > so I cannot give you an URL It's up again: see http://tinyurl.com/cub4y, http://tinyurl.com/bk8c7 Joaquñin M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] [1.33.1][serialization] buginlibs\serialization\src\basic_iarchive.cpp and proposed patch
by JOAQUIN LOPEZ MU?Z 02 Sep '05

02 Sep '05

Robert Ramey <ramey <at> rrsd.com> writes: > > Joaquín Mª López Muñoz wrote: > > The recent updates to Boost.Serialization code in RC_1_33_0 > > can provoke a crash at run-time, as shown for instance > > in http://tinyurl.com/dwu78 (there are other, compile-time problems > > that I'm not addressing in tihs post.) > > What are these compile-time problems? As I'm writting this the report engined seems to be stuck, so I cannot give you an URL: CW 9.5 for Linux, for instance, fails to build the lib complanining about an ambiguous overload with state_saver (if my memory serves me well.) > > > The problem is located in reset_object_address. The attached > > patch to libs\serialization\src\basic_iarchive.cpp fixes the > > problem in my local tests, but as I lack the knowledge to > > be sure, I'd rather not commit it myself and let it be confirmed > > to be OK. > > I've put the fix in my local system and will be testing it soon. I don't > see any harm in it but I'm not quite sure it should be necessary either. Look at it this way: before the updates to Boost.Serialization code 34h ago, multi_index->test_serialization worked fine, now it doesn't and I haven't changed anything in my code base, so... Of course, the possibility exists that I'm using your lib in a wrong way. Also be aware that I don't really know what the patch is supposed to be doing: I've just copypasted from the previous version of reset_object_address implementation and verified that the problem went away. > I > looked at the files in multi-index and didn't find any reference to > reset_object_address so I'm still a little puzzled. More information > please? > In multi_index_container::load() (boost/multi_index_container.hpp) The error shows as follows: when loading a previously saved pointer to a tracked object, the returned pointer is bogus. Funny thing is that the object pointed to is *not* the one on which reset_object_address() is used. If you need more details on the problem as I debugged it, please tell me so. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] [boost thread rework] New version uploaded to BoostVault
by Greer, Joe 02 Sep '05

02 Sep '05

> -----Original Message----- > Running the test program, the semaphore version gives a timing of 16s > compiled > with gcc-mingw-4.0.1, and 22s compiled with MSVC 7.1, on my machine. The > mutex > version gives timings of 23s (gcc) and 29s (MSVC), so the semaphore > version is > clearly faster. > Why use either? I wrote an implantation using critical sections and my timings are: Semaphores: 20 Mutex: 27 Critical section: 0 I must be missing something vital. joe

2 1

[Boost-bugs] [ boost-Support Requests-1280829 ] Multithreaded process pausing but not deadlocking or crashin
by SourceForge.net 02 Sep '05

02 Sep '05

Support Requests item #1280829, was opened at 2005-09-02 10:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1280829&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Multithreaded process pausing but not deadlocking or crashin Initial Comment: Hi, I am writing a largely multithreaded linux program (20-60 threads) on version Fedora Core 2. I am using glib c version 2.3.3-27. In addition, I am using the boost libraries (version 1.32.0) for my threading and locking. Specifically, I am using mutexes, recursive_mutexes, scoped locking, and conditions. My problem is that the process will suddenly cease activity for random lengths of time (1 sec to minutes). However, it never crashes or produces incorrect results. Also, I do not think that it is deadlocking because it always resumes its activity. I have done some profiling of the locks, and it shows very strange behavior. For instance, threads will block for long lengths of time (the length of the inactivity) while no thread is holding the corresponding mutex more than fractions of a second. When I explored this further, it appears that thread A is blocking on a mutex while thread B holds it. I am using boost::recursive_mutex::scoped_lock objects for the locking. The weird thing is that thread B pauses at the very end of the lock's scope (again for a the length of inactivity), as though the attempt to unlock the mutex is not waking thread A and descheduling thread B for a long time. I created a test program that spawns 30 threads that just do a bunch of locking of these boost scoped locks and yielding. This program, too, shows the same downtime activity (again without crashing or deadlocking), though less frequently (I suspect because the locking pattern is probably different than in my program). It also always resumes its activity eventually. I have attached the test program code. I'm not sure whether this is a problem with the boost libraries or a linux problem, or my own problem. I was wondering if anyone has experienced similar behavior and might be able to offer some insight or guidance. Thanks! Matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1280829&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[1.33.1][serialization] bug in libs\serialization\src\basic_iarchive.cpp and proposed patch
by Joaquín Mª López Muñoz 02 Sep '05

02 Sep '05

The recent updates to Boost.Serialization code in RC_1_33_0 can provoke a crash at run-time, as shown for instance in http://tinyurl.com/dwu78 (there are other, compile-time problems that I'm not addressing in tihs post.) The problem is located in reset_object_address. The attached patch to libs\serialization\src\basic_iarchive.cpp fixes the problem in my local tests, but as I lack the knowledge to be sure, I'd rather not commit it myself and let it be confirmed to be OK. HTH Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 201a202 > moveable_objects_recent(0), 259a261,265 > if(i >= moveable_objects_end) > return; > if(old_address != object_id_vector[i].address) > // skip to any lower level ones > ++i;

2 1

regex linking problems- no copy constructor or op= for basic_regex<char> ?
by Anthony Knittel 02 Sep '05

02 Sep '05

i've been using the regex library fine to match patterns, but when i changed my objects so the regex object is stored instead of initialised each time, i get linking problems. basically it was working fine as: (simplified code): bool myclass::myfunction(char* testString) { regex mypattern("abcd"); cmatch result; return regex_match(testString, result, mypattern); } but when i changed it to store the mypattern object it came up with linker problems: class myclass { ... regex _mypattern; } void myclass::myclass() { _mypattern = regex("abcd"); } bool myfunction(char* testString) { cmatch result; return regex_match(testString, result, _mypattern); } the complaint seems to be about the copy constructor and op= methods, which are supposedly implemented in the boost_regex library. i'm linking using -lboost_regex-mgw (with the library path defined in LIBRARY_PATH); Anthony

2 1

asio networking proposal
by Christopher Kohlhoff 02 Sep '05

02 Sep '05

As discussed in the "surveying async network io libraries" thread, I'd like to turn asio (asio.sourceforge.net) into a proposal for a boost networking library. As promised, here is a list of areas where asio could use some refinement. I'd appreciate input on: - What people think of the relative importance of the items. For example, what would be required for an initial implementation vs what could or should be left until a later revision. - Whether the proposed changes are of any value. - Any other things that should be on the list. What's Missing ============== * Asynchronous DNS operations. I think it would be reasonable to say that any operation that can block should have an asynchronous equivalent. Should these operations be cancellable (not necessarily portably implementable anyway)? * IPv6 support. I have no experience with IPv6, so it would be great if someone with experience could help out with the design here. * Asynchronous socket close. In certain circumstances closing a socket can block, so it would be reasonable to expect an asynchronous close operation. * Scatter-gather operations (sendv and recvv). * The BSD socket functions sendmsg/recvmsg (which I believe are necessary to support protocols such as SCTP). * SSL/TLS and DTLS support. This would require an external library, and how does that fit in with boost? * Other protocols (PF_UNIX, ...)? * Some type of integration (or support for) a higher-level iostreams-based socket library. * More examples. * Documentation on design and rationale. What Should Be Included and What Shouldn't ========================================== * Obviously asio::thread should not be part of a boost proposal, since that functionality is already covered by Boost.Thread. * The asio::time class should probably not be included, and wherever it's used replaced by Boost.Date-Time. Naming and Structure ==================== * The use of the word "Stream" can be confusing because its existing association in C++ with iostreams. Can anyone suggest an alternative? * Should stream_socket and dgram_socket be merged into a single socket class? There other types of sockets (e.g. sequenced packet) that would require additional classes if the current approach is retained. This would not be required if the BSD socket APIs were covered by a single class. Alternatively, should additional classes be added for the other socket types? * The current separate socket_connector implementation does not correspond to an OS resource, unlike socket_acceptor. This can be problematic, e.g. it prevents a Windows implementation using ConnectEx, and doesn't allow you to set socket options before the connection is established. Therefore I propose adding connect and async_connect operations to socket classes. Should the separate socket_connector be retained? * In designing asio I considered that people may want to customise the demultiplexing strategy associated with each resource. For example the basic_stream_socket template looks like: template <typename Service> class basic_stream_socket; where Service is a "facet" of the demuxer that provides demultiplexing facilities for the socket. The typedef for stream_socket specifies the Service type based on the target platform. However in practice I don't believe this level of customisation is required (to the best of my knowledge no existing asio user customises it), particularly if asio uses the "best" demultiplexing mechanism for each platform. Or another way of looking at it: developers who need this level of control might not use a general purpose networking library anyway. An alternative approach would to have the only template parameter be an allocator (since there is often memory allocation associated with asynchronous operations). For example: template <typename Allocator> class basic_demuxer; template <typename Allocator> class basic_stream_socket; where a stream_socket can only be used with a demuxer that has the same allocator type. The typedefs for demuxer and stream_socket would just use the default allocator. Cheers, Chris

20 65

iterator adapter, little help please?
by Neal Becker 02 Sep '05

02 Sep '05

Previously, I had implemented a nice complex_to_real iterator adapter. It used the older real(z) and imag(z) that return value, not ref. Now it seems it gcc-4.0.1, at least, there are .imag() and .real() that return ref. So I thought I'd update c_to_r adaptor to use them. But, I can't seem to get this to work. Any hints? Here's what I get: g++ -c -I src test2.cc /usr/include/boost/iterator/iterator_facade.hpp: In static member function ‘static typename Facade::reference boost::iterator_core_access::dereference(const Facade&) [with Facade = boost::c_to_r_adapt<__gnu_cxx::__normal_iterator<main()::Complex*, std::vector<main()::Complex, std::allocator<main()::Complex> > > >]’: /usr/include/boost/iterator/iterator_facade.hpp:635: instantiated from ‘Reference boost::iterator_facade<I, V, TC, R, D>::operator*() const [with Derived = boost::c_to_r_adapt<__gnu_cxx::__normal_iterator<main()::Complex*, std::vector<main()::Complex, std::allocator<main()::Complex> > > >, Value = double, CategoryOrTraversal = boost::random_access_traversal_tag, Reference = double&, Difference = ptrdiff_t]’ /usr/lib/gcc/x86_64-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_algobase.h:285: instantiated from ‘static _OI std::__copy<_BoolType, std::random_access_iterator_tag>::copy(_II, _II, _OI) [with _II = double*, _OI = boost::c_to_r_adapt<__gnu_cxx::__normal_iterator<main()::Complex*, std::vector<main()::Complex, std::allocator<main()::Complex> > > >, bool _BoolType = false]’ /usr/lib/gcc/x86_64-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_algobase.h:317: instantiated from ‘_OI std::__copy_aux(_II, _II, _OI) [with _II = double*, _OI = boost::c_to_r_adapt<__gnu_cxx::__normal_iterator<main()::Complex*, std::vector<main()::Complex, std::allocator<main()::Complex> > > >]’ /usr/lib/gcc/x86_64-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_algobase.h:335: instantiated from ‘static _OI std::__copy_normal<true, false>::copy_n(_II, _II, _OI) [with _II = __gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >, _OI = boost::c_to_r_adapt<__gnu_cxx::__normal_iterator<main()::Complex*, std::vector<main()::Complex, std::allocator<main()::Complex> > > >]’ /usr/lib/gcc/x86_64-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_algobase.h:387: instantiated from ‘_OutputIterator std::copy(_InputIterator, _InputIterator, _OutputIterator) [with _InputIterator = __gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >, _OutputIterator = boost::c_to_r_adapt<__gnu_cxx::__normal_iterator<main()::Complex*, std::vector<main()::Complex, std::allocator<main()::Complex> > > >]’ test2.cc:12: instantiated from here /usr/include/boost/iterator/iterator_facade.hpp:517: error: invalid initialization of reference of type ‘double&’ from expression of type ‘const double’

2 2

Re: [boost] [program_options] portability patches
by François Dumont 01 Sep '05

01 Sep '05

Ok you got me. I was only trying to build as many boost libs as possible with the msvc-stlport toolset. The fixes were rather easy to make program_options lib build, I should have understood that the reason of those fixes not having been done before is that a buildable library is not necessarily usable. If you think that program_options is totally useless without the as<> syntax support then you can ignore my patches. Maybe a #error reporting this fact would be more obvious and would avoid to people like me to spend some time on it again. Bests

1 0

[serialization] 1.33.0 outdated Jamfile.v2
by Arvid Norberg 01 Sep '05

01 Sep '05

It seems like some source files included in Jamfile are not included in Jamfile.v2 in the serialization library. thanks -- Arvid Norberg

2 1

bizarre test results: foreach, gcc-4_0-darwin
by Eric Niebler 01 Sep '05

01 Sep '05

I need help understanding some of the recent regression results. At http://tinyurl.com/72q3k you can see the most recent Foreach test results. The first and the third columns both purport to be gcc-4_0-darwin, but the results are different! How can that be? Both tests were run today, and I haven't touched the code since yesterday. -- Eric Niebler Boost Consulting www.boost-consulting.com

3 4

another question about regression tables
by Arkadiy Vertleyb 01 Sep '05

01 Sep '05

What exactly the toolset "como-4_3_3-vc7_1" stands for? Thanks, Arkadiy

2 1

Please help understanding regression results
by Arkadiy Vertleyb 01 Sep '05

01 Sep '05

What does a blank space (as opposed to "pass"/"fail"/"n/a") mean in the regression table? Thanks, Arkadiy

2 5

[mpl] broken count and at metafunctions
by Matt Calabrese 01 Sep '05

01 Sep '05

As much as I love MPL, I have come across a couple more problems. First, on MSVC++ 7.1, "count" returns 0 with maps, when there is an element in the map with the specified key (and probably on other compilers as well, though I haven't checked the implementation). As well, while a 3-argument form of "at" is described in documentation (where the third argument is the default type returned by "at" if an element with the provided key does not exist in the container), it does not appear to be implemented in 1.33. -Matt Calabrese

4 13

Boost.Threads doc bugs
by Merlyn Morgan-Graham 01 Sep '05

01 Sep '05

First time posting, please let me know if this is not the proper forum to relay this information. An aside: It seems that it might be useful to have a form on the website for reporting doc bugs (ie those found while browsing html versions)? Getting down to business: http://www.boost.org/doc/html/threads.html#id1357428 "The technique is well-know and is explained in ." http://www.boost.org/doc/html/thread/acknowledgements.html "William E. Kempf was the architect, designer, and implementor of ." If I remember correctly, I've seen other cases in boost docs where information was missing from the end of the sentence with a " ." (<single space or white space in general><dot>), so grepping all docs for this might prove useful? Again, let me know if this should be relayed differently. -Merlyn

1 0

[Boost-bugs] [ boost-Bugs-1277742 ] Serialization 1.33 assertion failure when deserializing STL
by SourceForge.net 01 Sep '05

01 Sep '05

Bugs item #1277742, was opened at 2005-08-31 15:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1277742&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: serialization Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zach Laine (tzlaine) Assigned to: Robert Ramey (ramey) Summary: Serialization 1.33 assertion failure when deserializing STL Initial Comment: I am seeing an assertion failure in reset_object_address. The assertion output is: /tmp/boost_cvs/libs/serialization/src/basic_iarchive.cpp:266: void boost::archive::detail::basic_iarchive_impl::reset_object_address(const void*, const void*): Assertion `object_id_vector[i].address >= ol d_address' failed. These are the values in the failed assertion: i == 1 object_id_vector[i].address == 0x43ef0920 old_address == 0xbfffe240 For good measure, new_address == 0x43ee7830 and this == 0x43eeffc0 at the point of failure. I don't know if that indicates that old_address is garbage, or if it is supposed to be that far away from the other addresses. This is the same assertion failure reported in bug #1262084, but I am not using polymorphic archives. I verified that the test code submitted for that bug fails for me as well, but when I converted it to non-polymorphic archives, it works fine. Therefor I have no idea if these bugs are related. The code producing the failure worked fine under version 1.32. Unfortunately, the code that produces this failure is pretty involved. All my attempts to produce a minimal set of code that provokes the failure have failed. The object producing the failure is being serialized through a pointer-to-base. The inheritance of the object's class is Wnd -> Control -> TextControl. The object within the TextControl that is actually producing the failure is m_line_data, which is a std::vector. I have two fairly minimal serialize methods that I have created for the object being loaded when the failure occurs -- one of which works and on of which does not. Method A works: template <class Archive> void GG::TextControl::serialize(Archive& ar, const unsigned int version) { ar & BOOST_SERIALIZATION_NVP(m_line_data); } Method B fails: template <class Archive> void GG::TextControl::serialize(Archive& ar, const unsigned int version) { ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(Control) & BOOST_SERIALIZATION_NVP(m_line_data); } The XML file produced using A: <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="3"> <new_plan_text_control class_id="0" tracking_level="1" version="0" object_id="_0"> <m_line_data class_id="1" tracking_level="0" version="0"> <count>1</count> <item class_id="2" tracking_level="0" version="0"> <char_data class_id="3" tracking_level="0" version="0"> <count>0</count> </char_data> <justification>8</justification> </item> </m_line_data> </new_plan_text_control> </boost_serialization> The XML file produced using B: <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="3"> <new_plan_text_control class_id="0" tracking_level="1" version="0" object_id="_0"> <Control class_id="1" tracking_level="1" version="0" object_id="_1"> <Wnd class_id="2" tracking_level="1" version="0" object_id="_2"> <m_text></m_text> <m_done>0</m_done> <m_parent class_id="-1"></m_parent> <m_children class_id="3" tracking_level="0" version="0"> <count>0</count> </m_children> <m_zorder>0</m_zorder> <m_visible>1</m_visible> <m_clip_children>0</m_clip_children> <m_upperleft class_id="4" tracking_level="0" version="0"> <x>0</x> <y>0</y> </m_upperleft> <m_lowerright> <x>150</x> <y>25</y> </m_lowerright> <m_min_size> <x>0</x> <y>0</y> </m_min_size> <m_max_size> <x>1073741824</x> <y>1073741824</y> </m_max_size> <m_filters class_id="5" tracking_level="0" version="0"> <count>0</count> </m_filters> <m_filtering class_id="6" tracking_level="0" version="0"> <count>0</count> </m_filtering> <m_layout class_id="-1"></m_layout> <m_containing_layout class_id="-1"></m_containing_layout> <m_flags>0</m_flags> </Wnd> <m_color class_id="8" tracking_level="0" version="0"> <r>0</r> <g>0</g> <b>0</b> <a>0</a> </m_color> <m_disabled>0</m_disabled> </Control> <m_line_data class_id="9" tracking_level="0" version="0"> <count>1</count> <item class_id="10" tracking_level="0" version="0"> <char_data class_id="11" tracking_level="0" version="0"> <count>0</count> </char_data> <justification>8</justification> </item> </m_line_data> </new_plan_text_control> </boost_serialization> Below is the stack at the point of failure. I Hope this helps. #0 0xffffe410 in ?? () #1 0xbfffe050 in ?? () #2 0x00000006 in ?? () #3 0x4062bf79 in abort () from /lib/tls/libc.so.6 #4 0x40623fe3 in __assert_fail () from /lib/tls/libc.so.6 #5 0x404be06f in boost::archive::detail::basic_iarchive_impl::reset_object_address (this=0x43eeffc0, new_address=0x43ee7830, old_address=0xbfffe240) at /tmp/boost_cvs/libs/serialization/src/basic_iarchive.cpp:266 #6 0x404bd7b1 in boost::archive::detail::basic_iarchive::reset_object_address (this=0xbfffebc0, new_address=0x43ee7830, old_address=0xbfffe240) at /tmp/boost_cvs/libs/serialization/src/basic_iarchive.cpp:529 up 5#7 0x0809c679 in boost::serialization::stl::archive_input_seq<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > >::operator() (this=0xbfffe27e, ar=@0xbfffebc0, s=@0x43ef099c) at collections_load_imp.hpp:91 #8 0x0809c495 in rebuild_collection<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> >, boost::serialization::stl::archive_input_seq<boost::archive::xml_iarchive, std::ve ctor<GG::Font::LineData, std::allocator<GG::Font::LineData> > >, boost::serialization::stl::reserve_imp<std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > > > (ar=@0xbfffebc0, s=@0x43ef099c) at collections_load_imp.hpp:208 #9 0x0809c41c in load_collection<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> >, boost::serialization::stl::archive_input_seq<boost::archive::xml_iarchive, std::vecto r<GG::Font::LineData, std::allocator<GG::Font::LineData> > >, boost::serialization::stl::reserve_imp<std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > > > (ar=@0xbfffebc0, s=@0x43ef099c) at collections_load_imp.hpp:230 #10 0x0809c402 in load<boost::archive::xml_iarchive, GG::Font::LineData, std::allocator<GG::Font::LineData> > (ar=@0xbfffebc0, t=@0x43ef099c) at vector.hpp:58 #11 0x0809c3e9 in boost::serialization::free_loader<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > >::invoke (ar=@0xbfffebc0, t=@0x43ef099c, file_version=0) at split_free.hpp:58 #12 0x0809c3ad in split_free<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > > (ar=@0xbfffebc0, t=@0x43ef099c, file_version=0) at split_free.hpp:74 #13 0x0809c391 in serialize<boost::archive::xml_iarchive, GG::Font::LineData, std::allocator<GG::Font::LineData> > (ar=@0xbfffebc0, t=@0x43ef099c, file_version=0) at vector.hpp:76 #14 0x0809b937 in serialize_adl<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > > (ar=@0xbfffebc0, t=@0x43ef099c, file_version=0) at serialization.hpp:140 #15 0x0809b3b0 in boost::archive::detail::iserializer<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > >::load_object_data (this=0x814c7e8, ar=@0xbfffebc0, x=0x43ef099c, file_version=0) at iserializer.hpp:158 #16 0x404be3c6 in boost::archive::detail::basic_iarchive_impl::load_object (this=0x43eeffc0, ar=@0xbfffebc0, t=0x43ef099c, bis=@0x814c7e8) at /tmp/boost_cvs/libs/serialization/src/basic_iarchive.cpp:378 #17 0x404bd7e1 in boost::archive::detail::basic_iarchive::load_object (this=0xbfffebc0, t=0x43ef099c, bis=@0x814c7e8) at /tmp/boost_cvs/libs/serialization/src/basic_iarchive.cpp:537 #18 0x08095170 in boost::archive::detail::load_non_pointer_type<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > >::load_standard::invoke (ar=@0xbfffebc0, t=@0x43ef099c) at iserializer.hpp:362 #19 0x08095144 in boost::archive::detail::load_non_pointer_type<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > >::invoke (ar=@0xbfffebc0, t=@0x43ef099c) at iserializer.hpp:412 #20 0x08094c6a in load<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > > (ar=@0xbfffebc0, t=@0x43ef099c) at iserializer.hpp:559 #21 0x08094c28 in boost::archive::basic_xml_iarchive<boost::archive::xml_iarchive>::load_override<std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > > (this=0xbfffebc0, t=@0xbfffe540) at basic_xml_iarchive.hpp:80 #22 0x08094bdc in boost::archive::xml_iarchive_impl<boost::archive::xml_iarchive>::load_override<boost::serialization::nvp<std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > > const> ( this=0xbfffebc0, t=@0xbfffe540) at xml_iarchive.hpp:74 #23 0x08094bb3 in operator>><const boost::serialization::nvp<std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > > > (this=0xbfffebc0, t=@0xbfffe540) at interface_iarchive.hpp:84 #24 0x08093aab in operator&<const boost::serialization::nvp<std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > > > (this=0xbfffebc0, t=@0xbfffe540) at interface_iarchive.hpp:91 #25 0x080947de in GG::TextControl::serialize<boost::archive::xml_iarchive> (this=0x43ef0920, ar=@0xbfffebc0, version=0) at GGTextControl.h:223 #26 0x08094775 in serialize<boost::archive::xml_iarchive, GG::TextControl> (ar=@0xbfffebc0, t=@0x43ef0920, file_version=0) at access.hpp:109 #27 0x08094759 in serialize<boost::archive::xml_iarchive, GG::TextControl> (ar=@0xbfffebc0, t=@0x43ef0920, file_version=0) at serialization.hpp:81 #28 0x0808e7cd in serialize_adl<boost::archive::xml_iarchive, GG::TextControl> (ar=@0xbfffebc0, t=@0x43ef0920, file_version=0) at serialization.hpp:140 #29 0x0809b672 in boost::archive::detail::iserializer<boost::archive::xml_iarchive, GG::TextControl>::load_object_data (this=0x814cad0, ar=@0xbfffebc0, x=0x43ef0920, file_version=0) at iserializer.hpp:158 #30 0x404be323 in boost::archive::detail::basic_iarchive_impl::load_object (this=0x43eeffc0, ar=@0xbfffebc0, t=0x43ef0920, bis=@0x814cad0) at /tmp/boost_cvs/libs/serialization/src/basic_iarchive.cpp:363 #31 0x404bd7e1 in boost::archive::detail::basic_iarchive::load_object (this=0xbfffebc0, t=0x43ef0920, bis=@0x814cad0) at /tmp/boost_cvs/libs/serialization/src/basic_iarchive.cpp:537 #32 0x0809b2c4 in boost::archive::detail::load_non_pointer_type<boost::archive::xml_iarchive, GG::TextControl>::load_standard::invoke (ar=@0xbfffebc0, t=@0x43ef0920) at iserializer.hpp:362 #33 0x0809b298 in boost::archive::detail::load_non_pointer_type<boost::archive::xml_iarchive, GG::TextControl>::invoke (ar=@0xbfffebc0, t=@0x43ef0920) at iserializer.hpp:412 #34 0x0809af74 in load<boost::archive::xml_iarchive, GG::TextControl> (ar=@0xbfffebc0, t=@0x43ef0920) at iserializer.hpp:559 #35 0x0809af28 in boost::archive::basic_xml_iarchive<boost::archive::xml_iarchive>::load_override<GG::TextControl> (this=0xbfffebc0, t=@0xbfffe760) at basic_xml_iarchive.hpp:80 #36 0x0809aedc in boost::archive::xml_iarchive_impl<boost::archive::xml_iarchive>::load_override<boost::serialization::nvp<GG::TextControl> const> (this=0xbfffebc0, t=@0xbfffe760) at xml_iarchive.hpp:74 #37 0x08098aaf in operator>><const boost::serialization::nvp<GG::TextControl> > (this=0xbfffebc0, t=@0xbfffe760) at interface_iarchive.hpp:84 #38 0x080984c7 in boost::archive::detail::pointer_iserializer<GG::TextControl, boost::archive::xml_iarchive>::load_object_ptr (this=0x814c8c0, ar=@0xbfffebc0, x=@0x43ed4518, file_version=0) at iserializer.hpp:308 #39 0x404be9b6 in boost::archive::detail::basic_iarchive_impl::load_pointer (this=0x43eeffc0, ar=@0xbfffebc0, t=@0xbfffed44, bpis_ptr=0x814c8c0, finder=0x8081928 <boost::archive::detail::archive_pointer_iserializer<boost::archive::xml_iarchive>::find(boost::serialization::extended_type_info const&)>) at /tmp/boost_cvs/libs/serialization/src/basic_iarchive.cpp:482 #40 0x404bd817 in boost::archive::detail::basic_iarchive::load_pointer (this=0xbfffebc0, t=@0xbfffed44, bpis_ptr=0x814c8c0, finder=0x8081928 <boost::archive::detail::archive_pointer_iserializer<boost::archive::xml_iarchive>::find(boost::serialization::extended_type_info const&)>) at /tmp/boost_cvs/libs/serialization/src/basic_iarchive.cpp:549 #41 0x0808b34b in boost::archive::detail::load_pointer_type<boost::archive::xml_iarchive, GG::TextControl*>::invoke (ar=@0xbfffebc0, t=@0xbfffed44) at iserializer.hpp:473 #42 0x08089d8e in load<boost::archive::xml_iarchive, GG::TextControl*> (ar=@0xbfffebc0, t=@0xbfffed44) at iserializer.hpp:559 #43 0x08089d4c in boost::archive::basic_xml_iarchive<boost::archive::xml_iarchive>::load_override<GG::TextControl*> (this=0xbfffebc0, t=@0xbfffed90) at basic_xml_iarchive.hpp:80 #44 0x08089d00 in boost::archive::xml_iarchive_impl<boost::archive::xml_iarchive>::load_override<boost::serialization::nvp<GG::TextControl*> const> (this=0xbfffebc0, t=@0xbfffed90) at xml_iarchive.hpp:74 #45 0x08089cd7 in operator>><const boost::serialization::nvp<GG::TextControl*> > (this=0xbfffebc0, t=@0xbfffed90) at interface_iarchive.hpp:84 #46 0x08087555 in operator&<const boost::serialization::nvp<GG::TextControl*> > (this=0xbfffebc0, t=@0xbfffed90) at interface_iarchive.hpp:91 #47 0x08085cb8 in SerializationTestGGApp::Initialize (this=0xbfffef50) at serialization.cpp:458 #48 0x400312cc in SDLGGApp::Run (this=0xbfffef50) at src/SDL/SDLGGApp.cpp:291 #49 0x402259ce in GG::App::operator() (this=0xbfffef50) at src/GGApp.cpp:257 #50 0x40030988 in SDLGGApp::operator() (this=0xbfffef50) at src/SDL/SDLGGApp.cpp:62 #51 0x08085fe8 in main (argc=1, argv=0xbfffeff4) at serialization.cpp:497 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1277742&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 1

Very fast delimited record parsing with boost
by David Abrahams 01 Sep '05

01 Sep '05

This appeared on comp.lang.c++.moderated a few days ago. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

[1.33.1][multi_index] permission for changes in the branch
by JOAQUIN LOPEZ MU?Z 31 Aug '05

31 Aug '05

I've comitted two changes for multi_index into the trunk: 1. A bugfix for a multithreading problem with safe mode. 2. A fix to sync with std DR 130, see http://tinyurl.com/9lhfs These changes were planned for 1.34, but I'd like to move them to 1.33.1 if given permission. Am I? Another question, is there an estimated date for 1.33.1 RC1? Thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

cvs watch off (was: Repository access and cvs watch)
by Thomas Witt 31 Aug '05

31 Aug '05

Hi, I've turned the forced read-only files feature on the boost repository off by issuing a 'cvs watch off' command on the boost tree. This means when you get files from the repository they will be writable by default. Those of you who prefer read-only files will have to either set the CVSREAD environment variable or add the -r flag to the _global_ options in your .cvsrc file. If you are using cvs edit you can go on doing that. Nothing has changed in this respect. If you want to watch files you can still do this by using cvs watch add/remove. In this respect the command name 'cvs watch off' is really misleading. Please tell me if this change causes trouble for you. Regards Thomas

1 0

reuse of strip-debug-rule
by Stefan Slapeta 31 Aug '05

31 Aug '05

Hi, the rule turn-off-intel-debug-symbols is now defined/used at least in 3 libraries: graph, python and spirit. There is another similar one ("special-requirements") in multi_index which does the same thing for GCC on Tru64. Does it make sense to provide a common rule for this case that accepts the OS and a wildcard for the toolset as parameter? Where could this rule be defined? Stefan

2 1

[Boost-bugs] [ boost-Bugs-1262084 ] crash deserializing 1.32 data (poly archive + stl container)
by SourceForge.net 31 Aug '05

31 Aug '05

Bugs item #1262084, was opened at 2005-08-17 06:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1262084&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: serialization Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Robert Ramey (ramey) Summary: crash deserializing 1.32 data (poly archive + stl container) Initial Comment: Hello, i got a problem deserializing STL containers with polymorphic archive interfaces. Serialization/Deserialization with boost 1.32 works fine. Simple object trees with stl containers (maps) and base class registration (no shared_ptr used). When i deserialize the data (xml) with boost 1.33 it asserts/crashes in basic_iarchive.cpp ( basic_iarchive_impl::reset_object_address): --- snip ---- inline void basic_iarchive_impl::reset_object_address( const void * new_address, const void *old_address ){ // if the this object wasn't tracked std::size_t i = moveable_object_position; if(i >= moveable_object_stack.size()) return; if(old_address != object_id_vector[i].address) // skip to any lower level ones ++i; while(i < moveable_object_stack.size()){ // calculate displacement from this level assert(object_id_vector[i].address >= old_address); <---- assert here !!! // warning - pointer arithmetic on void * is in herently non-portable // but expected to work on all platforms in current usage std::size_t member_displacement = reinterpret_cast<std::size_t>(object_id_vector[i].address) - reinterpret_cast<std::size_t>(old_address); ---- snip ---- Callstack: > ddc.exe!boost::archive::detail::basic_iarchive_impl::reset_object_address(const void * new_address=0x00fb67cc, const void * old_address=0x0135c67c) Line 266 + 0x2a C++ ddc.exe!boost::archive::detail::basic_iarchive::reset_object_address(const void * new_address=0x00fb67cc, const void * old_address=0x0135c67c) Line 530 C++ ddc.exe!boost::archive::detail::polymorphic_iarchive_impl<boost::archive::xml_iarchive_impl<boost::archive::xml_iarchive> >::reset_object_address(const void * new_address=0x00fb67cc, const void * old_address=0x0135c67c) Line 78 C++ ddc.exe!boost::serialization::stl::archive_input_map<boost::archive::polymorphic_iarchive,std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,xxx::LayoutObject *> > > >::operator()(boost::archive::polymorphic_iarchive & ar={...}, std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,xxx::LayoutObject *> > > & s={...}) Line 118 + 0x1a C++ ddc.exe!boost::serialization::stl::rebuild_collection<boost::archive::polymorphic_iarchive,std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,xxx::LayoutObject *> > >,boost::serialization::stl::archive_input_map<boost::archive::polymorphic_iarchive,std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,xxx::LayoutObject *> > > >,boost::serialization::stl::no_reserve_imp<std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,minimon::base::display::dispman::CLayoutObject *> > > > >(boost::archive::polymorphic_iarchive & ar={...}, std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,xxx::LayoutObject *> > > & s={...}) Line 209 C++ ddc.exe!boost::serialization::stl::load_collection<boost::archive::polymorphic_iarchive,std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,xxx::LayoutObject *> > >,boost::serialization::stl::archive_input_map<boost::archive::polymorphic_iarchive,std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,xxx::LayoutObject *> > > >,boost::serialization::stl::no_reserve_imp<std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,xxx::LayoutObject *> > > > >(boost::archive::polymorphic_iarchive & ar={...}, std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,xxx::LayoutObject *> > > & s={...}) Line 230 + 0xd C++ ---- The serializing code is implemented using split members and manual registration and usually read like this: ---- snip --- void DerivedLayoutObject::serialize( boost::archive::polymorphic_oarchive& ar, const unsigned int /* version */) { // register pointer type info ar.register_type(static_cast<LayoutObject*>(0)); // serialize data members ar & boost::serialization::make_nvp( "status", m_status); .... // serialize stl container (std::map here) ar & boost::serialization::make_nvp( "childs", m_childs); } (deserialization vise-versa) --------------------- Whats the problem here? I simply rebuilt the whole project using 1.33. Regards, A. Focht ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1262084&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 2

[program_options] portability patches
by François Dumont 31 Aug '05

31 Aug '05

Here are several patches to improve portability for this library: - options_description.hpp: The m_default_line_length is for me an implementation detail. As static constant are well known as not being portable I propose to use the dedicated BOOST_STATIC_CONSTANT macro in this case. I also move it to the private section as I think it is the place it must be but of course it do not change the portability aspect if it is retore back to the public section. - options_description.cpp: C++ Standard library implementors needs compiler partial template specialization support in order to offer the Standard reverse_iterator definition. Using reverse_iterator in this source introduce a major limitation in terms of compilers able to support it. As the only thing you need is a reverse_iterator on string::const_iterator the simplest solution is to use the string::const_reverse_iterator typedef. This way you simply rely on Standard library quality, I expect that all compilers with partial template specialization have a Standard string coming with a const_reverse_iterator typedef. - variables_map.cpp: A classic for loop internal variable problem, i is defined 2 times with a different type in 2 different for loop. I fix it by using an iterator approach to enumerate the desc.options() container. Thanks to those patches I build the lib with the msvc-stlport toolset with no problem. Bests *** options_description.hpp.orig Tue Aug 30 07:34:41 2005 --- options_description.hpp Tue Aug 30 21:05:22 2005 *************** *** 152,160 **** @sa option_description */ class BOOST_PROGRAM_OPTIONS_DECL options_description { public: - static const unsigned m_default_line_length = 80; - /** Creates the instance. */ options_description(unsigned line_length = m_default_line_length); /** Creates the instance. The 'caption' parameter gives the name of --- 152,159 ---- @sa option_description */ class BOOST_PROGRAM_OPTIONS_DECL options_description { + BOOST_STATIC_CONSTANT(unsigned, m_default_line_length = 80); public: /** Creates the instance. */ options_description(unsigned line_length = m_default_line_length); /** Creates the instance. The 'caption' parameter gives the name of *** options_description.cpp.orig Tue Aug 30 07:42:10 2005 --- options_description.cpp Tue Aug 30 07:43:28 2005 *************** *** 375,382 **** { // find last ' ' in the second half of the current paragraph line string::const_iterator last_space = ! find(reverse_iterator<string::const_iterator>(line_end - 1), ! reverse_iterator<string::const_iterator>(line_begin - 1), ' ') .base(); --- 375,382 ---- { // find last ' ' in the second half of the current paragraph line string::const_iterator last_space = ! find(string::const_reverse_iterator(line_end - 1), ! string::const_reverse_iterator(line_begin - 1), ' ') .base(); *** variables_map.cpp.orig Tue Aug 30 07:46:25 2005 --- variables_map.cpp Tue Aug 30 07:48:48 2005 *************** *** 80,92 **** } xm.m_final.insert(new_final.begin(), new_final.end()); - - // Second, apply default values. ! const vector<shared_ptr<option_description> >& all = desc.options(); ! for(unsigned i = 0; i < all.size(); ++i) { ! const option_description& d = *all[i]; string key = d.key(""); // FIXME: this logic relies on knowledge of option_description // internals. --- 80,91 ---- } xm.m_final.insert(new_final.begin(), new_final.end()); // Second, apply default values. ! vector<shared_ptr<option_description> >::const_iterator optIt(desc.options().begin()), ! optItEnd(desc.options().end()); ! for (; optIt != optItEnd; ++optIt) { ! const option_description& d = *(*optIt); string key = d.key(""); // FIXME: this logic relies on knowledge of option_description // internals.

2 1

Proposed BOOST_FOREACH
by Joel Eidsath 30 Aug '05

30 Aug '05

I like the BOOST_FOREACH macro, and I'm going to be spending a lot of time playing around with it. For working with iterator ranges, however, this sort of thing seems to be the best that I can come up with: //pFirst and pLast are iterators that return an int on dereference //they could be some_containter<int>.rbegin() and some_container<int>.rend(), for example BOOST_FOREACH(int i, vector<int>(pFirst,pLast)); It's not that ugly, but creating a new vector to do a loop is quite an efficiency hit. Is there an better way to do this? Joel Eidsath

2 2

A few questions about regression system
by Arkadiy Vertleyb 30 Aug '05

30 Aug '05

Hello All, I am currently setting up the test system for typeof. My understanding is that I have to do the following: 1) put each test in a separate CPP file; 2) import testing rules; 3) put the following in the Jamfile: compile test1.cpp ; compile test2.cpp ; . . . 4) mention typeof in the file that lists all the boost tests. Is this correct and all that needs to be done? Also, where is it specified which compilers are supportred? Thanks in advance. Regards, Arkadiy

2 4

Boost regression notification (2005-08-30)
by Douglas Gregor 30 Aug '05

30 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-30T15:14:11Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 109 failures in 13 libraries: foreach (24) function (1) graph (3) lambda (2) math (6) mpl (3) parameter (4) python (1) random (2) serialization (50) test (1) thread (8) wave (4) |foreach| array_byref: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin array_byval: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin rvalue_const: gcc-4_0-darwin rvalue_nonconst: gcc-4_0-darwin stl_byref: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin stl_byval: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin user_defined: cw-8_3 cw-9_4 cw-9_4 vc-6_5 vc-6_5-stlport vc-7_0 |function| lambda_test: gcc-4_0-darwin |graph| graphviz_test: vc-7_1 vc-7_1 vc-7_1 |lambda| bind_tests_simple_f_refs: gcc-4_0-darwin exception_test: gcc-4_0-darwin |math| octonion_test: gcc-4_0-darwin gcc-4_0-darwin quaternion_test: gcc-4_0-darwin gcc-4_0-darwin special_functions_test: gcc-4_0-darwin gcc-4_0-darwin |mpl| integral_c: gcc-4_0-darwin size_t: gcc-4_0-darwin gcc-4_0-darwin |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |python| exec: msvc |random| random_demo: gcc-4_0-darwin random_test: gcc-4_0-darwin |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |test| token_iterator_test: gcc-4_0-darwin |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: gcc-3.3.6-linux intel-9.0-linux

1 0

[serialization] The constant object problem
by Loïc Joly 30 Aug '05

30 Aug '05

Hello everybody, I've read the rationale for only allowing const trackable objects, but here is my problem : I want to serialize the following class : class C : boost::noncopyable { public: void setData(string s) {data = s;} //... }; int main() { C c; c.setData("Hello world"); vector <C*> v; v.push_back(&c); //... ar << c << c; } To have a c with meaningfull data, it cannot be const. I cannot create a local object that is a copy of the object (it is noncopyable) I do not think making the object untracked would be a good idea in this case (I might be wrong ?) So far, the best way I found to be able to serialize this object is : C const & cForSerialize = c; ar << cForSerialize << cForSerialize; But I do not think this is really elegant code. Is there a better alternative ? -- Loïc

4 6

Re: [boost] Preprocessot question
by Suman Cherukuri 30 Aug '05

30 Aug '05

> a.c > #include "err.h" > static const int err_tag = err_tag_a_c; > enum {err_bad_foobar=1, err_missing_baz, ... }; > > and you use the errors as follows: > > long err = ERR(missing_baz); How is it going to prevent duplication. Suppose, somewhere in a.c if I write long err = ERR(missing_baz), what happens? > > with the macro ERR defined in err.h as: > #define ERR(x) ((err_tag * 65536L) + err_##x) -----Original Message----- From: Martin Bonner [mailto:martin.bonner@pitechnology.com] Sent: Tuesday, August 30, 2005 1:40 AM To: 'Suman Cherukuri' Subject: RE: [boost] Preprocessot question ----Original Message---- From: Suman Cherukuri [mailto:suman@cherukuris.net] Sent: 29 August 2005 22:49 To: boost(a)lists.boost.org Subject: [boost] Preprocessot question > This probably doesn't belong to boost mailing list, but since boost > has a lot of support in preprocessor, there may be someone who can > answer my question. You would have done better to ask this in comp.lang.c.moderated. > I'm using general 'C' compiler in this project (hence I cannot use > boost headers). I want to write a macro as follows; > > #define ERR(x, y) \ > { \ > # ifndef ERR##x \ > # define ERR##x \ > # else \ > # error ERR##x already defined\ > # endif > y = x; \ > } > > When I compile, I get the error saying, > error C2162: expected macro formal parameter > on all the preprocessor lines inside the #define ERR(...) body. Right. You can't write a preprocessor macro that creates preprocessor directives. The #ifndef in your macro will never get parsed. > The reason I want to do something like this is to have some unique > numbers > in the code (like locators. Don't want to use __FILE__ and __LINE__ > for security reasons) and want to capture duplicates at compiletime. > > For example if I say in the code, int err = 10000 in one file, I > don't want any other engineer to use 10000 in the anywhere else in > the code. > > So I started writing something like int err = ERR(10000) but got into > several compiler problems as I mentioned above. The problem I see with your solution (assuming it worked), is that if we have two files a.c and b.c, then somebody could write: a.c: ... int err = ERR(10000); ... b.c: ... int err = ERR(10000); ... ... and the check would fail to detect that both files are using the same value :-( The simple solution is to have a err.h which defines a (long) enumeration, and every time you need a new error value, you add to err.h. That is simple, but of course it means you need to recompile everything every time you add a value. The slightly more complex version is that you have an err.h which has an enumeration which is specific to each .c file. (That means you will have to recompile every time you add an .c file, but that is probably bearable.) So err.h might look like: enum { err_tag_a_c=1, err_tag_b_c, .... }; Then each .c file has at the start: a.c #include "err.h" static const int err_tag = err_tag_a_c; enum {err_bad_foobar=1, err_missing_baz, ... }; and you use the errors as follows: long err = ERR(missing_baz); with the macro ERR defined in err.h as: #define ERR(x) ((err_tag * 65536L) + err_##x) To add a new error code, you update the enumeration at the top of file, and use it via the ERR macro. (Which only requires recompiling the file you were changing anyway). Note that I assumed you could use long for your error codes - if you are in the embedded world, that might not be affordable. On the other hand, in the embedded world you can probably live with only 255 different files, and 255 error codes per file. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

Re: [boost] [statechart] Problems if I make dtorS virtual?
by BRIDGES Dick 30 Aug '05

30 Aug '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Andreas Huber > Sent: Friday, August 26, 2005 3:00 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] [statechart] Problems if I make dtorS virtual? > > BRIDGES Dick wrote: > > Just a thought - might it be worthwhile to introduce a policy to allow > > the > > user to choose between maximum performance and the comforting > > consistency > > of virtual dtorS to go with those virtual functions? :-) > > Ugh, yet another policy or #define? I'd want to avoid that. Since this > is gcc-only problem, I think the best I can do is to make that > destructor virtual for gcc and leave it non-virtual for all other > compilers. > > Thoughts? My $.02 says to leave the destructor non-virtual across the board and I sell -Wno-non-vitual-dtor to my QA group. Otherwise some embedded device will show up that favors non-virtual and I'll be the one asking you to put it back so our gcc-based cross-compilers can use it. ;) That and the threat of a #define. %-P > Regards, > > -- > Andreas Huber > > When replying by private email, please remove the words spam and trap > from the address shown in the header. > Regards, Dick Bridges

2 1

date_time test questions
by John Maddock 30 Aug '05

30 Aug '05

Jeff, I've been playing with date_time to try and get it to do the right thing with VC++ when /Zc:wchar_t is *not* specified, and I've come up with a list of questions for you if you don't mind :-) 1) What's the meaning of USE_DATE_TIME_PRE_1_33_FACET_IO? Without it the testtime_wstream.cpp test case fails even with /Zc:wchar_t, this is a source of confusion if you're building the building the tests in your IDE for whatever reason. 2) Without USE_DATE_TIME_PRE_1_33_FACET_IO the testgrep_wstream.cpp test doesn't compile irrespective of the /Zc:wchar_t option: testgreg_wstream.cpp c:\data\boost\develop\boost\boost\date_time\date_facet.hpp(640) : error C2678: binary '+' : no operator found which takes a left-hand operand of type 'const char [35]' (or there is no acceptable conversion) c:\data\boost\develop\boost\boost\date_time\date_facet.hpp(606) : while compiling class-template member function 'std::istreambuf_iterator<_Elem,_Traits> boost::date_time::date_input_facet<date_type,CharT>::get(InItrT &,InItrT &,std::ios_base &,boost::date_time::date_input_facet<date_type,CharT>::duration_type &) const' with [ _Elem=wchar_t, _Traits=std::char_traits<wchar_t>, date_type=boost::gregorian::date, CharT=wchar_t, InItrT=std::istreambuf_iterator<wchar_t,std::char_traits<wchar_t>> ] c:\data\boost\develop\boost\boost\date_time\gregorian\gregorian_io.hpp(78) : see reference to class template instantiation 'boost::date_time::date_input_facet<date_type,CharT>' being compiled with [ date_type=boost::gregorian::date, CharT=wchar_t ] c:\data\boost\develop\boost\libs\date_time\test\gregorian\testgreg_wstream.cpp(50) : see reference to function template instantiation 'std::basic_istream<_Elem,_Traits> &boost::gregorian::operator >><wchar_t,std::char_traits<wchar_t>>(std::basic_istream<_Elem,_Traits> &,boost::gregorian::date &)' being compiled with [ _Elem=wchar_t, _Traits=std::char_traits<wchar_t> ] 3) Finally there are a lot of places where an unsigned short is written to or read from a stream: unfortunately the dinkumware lib treats these "as if" they were a wide character value, rather than an integer. Casting to unsigned int in these cases would fix that, but it's a horrid cludge, and I don't know what you might think about that! Thanks, John.

3 5

Questions on Serialization
by Daryle Walker 30 Aug '05

30 Aug '05

I just looked over this library (since Robert Ramey mentioned part of it as a solution to a different problem). I'm wondering how (future) Boost library code should implement serialization. Right now, the Serialization library contains code to serialize "shared_ptr" types. Should the Serialization library contain similar code for every potential Boost type, so should each type include the code? If the latter is the answer, then does: class my_type { friend class ::boost::serialization::access; //... }; need a forward (or full) declaration for "access" before it? Or does that only apply to template functions (or is it just template operators)[1]? Also, the Contents entries from "void_cast" to "BOOST_STATIC_WARNING" need to be raised a level so they don't look like child entries for "extended_type_info". And I think some of the demo programs could use a sprinkling of "std::auto_ptr". [1] I know there's at least one wacky friend combination that'll interpret a template function as a non-template function instead if you don't take proper precautions. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

7 11

secure asio using ssl
by Dirk Griffioen 30 Aug '05

30 Aug '05

Hi All, We would like to make the remark we created a first version of a secure (ssl/tls) extension to ASIO. It's use should be regarded as an extension to ASIO and configurable with the type of ssl a user has. From the test code (the server): #define HAS_OPENSSL #include <asio.hpp> When the server accepts a connection it then calls handle_accept to secure the socket: void handle_accept(const asio::error& error) { if (!error) { std::cout << "server connected..." << std::endl; // Secure the connection socket_.async_secure( boost::bind(&impl::handle_secure, this, asio::arg::error) ); After that it's a matter of async_recv/send - but the connection now is secure. the variable needed is: asio::tls_socket socket_; Additions to ASIO are: basic_secure_socket.hpp detail/openssl_crypto_initializer.hpp detail/openssl_secure_service.hpp detail/openssl_secure_session.hpp (And (to a lesser extent) the same for GnuTls.) Our question is, can we donate this to (boost::)asio? And if so, how do we approach this? Cheers, Dirk

2 1

[thread library rework] Ready to start
by Ion Gaztañaga 30 Aug '05

30 Aug '05

Hi to all, As previously discussed here, I'm trying to organize a boost thread rework in order to help C++ thread standarization. In this moment, Kevlin Henney is working on a paper to be presented int the next ISO meeting based in his C++ thread work which is available here, in this presentation-paper: http://www.two-sdg.demon.co.uk/curbralan/papers/accu/MoreC++Threading.pdf This approach proposes futures approach to C++ threads, and also defines lock mechanisms similar to boost::mutex and boost::condition with some changes. I've contacted with Kevlin and he is ready to help as much as he can with the Boost community to develop a good thread proposal. The idea is that we could have a working implementation of the proposal above boost threads. The presentation-paper does not currently cover all the functionality we have, like thread specific storage, barriers and read-write locks neither proposed message-queue, so there is a lot of work to do. There is an active discussion on futures that can be added to this effort since it proposes future-operations that are not incompatible with the proposal, but an extension. We need to keep the thread discussion constructive and effective, although any of us has strong opinions on threading. It would be nice if we could first concentrate in "basic" functionality that does not forbid future proposals. For example, thread cancellation is a hard issue, but it can be added later if the proposal allows to do that. I'm also concerned with (in my opinion) needed compatibility with Embedded C++. C++ will grow a lot in this area and obviously, threads are very used. Embedded C++ specification (http://www.caravan.net/ec2plus/) avoids templates and exceptions, so we need to think some alternatives (apart from exceptions, just like iostreams do) to do error checking. And provide some low-resource specializations or alternatives to the full-scale C++ threading. There are many areas to cover, but in this post I would like to say that the reworking effort is alive and we need to do some serious work. Like always, ideas are good but work is better, so let's try to avoid extremely long discussions so that we can have C++ threads in the following standard. I'm ready to try to organize a bit the effort and Michael Glassford, mantainer of boost threads, is ready to help, although he has no much time. Anyway, we know there are some good thread implementations out there, and we can take some ideas. And let's try to create a basic, simple, working thread tools but without forbidding extensions in the future. For the moment I've implemented the thread-launching mechanism (threader and joiner classes) described in Kevlin's paper above boost threads. It's in Boost Vault, in thread_ex directory. I plan to add more features detailed in the paper soon (mutexes, conditions, etc...) above boost threads, because it provides a good portable framework. Currently there is no other documentation that Kevlin's presentation, but I will start making some boost documentation in this library, once we start defining more elements. I will try to write some posts regarding concrete issues, like barriers, read-write mutexes or message-queues so that we can focus the work. Obviously if anyone wants to join this effort with ideas, code, organization etc... we can split the work on several issues. Regards, Ion P.D.: I plan to continue Shmem development although, I will have less time to work on it because of this threading work. I plan to upload a new snapshot soon.

4 9

serialization support for std::complex and boost::ublas::vector
by Neal Becker 29 Aug '05

29 Aug '05

Here are a couple of useful additions for serialization. std::complex is pretty trivial, and a no-brainer IMHO. I implemented support for ublas::vector unbounded_array only. Would be nice to do more, but that's all I need at the moment. #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/serialization/split_free.hpp> template<typename Archive, typename T> inline void save (Archive &ar, const std::complex<T>& z, const unsigned int) { ar << real (z); ar << imag (z); } template<typename Archive, typename T> inline void load (Archive &ar, std::complex<T>& z, const unsigned int) { T i, r; ar >> r; ar >> i; z = std::complex<T> (r, i); } namespace boost { namespace serialization { template<class Archive, class T> inline void serialize (Archive &ar, std::complex<T>& z, const unsigned int file_version) { boost::serialization::split_free (ar, z, file_version); } } } template<class Archive, class U> inline void save (Archive &ar, const vector<U> &v, const unsigned int) { unsigned int count = v.size(); ar << count; typename vector<U>::const_iterator it = v.begin(); while (count-- > 0) { ar << *it++; } } template<class Archive, class U> inline void load (Archive &ar, vector<U> &v, const unsigned int) { unsigned int count; ar >> count; v.resize (count); typename vector<U>::iterator it = v.begin(); while (count-- > 0) { ar >> *it++; } } namespace boost { namespace serialization { template<class Archive, class U> inline void serialize (Archive &ar, vector<U>& v, const unsigned int file_version) { boost::serialization::split_free (ar, v, file_version); } } }

7 23

Boost regression notification (2005-08-29)
by Douglas Gregor 29 Aug '05

29 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-29T15:06:11Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 69 failures in 7 libraries: foreach (28) graph (3) iostreams (1) parameter (4) python (2) serialization (30) wave (1) |foreach| array_byref: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin array_byval: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin pair_byref: vc-6_5 vc-6_5-stlport vc-7_0 pair_byval: vc-6_5 vc-6_5-stlport vc-7_0 stl_byref: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin stl_byval: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin user_defined: cw-8_3 cw-9_4 cw-9_4 vc-6_5 vc-6_5-stlport vc-7_0 |graph| graphviz_test: vc-7_1 vc-7_1 vc-7_1 |iostreams| mapped_file_test: intel-win32-9_0 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |python| exec: intel-win32-9_0 msvc |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |wave| testwave: gcc-3.3.6-linux

1 0

Re: [boost] [regex] missing header inclusion
by François Dumont 29 Aug '05

29 Aug '05

I don't really agree that the patches for the missing headers are fixes for STLport support. They are rather fixes to make boost less Standard library implementation dependant. There are of course not many available Standard library implementations on the market but it is not a reason to make this kind of shortcut :-) Thanks for applying those, I hope I will have soon a final fix for the bjam STLport toolset as for the moment they are not correctly handling: 1. The fact STLport do not support the wrapper mode anymore 2. The modification in the library naming convention. The last issue will then be the lexical_cast problem if you remember. lexical_cast used to not handle correctly configuration with no wchar_t intrinsic support but with wstring granted by the Standard lib. Have anything change lately ? If no shouldn't this kind of config be officially not supported anymore by boost ? I can do a fix to the stlport.hpp file for that if you need it. Bests

2 2

Boost regression notification (2005-08-28)
by Douglas Gregor 28 Aug '05

28 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-28T14:52:12Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 87 failures in 8 libraries: foreach (37) functional/hash (1) graph (7) iostreams (1) parameter (4) python (6) serialization (30) wave (1) |foreach| array_byref: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin array_byval: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin call_once: cw-8_3 cstr_byref: cw-8_3 cstr_byval: cw-8_3 dependent_type: cw-8_3 pair_byref: cw-8_3 vc-6_5 vc-6_5-stlport vc-7_0 pair_byval: cw-8_3 vc-6_5 vc-6_5-stlport vc-7_0 rvalue_const: cw-8_3 rvalue_nonconst: cw-8_3 stl_byref: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin stl_byval: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin user_defined: cw-8_3 cw-9_4 vc-6_5 vc-6_5-stlport vc-7_0 |functional/hash| point: borland-5_6_4 |graph| graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.1-linux vc-7_1 vc-7_1 vc-7_1 |iostreams| mapped_file_test: intel-win32-9_0 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |python| exec: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.1-linux intel-win32-9_0 msvc |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |wave| testwave: gcc-3.3.6-linux

1 0

[date_time] typo in gregorian.html
by Yuval Ronen 28 Aug '05

28 Aug '05

"proleptic" was misspelled as "propleptic". (I'm practicing for "The shortest Boost bug/doc report" competition ;-) )

2 1

RFE 1274707 (Re: [Boost.Thread]: consider removing catch(...)fromthread_proxy)
by Matt Gruenke 28 Aug '05

28 Aug '05

Coincidentally, I just filed an RFE on this very topic (something I'd been meaning to do for a while, but forgot about until I upgraded to 1.33.0). It was suggested to me that I mention it here. Actually, I'd have posted here, in the first place, but it seems I misunderstood the prerequisites for joining this list (I thought it was for code contributors, only). From the archive, I can see this thread has covered most, if not all, of my points. Still, my RFE is probably more cohesive than any single message, on this topic, I've come across in the archives: http://sourceforge.net/tracker/index.php?func=detail&aid=1274707&group_id=7… BTW, I really don't understand this continual talk of a user-supplied/overridable handler function. It still compromises debugging, and without managing to provide anything the user can't already do in the user-supplied threadfunc. (I'm only mentioning this because it's a proposal not addressed in my RFE.) Thanks for considering my views. Matt Gruenke Software Engineer IntelliVid Corp.

1 0

Re: [boost] Interest in an ODBC library?
by Corwin Joy 28 Aug '05

28 Aug '05

Looking at the issue of how to declare the binding functions, what I had proposed below (which is what I did in DTL) is remarkably similar to the functions required by the boost serialization library so it really might make sense to leverage off of that as pointed out earlier. There are a few "extra" things we do in DTL binding that I don't see in the serialization library which should be highlighted though: 1. Binding types. If you want to execute a stored procedure then when you bind a column or parameter you have to store information about the binding type (input, output, in/out). 2. Validation / final construction before save and load. In DTL, after the members in a class have been initialized from the database, we optionally allow the users to associate a validation function that can be used to perform any final class construction tasks including how to handle NULL fields. So e.g. we might have a class like: class { string Location; bool Location_is_null; double TempInCentigrage; double TempInFarenheit; } In the database, only Location and TempInCentigrade will be stored. When the class is initialized from the DB, only these two fields get set and we call a UserValidate() function to let the class finish constructing and initialize the rest of its internal state. Here is a link to the DTL documentation for further examples, we call this function SelVal there: http://dtemplatelib.sourceforge.net/SelVal.htm Similarly, we also have an InsVal that enforces any final validations or calculations that need to be performed prior to writing to the database (auto-generated keys are one common application, as are policies on how to handle NULL values). Honestly, I'm kind of surprised that boost:serialization does not have a similar concept, it may be that I just didn't look hard enough through the docs.

1 0

Re: [boost] Interest in an ODBC library?
by Brian Braatz 28 Aug '05

28 Aug '05

> On Behalf Of Hajo Kirchhoff > > Brian Braatz wrote: > > you split the lib into a few pieces: > > > > 1- Get the data from the data base and stream it into X > > 2- a stock form of "X" (like the table you described) > > 3- Helpers for binding > > > > if you built the thing that way, then it will be usable by those of us > > out there who have large bodies of code relying on things like ADO > > recordsets. I would love to replace the recordsets, but I need to be > > able to selectively use pieces of your library and I need to have a > > usage model that is similar. > > > > Thanks, interesting thoughts. > > Hajo > [Brian Braatz Writes:] If you are interested in collaborating, I have wanted to (for some time now) build the table<> aspect of what you are working on. My goals: 1- functional drop in replacement for ADO recordset 2- Dynamic and static "views" and indexes 3- binding model that does NOT force you to use the bindings supplied with the library this is something ADO lacks, and something I have had to work around to great frustration 4- the ability to COPY from one table<> to another table<> * ADO does NOT ALLOW you to copy recordsets. (brilliant no?) Additionally - I am not sure if he is still interested, but Joaquin Munez and I exchanged emails awhile back about collaborating on such a beast. The general idea was to take the functionality in multi-index container and make it work dynamically. (and there is more) I am working on something unrelated to this discussion that could form a good foundation for table<>. I should have something to share middle of next week. Just let me know if you are interested in putting our heads together. :) Brian

9 43

Range adaptor for adjacent_difference
by Chad Parry 28 Aug '05

28 Aug '05

(Resending to the Boost distribution list.) I have a suggestion for the range_ex library. It is such a useful library -- IMHO, the Boost.Range library is useless without it. I would also like to see it include a numeric.hpp that has a version of adjacent_difference, etc. In my mind, any standard algorithm that takes an input iterator and an output iterator as parameters could be rewritten as a range adaptor. I attached a sample implementation. It's not done using Boost coding standards or anything. BTW, I also found the "tail" (a.k.a. "pop_front") adaptor to be useful in conjunction with adjacent_difference. Here's how I use it in my toy project: QuoteSum sum( accumulate( make_ResUse_range(result) | boost::adaptor::transform( boost::bind(adaptable_constructor<QuoteAddend>(), boost::bind(&parseTimestampColumn, boost::bind(&mysqlpp::Row::operator[], _1, 0) ), boost::bind(&mysqlpp::Row::operator[], _1, 1) ) ) | adjacent_difference() | tail(), QuoteSum(), AccumulateQuotes(inverseYearDuration, annualMeanRate) ) ); Thanks for the work that went into the library -- I hope it gets adopted. I personally find it much more powerful than BOOST_FOREACH. -- chad

2 1

[Boost-bugs] [ boost-Bugs-1274839 ] bind/placeholders.hpp breaks GCC 3.4 + precompiled headers
by SourceForge.net 27 Aug '05

27 Aug '05

Bugs item #1274839, was opened at 2005-08-27 18:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1274839&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: functional Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Gruenke (mgruenke) Assigned to: Mark Rodgers (mark_rodgers) Summary: bind/placeholders.hpp breaks GCC 3.4 + precompiled headers Initial Comment: Like a number of other compilers, GCC (version 3.4.3) appears to have problems related to precompiled headers that contain anonymous namespaces - such as the one in bind/placeholders.hpp. There seems to be some consensus that it currently does have issues in this area (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10591) I noticed the workarounds in bind/placeholders.hpp (Boost version 1.33.0) for other compilers, and tried them with the above version of GCC. I discovered that only the work-around using static inline wrapper functions (i.e. the one for Borland compilers) seems to work. I've only encountered this problem in bind/placeholders.hpp. However, this problem could presumably exist anywhere anonymous/unnamed namespaces are used. This seems to be a one-line fix. I'll submit a patch file, separately. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1274839&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Feature Requests-1274707 ] Remove try/catch(...) in thread.cpp:thread_proxy()
by SourceForge.net 27 Aug '05

27 Aug '05

Feature Requests item #1274707, was opened at 2005-08-27 14:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1274707&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: thread Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Gruenke (mgruenke) Assigned to: William E. Kempf (bill_kempf) Summary: Remove try/catch(...) in thread.cpp:thread_proxy() Initial Comment: THE CASE AGAINST try {} catch (...) {} IN libs/thread/src/thread.cpp:thread_proxy() The only platform on which I've used boost::thread is Linux + GCC. So, on the debugging front, I can only speak to that. In this configuration (using pthreads), the behavior of an exception being allowed to propagate outside of a thread function is quite useful - you get a backtrace of the entire call sequence leading up to the throw, AND a full unwind back from that point (which looks like further entries in the call stack). However, if an exception is caught & rethrown, all of the prior call & unwind history is lost. Obviously, this also happens if an exception is caught and not rethrown - which is the current (circa version 1.33.0) behavior of thread_proxy(). I've tried a number of experiments, as well as inspecting pthreads & glibc code, and have been unsuccessful at reproducing this behavior in user code. However it's so useful that, on virtually every project where I'd like to use boost::thread, I eventually resort patching the source to remove this last-resort try/catch block. For a library to be of much practical value, debugging must not be significantly impaired (and even enhanced, where possible without significant compromises). The additional complexity of multithreaded programs makes this all the more important. I think this point stands pretty well, on its own. A more troubling aspect of this try/catch block is that the thread terminates in exactly the same way via an otherwise unhandled exception as it does when the user-supplied threadfunc exits cleanly. If the user of boost::thread didn't think to catch the particular exception in question, then it's unlikely it employed and is inspecting any other mechanism for determining whether the thread accomplished its goal. This assumption violated, it's unsafe to assume the program will continue to function correctly. Since the thread exists in the same memory space as the rest of the process (and shares library state, if not also other data structures), an unhandled exception indicates bad state in the process, or some other invalidated assumption. In fact, in non-exception-safe code, it may even produce bad state. Any of these conditions makes it unsafe to assume the program will continue to operate correctly. Finally, there's a more philosophical point that should probably be made. The primary purpose of exceptions is to provide proactive notification of program errors (as opposed to relying on return codes - which facilitate errors being silently ignored). Why should behavior of uncaught exceptions in other threads be any different than main? Yet thread_proxy() just quietly drops them on the floor. As a user, I normally expect that no unhandled exceptions were thrown, if my program runs to completion. WHAT WILL HAPPEN IF IT'S REMOVED? If the user specifically wants this behavior, it can suitably augment its user-supplied threadfunc to contain the catchall. There's nothing wrong with simply stating that the behavior of exceptions that propagate outside threadfunc is undefined. While changing this might "break" some existing code, it's really quite likely that code is already broken - though the user simply doesn't know it. IMO, there's nothing wrong with libraries evolving to detect more errors and invalid conditions. CONCLUSION In summary, I believe the current behavior is: 1. Dangerous - hides program errors in a most un-exception-like manner. 2. Unfriendly - defeats useful debugging functionality, on some platforms. 3. Surprising - users don't expect libraries to inhibit propagation of their exceptions. 4. Unnecessary - the user can easily supply this behavior, if desired. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1274707&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Boost regression notification (2005-08-27)
by Douglas Gregor 27 Aug '05

27 Aug '05

<html> <head> <meta http-equiv="refresh" content="1; url=issues-email.txt"> </head> <body> <p>Update in progress (building archive index, done in approximately 19 seconds), please wait...</p> </body> </html>

1 0

Preparing for 1.33.1 ?
by John Maddock 27 Aug '05

27 Aug '05

So.... it looks like we have a number of small niggles, not least of which is the shared_ptr problem, so do we go for a 1.33.1 release? Assuming "yes", can everyone who's made changes to the RC_1_33_0 branch, please make sure that those fixes are logged in the news section of index.htm. I've added preliminary entries for config, shared_ptr and regex, but the following libs also have changes: hash, iostreams parameter program_options serialization test The plan then would be to produce an early *beta* of the tarballs/zips sometime soon (I may be able to do this on Saturday), this would act as an initial hotfix release as well as the first beta: we can then move on to a fairly leisurely cycle (two weeks or so?) of one or two more betas, followed by a final 1.33.1 release. The aim would be to: * Give lib authors more time to fix any issues that may have come up. * Test a beta release procedure and see how it works out. * Give uses a little more time to report critical issues that still need fixing, but aren't in the Beta. We also need to decide how much of our testing resources to devote to testing 1.33.1: this is the biggest argument against another release, we do not want to stall main branch development. How does this sound to everyone? John.

15 21

[Boost-bugs] [ boost-Bugs-1274584 ] wave crashes with this input
by SourceForge.net 27 Aug '05

27 Aug '05

Bugs item #1274584, was opened at 2005-08-27 15:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1274584&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: jmihalicza (jmihalicza) Assigned to: Nobody/Anonymous (nobody) Summary: wave crashes with this input Initial Comment: wave.exe crashes when it is given this input. Using a debugger it turns out that in cpp.re in the fill function memcpy gets a negative number as count (-> very big positive number 'coz size_t is unsigned) -> crash. Somehow s->lim == 0, this is why count becomes negative in memcpy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1274584&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[repost][multi_index][rfc] random access indices
by JOAQUIN LOPEZ MU?Z 27 Aug '05

27 Aug '05

Hello all, I'm considering whether to add to Boost.MultiIndex a new type of indices with random access semantics, somewhat similar to std::vectors. As I wouldn't like to keep adding things to the library without some actual feedback as of its suitability, I've written some preliminary notes about how these indices could look like, located at: http://195.235.93.150/rnd_indices_spec.html I'm very interested in knowing your opinion about this stuff, ways of improving the spec, and most of all whether it is really an interesting thing to have in Boost.MultiIndex 1.34. Please go ahead and comment on this. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[regex] missing header inclusion
by François Dumont 27 Aug '05

27 Aug '05

Hello The sprintf function reference in the using directive at regex_workaround.hpp is declared in stdio.h or cstdio which is not included. This missing header inclusion makes build of boost regex lib impossible with msvc-stlport toolset and surely with many other STLport toolsets. I try to remove the using directive as this function is not used in this file but it is in regex lib sources so the fix is really to add the header inclusion. Bests *** regex_workaround.hpp.orig Thu Aug 25 05:32:32 2005 --- regex_workaround.hpp Thu Aug 25 05:32:50 2005 *************** *** 22,27 **** --- 22,28 ---- #include <new> #include <cstring> + #include <cstdio> #include <cstdlib> #include <cstddef> #include <cassert>

2 2

serialization as generialized I/O
by Neal Becker 27 Aug '05

27 Aug '05

Looking again at mersenne_twister, one of the objections that has been raised to adding serialization support, is that there is already iostream I/O support. It is in principle possible to leverage iostream to do serialization. Unfortunately, that approach is hardly efficient and rather ugly IMHO. But, what about the other way around? If we have generic archive support, can we use it to eliminate the need for iostream? I think so. In fact, consider this code (assuming serialization suport added to mersenne_twister): typedef boost::mt19937 rng_t; int main() { rng_t rng1; std::ostringstream os; boost::archive::text_oarchive oa(os, boost::archive::no_header); oa << const_cast<const rng_t&>(rng1); std::string st (os.str()); std::cout << rng1 << '\n'; std::cout << st << '\n'; } As it is, the 2 outputs are almost identical. There is only one difference: the text_oarchive (,no_header) output prints 2 leading '0' characters. Is there some way to suppress this preamble? If so, then we have a more elegant solution. All we need to do is put in the serialization support and remove the iostream support, since serialization is just a generalization of i/o.

2 2

Redhat boost rpm update
by Neal Becker 27 Aug '05

27 Aug '05

Well, they ignored me again - this is from the posting: * Fri Aug 12 2005 Benjamin Kosnik <bkoz(a)redhat.com> 1.33.0-1 - Update to boost-1.33.0, update SONAME to 2 due to ABI changes. - Simplified PYTHON_VERSION by Philipp Thomas <pth(a)suse.de>

3 2

optional.hpp problem on AIX and fix (forwarded from boost-users)
by Peter Dimov 26 Aug '05

26 Aug '05

Rich Cook wrote: > That fixed it! Thank you very much for your valuable help. > > To be clear, when I replaced line 388 of optional.hpp: > > get_ptr_impl()->T::~T(); > > with > > get_ptr_impl()->~T(); > > My program compiled fine. > > On Aug 26, 2005, at 2:20 PM, Peter Dimov wrote: > >> Rich Cook wrote: >> >> >>> Ah, but does it work on AIX? :-) >>> Sorry, I couldn't resist. (My posts are getting ignored, so I >>> assume nobody uses boost on AIX. >>> >> >> This might well be the case. Have you tried replacing the problematic >> >> get_ptr_impl()->T::~T(); >> >> construct at line 388 of optional.hpp with >> >> get_ptr_impl()->~T(); >> >> or perhaps >> >> get_ptr_impl()->~value_type(); >> >> _______________________________________________ >> Boost-users mailing list >> Boost-users(a)lists.boost.org >> http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [boost] [statechart] Problems if I make dtorS virtual?
by BRIDGES Dick 26 Aug '05

26 Aug '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Andreas Huber > Sent: Thursday, August 25, 2005 9:14 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] [statechart] Problems if I make dtorS virtual? > > BRIDGES Dick wrote: [snip] > > I followed the instructions to build the examples. Changed to the > > example directory and ran <<bjam "sTOOLS=gcc">>. I got lazy and only > > ran the PingPong* progs. Guess I should have mentioned that. %>] > > Oh, sorry. The fact that you saw the warnings led me to believe that the > examples weren't built with bjam. > Again my exposition was lacking. I built my code and the examples with both bjam and make in unsuccessful attempts to get myself out from between this rock (warnings,warnings everywhere) and that hard place (convincing QA that setting the -Wno-non-virtual-dtor flag for *ALL* of our code that touches the library is acceptable). > > Any chance that, in the absence of some future evidence to the > > contrary, those dtorS can be made virtual in the library? > > I'm at least reluctant to do that. Given the abundance of platforms that > support C++ we can never be sure that there is not one where performance > will suffer significantly when the dtors are made virtual. From the 3 > compilers I use GCC is the only one that a) has such a non-virtual dtor > warning *and* b) doesn't have a pragma to turn off warnings. Hopefully, > the latter will soon be taken care of... I understand. Balancing performance and safety in this dynamic environment of promises and deadlines must be very difficult. I envy your ability and admire what you've accomplished. Just a thought - might it be worthwhile to introduce a policy to allow the user to choose between maximum performance and the comforting consistency of virtual dtorS to go with those virtual functions? :-) > Regards, > > -- > Andreas Huber Regards, Dick Bridges

2 1

Confused about serialization
by Neal Becker 26 Aug '05

26 Aug '05

I don't understand why this simple test doesn't compile. Any hints? #include <iostream> #include <sstream> #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> class rng_t { public: friend class boost::serialization::access; // BOOST_SERIALIZATION_SPLIT_MEMBER() template<class Archive> inline void save (Archive &ar, const unsigned int) const { for (int j = 0; j < 10; ++j) // ar << compute(j); ar << int(0); } template<class Archive> inline void load (Archive &ar, const unsigned int) { } template<class Archive> void serialize(Archive & ar, const unsigned int file_version) { boost::serialization::split_member(ar, *this, file_version); } }; void getstate (const rng_t& rng) { std::ostringstream os; boost::archive::binary_oarchive oa(os); oa << rng; } void setstate (rng_t& rng, std::string& st) { std::istringstream is (st); boost::archive::binary_iarchive ia (is); ia >> rng; } g++ -c test.cc test.cc: In member function ‘void rng_t::save(Archive&, unsigned int) const [with Archive = boost::archive::binary_oarchive]’: /usr/include/boost/serialization/access.hpp:93: instantiated from ‘static void boost::serialization::access::member_save(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive, T = const rng_t]’ /usr/include/boost/serialization/split_member.hpp:43: instantiated from ‘static void boost::serialization::detail::member_saver<Archive, T>::invoke(Archive&, const T&, unsigned int) [with Archive = boost::archive::binary_oarchive, T = rng_t]’ /usr/include/boost/serialization/split_member.hpp:69: instantiated from ‘void boost::serialization::split_member(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive, T = rng_t]’ test.cc:25: instantiated from ‘void rng_t::serialize(Archive&, unsigned int) [with Archive = boost::archive::binary_oarchive]’ /usr/include/boost/serialization/access.hpp:109: instantiated from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive, T = rng_t]’ /usr/include/boost/serialization/serialization.hpp:81: instantiated from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive, T = rng_t]’ /usr/include/boost/serialization/serialization.hpp:140: instantiated from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive, T = rng_t]’ /usr/include/boost/archive/detail/oserializer.hpp:147: instantiated from ‘void boost::archive::detail::oserializer<Archive, T>::save_object_data(boost::archive::detail::basic_oarchive&, const void*) const [with Archive = boost::archive::binary_oarchive, T = rng_t]’ test.cc:37: instantiated from here test.cc:16: error: no match for ‘operator<<’ in ‘ar << 0’ /usr/include/boost/archive/detail/interface_oarchive.hpp:84: note: candidates are: Archive& boost::archive::detail::interface_oarchive<Archive>::operator<<(T&) [with T = int, Archive = boost::archive::binary_oarchive]

3 6

Suggestions for new types in the Boost.Any library
by christopher diggins 26 Aug '05

26 Aug '05

Since there has been interest in making changes to boost::any, I thought I would suggest a couple of new types which would be appropriate for the any namespace, which I find useful and use commonly. - A typed_any. This is a type very similar to any with the added restriction that it can not be reset, it must be initialized with a type, and once initialized it can only hold values of that type. I am using a homegrown version an interpreter for a strongly typed scripting language (HeronScript). - any_ptr. The name says it all. Anyone else interested in these types? Christopher Diggins http://www.cdiggins.com

2 1

[ANN] BOOST_FOREACH committed to main CVS
by Eric Niebler 26 Aug '05

26 Aug '05

BOOST_FOREACH was accepted back in May, but the tree was frozen for release. Now that 1.33 is out and the dust is settling, I finally checked it in. It's in boost/foreach.hpp. BTW, is there a guide for adding new libraries to Boost main CVS? I think I got all the bases covered as far as integration with the main docs and the regression test, but I'd like to be sure. -- Eric Niebler Boost Consulting www.boost-consulting.com

3 3

Boost regression notification (2005-08-26)
by Douglas Gregor 26 Aug '05

26 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-26T14:22:15Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 78 failures in 7 libraries: foreach (24) functional/hash (1) graph (7) parameter (4) python (11) serialization (30) wave (1) |foreach| array_byref: cw-9_5-darwin gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3_3-darwin array_byval: cw-9_5-darwin gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3_3-darwin cstr_byref: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux cstr_byval: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux pair_byref: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux pair_byval: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux stl_byref: cw-9_5-darwin gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3_3-darwin stl_byval: cw-9_5-darwin gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3_3-darwin |functional/hash| point: borland-5_6_4 |graph| graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.1-linux vc-7_1 vc-7_1 vc-7_1 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |python| exec: cw-8_3 gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux intel-win32-9_0 msvc vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |wave| testwave: gcc-3.3.6-linux

1 0

[Boost-bugs] [ boost-Bugs-1274143 ] bjam HDRS rule in python tutorial compilation
by SourceForge.net 26 Aug '05

26 Aug '05

Bugs item #1274143, was opened at 2005-08-26 18:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1274143&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Group: None Status: Open Resolution: None Priority: 5 Submitted By: Leon Oostrijk (ljo_) Assigned to: David Abrahams (david_abrahams) Summary: bjam HDRS rule in python tutorial compilation Initial Comment: When I set HDRS to a value it has no effect. It always produces the value -I"bin/boost" or -I"bin/tutorial". When checked with "-d+7" you can see that the original value is overwritten halfway in the process. As far as I can see nobody uses HDRS in a Boost Jamfile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1274143&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

undefined behaviour in tuple_io.hpp (bug)(patch)
by Rupert Kittinger 26 Aug '05

26 Aug '05

In the tuple_io.hpp header, there seems to be a slight problem in extract_and_check_delimiter(). The following snippet is problematic: char c; if (is_delimiter) { is >> c; if (c!=d) { is.setstate(std::ios::failbit); } } If c cannot be read because is.eof(), the result of c!=d is undefined. A simple fix is attached. cheers, Rupert -- Rupert Kittinger <rkit(a)mur.at> *** tuple_io.hpp.orig Wed Aug 24 21:05:26 2005 --- tuple_io.hpp Wed Aug 24 21:07:13 2005 *************** *** 349,355 **** char c; if (is_delimiter) { is >> c; ! if (c!=d) { is.setstate(std::ios::failbit); } } --- 349,355 ---- char c; if (is_delimiter) { is >> c; ! if (is.good() && c!=d) { is.setstate(std::ios::failbit); } } *************** *** 443,449 **** CharType c; if (is_delimiter) { is >> c; ! if (c!=d) { is.setstate(std::ios::failbit); } } --- 443,449 ---- CharType c; if (is_delimiter) { is >> c; ! if (is.good() && c!=d) { is.setstate(std::ios::failbit); } }

3 3

?? yilin yang ????????????????!
by yyl_20020115＠yahoo.com.cn 26 Aug '05

26 Aug '05

yilin yang 希望与您通过雅虎通聊天。请点击这个链接接受邀请： http://invite.msg.yahoo.com/invite?op=accept&intl=cn&sig=jjk1zy0GAiCp6Fp5jR… 通过雅虎通，您将获得：卓越语音通过质量，通达全球，完全免费。您只需要扬声器和麦克风。如果对方无法接听，还可以语音留言！轻松的照片共享。简单到只需把图片拖拽到聊天窗口就可以开始共享了。选择性隐身。轻松控制谁可以看到您是否在线，进退自如，保护隐私。还在等什么？这些都是免费的！现在就下载雅虎通，开始与您的好友交流吧！

1 0

Discussion Policy document - Outlook QuoteFix
by Martin Bonner 26 Aug '05

26 Aug '05

http://www.boost.org/more/discussion_policy.htm has a link to OE-QuoteFix by Dominic Jain, and the statement "Unfortunately there's no similar utility for Outlook Users; they will have to clean up their posts manually." In actual fact, the nice Mr Jain has also written Outlook-Quotefix available at: http://home.in.tum.de/~jain/software/outlook-quotefix/ (This is particularly generous of him as he doesn't actually /use/ Outlook - just Outlook Express). It would be good if somebody could update the discussion policy document. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1

Re: [boost] Questions on Serialization
by Bjorn.Karlsson＠readsoft.com 26 Aug '05

26 Aug '05

> From: David Abrahams [mailto:dave@boost-consulting.com] > > "Robert Ramey" <ramey(a)rrsd.com> writes: > > > When the test system introduced automatic memory leak detection, I > > noticed for the first time that lots of the demos and tests had > > memory leaks. It doesn't affect the validity of the demos and tests > > but it does look a little sloppy. I'm reluctant to fix this as I'm > > concerned about complicating the demos and diminishing their > > tutorial value and about complicating the tests. > > IMO that's unacceptable for Boost. A naive user who follows a Boost > example like a recipe could introduce errors into his organization's > codebase. Who do you think the deveopment team manager will blame > when he finds out the error was present in our example? Do you think > they'll continue to have confidence in the quality of the Boost > libraries they're using? I don't. I strongly agree with this sentiment. I often direct colleagues and readers of my articles to the Boost libraries' online documentation; knowing that the documentation is generally of very high quality and accuracy. Bjorn

1 0

Which libs need multithreading?
by Neal Becker 26 Aug '05

26 Aug '05

I'm trying to package up a boost_1_33 RPM. The current default build produces single/multi thread variants of all libs. The current Redhat/Fedora rpm doesn't follow this. I'm tempted to just build single/multi thread variants of all libs just like the default build, but my question is, for which libs does multi-threading actually matter? Is there a subset of boost libs that actually change behavior with this switch? I'd like to get a minimal set.

9 14

[Boost-bugs] [ boost-Patches-1273960 ] spirit/symbols.ipp pragma warning fix
by SourceForge.net 26 Aug '05

26 Aug '05

Patches item #1273960, was opened at 2005-08-26 13:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1273960&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: jmihalicza (jmihalicza) Assigned to: Nobody/Anonymous (nobody) Summary: spirit/symbols.ipp pragma warning fix Initial Comment: The original version sets the default setting back at the end of the file so the following code doesn't work as expected: #pragma warning (disable:4355) #include <boost/spirit/....> // some file that includes symbols.ipp // here 4355 may be enabled according to the default settings (warning level) The fix uses push/pop ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1273960&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[quick_allocator] false sharing on SMP
by Maxim Yegorushkin 26 Aug '05

26 Aug '05

Pavel Vozenilek asked to repost this here, so here it is: http://groups.google.com/group/comp.lang.c++.moderated/msg/2b85fdcd20239a52 I just skimmed through boost/detail/quick_allocator.hpp and noticed that quick_allocator causes false sharing on SMP. It happens when several counters are allocated within the same cache line and those counters are used by different processors, thus thrashing processors' cache lines when the counter is written, even when the counter is used by a single processor only. More information about allocators and false sharing can be found in papers included with Hoard allocator sources. http://hoard.org/ -- Maxim Yegorushkin

3 5

[Boost-bugs] [ boost-Bugs-1273836 ] bjam HDRS rule in python tutorial compilation
by SourceForge.net 26 Aug '05

26 Aug '05

Bugs item #1273836, was opened at 2005-08-26 09:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1273836&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Group: None Status: Open Resolution: None Priority: 5 Submitted By: Leon Oostrijk (ljo_) Assigned to: David Abrahams (david_abrahams) Summary: bjam HDRS rule in python tutorial compilation Initial Comment: When I set HDRS to a value it has no effect. It always produces the value -I"bin/boost" or -I"bin/tutorial". When checked with "-d+7" you can see that the original value is overwritten halfway in the process. As far as I can see nobody uses HDRS in a Boost Jamfile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1273836&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[multi_index] feature request
by Maxim Yegorushkin 26 Aug '05

26 Aug '05

[multi_index] feature request In my code I often use collections of noncopyable objects and yet I need to have them indexed. The usual solution is to store pointers to the objects in the index (be it a std::set/map or boost::multi_index). This leads to two allocations: the first for the object and the second for the index node. For me it would be more natural and effective to embed the index node in the object, so that the container is obviated from allocating nodes and only maintains indexes. This also would make all container operations nothrow, since element insertion and removal requires only node pointer manipulations and using the comparer object which is typically nothrow. In my work I use my own intrusive_list which has proved itself quite useful and effective. The syntax is: struct noncopyable_object; typedef intrusive_list<noncopyable_object> list; struct noncopyable_object : list::node // embed the list node in the class { // ... }; Will such a feature ever make it to multi_index? -- Maxim Yegorushkin <firstname.lastname(a)gmail.com>

2 1

Re: [boost] [statechart] Problems if I make dtorS virtual?
by BRIDGES Dick 25 Aug '05

25 Aug '05

Hi Andreas > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Andreas Huber > Sent: Wednesday, August 24, 2005 2:19 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] [statechart] Problems if I make dtorS virtual? > > Hi Dick > > BRIDGES Dick wrote: > > When compiling the examples (statechart library downloaded from sf 18 > > Aug), I get the following warnings: > > [snip warnings] > > > I changed ~simple_State() and ~state_base() to virtual and the > > warnings disappeared. [snip] > > As a quick, not-definitive check, I built PingPong* with both the > > virtual and non-virtual dtorS using gcc 3.4.2 on an old > > i386-redhat-linux machine. > > I would expect the PingPong examples to deliver the least-dependable > information regarding virtual vs. non-virtual dtors. This is due to the > fact that a lot of stuff is going on besides the destruction of states. > I think BitMachine would make for a better testing platform... > > > The results appear to be the reverse of what I would expect, but I > > checked > > to verify that I have the correct result/config correspendence. > > > > ..................non-virtual.....virtual > > PingPongSingle.... 4.08 ..... 3.71 > > PingPongMulti1.... 6.01997 ..... 5.85999 > > PingPongMulti2.... 19.53 ..... 19.55 > > Hmmm, here's what I get on a 3.2GHz Intel Pentium 4 Windows XP machine > (all numbers in microseconds non-virtual / virtual): > > *** MSVC7.1 *** > > PingPongSingle: 1.06 / 1.07 > PingPongMulti1: 5.41 / 5.43 > PingPongMulti2: 12.34 / 12.26 > > BitMachineCustom3: 0.18 / 0.19 [snip_similar_results] Looks more like what I would expect. BTW: Could I talk you into trading computers? ;) > I.e. no significant difference non-virtual vs. virtual. Two things come > to mind: > 1. At the point where states are destructed (see simple_state.hpp, line > 983) the compiler might know that the type of the pointer matches the > runtime type of the referenced object and therefore call the virtual > destructor non-virtually. However, I'm not sure whether such compiler > magic is implemented in any of the tested platforms nor do I have a clue > whether that's possible at all (it does sound pretty impossible) > 2. There could be little difference on modern processors anyway (as you > have mentioned) > > > Reminds me of the old joke: "I see fine. I just don't understand > > what > > I'm looking at." Two questions: 1) will making the dtorS virtual > > lead > > to adverse consequences I simply haven't encountered yet; > > Given the numbers above I don't see any problems whatsoever. Not on the > tested processors, that is. I can't say whether the picture is the same > for processors used in the embedded world. I may know the answer for some ARM machines soon - I hope. ;) I'll try the BitMachine* tests if I can get the cross compilers to build them. > > and 2) can > > someone help me understand what I did wrong in setting up this test? > > Difficult to say. Could you build with bjam and repeat the test? I followed the instructions to build the examples. Changed to the example directory and ran <<bjam "sTOOLS=gcc">>. I got lazy and only ran the PingPong* progs. Guess I should have mentioned that. %>] Any chance that, in the absence of some future evidence to the contrary, those dtorS can be made virtual in the library? [snip] > Regards, > > -- > Andreas Huber Regards, Dick Bridges "Multithreading is just one damn thing after, before, or simultaneous with another." Scott Meyers and Andrei Alexandrescu

4 5

[futures] Request for Comments
by Thorsten Schuett 25 Aug '05

25 Aug '05

Hi, Hartmut and I wrote a small library which implements futures for C++. I uploaded the code to the boost-sandbox vault. If you find anything odd in there (like e.g. overloading operator T()), you have to blame me, if you find interesting stuff in there, you have to blame Hartmut. The most basic future is simple_future<T>. Its constructor takes a function which returns T and spawns a new thread executing this function. Afterwards you can call operator()() to block until the thread is done and get the result. int slow_fac(int n){ if(n == 0) return 0; if(n == 1) return 1; sleep(1); return n * fac(n - 1); } simple_future<int> f1 = bind(slow_fac, 4); ... cout << f1() << endl; //should print 24 if you have two different implementations of fac and you are only interested in the result of the faster implementation, you can combine two futures using '||'. int fast_fac(int n){ if(n == 0) return 0; if(n == 1) return 1; return n * fac(n - 1); } simple_future<int> f2 = bind(fast_fac, 4); future<int> f3 = f1 || f2; ... cout << f3() << endl; // should print 24 If the result type of the futures given to '||' differ, the result type of the new future is a variant over the types. double fac4(){ return (double)fast_fac(4); } future<variant<int, double> > f4 = f2 || double_[&fac4]; //double_[] creates a simple_future<double> Similarly, the '&&'-operator creates a tuple of the types of the individual futures and blocks until all futures are done. future<tuple<int, double> > f5 = f2 && double_[&fac4]; Warning: I overloaded operator T() for futures to get a nicer syntax. int fac_of_4 = f1; // <- this works! Thorsten

11 37

Boost regression notification (2005-08-25)
by Douglas Gregor 25 Aug '05

25 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-25T15:48:12Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 113 failures in 14 libraries: bind (1) function (10) functional/hash (1) graph (7) iostreams (1) parameter (4) program_options (14) property_map (1) python (23) regex (2) serialization (30) signals (5) thread (13) wave (1) |bind| bind_function_test: borland-5_6_4 |function| allocator_test: borland-5_6_4 contains2_test: borland-5_6_4 contains_test: borland-5_6_4 function_arith_portable: borland-5_6_4 function_n_test: borland-5_6_4 function_ref_portable: borland-5_6_4 mem_fun_portable: borland-5_6_4 stateless_test: borland-5_6_4 std_bind_portable: borland-5_6_4 sum_avg_portable: borland-5_6_4 |functional/hash| point: borland-5_6_4 |graph| graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.1-linux vc-7_1 vc-7_1 vc-7_1 |iostreams| regex_filter_test: borland-5_6_4 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |program_options| cmdline_test: borland-5_6_4 cmdline_test_dll: borland-5_6_4 options_description_test: borland-5_6_4 options_description_test_dll: borland-5_6_4 parsers_test: borland-5_6_4 parsers_test_dll: borland-5_6_4 positional_options_test: borland-5_6_4 positional_options_test_dll: borland-5_6_4 unicode_test: borland-5_6_4 unicode_test_dll: borland-5_6_4 variable_map_test: borland-5_6_4 variable_map_test_dll: borland-5_6_4 winmain: borland-5_6_4 winmain_dll: borland-5_6_4 |property_map| dynamic_properties_test: borland-5_6_4 |python| exec: cw-8_3 cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4.0.1-linux intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 vc-7_1 vc-7_1 |regex| grep: borland-5_6_4 static_mutex_test: borland-5_6_4 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |signals| dead_slot_test: borland-5_6_4 deletion_test: borland-5_6_4 ordering_test: borland-5_6_4 signal_n_test: borland-5_6_4 trackable_test: borland-5_6_4 |thread| test_barrier: borland-5_6_4 test_barrier_lib: borland-5_6_4 test_condition: borland-5_6_4 test_condition_lib: borland-5_6_4 test_mutex: borland-5_6_4 test_mutex_lib: borland-5_6_4 test_once: borland-5_6_4 test_once_lib: borland-5_6_4 test_read_write_mutex: borland-5_6_4 test_read_write_mutex_lib: borland-5_6_4 test_thread: borland-5_6_4 test_thread_lib: borland-5_6_4 test_tss: borland-5_6_4 |wave| testwave: gcc-3.3.6-linux

1 0

Trouble compiling divides.hpp in metamath
by Chris Weed 25 Aug '05

25 Aug '05

Hi, I can't get this to compile. #include "boost/metamath/double.hpp" #include "boost/metamath/double_macros.hpp" #include "boost/mpl/apply.hpp" #include "boost/metamath/double/divides.hpp" int main() { typedef BOOST_DOUBLE(3.3f) xt; typedef BOOST_DOUBLE(2.2f) yt; typedef boost::metamath::detail::divides_double_double<xt,yt>::type zt; zt z; return 0; }; The header file seems to have a macro problem. Here is the error message in g++ 3.4.2 in Linux: In file included from ../boost/metamath/double_macros.hpp:8, from fail.cpp:2: ../boost/metamath/double/double_macros.hpp:140:8: warning: extra tokens at end of #endif directive In file included from ../boost/metamath/double/divides.hpp:13, from fail.cpp:4: ../boost/metamath/double/limits.hpp:58:7: warning: no newline at end of file In file included from fail.cpp:4: ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token In file included from fail.cpp:4: ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:70: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71:1: pasting ")" and "1" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:71: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72:1: pasting ")" and "2" does not give a valid preprocessing token ../boost/metamath/double/divides.hpp:72: error: expected `;' before numeric constant ../boost/metamath/double/divides.hpp:73: error: `result311' was not declared in this scope ../boost/metamath/double/divides.hpp:74: error: `result312' was not declared in this scope ../boost/metamath/double/divides.hpp:78: error: non-constant `<expression error>' cannot be used as template argument ../boost/metamath/double/divides.hpp:78: error: non-constant `<expression error>' cannot be used as template argument ../boost/metamath/double/divides.hpp:78: error: template argument 1 is invalid ../boost/metamath/double/divides.hpp:78: error: `type' does not name a type ../boost/metamath/double/divides.hpp:265:47: warning: no newline at end of file ../boost/metamath/double/divides.hpp: In instantiation of `boost::metamath::detail::divides_double_double<main()::xt, main()::yt>': fail.cpp:10: instantiated from here ../boost/metamath/double/divides.hpp:208: error: no type named `type' in `struct boost::mpl::apply2<boost::metamath::detail::divides_double_double_impl<double, double>, main()::xt, main()::yt>' fail.cpp: In function `int main()': fail.cpp:10: error: expected init-declarator before "zt" fail.cpp:10: error: expected `,' or `;' before "zt" fail.cpp:11: error: `zt' undeclared (first use this function) fail.cpp:11: error: (Each undeclared identifier is reported only once for each function it appears in.) fail.cpp:11: error: expected `;' before "z" Thanks, Chris

2 2

[Boost-bugs] [ boost-Bugs-1272315 ] boost.range and "const char[]".
by SourceForge.net 25 Aug '05

25 Aug '05

Bugs item #1272315, was opened at 2005-08-26 00:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1272315&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sergey Shandar (sergey_shandar) Assigned to: Nobody/Anonymous (nobody) Summary: boost.range and "const char[]". Initial Comment: // Both boost::end(...) and boost::size(...) return wrong values. // Compilers: GCC 3.3.4 and VC 7.1. // A simple example: #include <boost/range/size.hpp> #include <boost/test/minimal.hpp> int test_main(int, char *[]) { const char A[] = "\0A"; BOOST_CHECK(boost::size(A)==2); // failed. return 0; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1272315&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] stlport config patch
by François Dumont 25 Aug '05

25 Aug '05

Sorry for the mistake, here is the patch file. Bests *** stlport.hpp.orig Tue Aug 23 19:06:41 2005 --- stlport.hpp Mon Aug 22 21:15:14 2005 *************** *** 74,80 **** // #define BOOST_HAS_PARTIAL_STD_ALLOCATOR ! #if !defined(_STLP_MEMBER_TEMPLATE_CLASSES) # define BOOST_NO_STD_ALLOCATOR #endif --- 74,80 ---- // #define BOOST_HAS_PARTIAL_STD_ALLOCATOR ! #if !defined(_STLP_MEMBER_TEMPLATE_CLASSES) || defined(_STLP_DONT_SUPPORT_REBIND_MEMBER_TEMPLATE) # define BOOST_NO_STD_ALLOCATOR #endif

2 1

Re: [boost] undefined behaviour in tuple_io.hpp (bug)(patch)
by Martin Bonner 25 Aug '05

25 Aug '05

----Original Message---- From: Jonathan Wakely [mailto:cow@compsoc.man.ac.uk] Sent: 25 August 2005 11:42 To: boost(a)lists.boost.org Subject: Re: [boost] undefined behaviour in tuple_io.hpp (bug)(patch) > Rupert Kittinger wrote: > >> In the tuple_io.hpp header, there seems to be a slight problem in >> extract_and_check_delimiter(). The following snippet is problematic: >> >> char c; >> if (is_delimiter) { >> is >> c; >> if (c!=d) { >> is.setstate(std::ios::failbit); >> } >> } >> >> If c cannot be read because is.eof(), the result of c!=d is >> undefined. > > IMHO the fix is neater as: > > if (is>>c && c!=d) > > basic_ios::operator void*() exists to support this syntax rather than > explicitly testing the state with good(), fail() etc. And IMveryHO, the original patch is neater. This is a religous issue; I think the only sensible approach is to require each individual library to be consistent, and let the library developer / maintainer make the decision. (Apologies if you /are/ the maintainer of Boost.Tuple - I looked, but couldn't find a list of library maintainers.) -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

Link errors with wserialization on MSVC 7.1 (boost 1.33)
by Rodger Bernstein 25 Aug '05

25 Aug '05

I'm using VC 7.1 with MFC and boost 1.33 serialization. I'm getting these link errors. Any one have this problem? I had more link errors with 1.32 I just didn't use Unicode to get around the link errors. But I'd really really like to have Unicode XML files. Linking... libboost_wserialization-vc71-mt-sgd-1_33.lib(xml_wgrammar.obj) : error LNK2005: _iswdigit already defined in libcmtd.lib(_wctype.obj) libboost_wserialization-vc71-mt-sgd-1_33.lib(xml_wgrammar.obj) : error LNK2005: _iswxdigit already defined in libcmtd.lib(_wctype.obj) libboost_wserialization-vc71-mt-sgd-1_33.lib(basic_text_wiprimitive.obj) : error LNK2005: _iswspace already defined in libcmtd.lib(_wctype.obj) libboost_wserialization-vc71-mt-sgd-1_33.lib(xml_wgrammar.obj) : warning LNK4006: _iswdigit already defined in libcmtd.lib(_wctype.obj); second definition ignored libboost_wserialization-vc71-mt-sgd-1_33.lib(xml_wgrammar.obj) : warning LNK4006: _iswxdigit already defined in libcmtd.lib(_wctype.obj); second definition ignored libboost_wserialization-vc71-mt-sgd-1_33.lib(basic_text_wiprimitive.obj) : warning LNK4006: _iswspace already defined in libcmtd.lib(_wctype.obj); second definition ignored

5 5

[iostreams] mapped_file trouble
by Dylan Trotter 25 Aug '05

25 Aug '05

Hi, I just wanted to point out a fairly major flaw with the Windows implementation of memory mapped files. In memory_mapped.cpp on line 205-207 a file mapping is created as follows: ::CreateFileMappingA( pimpl_->handle_, NULL, readonly ? PAGE_READONLY : PAGE_READWRITE, 0, 0, p.path.c_str() ); The problem with this is that if p.path.c_str() has any backslashes in it (very likely given that it's Windows), the call fails. From the MS documentation: "Windows NT: The name can contain any character except the backslash character. Windows Me/98/95: The name can contain any character except the backslash character. The empty string ("") is a valid object name." Also from the documentation: "If this parameter is NULL, the mapping object is created without a name." Given that there's no way to access named memory maps from the boost interface anyway, it seems pointless to name the mapping. My suggestion is to pass in NULL and avoid naming difficulties altogether. Thanks, Dylan Trotter

2 3

[statechart] Problems if I make dtorS virtual?
by BRIDGES Dick 25 Aug '05

25 Aug '05

When compiling the examples (statechart library downloaded from sf 18 Aug), I get the following warnings: <warnings format=edited> /usr/local/boost_1_33_0/boost/statechart/detail/state_base.hpp: In instantiation of `boost::statechart::detail::state_base<std::allocator<void>, boost::statechart::detail::rtti_policy>': /usr/local/boost_1_33_0/boost/statechart/state_machine.hpp:443: instantiated from `boost::statechart::state_machine<Machine, Greeting, std::allocator<void>, boost::statechart::null_exception_translator>' ../main.cpp:12: instantiated from here /usr/local/boost_1_33_0/boost/statechart/detail/state_base.hpp:74: warning: `class boost::statechart::detail::state_base<std::allocator<void>, boost::statechart::detail::rtti_policy>' has virtual functions but non-virtual destructor [snip] /usr/local/boost_1_33_0/boost/statechart/simple_state.hpp:189: instantiated from `boost::statechart::simple_state<Greeting, Machine, boost::mpl::list<mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, has_no_history>' ../main.cpp:14: instantiated from here /usr/local/boost_1_33_0/boost/statechart/detail/leaf_state.hpp:27: warning: `class boost::statechart::detail::leaf_state<std::allocator<void>, boost::statechart::detail::rtti_policy>' has virtual functions but non-virtual destructor </warnings> I changed ~simple_State() and ~state_base() to virtual and the warnings disappeared. However, ~state_base() contains the following annotation: // This destructor is not virtual for performance reasons. The library // ensures that a state object is never deleted through a state_base // pointer but only through a pointer to the most-derived type. ~state_base() {} As a quick, not-definitive check, I built PingPong* with both the virtual and non-virtual dtorS using gcc 3.4.2 on an old i386-redhat-linux machine. The results appear to be the reverse of what I would expect, but I checked to verify that I have the correct result/config correspendence. ..................non-virtual.....virtual PingPongSingle.... 4.08 ..... 3.71 PingPongMulti1.... 6.01997 ..... 5.85999 PingPongMulti2.... 19.53 ..... 19.55 Reminds me of the old joke: "I see fine. I just don't understand what I'm looking at." Two questions: 1) will making the dtorS virtual lead to adverse consequences I simply haven't encountered yet; and 2) can someone help me understand what I did wrong in setting up this test? <extra_credit ot=true my_understanding=faulty> With a well-developed pipelined architecture and a reasonably rich set of addressing operations, shouldn't there be little or no difference between direct and indirect access times - given that the bookeeping normally associated with virtual classes has already been paid for? </extra_credit> Thanks to any/all for help with this. Regards, Dick Bridges "Multithreading is just one damn thing after, before, or simultaneous with another." Scott Meyers and Andrei Alexandrescu

3 2

BOOST_PP_STRINGIZE with MSVC 7.1 broken in 1.33.0 library version
by Sergey Skorniakov 24 Aug '05

24 Aug '05

Test code: #define AAA const char bbb[] = BOOST_PP_STRINGIZE(prefix BOOST_PP_COMMA() postfix) AAA; Preprocessing of such a code is accompanied by warning C4002: too many actual parameters for macro 'BOOST_PP_STRINGIZE_I'. With 1.32.0 library version variable bbb value was "prefix, postfix". With new version it is just "prefix".

2 1

Boost regression notification (2005-08-24)
by Douglas Gregor 24 Aug '05

24 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-24T15:46:17Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 119 failures in 14 libraries: bind (1) function (10) functional/hash (1) graph (13) iostreams (1) parameter (4) program_options (14) property_map (1) python (23) regex (2) serialization (30) signals (5) thread (13) wave (1) |bind| bind_function_test: borland-5_6_4 |function| allocator_test: borland-5_6_4 contains2_test: borland-5_6_4 contains_test: borland-5_6_4 function_arith_portable: borland-5_6_4 function_n_test: borland-5_6_4 function_ref_portable: borland-5_6_4 mem_fun_portable: borland-5_6_4 stateless_test: borland-5_6_4 std_bind_portable: borland-5_6_4 sum_avg_portable: borland-5_6_4 |functional/hash| point: borland-5_6_4 |graph| cuthill_mckee_ordering: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux dfs: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.1-linux vc-7_1 vc-7_1 vc-7_1 king_ordering: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |iostreams| regex_filter_test: borland-5_6_4 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |program_options| cmdline_test: borland-5_6_4 cmdline_test_dll: borland-5_6_4 options_description_test: borland-5_6_4 options_description_test_dll: borland-5_6_4 parsers_test: borland-5_6_4 parsers_test_dll: borland-5_6_4 positional_options_test: borland-5_6_4 positional_options_test_dll: borland-5_6_4 unicode_test: borland-5_6_4 unicode_test_dll: borland-5_6_4 variable_map_test: borland-5_6_4 variable_map_test_dll: borland-5_6_4 winmain: borland-5_6_4 winmain_dll: borland-5_6_4 |property_map| dynamic_properties_test: borland-5_6_4 |python| exec: cw-8_3 cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4.0.1-linux intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 vc-7_1 vc-7_1 |regex| grep: borland-5_6_4 static_mutex_test: borland-5_6_4 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |signals| dead_slot_test: borland-5_6_4 deletion_test: borland-5_6_4 ordering_test: borland-5_6_4 signal_n_test: borland-5_6_4 trackable_test: borland-5_6_4 |thread| test_barrier: borland-5_6_4 test_barrier_lib: borland-5_6_4 test_condition: borland-5_6_4 test_condition_lib: borland-5_6_4 test_mutex: borland-5_6_4 test_mutex_lib: borland-5_6_4 test_once: borland-5_6_4 test_once_lib: borland-5_6_4 test_read_write_mutex: borland-5_6_4 test_read_write_mutex_lib: borland-5_6_4 test_thread: borland-5_6_4 test_thread_lib: borland-5_6_4 test_tss: borland-5_6_4 |wave| testwave: gcc-3.3.6-linux

2 1

warning C4275 with VC++ (non dll-interface class...) (again)
by Luke Elliott 24 Aug '05

24 Aug '05

Hi I was wondering why boost libraries don't do something like: class positional_options_description { public: BOOST_PROGRAM_OPTIONS_DECL positional_options_description(); BOOST_PROGRAM_OPTIONS_DECL void add(const char* name, int max_count); ... }; instead of: class BOOST_PROGRAM_OPTIONS_DECL positional_options_description { public: max_count); ... }; in order to remove the irritating C4275 warning? i.e. only declspec public, protected members (and any private members invoked from inline methods). From searching the archives it looks like the usual suggestion is to disable the warning, I just wondered if the above had been considered (and if rejected, why)? Is it because this behaviour doesn't work with win32 builds of GCC if using the declspec functionality (instead of the export-all)? Thanks for any insight. Luke Elliott.

5 10

[TypeTraits] aligned_storage & type_with_alignment docs swapped
by Kim Barrett 24 Aug '05

24 Aug '05

In the type_traits library, the documentation for aligned_storage and type_with_alignment seem to be somewhat swapped. Certainly the documentation doesn't match the implementation. Swapping the documentation would make the names make much more sense wrto their documentation too.

2 1

Re: [boost] Questions on Serialization
by Martin Bonner 24 Aug '05

24 Aug '05

----Original Message---- From: Robert Ramey [mailto:ramey@rrsd.com] Sent: 24 August 2005 16:19 To: boost(a)lists.boost.org Subject: Re: [boost] Questions on Serialization > I believe I've fixed this in the latest CVS. Let me know if its still > broken. > > Robert Ramey > >> Add Firefox 1.0.6 on Windows XP to the list of problem browsers. >> >> Note that Internet Explorer 6.0.2900 on Windows XP DOES behave >> correctly. Sadly, http://www.boost.org/libs/serialization/doc/index.html is still broken - but that is probably because it isn't showing the latest CVS version! Do you have a URL where I can look at it (or instructions on what to download, so I can view it from a local copy - be gentle, I've never used CVS!). -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

Re: [boost] Questions on Serialization
by Martin Bonner 24 Aug '05

24 Aug '05

----Original Message---- From: Christoph Ludwig [mailto:cludwig@cdc.informatik.tu-darmstadt.de] Sent: 23 August 2005 20:34 To: boost(a)lists.boost.org Subject: Re: [boost] Questions on Serialization > On Tue, Aug 23, 2005 at 08:44:15AM -0700, Robert Ramey wrote: >> Daryle Walker wrote: >>> Also, the Contents entries from "void_cast" to >>> "BOOST_STATIC_WARNING" need to be raised a level so they don't look >>> like child entries for "extended_type_info". >> >> It the current version of the manual I see: >> >> Miscelenaeous >> extended_type_info >> Motivation >> Runtime Interface >> Requirements >> Models >> void_cast >> utf8_code_cvt >> BOOST_STRONG_TYPE >> state_saver >> Datafow Iterators >> smart_cast >> BOOST_STATIC_WARNING >> Rationale >> >> That is, void_cast is not show as part of extended_type_info. > > I am sorry, but with Konqueror 3.4.2 and Firefox 1.0.6 on a Linux > machine void_cast through BOOST_STATIC_WARNING appear all one level > *under* extended_type_info. I am going to attach screenshots which > exhibit the problem. > <AOL>Me too</AOL> Add Firefox 1.0.6 on Windows XP to the list of problem browsers. Note that Internet Explorer 6.0.2900 on Windows XP DOES behave correctly. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1

[minmax] A link needs to be corrected
by Daryle Walker 24 Aug '05

24 Aug '05

This is for the top page for the min-max algorithms at <http://www.boost.org/libs/algorithm/minmax/>. The link reference for Alexandrescu's paper about std::min/max problems is no longer active. I think the new link is <http://www.cuj.com/documents/cujcexp1904alexandr/> (which got redirected to <http://www.cuj.com/documents/s=7996/cujcexp1904alexandr/alexandr.htm> on my browser). -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

Updated version history 3rd time
by Daryle Walker 24 Aug '05

24 Aug '05

I undid the last two changes I did, because I realized I didn't have to peruse the Mail archives for changes; I could use <http://www.archive.org> instead. Now I updated down to 1999-Sep-1. I still have to look at the old e-mails for earlier results. (I think Beman did all the pre-CVS website edits back then, so if he has a master list, then I don't have to guesstimate releases from reading _every_ old e-mail.) Between my first two changes and the redo, Rene Rivera changed the CSS to fix the table. The new listing doesn't use a table any longer, but the quick glimpse I had of the change (before I paved it over) didn't show any change to the table. Instead of adding CSS attributes to restore table functionality, maybe we should change whatever CSS took it away in the first place. Why was the "...remainder..." paragraph moved inward? I deliberately did _not_ have it within the history list. And what's with the extra "-body" and/or "-DIGIT" sections? Are they for visual CSS layout, because they seem superfluous semantically? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 2

[multi_index][rfc] random access indices
by Joaquín Mª López Muñoz 24 Aug '05

24 Aug '05

Hello all, I'm considering whether to add to Boost.MultiIndex a new type of indices with random access semantics, somewhat similar to std::vectors. As I wouldn't like to keep adding things to the library without some actual feedback as of its suitability, I've written some preliminary notes about how these indices could look like, located at: http://195.235.93.150/rnd_indices_spec.html I'm very interested in knowing your opinion about this stuff, ways of improving the spec, and most of all whether it is really an interesting thing to have in Boost.MultiIndex 1.34. Please go ahead and throw your 2 cents. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

stlport config patch
by François Dumont 24 Aug '05

24 Aug '05

Hello In order to prepare STLport 5.0 release here is a patch for the stlport.hpp boost config file. It is really limited, only introduction of a new macro to distinguish between different kind of support of nested template classes. It is backward compatible with previous STLport version. Bests // (C) Copyright John Maddock 2001 - 2002. // (C) Copyright Darin Adler 2001. // (C) Copyright Jens Maurer 2001. // Use, modification and distribution are subject to 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) // See http://www.boost.org for most recent version. // STLPort standard library config: #if !defined(__SGI_STL_PORT) && !defined(_STLPORT_VERSION) # include <utility> # if !defined(__SGI_STL_PORT) && !defined(_STLPORT_VERSION) # error "This is not STLPort!" # endif #endif // // __STL_STATIC_CONST_INIT_BUG implies BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS // for versions prior to 4.1(beta) // #if (defined(__STL_STATIC_CONST_INIT_BUG) || defined(_STLP_STATIC_CONST_INIT_BUG)) && (__SGI_STL_PORT <= 0x400) # define BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS #endif // // If STLport thinks that there is no partial specialisation, then there is no // std::iterator traits: // #if !(defined(_STLP_CLASS_PARTIAL_SPECIALIZATION) || defined(__STL_CLASS_PARTIAL_SPECIALIZATION)) # define BOOST_NO_STD_ITERATOR_TRAITS #endif // // No new style iostreams on GCC without STLport's iostreams enabled: // #if (defined(__GNUC__) && (__GNUC__ < 3)) && !(defined(__SGI_STL_OWN_IOSTREAMS) || defined(_STLP_OWN_IOSTREAMS)) # define BOOST_NO_STRINGSTREAM #endif // // No new iostreams implies no std::locale, and no std::stringstream: // #if defined(__STL_NO_IOSTREAMS) || defined(__STL_NO_NEW_IOSTREAMS) || defined(_STLP_NO_IOSTREAMS) || defined(_STLP_NO_NEW_IOSTREAMS) # define BOOST_NO_STD_LOCALE # define BOOST_NO_STRINGSTREAM #endif // // If the streams are not native, and we have a "using ::x" compiler bug // then the io stream facets are not available in namespace std:: // #ifdef _STLPORT_VERSION # if !defined(_STLP_OWN_IOSTREAMS) && defined(_STLP_USE_NAMESPACES) && defined(BOOST_NO_USING_TEMPLATE) && !defined(__BORLANDC__) # define BOOST_NO_STD_LOCALE # endif #else # if !defined(__SGI_STL_OWN_IOSTREAMS) && defined(__STL_USE_NAMESPACES) && defined(BOOST_NO_USING_TEMPLATE) && !defined(__BORLANDC__) # define BOOST_NO_STD_LOCALE # endif #endif // // Without member template support enabled, their are no template // iterate constructors, and no std::allocator: // #if !(defined(__STL_MEMBER_TEMPLATES) || defined(_STLP_MEMBER_TEMPLATES)) # define BOOST_NO_TEMPLATED_ITERATOR_CONSTRUCTORS # define BOOST_NO_STD_ALLOCATOR #endif // // however we always have at least a partial allocator: // #define BOOST_HAS_PARTIAL_STD_ALLOCATOR #if !defined(_STLP_MEMBER_TEMPLATE_CLASSES) # define BOOST_NO_STD_ALLOCATOR #endif #if defined(_STLP_NO_MEMBER_TEMPLATE_KEYWORD) && defined(BOOST_MSVC) && (BOOST_MSVC <= 1300) # define BOOST_NO_STD_ALLOCATOR #endif // // If STLport thinks there is no wchar_t at all, then we have to disable // the support for the relevant specilazations of std:: templates. // #if !defined(_STLP_HAS_WCHAR_T) && !defined(_STLP_WCHAR_T_IS_USHORT) # ifndef BOOST_NO_STD_WSTRING # define BOOST_NO_STD_WSTRING # endif # ifndef BOOST_NO_STD_WSTREAMBUF # define BOOST_NO_STD_WSTREAMBUF # endif #endif // // We always have SGI style hash_set, hash_map, and slist: // #define BOOST_HAS_HASH #define BOOST_HAS_SLIST // // STLport does a good job of importing names into namespace std::, // but doesn't always get them all, define BOOST_NO_STDC_NAMESPACE, since our // workaround does not conflict with STLports: // // // Harold Howe says: // Borland switched to STLport in BCB6. Defining BOOST_NO_STDC_NAMESPACE with // BCB6 does cause problems. If we detect C++ Builder, then don't define // BOOST_NO_STDC_NAMESPACE // #if !defined(__BORLANDC__) && !defined(__DMC__) // // If STLport is using it's own namespace, and the real names are in // the global namespace, then we duplicate STLport's using declarations // (by defining BOOST_NO_STDC_NAMESPACE), we do this because STLport doesn't // necessarily import all the names we need into namespace std:: // # if (defined(__STL_IMPORT_VENDOR_CSTD) \ || defined(__STL_USE_OWN_NAMESPACE) \ || defined(_STLP_IMPORT_VENDOR_CSTD) \ || defined(_STLP_USE_OWN_NAMESPACE)) \ && (defined(__STL_VENDOR_GLOBAL_CSTD) || defined (_STLP_VENDOR_GLOBAL_CSTD)) # define BOOST_NO_STDC_NAMESPACE # define BOOST_NO_EXCEPTION_STD_NAMESPACE # endif #elif defined(__BORLANDC__) && __BORLANDC__ < 0x560 // STLport doesn't import std::abs correctly: #include <stdlib.h> namespace std { using ::abs; } // and strcmp/strcpy don't get imported either ('cos they are macros) #include <string.h> #ifdef strcpy # undef strcpy #endif #ifdef strcmp # undef strcmp #endif #ifdef _STLP_VENDOR_CSTD namespace std{ using _STLP_VENDOR_CSTD::strcmp; using _STLP_VENDOR_CSTD::strcpy; } #endif #endif // // std::use_facet may be non-standard, uses a class instead: // #if defined(__STL_NO_EXPLICIT_FUNCTION_TMPL_ARGS) || defined(_STLP_NO_EXPLICIT_FUNCTION_TMPL_ARGS) # define BOOST_NO_STD_USE_FACET # define BOOST_HAS_STLP_USE_FACET #endif // // If STLport thinks there are no wide functions, <cwchar> etc. is not working; but // only if BOOST_NO_STDC_NAMESPACE is not defined (if it is then we do the import // into std:: ourselves). // #if defined(_STLP_NO_NATIVE_WIDE_FUNCTIONS) && !defined(BOOST_NO_STDC_NAMESPACE) # define BOOST_NO_CWCHAR # define BOOST_NO_CWCTYPE #endif // // If STLport for some reason was configured so that it thinks that wchar_t // is not an intrinsic type, then we have to disable the support for it as // well (we would be missing required specializations otherwise). // #if !defined( _STLP_HAS_WCHAR_T) || defined(_STLP_WCHAR_T_IS_USHORT) # undef BOOST_NO_INTRINSIC_WCHAR_T # define BOOST_NO_INTRINSIC_WCHAR_T #endif // // Borland ships a version of STLport with C++ Builder 6 that lacks // hashtables and the like: // #if defined(__BORLANDC__) && (__BORLANDC__ == 0x560) # undef BOOST_HAS_HASH #endif // // gcc-2.95.3/STLPort does not like the using declarations we use to get ADL with std::min/max // #if defined(__GNUC__) && (__GNUC__ < 3) # include <algorithm> // for std::min and std::max # define BOOST_USING_STD_MIN() ((void)0) # define BOOST_USING_STD_MAX() ((void)0) namespace boost { using std::min; using std::max; } #endif #define BOOST_STDLIB "STLPort standard library version " BOOST_STRINGIZE(__SGI_STL_PORT)

2 1

Re: [boost] shared_ptr under OS X
by Steve Ramsey 24 Aug '05

24 Aug '05

On Sun, 21 Aug 2005, at 16:56, Howard Hinnant wrote: > On Aug 21, 2005, at 4:28 PM, Steve Ramsey wrote: > >> I've had a number of programs crash after recompiling with the 1.33.0 >> release and eventually tracked the problems down to shared_ptr, >> specifically the atomic_decrement function provided in >> sp_counted_base_cw_ppc.hpp. > > Try these: <snip> That seems to have done the trick. Presumably the return value was never making it out of the decrement function, eventually causing double deletes when circumstances were right. Thanks for the quick response; I'll send along another message if this turns out not to be a complete solution, though I don't foresee problems. Steve

6 8

shared_ptr under OS X
by Steve Ramsey 24 Aug '05

24 Aug '05

I've had a number of programs crash after recompiling with the 1.33.0 release and eventually tracked the problems down to shared_ptr, specifically the atomic_decrement function provided in sp_counted_base_cw_ppc.hpp. So far, I've only noted problems on a dual processor G5 running OS X 10.4.2, most often when a shared_ptr created as a temporary object goes out of scope and the destructor gets called. I was able to eliminate the problem by replacing the hand-rolled asm atomic routines with equivalent system routines from CarbonCore/DriverSychronization.h (except for atomic_conditional_increment, which I don't have an equivalent for). I'm not a PPC asm guru, or even a threading/mp guru, so I haven't been able to properly evaluate the boost functions. I do know that I was getting access exceptions upon execution of the sync instruction in the affected areas of the code. This was using CodeWarrior 9.5 to compile, with optimizations disabled, but inlining activated (the decrement was being inlined). In my (limited) research into the problem, I haven't been able to find any good examples of hand-rolled atomic ops that are mp-savvy, though I found plenty of dire warnings against making the attempt and numerous recommendations to use either the kernel-level or Carbon-level routines instead, depending on context. What additional information can I provide and who can I provide it to? I haven't spent enough time on this to conclude definitively that the problem is in the boost source, as it might be CodeWarrior's munging of it that causes the problem. It's unlikely to be an issue in my code, as I've seen the issue pop up in relation to several different constructs, all of which appear to be legal C++ to me. I won't be pursuing this independently, as the workaround I've found solves my immediate problem and lets me get back to work after killing a couple of days playing around with it. Steve

7 10

missing stdio.h include in thread lib
by François Dumont 23 Aug '05

23 Aug '05

Hello I am submitting once again this patch for the thread library as the issue still exist with 1.33.0. When building boost with msvc-stlport toolset the _snprintf function used at read_write_mutex.cpp:151 is undefined as stdio.h has not been included next to tchar.h include at line 38. In order to have this patch apply this time I have study why _snprintf _is_ defined when using msvc toolset. The conclusion is that the definition comes from the <utility> include in boost/config/select_stdlib_config.hpp which is used to guess what is the std lib. In VC6 utility header include a lot of headers indirectly like cstring, cwchar, xstddef and cstdio which give _snprintf. The STLport utility try to limit the includes, maybe it shouldn't ;-) For your info I discovered an other issue, some guy from boost will have perhaps to work on it. I have only check it with VC6, don't know if it is reproductible with .NET 2002 or 2003. Even if you set your INCLUDE env variable to use the latest PSDK rather than the one integrated in VC6 you are still include of windows.h from boost during build process are still referencing the VC6 windows.h rather than the one of the latest SDK. I thought it was coming from the #include "windows.h" that exists in many VC6 headers but it is not the case. Bests *** read_write_mutex.cpp.orig Tue Aug 23 07:46:00 2005 --- read_write_mutex.cpp Tue Aug 23 19:02:08 2005 *************** *** 36,41 **** --- 36,42 ---- #ifdef BOOST_HAS_WINTHREADS # include <windows.h> # include <tchar.h> + # include <stdio.h> # if !((_WIN32_WINNT >= 0x0400) || (_WIN32_WINDOWS > 0x0400)) inline bool IsDebuggerPresent(void)

1 0

Boost regression notification (2005-08-23)
by Douglas Gregor 23 Aug '05

23 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-23T14:59:18Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 67 failures in 6 libraries: functional/hash (4) graph (14) parameter (4) python (22) serialization (22) wave (1) |functional/hash| point: borland-5_6_4 portable: msvc vc-6_5 vc-6_5-stlport |graph| cuthill_mckee_ordering: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux dfs: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux vc-7_1 vc-7_1 vc-7_1 king_ordering: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |python| exec: cw-8_3 cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 vc-7_1 vc-7_1 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_derived_class_xml_warchive: vc-7_1 test_derived_class_xml_warchive_dll: vc-7_1 test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |wave| testwave: gcc-3.3.6-linux

1 0

boost dll versions
by Neal Becker 23 Aug '05

23 Aug '05

I think it is a bit unfortunate that we don't have a system to determine whether boost updates break existing api's. The usual process is that, for example, suppose we have libboost.so.1.33.0 Let's assign this soname libboost.so.1. Then a symlink is created libboost.so.1 -> libboost.so.1.33.0. Now if a bugfix comes out that does not change the api, be can have libboost.so.1.33.1, which also has soname libboost.so.1, and then symlink: libboost.so.1 -> libboost.so.1.33.1 OK, so that's the background. AFAICT, we (boost) don't have any way to tell if a new release breaks existing api, and whether to up the version. I think that is unfortunate. I don't really know what to do about it, though.

11 24

[Boost-bugs] [ boost-Bugs-1267229 ] Cannot compile on Sparc/NetBSD: redefinition of `struct
by SourceForge.net 23 Aug '05

23 Aug '05

Bugs item #1267229, was opened at 2005-08-23 17:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1267229&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephane Bortzmeyer (bortz) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot compile on Sparc/NetBSD: redefinition of `struct Initial Comment: I cannot compile Boost on my UltraSparc (64 bits) machine running NetBSD: ...found 4111 targets... ...updating 325 targets... gcc-C++-action /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/build/bin/boost/libs/dat e_time/build/libboost_date_time.so/gcc/release/shared-linkable-true/threading-multi/gr eg_month.o In file included from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/type_traits /intrinsics.hpp:39, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/type_traits /is_union.hpp:16, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/type_traits /is_class.hpp:14, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/detail/indi rect_traits.hpp:10, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/iterator/de tail/facade_iterator_category.hpp:27, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/iterator/it erator_facade.hpp:14, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/iterator/it erator_adaptor.hpp:15, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/token_itera tor.hpp:21, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/tokenizer.h pp:20, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/date_time/d ate_parsing.hpp:12, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/date_time/g regorian/parsers.hpp:13, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/date_time/g regorian/greg_facet.hpp:14, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/libs/date_time/sr c/gregorian/greg_month.cpp:15: /usr/include/g++/type_traits.h:55: error: redefinition of `struct __true_type' /usr/include/g++/bits/type_traits.h:90: error: previous definition of `struct __true_type' /usr/include/g++/type_traits.h:58: error: redefinition of `struct __false_type' /usr/include/g++/bits/type_traits.h:91: error: previous definition of `struct __false_type' /usr/include/g++/type_traits.h:62: error: redefinition of `struct __type_traits<_Tp>' /usr/include/g++/bits/type_traits.h:94: error: previous definition of `struct __type_traits<_Tp>' /usr/include/g++/type_traits.h:96: error: redefinition of `struct __type_traits<bool>' /usr/include/g++/bits/type_traits.h:123: error: previous definition of `struct __type_traits<bool>' /usr/include/g++/type_traits.h:106: error: redefinition of `struct __type_traits<char>' NetBSD 2.0.1 gcc: % g++ -v Using built-in specs. Configured with: /home/nick/work/netbsd/src/tools/gcc/../../gnu/dist/gcc/configure --enable-long-long --disable-multilib --enable-threads --disable-symvers --build=i386-unknown-netbsdelf --host=sparc64--netbsd --target=sparc64--netbsd Thread model: posix gcc version 3.3.3 (NetBSD nb3 20040520) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1267229&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Issues with compile time double [metamath]
by Chris Weed 23 Aug '05

23 Aug '05

Hi, In order to use plus_double_double<a,b>::type I needed to make the following two changes to boost/metamath/double/detail/shift.hpp Change line 72 to: shift_integral_impl<shift_sign_overflow<Amount>::value>::template apply<T,Value,Amount> Change line 113 to: struct shift_mantissa : shift_mantissa_impl<shift_sign<Amount>::value>::template apply<Mantissa,Amount> I am using gcc 4.0 in debian. Chris

2 1

[regex] broken match_results functions for Intel 8.0
by Richard Hadsell 23 Aug '05

23 Aug '05

After upgrading to Boost 1.33.0 I found a problem with my code when built for Intel 8.0 on Linux. The problem doesn't show up with g++. I reduced it to a simple test case. With Intel 8.0 it compiles but fails to link the executable, complaining that it can't find the 'position' and 'str' functions. Note that it does find the 'length' function. I built the library with these options, and there were no errors: bjam -sTOOLS=intel-linux -sINTEL_PATH=/usr/local/intel/compiler80/ia32 --with-python-root=/usr --without-iostreams --without-python --without-serialization --stagedir=stage -sBUILD="debug release <threading>single" stage This copy of the console log documents the test case, working with g++ and failing to link with icpc: % cat RegexIntelLinuxBug.cc #include <iostream> #include <boost/regex.hpp> int main (int argc, const char * const *argv) { static const boost::regex pat ("[[:alpha:]]+"); const char str[] = "xyzzy"; boost::cmatch what; if (! boost::regex_search (str, what, pat)) std::cout << "not found" << std::endl; else { std::cout << "found '" << what.str () << "': " << what.length () << " characters at position " << what.position () << std::endl; } return 0; } % g++ -I/u/hadsell/cgi/Include/libboost -c -o RegexIntelLinuxBug.o RegexIntelLinuxBug.cc % g++ -o RegexIntelLinuxBug RegexIntelLinuxBug.o /u/hadsell/cgi/Lib/LINUX_X86FC3/libboostrgx.a % RegexIntelLinuxBug found 'xyzzy': 5 characters at position 0 % icpc -V Intel(R) C++ Compiler for 32-bit applications, Version 8.0 Build 20040304Z Package ID: l_cc_pc_8.0.058_pe061 Copyright (C) 1985-2004 Intel Corporation. All rights reserved. icpc: Command line error: no files specified; for help type "icpc -help" % icpc -I/u/hadsell/cgi/Include/libboost -c -o RegexIntelLinuxBug.o RegexIntelLinuxBug.cc % icpc -o RegexIntelLinuxBug RegexIntelLinuxBug.o /u/hadsell/cgi/Lib/LINUX_X86/libboostrgx.a RegexIntelLinuxBug.o(.text+0x1b1): In function `main': : undefined reference to `boost::match_results<char const*, std::allocator<boost::sub_match<char const*> > >::str(int) const' RegexIntelLinuxBug.o(.text+0x1fe): In function `main': : undefined reference to `boost::match_results<char const*, std::allocator<boost::sub_match<char const*> > >::position(unsigned) const' -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

3 6

[Boost-bugs] [ boost-Bugs-1266877 ] multitoken broken in program_options 1.33
by SourceForge.net 23 Aug '05

23 Aug '05

Bugs item #1266877, was opened at 2005-08-23 10:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1266877&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: config Group: None Status: Open Resolution: None Priority: 5 Submitted By: Drazen Dotlic (rutavibaja) Assigned to: John Maddock (johnmaddock) Summary: multitoken broken in program_options 1.33 Initial Comment: Due to the changes in the parser, multitoken is broken in program_options [boost 1.33]. Looking at the code it is relatively clear why - the parser is too "greedy" and eats up all the options following the multitoken one without checking when to stop (for example, it should stop once it encounters another option/switch). If this functionality is to be deprecated as hinted in some mails on the mailing list, it should be removed from the public interface. If not, I guess it should be fixed :) The way to test it is to have a multitoken switch appear _in the middle_ of the command line (definitely not at the end) which should then simply eat all options to the right of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1266877&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Updated version history again
by Daryle Walker 22 Aug '05

22 Aug '05

Added notes for 1.10.3, the first numbered release, to "version_history.html". Should be in CVS and the web site. The CSS needs to be fixed. I attached a picture of how it looks on my system (Safari 2.0 on Mac OS X 10.4.2). The CSS neutralized my table's centering and made TH tags look the same as TD tags. I originally had the information as a DL list, but the CSS gave the DT and DD tags the same indentation amount, so that needs to be fixed too. Finally, there needs to be a gap between the last history item and the "...And the remainder are lost to the mists of time (for now, anyway)...." paragraph that is outside the history list. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

Purpose adding a scope guard classes to the Boost library
by Andrey Semashev 22 Aug '05

22 Aug '05

Sometimes it is very useful to register some postponed actions regardless of some part of the program result (a function, for example). Smart pointers are obvious example of such actions (namely, freeing resources) and in fact are a special case of so called scope guards. Guards may be especially useful in heavilly-logical code with multiple (maybe folded into each other) checks or in code using exceptions. As a simple example, suppose we have a logging system that may trace function calls in our program. The easiest and obvious way to implement such functionality is to create some object in the beginning of each function to be traced. This object will add the function to the logger on its construction and remove it on destruction. Another application is resolving circular calling dependency issues which tend to come up in rather complex projects. The following example illustrates the problem: class A; // The objects of class B are managed by object of class A class B { public: void execute(A* pA, int n); }; // The object of main class A manages some other objects of class B class A { // Some internal data, which is provided to the managed objects std::set< int > m_Data; public: // The entrance method, called from somewhere outside void process(B* pB) { // Imagine we have some real processing here and m_Data is not empty pB->execute(this, *m_Data.begin()); // Here we cannot be absolutely sure if m_Data still contains the element we passed in line above } void remove(int n) { m_Data.erase(n); } }; void B::execute(A* pA, int n) { if (n > 10) pA->remove(n); } The case above is usually fixed by using some kind of state variables or flags or, in more complex cases, some stacks of postprocessing. I.e. in A::remove we don't actually erase the element but schedule some action to perform when control returns to A::process. This can easily be done by enqueued functors or scope guards. In some cases the latter are simplier to use and more laconic. I purpose to add a generalized scope guard classes to the Boost library. I have a rather simple but flexible implementation of such classes (I've attached the sources). Since I'm new here, I don't really know if they conform some source code conventions in Boost (if any), but if they don't - please, let me know. Few general words about the implementation. There are two general guard classes: leaving_scope_guard and scope_guard. The first one calls a functor (boost::function is used) with no arguments on its destruction if it is armed. The second class extends the first one by calling another functor on its construction (this is not a functionality of real necessity, but it allows to semantically group paired functions invocation, see the example above). A guard once created may be armed or disarmed later in thÕ program, but the armed status applies only to the destructing functor invoking (the constructing one is controlled via initial status of the guard which is passed in guard constructor arguments). The flexibility of implementation is in ability to change the functors invoking policy. In the simpliest case it is a direct invoking (all template parameters by default), but there is a policy with exception catching support. See the example: struct my_exception : public std::exception { /* ... */ }; void guarded_foo(int n, const char* p); // throws bad_cast, bad_alloc and my_exception // This is the class of the exception handler object struct CHandler { void on_exception(std::bad_cast& e) throw() { std::cout << "on_exception called, bad_cast caught" << std::endl; } void on_exception(std::bad_alloc& e) throw() { std::cout << "on_exception called, bad_alloc caught" << std::endl; } void on_exception(my_exception& e) throw() { std::cout << "on_exception called, my_exception caught" << std::endl; } }; void foo(int n) { leaving_scope_guard< guard::with_catcher< // Indicate that we're expecting some exceptions to be thrown by guarded_foo CHandler, // This is the class, which object is to process exceptions caught guard::exceptions< std::bad_cast, std::bad_alloc, my_exception >, // Exceptions to be caught (up to 10 exception types supported) boost::shared_ptr< CHandler > // An optional parameter describes the way the pointer to CHandler object should be stored. The default value would be CHandler*. > > guard(boost::bind(&guarded_foo, n, "called from foo"), boost::shared_ptr< CHandler >(new CHandler)); // Guard object // ... } There also are macroses defined for setting anonymous scope guards when there is no need for arming or disarming it. As for compatibility, I successfully compiled it on VC 7.1, ICC 9.0 and GCC 3.4.4 (MinGW version). I don 't think it will compile on VC 6 since explicit template function instantiation is used there which is not supported by the compiler, but I think it is possible to work around it. Besides that I don't think there should be any problems for other compilers. Any suggestions are welcome. begin 666 scope_guard.h M+RHA#0H@*B!<9FEL92 @('-C;W!E7V=U87)D+F@-"B J(%QA=71H;W(@4V5M M87-H978@06YD<F5Y#0H@*B!<9&%T92 @(#(U+C W+C(P,#4-"B J( T*("H@ M7&)R:65F("!'96YE<F%L:7IE9"!S8V]P92!G=6%R9"!D96-L87)A=&EO;@T* M("H@#0H@*B\-"@T*(VEF;F1E9B!?7U-#3U!%1U5!4D1?2%]?#0HC9&5F:6YE M(%]?4T-/4$5'54%21%](7U\-"@T*(VEN8VQU9&4@(F)O;W-T+V9U;F-T:6]N M+V9U;F-T:6]N,"YH<' B#0HC:6YC;'5D92 B8F]O<W0O;F]N8V]P>6%B;&4N M:'!P(@T*(VEN8VQU9&4@(F)O;W-T+W1Y<&5?=')A:71S+VES7V)A<V5?86YD M7V1E<FEV960N:'!P(@T*(VEN8VQU9&4@(F)O;W-T+W1Y<&5?=')A:71S+VES M7W!O:6YT97(N:'!P(@T*#0HO+R!-86-R;W-E<R!F;W(@9V5N97)A=&EN9R!R M96=U;&%R(&-O9&4-"B-D969I;F4@7U]30T]015]'54%21%]%3E5-15)!5$5? M34%#4D]?*&EM<&Q?;6%C<F\I7 T*"6EM<&Q?;6%C<F\H,2E<#0H):6UP;%]M M86-R;R@R*5P-"@EI;7!L7VUA8W)O*#,I7 T*"6EM<&Q?;6%C<F\H-"E<#0H) M:6UP;%]M86-R;R@U*5P-"@EI;7!L7VUA8W)O*#8I7 T*"6EM<&Q?;6%C<F\H M-RE<#0H):6UP;%]M86-R;R@X*5P-"@EI;7!L7VUA8W)O*#DI#0H-"B-D969I M;F4@7U]30T]015]'54%21%]%3E5-15)!5$5?34%#4D\H:6UP;%]M86-R;RE< M#0H):6UP;%]M86-R;R@P*5P-"@E?7U-#3U!%7T=505)$7T5.54U%4D%415]- M04-23U\H:6UP;%]M86-R;RD-"@T*(V1E9FEN92!?7U-#3U!%7T=505)$7TY5 M3$Q465!%4RAI=&5R*2!S=')U8W0@;G5L;'1Y<&4C(VET97(@.B!P=6)L:6,@ M;G5L;'1Y<&4@>WT[#0HC9&5F:6YE(%]?4T-/4$5?1U5!4D1?5$5-4$Q!5$5? M4$%204U3*&ET97(I("P@='EP96YA;64@17AC97!T:6]N5",C:71E<B ](&1E M=&%I;#HZ;G5L;'1Y<&4C(VET97(-"B-D969I;F4@7U]30T]015]'54%21%]4 M65!%1$5&4RAI=&5R*2!T>7!E9&5F($5X8V5P=&EO;E0C(VET97(@97AC97!T M:6]N7W1Y<&4C(VET97([#0HC9&5F:6YE(%]?4T-/4$5?1U5!4D1?0T%40TA% M4RAI=&5R*5P-"@EC871C:" H='EP96YA;64@17AC97!T:6]N<TQI<W14.CIE M>&-E<'1I;VY?='EP92,C:71E<B F(&4I('M<#0H)"71Y<&5D968@9&5T86EL M.CI'=6%R9$AE;'!E<CP@='EP96YA;64@17AC97!T:6]N<TQI<W14.CIE>&-E M<'1I;VY?='EP92,C:71E<B ^($AE;'!E<E]T.UP-"@D)2&5L<&5R7W0Z.FEN M=F]K95]E>&-E<'1I;VY?:&%N9&QE<CP@97AC97!T:6]N<U]H86YD;&5R7W!O M:6YT97)?='EP92 ^*&U?<$AA;F1L97(L(&4I.UP-"@E]#0H-"FYA;65S<&%C M92!B;V]S="![#0H-"FYA;65S<&%C92!G=6%R9"![#0H-"B\O(2!%;G5M97)A M=&EO;B!O9B!S=&%T=7-E<R!O9B!G=6%R9 T*96YU;2!E;G5M4V-O<&5'=6%R M9%-T871U<R![#0H)87)M960@/2!F86QS92P-"@ED:7-A<FUE9" ]('1R=64- M"GT[#0H-"FYA;65S<&%C92!D971A:6P@>PT*#0H)+R\A($5M<'1Y('-T<G5C M='5R97,@9F]R(&EN9&EC871I;VX@;V8@='EP92!A8G-E;F-E#0H)<W1R=6-T M(&YU;&QT>7!E('M].PT*"5]?4T-/4$5?1U5!4D1?14Y53452051%7TU!0U)/ M7RA?7U-#3U!%7T=505)$7TY53$Q465!%4RD-"@T*"2\O(2!4:&ES(&-L87-S M(&1E=&5C=',@=&AE(&]P=&EM86P@<&%R86UE=&5R('1Y<&4@;V8@<&]I;G1E M<B!T;R!E>&-E<'1I;VX@:&%N9&QE<B!O8FIE8W0-"@ET96UP;&%T93P@='EP M96YA;64@5"P@8F]O;"!F4&]I;G1E<B ](&)O;W-T.CII<U]P;VEN=&5R/"!4 M(#XZ.G9A;'5E(#X-"@ES=')U8W0@<&]I;G1E<E]T>7!E('L-"@D)='EP961E M9B!4(&-O;G-T)B!T>7!E.PT*"7T[#0H)=&5M<&QA=&4\('1Y<&5N86UE(%0@ M/@T*"7-T<G5C="!P;VEN=&5R7W1Y<&4\(%0L('1R=64@/B![#0H)"71Y<&5D M968@5"!T>7!E.PT*"7T[#0H-"@DO+R$@17AC97!T:6]N(&AA;F1L97(@:6YV M;VMI;F<@:&5L<&5R#0H)=&5M<&QA=&4\('1Y<&5N86UE(%0L(&)O;VP@9DYU M;&Q4>7!E(#T@8F]O<W0Z.FES7V)A<V5?86YD7V1E<FEV960\(&YU;&QT>7!E M+"!4(#XZ.G9A;'5E(#X-"@ES=')U8W0@1W5A<F1(96QP97(@>PT*"0ET96UP M;&%T93P@='EP96YA;64@52 ^#0H)"0ES=&%T:6,@:6YL:6YE('9O:60@:6YV M;VME7V5X8V5P=&EO;E]H86YD;&5R*'1Y<&5N86UE('!O:6YT97)?='EP93P@ M52 ^.CIT>7!E('!(86YD;&5R+"!4)B!E*2![#0H)"0DO+R!)9B!T:&4@9F]L M;&]W:6YG(&QI;F4@9F%I;',@=&\@8V]M<&EL92!T:&5N('1H97)E(&ES(&%N M(&5X8V5P=&EO;B!T>7!E+"!F;W(@=VAI8V@-"@D)"2\O(&]N7V5X8V5P=&EO M;B!F=6YC=&EO;B!I<R!N;W0@9&5F:6YE9"!I;B!E>&-E<'1I;VX@:&%N9&QE M<B!C;&%S<PT*"0D):68@*'!(86YD;&5R*2!P2&%N9&QE<BT^;VY?97AC97!T M:6]N*&4I.PT*"0E]#0H)?3L-"@ET96UP;&%T93P@='EP96YA;64@5" ^#0H) M<W1R=6-T($=U87)D2&5L<&5R/"!4+"!T<G5E(#X@>PT*"0ET96UP;&%T93P@ M='EP96YA;64@52 ^#0H)"7-T871I8R!I;FQI;F4@=F]I9"!I;G9O:V5?97AC M97!T:6]N7VAA;F1L97(H='EP96YA;64@<&]I;G1E<E]T>7!E/"!5(#XZ.G1Y M<&4L(%0F*2![#0H)"7T-"@E].PT*#0H)+R\A(%1H92!C;&%S<R!H;VQD<R!A M;F0@;6%N86=E<R!T:&4@<W1A='5S(&]F('1H92!G=6%R9 T*"6-L87-S('-C M;W!E7V=U87)D7W1R:6=G97(-"@E[#0H)<')O=&5C=&5D.@T*"0DO+R$@1W5A M<F0G<R!S=&%T=7,-"@D)96YU;5-C;W!E1W5A<F13=&%T=7,@;5]3=&%T=7,[ M#0H)<'5B;&EC.@T*"0ES8V]P95]G=6%R9%]T<FEG9V5R*&5N=6U38V]P94=U M87)D4W1A='5S(%-T871U<RD@.B!M7U-T871U<RA3=&%T=7,I('L-"@D)?0T* M"0EI;FQI;F4@=F]I9"!A<FTH*2![#0H)"0EM7U-T871U<R ](&%R;65D.PT* M"0E]#0H)"6EN;&EN92!V;VED(&1I<V%R;2@I('L-"@D)"6U?4W1A='5S(#T@ M9&ES87)M960[#0H)"7T-"@D):6YL:6YE(&5N=6U38V]P94=U87)D4W1A='5S M(&=E=%]S=&%T=7,H*2!C;VYS="![#0H)"0ER971U<FX@;5]3=&%T=7,[#0H) M"7T-"@E].PT*#0I]("\O(&YA;65S<&%C92!D971A:6P-"@T*+R\A($1I<F5C M="!F=6YC=&]R(&EN=F]K97(@8VQA<W,-"F-L87-S('-I;7!L95]I;G9O:V5R M('L-"G!R;W1E8W1E9#H-"@ET96UP;&%T93P@='EP96YA;64@1G5N8W1O<E0@ M/@T*"6EN;&EN92!V;VED(&9I<F4H1G5N8W1O<E0@8V]N<W0F($9U;F-T;W(I M(&-O;G-T('L-"@D)1G5N8W1O<B(a)I.PT*"7T-"GT[#0H-"B\O(2!#;&%S<R!F M;W(@96YU;65R871I;F<@97AC97!T:6]N('1Y<&5S#0IT96UP;&%T93P@='EP M96YA;64@17AC97!T:6]N5# @7U]30T]015]'54%21%]%3E5-15)!5$5?34%# M4D]?*%]?4T-/4$5?1U5!4D1?5$5-4$Q!5$5?4$%204U3*2 ^#0IS=')U8W0@ M97AC97!T:6]N<PT*>PT*"5]?4T-/4$5?1U5!4D1?14Y53452051%7TU!0U)/ M*%]?4T-/4$5?1U5!4D1?5%E0141%1E,I#0I].PT*#0HO+R$@17AC97!T:6]N M(&-A=&-H:6YG(&9U;F-T;W(@:6YV;VME<B!C;&%S<PT*=&5M<&QA=&4\(&-L M87-S($5(86YD;&5R5"P@8VQA<W,@17AC97!T:6]N<TQI<W14+"!T>7!E;F%M M92!%2&%N9&QE<E!T<E0@/2!%2&%N9&QE<E0J(#X-"F-L87-S('=I=&A?8V%T M8VAE<B Z('!U8FQI8R!%>&-E<'1I;VYS3&ES=%0-"GL-"G!U8FQI8SH-"@ET M>7!E9&5F($5(86YD;&5R5"!E>&-E<'1I;VYS7VAA;F1L97)?='EP93L-"@ET M>7!E9&5F($5(86YD;&5R4'1R5"!E>&-E<'1I;VYS7VAA;F1L97)?<&]I;G1E M<E]T>7!E.PT*#0IP<F]T96-T960Z#0H)97AC97!T:6]N<U]H86YD;&5R7W!O M:6YT97)?='EP92!M7W!(86YD;&5R.PT*#0IP=6)L:6,Z#0H)=VET:%]C871C M:&5R*"D@.B!M7W!(86YD;&5R*"D@>PT*"7T-"@EW:71H7V-A=&-H97(H='EP M96YA;64(a)9&5T86EL.CIP;VEN=&5R7W1Y<&4\(&5X8V5P=&EO;G-?:&%N9&QE M<E]P;VEN=&5R7W1Y<&4@/CHZ='EP92!P2&%N9&QE<BD@.B!M7W!(86YD;&5R M*'!(86YD;&5R*2![#0H)?0T*#0IP<F]T96-T960Z#0H)=&5M<&QA=&4\('1Y M<&5N86UE($9U;F-T;W)4(#X-"@EI;FQI;F4@=F]I9"!F:7)E*$9U;F-T;W)4 M(&-O;G-T)B!&=6YC=&]R*2!C;VYS="![#0H)"71R>2![#0H)"0E&=6YC=&]R M*"D[#0H)"7T@7U]30T]015]'54%21%]%3E5-15)!5$5?34%#4D\H7U]30T]0 M15]'54%21%]#051#2$53*3L-"@E]#0I].PT*#0I]("\O(&YA;65S<&%C92!G M=6%R9 T*#0HO+R$@1&5S=')U8W1I;F<@<V-O<&4@9W5A<F0@8VQA<W,-"G1E M;7!L871E/"!C;&%S<R!);G9O:V5R5" ](&=U87)D.CIS:6UP;&5?:6YV;VME M<B ^#0IC;&%S<R!L96%V:6YG7W-C;W!E7V=U87)D(#H-"@EP<FEV871E(&YO M;F-O<'EA8FQE+ T*"7!U8FQI8R!G=6%R9#HZ9&5T86EL.CIS8V]P95]G=6%R M9%]T<FEG9V5R+ T*"7!U8FQI8R!);G9O:V5R5 T*>PT*<')O=&5C=&5D.@T* M"71Y<&5D968@9W5A<F0Z.F1E=&%I;#HZ<V-O<&5?9W5A<F1?=')I9V=E<B!T M<FEG9V5R7W1Y<&4[#0H-"G!U8FQI8SH-"@ET>7!E9&5F($EN=F]K97)4(&EN M=F]K97)?='EP93L-"@ET>7!E9&5F(&9U;F-T:6]N,#P@=F]I9" ^(&9U;F-T M;W)?='EP93L-"@T*<')O=&5C=&5D.@T*"69U;F-T;W)?='EP92!M7TQE879I M;F=&=6YC=&]R.PT*#0IP<FEV871E.@T*"6QE879I;F=?<V-O<&5?9W5A<F0H M*3L-"@T*<'5B;&EC.@T*"6QE879I;F=?<V-O<&5?9W5A<F0H9G5N8W1O<E]T M>7!E(&-O;G-T)B!,96%V:6YG1G5N8W1O<BP@:6YV;VME<E]T>7!E(&-O;G-T M)B!);G9O:V5R(#T@:6YV;VME<E]T>7!E*"DL(&=U87)D.CIE;G5M4V-O<&5' M=6%R9%-T871U<R!3=&%T=7,@/2!G=6%R9#HZ87)M960I#0H)"3H@=')I9V=E M<E]T>7!E*%-T871U<RDL(&EN=F]K97)?='EP92A);G9O:V5R*2P@;5],96%V M:6YG1G5N8W1O<BA,96%V:6YG1G5N8W1O<BD-"@E[#0H)?0T*"6QE879I;F=? M<V-O<&5?9W5A<F0H9G5N8W1O<E]T>7!E(&-O;G-T)B!,96%V:6YG1G5N8W1O M<BP@9W5A<F0Z.F5N=6U38V]P94=U87)D4W1A='5S(%-T871U<RP@:6YV;VME M<E]T>7!E(&-O;G-T)B!);G9O:V5R(#T@:6YV;VME<E]T>7!E*"DI#0H)"3H@ M=')I9V=E<E]T>7!E*%-T871U<RDL(&EN=F]K97)?='EP92A);G9O:V5R*2P@ M;5],96%V:6YG1G5N8W1O<BA,96%V:6YG1G5N8W1O<BD-"@E[#0H)?0T*"7YL M96%V:6YG7W-C;W!E7V=U87)D*"D@>PT*"0EI9B H*"AC:&%R*71R:6=G97)? M='EP93HZ9V5T7W-T871U<R@I('P@*&-H87(I=&AI<RT^;5],96%V:6YG1G5N M8W1O<BYE;7!T>2@I*2 ]/2 P*0T*"0D)=&AI<RT^9FER95]L96%V:6YG7V9U M;B(a)I.PT*"7T-"@DO+R$@5&AE(&UE=&AO9"!E>'!L:6-I=&QY(&-A;&QS('1H M92!L96%V:6YG(&9U;F-T;W(-"@EI;FQI;F4@=F]I9"!F:7)E7VQE879I;F=? M9G5N*"D@8V]N<W0@>PT*"0EI;G9O:V5R7W1Y<&4Z.F9I<F4H=&AI<RT^;5], M96%V:6YG1G5N8W1O<BD[#0H)?0T*"2\O(2!4:&4@;65T:&]D(')E9&5F:6YE M<R!T:&4@;&5A=FEN9R!F=6YC=&]R#0H):6YL:6YE('9O:60@87-S:6=N7VQE M879I;F=?9G5N*&9U;F-T;W)?='EP92!C;VYS="8@1G5N8W1O<BD@>PT*"0ET M:&ES+3YM7TQE879I;F=&=6YC=&]R(#T@1G5N8W1O<CL-"@E]#0I].PT*#0HO M+R$@0V]N<W1R=6-T:6YG(&%N9"!D97-T<G5C=&EN9R!S8V]P92!G=6%R9"!C M;&%S<PT*=&5M<&QA=&4\(&-L87-S($EN=F]K97)4(#T@9W5A<F0Z.G-I;7!L M95]I;G9O:V5R(#X-"F-L87-S('-C;W!E7V=U87)D(#H@<'5B;&EC(&QE879I M;F=?<V-O<&5?9W5A<F0\($EN=F]K97)4(#X-"GL-"G!R:79A=&4Z#0H)='EP M961E9B!L96%V:6YG7W-C;W!E7V=U87)D/"!);G9O:V5R5" ^(&)A<V5?='EP M93L-"@T*<')O=&5C=&5D.@T*"71Y<&5D968@='EP96YA;64@8F%S95]T>7!E M.CIT<FEG9V5R7W1Y<&4@=')I9V=E<E]T>7!E.PT*#0IP=6)L:6,Z#0H)='EP M961E9B!T>7!E;F%M92!B87-E7W1Y<&4Z.FEN=F]K97)?='EP92!I;G9O:V5R M7W1Y<&4[#0H)='EP961E9B!T>7!E;F%M92!B87-E7W1Y<&4Z.F9U;F-T;W)? M='EP92!F=6YC=&]R7W1Y<&4[#0H-"G!R;W1E8W1E9#H-"@EF=6YC=&]R7W1Y M<&4@;5]%;G1E<FEN9T9U;F-T;W([#0H-"G!R:79A=&4Z#0H)<V-O<&5?9W5A M<F0H*3L-"@T*<'5B;&EC.@T*"7-C;W!E7V=U87)D* T*"0EF=6YC=&]R7W1Y M<&4@8V]N<W0F($5N=&5R:6YG1G5N8W1O<BP-"@D)9G5N8W1O<E]T>7!E(&-O M;G-T)B!,96%V:6YG1G5N8W1O<BP-"@D):6YV;VME<E]T>7!E(&-O;G-T)B!) M;G9O:V5R(#T@:6YV;VME<E]T>7!E*"DL#0H)"6=U87)D.CIE;G5M4V-O<&5' M=6%R9%-T871U<R!3=&%T=7,@/2!G=6%R9#HZ87)M960-"@DI(#H@8F%S95]T M>7!E*$QE879I;F=&=6YC=&]R+"!);G9O:V5R+"!3=&%T=7,I+"!M7T5N=&5R M:6YG1G5N8W1O<BA%;G1E<FEN9T9U;F-T;W(I#0H)>PT*"0EI9B H*"AC:&%R M*71R:6=G97)?='EP93HZ9V5T7W-T871U<R@I('P@*&-H87(I=&AI<RT^;5]% M;G1E<FEN9T9U;F-T;W(N96UP='DH*2D@/3T@,"D-"@D)"71H:7,M/F9I<F5? M96YT97)I;F=?9G5N*"D[#0H)?0T*"7-C;W!E7V=U87)D* T*"0EF=6YC=&]R M7W1Y<&4@8V]N<W0F($5N=&5R:6YG1G5N8W1O<BP-"@D)9G5N8W1O<E]T>7!E M(&-O;G-T)B!,96%V:6YG1G5N8W1O<BP-"@D)9W5A<F0Z.F5N=6U38V]P94=U M87)D4W1A='5S(%-T871U<RP-"@D):6YV;VME<E]T>7!E(&-O;G-T)B!);G9O M:V5R(#T@:6YV;VME<E]T>7!E*"D-"@DI(#H@8F%S95]T>7!E*$QE879I;F=& M=6YC=&]R+"!);G9O:V5R+"!3=&%T=7,I+"!M7T5N=&5R:6YG1G5N8W1O<BA% M;G1E<FEN9T9U;F-T;W(I#0H)>PT*"0EI9B H*"AC:&%R*71R:6=G97)?='EP M93HZ9V5T7W-T871U<R@I('P@*&-H87(I=&AI<RT^;5]%;G1E<FEN9T9U;F-T M;W(N96UP='DH*2D@/3T@,"D-"@D)"71H:7,M/F9I<F5?96YT97)I;F=?9G5N M*"D[#0H)?0T*"2\O(2!4:&4@;65T:&]D(&5X<&QI8VET;'D@8V%L;',@=&AE M(&5N=&5R:6YG(&9U;F-T;W(-"@EI;FQI;F4@=F]I9"!F:7)E7V5N=&5R:6YG M7V9U;B@I(&-O;G-T('L-"@D):6YV;VME<E]T>7!E.CIF:7)E*'1H:7,M/FU? M16YT97)I;F=&=6YC=&]R*3L-"@E]#0H)+R\A(%1H92!M971H;V0@<F5D969I M;F5S('1H92!E;G1E<FEN9R!F=6YC=&]R#0H):6YL:6YE('9O:60@87-S:6=N M7V5N=&5R:6YG7V9U;BAF=6YC=&]R7W1Y<&4@8V]N<W0F($9U;F-T;W(I('L- M"@D)=&AI<RT^;5]%;G1E<FEN9T9U;F-T;W((a)/2!&=6YC=&]R.PT*"7T-"GT[ M#0H-"GT@+R\@;F%M97-P86-E(&)O;W-T#0H-"@T*+R\@36%C<F]S97,@9F]R M('-E='1I;F<@=7 @86YO;GEM;W5S('-C;W!E(&=U87)D<PT*#0HC9&5F:6YE M(%]?4T-/4$5?1U5!4D1?3D%-15\H<')E9FEX+"!P;W-T9FEX*2!P<F5F:7@C M(W!O<W1F:7@-"B-D969I;F4@7U]30T]015]'54%21%].04U%*'!R969I>"P@ M<&]S=&9I>"D@7U]30T]015]'54%21%].04U%7RAP<F5F:7@L('!O<W1F:7@I M#0H-"B\O($EN(%9#('=H96X@8V]M<&EL:6YG('=I=&@@+UI)(&]P=&EO;B!? M7TQ)3D5?7R!M86-R;R!I<R!C;W)R=7!T960-"B-I9B!D969I;F5D*%]-4T-? M5D52*2 F)B!?35-#7U9%4B ^/2 Q,S P#0H-"B-D969I;F4(a)3$5!5DE.1U]3 M0T]015]'54%21"AF=6YC=&]R*2!<#0H)8F]O<W0Z.FQE879I;F=?<V-O<&5? M9W5A<F0\(#X@7U]30T]015]'54%21%].04U%*%]G=6%R9%\L(%]?0T]53E1% M4E]?*2 H9G5N8W1O<BD[#0HC9&5F:6YE($Q%059)3D=?4T-/4$5?1U5!4D1? M15@H9G5N8W1O<BP@97AC7W1Y<&5?;&ES="P@97AC7VEF86-E+"!H86YD;&5R M*2!<#0H)8F]O<W0Z.FQE879I;F=?<V-O<&5?9W5A<F0\(&)O;W-T.CIG=6%R M9#HZ=VET:%]C871C:&5R/"!E>&-?:69A8V4L(&)O;W-T.CIG=6%R9#HZ97AC M97!T:6]N<SP@97AC7W1Y<&5?;&ES=" ^(#X@/B!?7U-#3U!%7T=505)$7TY! M344H7V=U87)D7V5X7RP(a)7U]#3U5.5$527U\I("AF=6YC=&]R+"!H86YD;&5R M*3L-"@T*(V1E9FEN92!30T]015]'54%21"AE;G1E<E]F=6YC=&]R+"!L96%V M95]F=6YC=&]R*2!<#0H)8F]O<W0Z.G-C;W!E7V=U87)D/" ^(%]?4T-/4$5? M1U5!4D1?3D%-12A?9W5A<F1?+"!?7T-/54Y415)?7RD@*&5N=&5R7V9U;F-T M;W(L(&QE879E7V9U;F-T;W(I.PT*(V1E9FEN92!30T]015]'54%21%]%6"AE M;G1E<E]F=6YC=&]R+"!L96%V95]F=6YC=&]R+"!E>&-?='EP95]L:7-T+"!E M>&-?:69A8V4L(&AA;F1L97(I(%P-"@EB;V]S=#HZ;&5A=FEN9U]S8V]P95]G M=6%R9#P@8F]O<W0Z.F=U87)D.CIW:71H7V-A=&-H97(\(&5X8U]I9F%C92P@ M8F]O<W0Z.F=U87)D.CIE>&-E<'1I;VYS/"!E>&-?='EP95]L:7-T(#X@/B ^ M(%]?4T-/4$5?1U5!4D1?3D%-12A?9W5A<F1?97A?+"!?7T-/54Y415)?7RD@ M*&5N=&5R7V9U;F-T;W(L(&QE879E7V9U;F-T;W(L(&AA;F1L97(I.PT*#0HC M96QS90T*#0HC9&5F:6YE($Q%059)3D=?4T-/4$5?1U5!4D0H9G5N8W1O<BD@ M7 T*"6)O;W-T.CIL96%V:6YG7W-C;W!E7V=U87)D/" ^(%]?4T-/4$5?1U5! M4D1?3D%-12A?9W5A<F1?+"!?7TQ)3D5?7RD(a)*&9U;F-T;W(I.PT*(V1E9FEN M92!,14%624Y'7U-#3U!%7T=505)$7T58*&9U;F-T;W(L(&5X8U]T>7!E7VQI M<W0L(&5X8U]I9F%C92P@:&%N9&QE<BD@7 T*"6)O;W-T.CIL96%V:6YG7W-C M;W!E7V=U87)D/"!B;V]S=#HZ9W5A<F0Z.G=I=&A?8V%T8VAE<CP@97AC7VEF M86-E+"!B;V]S=#HZ9W5A<F0Z.F5X8V5P=&EO;G,\(&5X8U]T>7!E7VQI<W0@ M/B ^(#X@7U]30T]015]'54%21%].04U%*%]G=6%R9%]E>%\L(%]?3$E.15]? M*2 H9G5N8W1O<BP@:&%N9&QE<BD[#0H-"B-D969I;F4@4T-/4$5?1U5!4D0H M96YT97)?9G5N8W1O<BP@;&5A=F5?9G5N8W1O<BD@7 T*"6)O;W-T.CIS8V]P M95]G=6%R9#P@/B!?7U-#3U!%7T=505)$7TY!344H7V=U87)D7RP@7U],24Y% M7U\I("AE;G1E<E]F=6YC=&]R+"!L96%V95]F=6YC=&]R*3L-"B-D969I;F4@ M4T-/4$5?1U5!4D1?15@H96YT97)?9G5N8W1O<BP@;&5A=F5?9G5N8W1O<BP@ M97AC7W1Y<&5?;&ES="P@97AC7VEF86-E+"!H86YD;&5R*2!<#0H)8F]O<W0Z M.FQE879I;F=?<V-O<&5?9W5A<F0\(&)O;W-T.CIG=6%R9#HZ=VET:%]C871C M:&5R/"!E>&-?:69A8V4L(&)O;W-T.CIG=6%R9#HZ97AC97!T:6]N<SP@97AC M7W1Y<&5?;&ES=" ^(#X@/B!?7U-#3U!%7T=505)$7TY!344H7V=U87)D7V5X M7RP@7U],24Y%7U\I("AE;G1E<E]F=6YC=&]R+"!L96%V95]F=6YC=&]R+"!H M86YD;&5R*3L-"@T*(V5N9&EF("\O(&1E9FEN960H7TU30U]615(I("8F(%]- M4T-?5D52(#X](#$S,# -"@T*(V1E9FEN92!30T]015]'54%21%]%6$-%4%1) M3TY37S$H97AC97!T:6]N7W1Y<&4P*2!E>&-E<'1I;VY?='EP93 -"B-D969I M;F4(a)4T-/4$5?1U5!4D1?15A#15!424].4U\R*&5X8V5P=&EO;E]T>7!E,"P@ M97AC97!T:6]N7W1Y<&4Q*5P-"@E30T]015]'54%21%]%6$-%4%1)3TY37S$H M97AC97!T:6]N7W1Y<&4P*2P@97AC97!T:6]N7W1Y<&4Q#0HC9&5F:6YE(%-# M3U!%7T=505)$7T580T505$E/3E-?,RAE>&-E<'1I;VY?='EP93 L(&5X8V5P M=&EO;E]T>7!E,2P@97AC97!T:6]N7W1Y<&4R*5P-"@E30T]015]'54%21%]% M6$-%4%1)3TY37S(H97AC97!T:6]N7W1Y<&4P+"!E>&-E<'1I;VY?='EP93$I M+"!E>&-E<'1I;VY?='EP93(-"B-D969I;F4@4T-/4$5?1U5!4D1?15A#15!4 M24].4U\T*&5X8V5P=&EO;E]T>7!E,"P@97AC97!T:6]N7W1Y<&4Q+"!E>&-E M<'1I;VY?='EP93(L(&5X8V5P=&EO;E]T>7!E,RE<#0H)4T-/4$5?1U5!4D1? M15A#15!424].4U\S*&5X8V5P=&EO;E]T>7!E,"P@97AC97!T:6]N7W1Y<&4Q M+"!E>&-E<'1I;VY?='EP93(I+"!E>&-E<'1I;VY?='EP93,-"B-D969I;F4@ M4T-/4$5?1U5!4D1?15A#15!424].4U\U*&5X8V5P=&EO;E]T>7!E,"P@97AC M97!T:6]N7W1Y<&4Q+"!E>&-E<'1I;VY?='EP93(L(&5X8V5P=&EO;E]T>7!E M,RP@97AC97!T:6]N7W1Y<&4T*5P-"@E30T]015]'54%21%]%6$-%4%1)3TY3 M7S0H97AC97!T:6]N7W1Y<&4P+"!E>&-E<'1I;VY?='EP93$L(&5X8V5P=&EO M;E]T>7!E,BP@97AC97!T:6]N7W1Y<&4S*2P@97AC97!T:6]N7W1Y<&4T#0HC M9&5F:6YE(%-#3U!%7T=505)$7T580T505$E/3E-?-BAE>&-E<'1I;VY?='EP M93 L(&5X8V5P=&EO;E]T>7!E,2P@97AC97!T:6]N7W1Y<&4R+"!E>&-E<'1I M;VY?='EP93,L(&5X8V5P=&EO;E]T>7!E-"P@97AC97!T:6]N7W1Y<&4U*5P- M"@E30T]015]'54%21%]%6$-%4%1)3TY37S4H97AC97!T:6]N7W1Y<&4P+"!E M>&-E<'1I;VY?='EP93$L(&5X8V5P=&EO;E]T>7!E,BP@97AC97!T:6]N7W1Y M<&4S+"!E>&-E<'1I;VY?='EP930I+"!E>&-E<'1I;VY?='EP934-"B-D969I M;F4(a)4T-/4$5?1U5!4D1?15A#15!424].4U\W*&5X8V5P=&EO;E]T>7!E,"P@ M97AC97!T:6]N7W1Y<&4Q+"!E>&-E<'1I;VY?='EP93(L(&5X8V5P=&EO;E]T M>7!E,RP@97AC97!T:6]N7W1Y<&4T+"!E>&-E<'1I;VY?='EP934L(&5X8V5P M=&EO;E]T>7!E-BE<#0H)4T-/4$5?1U5!4D1?15A#15!424].4U\V*&5X8V5P M=&EO;E]T>7!E,"P@97AC97!T:6]N7W1Y<&4Q+"!E>&-E<'1I;VY?='EP93(L M(&5X8V5P=&EO;E]T>7!E,RP@97AC97!T:6]N7W1Y<&4T+"!E>&-E<'1I;VY? M='EP934I+"!E>&-E<'1I;VY?='EP938-"B-D969I;F4@4T-/4$5?1U5!4D1? M15A#15!424].4U\X*&5X8V5P=&EO;E]T>7!E,"P@97AC97!T:6]N7W1Y<&4Q M+"!E>&-E<'1I;VY?='EP93(L(&5X8V5P=&EO;E]T>7!E,RP@97AC97!T:6]N M7W1Y<&4T+"!E>&-E<'1I;VY?='EP934L(&5X8V5P=&EO;E]T>7!E-BP@97AC M97!T:6]N7W1Y<&4W*5P-"@E30T]015]'54%21%]%6$-%4%1)3TY37S<H97AC M97!T:6]N7W1Y<&4P+"!E>&-E<'1I;VY?='EP93$L(&5X8V5P=&EO;E]T>7!E M,BP@97AC97!T:6]N7W1Y<&4S+"!E>&-E<'1I;VY?='EP930L(&5X8V5P=&EO M;E]T>7!E-2P@97AC97!T:6]N7W1Y<&4V*2P@97AC97!T:6]N7W1Y<&4W#0HC M9&5F:6YE(%-#3U!%7T=505)$7T580T505$E/3E-?.2AE>&-E<'1I;VY?='EP M93 L(&5X8V5P=&EO;E]T>7!E,2P@97AC97!T:6]N7W1Y<&4R+"!E>&-E<'1I M;VY?='EP93,L(&5X8V5P=&EO;E]T>7!E-"P@97AC97!T:6]N7W1Y<&4U+"!E M>&-E<'1I;VY?='EP938L(&5X8V5P=&EO;E]T>7!E-RP@97AC97!T:6]N7W1Y M<&4X*5P-"@E30T]015]'54%21%]%6$-%4%1)3TY37S@H97AC97!T:6]N7W1Y M<&4P+"!E>&-E<'1I;VY?='EP93$L(&5X8V5P=&EO;E]T>7!E,BP@97AC97!T M:6]N7W1Y<&4S+"!E>&-E<'1I;VY?='EP930L(&5X8V5P=&EO;E]T>7!E-2P@ M97AC97!T:6]N7W1Y<&4V+"!E>&-E<'1I;VY?='EP93<I+"!E>&-E<'1I;VY? M='EP93@-"B-D969I;F4(a)4T-/4$5?1U5!4D1?15A#15!424].4U\Q,"AE>&-E M<'1I;VY?='EP93 L(&5X8V5P=&EO;E]T>7!E,2P@97AC97!T:6]N7W1Y<&4R M+"!E>&-E<'1I;VY?='EP93,L(&5X8V5P=&EO;E]T>7!E-"P@97AC97!T:6]N M7W1Y<&4U+"!E>&-E<'1I;VY?='EP938L(&5X8V5P=&EO;E]T>7!E-RP@97AC M97!T:6]N7W1Y<&4X+"!E>&-E<'1I;VY?='EP93DI7 T*"5-#3U!%7T=505)$ M7T580T505$E/3E-?.2AE>&-E<'1I;VY?='EP93 L(&5X8V5P=&EO;E]T>7!E M,2P@97AC97!T:6]N7W1Y<&4R+"!E>&-E<'1I;VY?='EP93,L(&5X8V5P=&EO M;E]T>7!E-"P@97AC97!T:6]N7W1Y<&4U+"!E>&-E<'1I;VY?='EP938L(&5X M8V5P=&EO;E]T>7!E-RP@97AC97!T:6]N7W1Y<&4X*2P@97AC97!T:6]N7W1Y M<&4Y#0H-"B\O($-L96%N:6YG('5P(&UA8W)O<V5S#0HC=6YD968@7U]30T]0 M15]'54%21%]#051#2$53#0HC=6YD968@7U]30T]015]'54%21%]465!%1$5& M4PT*(W5N9&5F(%]?4T-/4$5?1U5!4D1?5$5-4$Q!5$5?4$%204U3#0HC=6YD M968@7U]30T]015]'54%21%].54Q,5%E015,-"B-U;F1E9B!?7U-#3U!%7T=5 M05)$7T5.54U%4D%415]-04-23PT*(W5N9&5F(%]?4T-/4$5?1U5!4D1?14Y5 M3452051%7TU!0U)/7PT*#0HC96YD:68@+R\@7U]30T]014=505)$7TA?7PT* ` end

3 5

Re: [boost] asio networking proposal
by Dave Gomboc 22 Aug '05

22 Aug '05

> - Consistency with a future asynchronous version of the same function. > As a rule, in async versions of the functions complex structures or > buffers need to be passed as arguments, andthe only difference between > the sync and async functions is the callback handler, i.e.: > > void operation(parameters); > > template <typename Handler> > void async_operation(parameters, Handler handler); Treating synchronous and asynchronous differently here seems less generic than always using template <typename Handler> void operation(parameters, Handler handler); Would it be bad to do it this way (possibly with a synchronous handler defaulted?) > Yes, I agree that read and write are better, because of the > "portability" of the names to non-sockets that it gives. I've wanted to > make that change for some time, but the thing that has been preventing > me is what to call the datagram functions sendto and recvfrom, as > writeto and readfrom don't seem quite right. Any suggestions? I don't perceive what's wrong with "write_to" and "read_from". Dave P.S. I saw in another Boost posting a poster using email address sid(a)6581.com. It's nice to see that there's other C=64 oldtimers out there! ;-)

3 2

[range] extension proposal - construct
by Pavol Droba 22 Aug '05

22 Aug '05

Hi, I have a proposal for addition to Boost.Range library: template<typename RangeT, typename OtherRangeT> RangeT construct<RangeT>(const OtherRangeT& Source); template<typename RangeT, typename IteratorT> RangeT construct<RangeT>(IteratorT From, IteratorT To); Both functions should construct a range of type RangeT, that will contain elements from Source or [From,To) respectively. Motivation: In the standard library Sequence concept defines a way for constructing a sequence from and arbitrary range of iterators. This is very useful concept and it would be nice to have something similar available in the Range library. Most significant advantage of this construct is that it allows to create algorithms, that modify an input range and return a copy of it. Currently there is no generic way for constructing or modifying a range, therefor it restricts the usage of range to non-mutable input parameters. For instance a simple to_lower algorithm (available in StringAlgo library) template<typename SequenceT> SequenceT to_lower_copy(const SequenceT& Input, const std::locale& Loc=std::locale()); requires the input to satisfy sequence requirements so it can construct the result. This effectively disables many advantages of Range library. Because it is not possible to adapt an external class (like CString) to work with this algorithm. Yes it could be very easy to implement construction for this class. There is already a similar function in the range library. It's called copy<> but, this function is provided solely for sequences and there is no feasible and documented way for customization. Best Regards, Pavol

3 3

logging v1.4 - some comments
by Darryl Green 22 Aug '05

22 Aug '05

Excuse the break in threading - gmane has lost/missed a lot of boost traffic. Hi John, I've only had a quick look at the latest version: The m_destroyed hack needs to go - this should only be relevant for static (not scoped) logs and the real issue is that you need to do thread-safe singletons - ie. you need to use posix call_once or equivalent to contstruct the thing. Destruction is a bit tricky - not doing it seems a reasonable option, though stopping leak detectors from compaining would be nice. The scoped log stuff doesn't seem to have been updated to support levels yet - in fact I'm not sure if it currently works? I think (fancy that - given the way it was in analog ;-)) that the named appenders need to be managed - currently, you can create multiple appenders with the same name, then when you delete by name you delete all appenders with that name. I don't see the utility of that model, which when combined with the wildcard matching is really fairly hard to use. For example, suppose I have an appender that logs to some sort of display for "real time" tracing. First off, I say: manipulate_logs("error.*").add_appender(displaywrite, "display") Then I notice an error about some component foo and decide to look at more detail about foo: manipulate_logs("*.foo").add_appender(displaywrite, "display") Now I get anything logged to "error.foo" written to "display" twice. I then say: manipulate_logs("error.*").del_appender("display") Because I want to concentrate on "foo" only. Now I find I don't get errors from foo displayed, only other less critical messaages. Then, foo goes out of scope (it's a scoped log), only to come back into scope again. When it does, and it generates an error, I'm (not really) suprised to see it sent to "display".... As the purpose of named appenders is to facilitate runtime modification of the appender set, surely the ability to make these modifications using *only* the name is reasonable. The fact that add requires a function while del only needs a name only highlights this. Regardless of what the rules for combining appenders/modifiers/enabledness are, they need to be consistent and to work across scoped logs going in/out of scope. I think what is needed is a set of connections (logs connect to appenders/modifiers) ordered by the log name which may include wildcards. Log name (segments) containing wildcards should be ordered before exact names so the more specific rules override the less specific ones. Note the above was from reading the docs + code - I haven't tried running it yet, and maybe I'm misunderstanding something. Regards Darryl.

6 9

logging v1.4 - multiple levels implemented!
by John Torjo 22 Aug '05

22 Aug '05

Hi all, Just updated the Logging library. Find it here: http://torjo.com/code/logging.zip Also, I've updated the docs. Feedback is welcome. Highlights: **** Multiple levels. **** Easier manipulation of logs **** Modifiers/Appenders can now be deleted. **** Shortcut for BOOST_IS_LOG_ENABLED **** Exception guards **** Shared Memory Appender **** Multiple levels. You can specify levels, very much like log4j. To assign a level to a message, use BOOST_LOGL, like this: BOOST_LOGL(app,dbg) << "some debug message"; BOOST_LOGL(app,err) << "some error"; BOOST_LOGL(gui,warn) << "some GUIsh warning"; Note the BOOST_LOG still works: BOOST_LOG(app) << "some message"; // equivalent to: // BOOST_LOGL(app,default_) << "some message" **** Easier manipulation of logs Every time you need to manipulate some logs (add/delete appenders/modifiers, set the log's level), you use manipulate_logs("logs_spec") Example: manipulate_logs("*") // all logs prefix the message by time .add_modifier(prepend_time("$hh:$mm:$ss "), DEFAULT_INDEX + 1 ) // all log' messages are prefixed by the log name .add_modifier(&prepend_prefix) // all messages are written to cout .add_appender(&write_to_cout); // write all dbg messages and above to app.* logs manipulate_logs("app.*").enable(boost::logging::level::dbg); **** Modifiers/Appenders can now be deleted. In order to delete a modifier/appender, just give it a name: // prepend time, and name this modifier as "time" manipulate_logs("*") .add_modifier(prepend_time("$hh:$mm:$ss "), "time" ); // at a later time BOOST_LOG(app) << "this is prefixed by time"; manipulate_logs("*") .del_modifier("time"); BOOST_LOG(app) << "this is NOT prefixed by time"; ***** Shortcut for BOOST_IS_LOG_ENABLED Instead of saying: // test if message should be written to this log if ( BOOST_IS_LOG_ENABLED(app,some_level)) ...; You can say: if ( app()(some_level)) ...; **** Exception guards When logging, if any modifier/appender throws, the exception is not allowed to propagate. **** Shared Memory Appender An appender that allows writing to a shared memory zone, internally using shmem library. Still to do: **** compile-time logs: write docs about it **** appenders to Event log **** alternate logging manager Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -v1.6.3 (Resource Splitter) -- http://www.torjo.com/cb/ - Click, Build, Run!

5 15

Boost regression notification (2005-08-22)
by Douglas Gregor 22 Aug '05

22 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-22T15:05:38Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 65 failures in 6 libraries: functional/hash (9) graph (9) parameter (4) python (22) serialization (20) wave (1) |functional/hash| books: vc-6_5 vc-6_5-stlport vc-7_0 point: borland-5_6_4 vc-6_5 vc-6_5-stlport vc-7_0 portable: vc-6_5 vc-6_5-stlport |graph| graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux mingw-3_4_2 vc-7_1 vc-7_1 vc-7_1 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |python| exec: cw-8_3 cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 vc-7_1 vc-7_1 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |wave| testwave: gcc-3.3.6-linux

1 0

Start separating mandatory source?
by Daryle Walker 22 Aug '05

22 Aug '05

Since we just had a release, should be re-visit moving all the mandatory source code into a separate directory together? For the newbies, this means changing the BOOST_ROOT . libs .. date_time ... src .. graph ... src into something like BOOST_ROOT . src .. date_time .. graph Right now, using mandatory source files means scrambling into a lot of directories figuring out what to add. There is stuff like Boost-Build, but it doesn't work for everyone, and I feel that it's a "cute" overkill solution. No matter the plan there are some caveats: 1. Some platforms require some libraries to be put in separate DLLs. 2. You have to exclude the driver files from Boost-Test, since each includes a "main" function. (And if you actually are doing testing, then you know that you can include at most one driver file.) Besides the caveats, you can just dump all the mandatory source code into your IDE's project file (or make file) and don't worry Boost-Build. If some source needs to be in a DLL, then start a sub-project. (If you don't need a library at all, then exclude it from the project to save compile time. The linker will tell you, by choking, if you went too far.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

4 9

Should we add two simple character-to-Unicode converters?
by Daryle Walker 22 Aug '05

22 Aug '05

Nothing fancy, just something like: int_fast32_t char_to_Unicode( char c ); int_fast32_t wchar_to_Unicode( wchar_t c ); that converts a native character to a Unicode value. They would need a separate source file that contains #if blocks for each platform. Maybe they can start a namespace with "utf8_codecvt_facet"? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 3

interest in "policy_composite" library?
by Larry Evans 22 Aug '05

22 Aug '05

Is there any interest in a "policy_composite" library which will have policies just as the proposed policy_ptr: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/pol… library has policies? These composite policies might allow different allocation strategies for variant and possibly different CTOR arguments for tuple. It could also allow adding different methods, such as the get_base_ptr(void) as described here: http://groups-beta.google.com/group/comp.std.c++/msg/27e41e693228c6c7?hl=en& which would of course satisfy (hopefully) that OP's request for a variant extension.

1 0

Re: [boost] Should we add two simple character-to-Unicode converters?
by Graham 22 Aug '05

22 Aug '05

>From: Daryle Walker <darylew(a)hotmail.com> Dear Daryle, >I thought of these functions while considering how Wave process the various >phases of C++ translation (see section 2.1 of the standard). I wanted the >conversion to be one native-character to one code-point because that is how >Phase 1 implies it[1]. If you don't think that's right, maybe we should >file a defect with the Standard committee. Maybe I misunderstood you - you seem to be asking for code page conversion here not UTF conversion. Code page conversion is anything but simple and requires data conversion tables for many of the code pages. It is not very practical at the character level as you can see from the calls below, but would require conversion objects to be created that can then implement these functions. int_fast32_t char_to_Unicode(std::string locale, char c ); // very inefficient int_fast32_t wchar_to_Unicode(std::string locale, wchar_t c ); // very inefficient conv1250 = new convertor(std::string locale); // better convertor->char_to_Unicode(char c); >[1] In other words, any extended native character (i.e. not a character C++ >uses for parsing) must be mapped to one C++ Unicode name, which maps to a >single code-point. That depends on what you mean. For example <e><acute> can be one <e acute>, or two <e><acute> Unicode characters depending on how it is normalised. A character parser should understand this if it wants to present Unicode graphemes which are the default unit of parsing in unicode and which should be in any compliant native handler even if working with the local code page. I suggest you wait for the release of the unicode library, alternatively if you want to volunteer to write lots of code page conversion functions, and their data tables where necessary, please let us know. Yours, Graham

2 1

Updated version history
by Daryle Walker 22 Aug '05

22 Aug '05

I added items for 1.11.1 and 1.11.0, which I found in e-mails in the Archives. Worse, 1.11.1 was just incidentally mentioned and was not a subject of an e-mail. Updated CVS and the web site (hopefully not frying the latter). -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[config] Why does BOOST_NO_INTEGRAL_INT64_T depend on BOOST_HAS_LONG_LONG?
by Markus Schöpflin 22 Aug '05

22 Aug '05

Currently config/suffix.hpp contains the following code which seems pretty wrong to me: ---%<--- #if !defined(BOOST_HAS_LONG_LONG) && !defined(BOOST_NO_INTEGRAL_INT64_T) # define BOOST_NO_INTEGRAL_INT64_T #endif --->%--- AFAICT, the existence of a 64 bit integral type has nothing to do with support for long long types. On Tru64 for example, uint64_t is defined as unsigned long and there is no unsigned long long when the compiler operates in strict ansi mode. Shouldn't these lines just be removed? Markus

3 10

build boost_1.33 on cygwin failed
by Bernd Martin Wollny 22 Aug '05

22 Aug '05

Hello, I am using cygwin on a Windows XP system. I can build boost 1_32.0 with no problems. If i Try to build boos_1.33 The build failed with the following error: ./bjam -sTools="gcc" --prefix=/usr stage Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (and if you don't know what ICU is then you probably don't need it). unknown target type for <@boost!libs!test!build>libboost_prg_exec_monitor.dll The error doesn't depend on prefix. what is wrong ??? buy Bernd

1 0

[type_traits] small workaround logic change
by Vladimir Prus 22 Aug '05

22 Aug '05

Hello, I suggest that the following patch be applied to type_traits/detail/cv_traits_impl.hpp: --- cv_traits_impl.hpp 22 Jun 2005 16:59:26 -0000 1.4 +++ cv_traits_impl.hpp 14 Jul 2005 06:49:40 -0000 @@ -19,7 +19,7 @@ // implementation helper: -#if !(BOOST_WORKAROUND(__GNUC__,== 3) && (__GNUC_MINOR__ <= 2)) +#if !(BOOST_WORKAROUND(__GNUC__,== 3) && BOOST_WORKAROUND(__GNUC_MINOR__, <= 2)) namespace boost { namespace detail { #else The reason is that later in the file, we have: #if BOOST_WORKAROUND(__GNUC__,== 3) && BOOST_WORKAROUND(__GNUC_MINOR__, <= 2) and first condition does not exactly match the second condition. Specifically, suppose __GNUC__ is set to 3 and __GNUC_MINOR__ is not set. The first condition will evaluate to ! (BOOST_WORKAROUND(__GNUC__, == 3) && (__GNUC_MINOR__ <= 2) = ! (1 && (0 <= 2)) = ! (1 && 1 ) = 0 The second condition in the file will evaluate to: BOOST_WORKAROUND(__GNUC__,== 3) && BOOST_WORKAROUND(__GNUC_MINOR__, <= 2) = 1 && 0 = 0 So, both conditions evaluate to the same value, while they are supposed to be mutually exclusive. The case where __GNUC_MINOR__ is not set is a pathological -- I've found it when playing with some C++ parser, but the patch should do no harm. Opinions? - Volodya

3 2

Bug in boost::rational, no Boolean conversion; an operator template suggestion
by Daryle Walker 22 Aug '05

22 Aug '05

I'm writing a class template where the template parameter is a type that should represent real numbers. It started choking when using boost::rational when I needed Boolean conversion, e.g. template < typename T > void my_class<T>::my_func() { if ( this->s_ ) //... } Looking at boost::rational, I noticed that it does NOT have a Boolean conversion operator (i.e. an unspecified numeric/pointer type). Before anyone says that's proper, realize that boost::rational DOES have "operator not()" defined! This is a surprise to the typical C++ programmer. Either both should be defined, or neither. I think that boost::rational should add a Boolean conversion. (It's a quick fix, and it is critical, so it should be done for this release.) Incidentally, maybe we should define another helper template for <boost/operators.hpp>. If a type supports default construction and equality via "operator ==()", then a Boolean conversion and "operator not()" will be added. (It's up to the user to make sure the type is numeric and the default value is equivalent to zero.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 4

Re: [boost] Should we add two simple character-to-Unicode converters?
by Graham 22 Aug '05

22 Aug '05

Hi, Both: int_fast32_t char_to_Unicode( char c ); int_fast32_t wchar_to_Unicode( wchar_t c ) will require processing of surrogates on order to be Unicode 4 compliant. A Unicode library is currently under development that will give access to the surrogate ranges directly from the ucd to allow this to be done properly. Please bear with us. Yours, Graham >Message: 13 >Date: Fri, 19 Aug 2005 17:15:03 +0400 >From: Vladimir Prus <ghost(a)cs.msu.su> >Subject: Re: [boost] Should we add two simple character-to-Unicode > converters? >To: boost(a)lists.boost.org >Message-ID: <de4m0n$aq9$1(a)sea.gmane.org> >Content-Type: text/plain; charset=us-ascii > >Daryle Walker wrote: > >> Nothing fancy, just something like: >> >> int_fast32_t char_to_Unicode( char c ); >> int_fast32_t wchar_to_Unicode( wchar_t c ); >> >> that converts a native character to a Unicode value. > >Maybe, but it's hard to comment as you haven't even explained what those >function will do. What's a "native character" and what a "Unicode value" >and how the conversion will be done? If the first function does conversion >from local 8 bit encoding to unicode then: > > - do you have a working implementation? > - isn't dealing with individual characters too slow? > >- Volodya Graham Barnett BEng, ACGI, MCSD/ MCAD .Net, MCSE/ MCSA 2003, CompTIA Sec+

2 1

[Repost][RFC] Alternative any design
by Pablo Aguilar 22 Aug '05

22 Aug '05

I posted this the same day 1.33 was released, but got no reply, I'd like to think it was due to bad timing rather than lack of interest. Any comments are welcome... ---- Original post ---- Hi, First of all, thanks to everyone who's commented on the proposed any alternative. Given that the alignment issue doesn't seem to be easy to solve, I'm thinking of giving up on trying to align correctly, and just skip the "in place storing of value" optimization when it might be an issue. So I'm wondering, is the following a proper way to detect alignment problems? <code> typedef void* any_buffer_base_type; // could be customized int const ANY_BUFFER_SIZE = sizeof(any_buffer_base_type); union object_holder { char buffer[ANY_BUFFER_SIZE]; void* pointer; any_buffer_base_type alignment_dummy_; }; template<typename T> struct optimize { enum { T_size_ = sizeof(T) , base_size_ = sizeof(any_buffer_base_type) , size_ok_ = (T_size_ <= base_size_) , T_align_ = alignment_of<T>::value , base_align_= alignment_of<any_buffer_base_type>::value , align_ok_ = ((base_align_ % T_align_) == 0) , value = size_ok_ && align_ok_ }; }; </code> I looked at Optional's alignment tecnique, and couldn't come up with how to use it, given that the stored type for any changes at runtime. If there's something I missed about this, any help would be welcome. My current solution is to use the above shown code (assuming it works, of course!), and fall back on heap based storage when optimization is deemed not possible. The 2nd question I had to ask is, how should any's alignment type be specified, with a configuration macro or through a template parameter? I haven't posted an updated version, given that there's some issues (other than alignment) still requiring attention. Thanks in advance for any help you might provide, Pablo Aguilar

2 2

Suggestion for serialization
by Scott Woods 21 Aug '05

21 Aug '05

Hi, I've been using a small family of templates that simplify the use of serialization. It's nothing tricky but it has a nice effect on application-level code. Rather than (from serialization tutorial); int main() { // create and open a character archive for output std::ofstream ofs("filename"); boost::archive::text_oarchive oa(ofs); // create class instance const gps_position g(35, 59, 24.567f); // write class instance to archive oa << g; // close archive ofs.close(); // ... some time later restore the class instance to its orginal state // create and open an archive for input std::ifstream ifs("filename", std::ios::binary); boost::archive::text_iarchive ia(ifs); // read class state from archive gps_position newg; ia >> newg; // close archive ifs.close(); return 0; } It could instead be expressed; int main() { // create and open a character archive for output // create class instance // write class instance to archive // close archive persistent<gps_position>( "filename", gps_position( 35, 59, 24.567f ) ); // ... some time later restore the class instance to its orginal state // create and open an archive for input // read class state from archive persistent<gps_position> g( "filename" ); // do something with g return 0; } Basic technique goes like; template<typename T> struct persistent : public T { typedef T persistent_type; std::string name; persistent( const std::string &s ) : name( s ) { load(); } persistent( const std::string &s, const persistent_type &initial ) : persistent_type( initial ), name( s ) { save(); } virtual ~persistent() { save(); } bool load() { std::ifstream ifs(name.c_str(), std::ios::binary); boost::archive::text_iarchive ia(ifs); ... } bool save() { std::ofstream ofs(name.c_str()); // Binary flag? boost::archive::text_oarchive oa(ofs); ... } }; I haven't listed my own code as it is much more lengthy. It includes finer control over the loading+saving automation (the implementation above is simplistic) and adds to the set of methods available, e.g. "blank" (delete the underlying file image). Its also non-boostified. This is just syntactic sugar for serialization (that would be caramelization?). Its also seems to be a useful example of generic coding. If anyone is interested in my header just mail me directly. Cheers, Scott ps: Some typos in serialization docs; 1. Strange grammar? "Depending on this context, this might used implement object persistence" 2.Spelling "are needed to associate a data item name with the correspoding xml tag"

2 2

[bjam] Trouble With Getting Started
by Rob Stewart 21 Aug '05

21 Aug '05

Like some others writing recently, I found that http://www.boost.org/more/getting_started.html doesn't paint the whole picture. In step five, the table describing the actions was a bit confusing. Some options were described with "<something>" values and others with "SOMETHING" values. I thought the latter were e-var references at first. Also in that table, there is mention of cygwin as a special case. Elsewhere, only *nix and windows are mentioned. Is cygwin considered *nix or windows in those other contexts? Another confusing aspect is where one should "install" boost. Upon downloading the tarball, where should one expand it? Once done, where should one tell bjam to install the files and how does that relate to where the tarball was expanded? There is no mention of the possible to simply install the header-only libraries. Perhaps that's not a supported option, but it should be. At the very least, there should be a way to install just the headers, without building any libraries, even if that includes headers for libraries that require a library. Then, folks can "install" Boost quickly, start using the header-only libraries and then, if desirable, go back and build the needed libraries. This would avoid the need to specify a toolset I think, so invoking bjam would be much simpler. Now for the real problem: When I ran bjam -sTools=gcc --prefix=d:/dev/boost install, I was surprised to find that bjam wouldn't create that directory. I created the directory and reran the command. Much to my chagrin, it then couldn't create d:/dev/boost/lib. I created that directory and reran the command. Finally, I thought, it needed but couldn't create "bin." Not "d:/dev/boost/bin" or some other fully qualified directory, but "bin." I tried creating d:/dev/boost/bin, but that didn't help. I didn't try creating $PWD/bin because I didn't really want files there. Since http://www.boost.org/more/getting_started.html doesn't mention a bin directory, I didn't know where else to create it. So, I could't seem to get bjam to build anything and it wasn't helping me to understand what was wrong. The error message was simple: MkDir1 bin spawn: No such file or directory This was in cygwin, so perhaps there's some confusion as to what should be on my path. At present, it's pretty simple: ~/bin:/bin:/usr/bin. Does bjam need more than that? If so, what? I don't know what MkDir1 is, so I was at somewhat of a loss. On a lark, I decided to set --builddir and rerun the command. I set it to d:/tmp/build and tried again. Lo and behold! It almost worked. The error then read: MkDir1 d:\tmp\build\bin spawn: No such file or directory That immediately made me wonder three things: 1. Why couldn't bjam create the bin subdirectory? 2. Why did bjam need to create a bin subdirectory instead of just using the directory I specified using --builddir? 3. Why didn't the error message indicate that "bin" was the --builddir value so I could know which parameter to manipulate? Well, the dance wasn't over yet. The next directory bjam wanted, but couldn't create was d:/tmp/build/bin/boost! Yes, I created that directory and tried again. Next I had to create d:/tmp/build/bin/boost/libs. Then it was d:/tmp/build/bin/boost/libs/date_time. I created that directory, too. Finally, I got this message: MkDir1 d:\tmp\build\bin\boost\libs\date_time\boost_date_time.dll spawn: No such file or directory At that point, I gave up. (No doubt I should have given up sooner!) Adding insult to injury were the interminable waits while bjam figured out over and over what needed to be done. Clearly, this isn't how things are supposed to work. Any ideas? -- Rob Stewart stewart(a)sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

2 3

[Boost-bugs] [ boost-Bugs-1265642 ] regex 1-32 math.h error when compiling with vc71
by SourceForge.net 21 Aug '05

21 Aug '05

Bugs item #1265642, was opened at 2005-08-21 11:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1265642&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: regex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: regex 1-32 math.h error when compiling with vc71 Initial Comment: Hi, just adding the <boost/regex.hpp> to my project generated a lot of errors in math.h: C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\xlocmon(231): fatal error C1903: unable to recover from previous error(s); stopping compilation C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(182): error C2059: syntax error : '(' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(182): error C2059: syntax error : '-' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(182): error C2059: syntax error : ')' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(528): error C2059: syntax error : '(' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(528): error C2059: syntax error : '-' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(528): error C2059: syntax error : ')' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(529): error C2143: syntax error : missing ';' before '{' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(529): error C2447: '{' : missing function header (old-style formal list?) C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(530): error C2059: syntax error : '(' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(530): error C2059: syntax error : '-' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(530): error C2059: syntax error : ')' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(531): error C2143: syntax error : missing ';' before '{' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(531): error C2447: '{' : missing function header (old-style formal list?) C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(536): error C2059: syntax error : '(' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(536): error C2059: syntax error : '-' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(536): error C2059: syntax error : ')' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(537): error C2143: syntax error : missing ';' before '{' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(537): error C2447: '{' : missing function header (old-style formal list?) C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(584): error C2059: syntax error : '(' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(584): error C2059: syntax error : '-' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(584): error C2059: syntax error : ')' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(585): error C2143: syntax error : missing ';' before '{' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\math.h(585): error C2447: '{' : missing function header (old-style formal list?) any ideas? thanks, KH ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1265642&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1265640 ] b 1_33_0 VC71 regex build fails
by SourceForge.net 21 Aug '05

21 Aug '05

Bugs item #1265640, was opened at 2005-08-21 11:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1265640&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: regex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: b 1_33_0 VC71 regex build fails Initial Comment: I was trying to to build the regex libraries but it failed with this: \regex\build>nmake vc71.mak Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. Building Boost.Regex without ICU / Unicode support: Hint: set ICU_PATH on the nmake command line to point to your ICU installation if you have one. NMAKE : fatal error U1073: don't know how to make '../../../boost/regex/config/allocator.hpp' Stop. ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1265640&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Boost regression notification (2005-08-21)
by Douglas Gregor 21 Aug '05

21 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-21T15:31:12Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 60 failures in 5 libraries: graph (11) parameter (6) python (22) serialization (20) wave (1) |graph| graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux mingw-3_4_2 vc-7_1 vc-7_1 vc-7_1 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 vc-6_5 vc-6_5-stlport |python| exec: cw-8_3 cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 vc-7_1 vc-7_1 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |wave| testwave: gcc-3.3.6-linux

1 0

Re: [boost] Boost 1.33 is an exe?
by David Abrahams 21 Aug '05

21 Aug '05

Scott Meyers <smeyers(a)aristeia.com> writes: > Just visited the semi-spiffed up (*) boost site to get 1.33 (not mentioned > at http://boost.org/more/version_history.html, BTW) That's for past versions. You can find out about 1.33 on the home page. > and I have a question to which I didn't see an answer. What's the > deal with a .exe distribution? This is a break with the past Seems to me there's a 1.32 exe also. It's just a self-extracting archive. > and it's not described anywhere that I can find. (Try as I might, I > can't make any sense of "Before downloading, you may want to read > Release Notes and ChangeLog (accessible by clicking on release > version)" at > http://sourceforge.net/project/showfiles.php?group_id=7586. The articles are missing. Does this help? "Before downloading, you may want to read the Release Notes and ChangeLog (accessible by clicking on the release version)" > The text "release version" exists on that page only in that > sentence, and ditto for "changelog" and "release notes".) I guess he also left off the word "number." Click on the text "1.33.0" on that page. > Sigh, I also managed to reproducably crash firefox trying to > download the file. Just worked for me. 'Course, I downloaded the .exe. The .zip seems to be doing just fine too. > The story of my life. I finally decided that while firefox was > downloading, it really didn't want to be doing anything else. Kind > of defeats the purpose of multiple tabs.... > > Thanks for any info you can offer on the .exe. > > Scott > > (*) The "semi" is because the home page now looks quite different from many > internal pages, e.g., compare the look of the home page with that of > http://boost.org/libs/libraries.htm. (This is not a complaint, just an > observation.) Work in progress. It's a huge job. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

Boostbook Trouble Again
by David A. Greene 21 Aug '05

21 Aug '05

I updated from the latest CVS today and I am having trouble building docs. I get the same errors from a fresh checkout. I followed the steps for automatic setup at http://www.boost.org/doc/html/boostbook/getting/started.html Still trying to build NTP docs. I got through most of my syntax errors before hitting this. I was having difficulty with getting Doxygen invoked for the reference portions and thought the auto-setup would help. Any ideas? -Dave >>-waller-> pwd /home/greened/src/boost/tools/build/jam_src >>-waller-> ls -l bin.linuxx86/ total 140 -rwxr-x--- 1 greened mirv 137744 Aug 20 23:11 bjam* cd /home/greened/ cd /home/greened/src/boost/doc && /home/greened/src/boost/tools/build/jam_src/bin.linuxx86/bjam --v2 /home/greened/src/boost/tools/build/v2/build/toolset.jam:26: in using *** argument error * rule boostbook.init ( docbook-xsl-dir ? : docbook-dtd-dir ? : boostbook-dir ? ) * called with: ( /home/greened/src/boost/boostbook/docbook-xsl-1.67.2 : /home/greened/src/boost/boostbook/docbook-dtd-4.2 using xsltproc : /usr/bin/xsltproc : : : : : ) * extra argument using /home/greened/src/boost/tools/build/v2/tools/boostbook.jam:63:see definition of rule 'init' being called /home/greened/user-config.jam:63: in modules.load /home/greened/src/boost/tools/build/v2/build-system.jam:115: in load /home/greened/src/boost/tools/build/v2/kernel/modules.jam:259: in import /home/greened/src/boost/tools/build/v2/kernel/bootstrap.jam:153: in boost-build /home/greened/src/boost/boost-build.jam:12: in module scope Compilation exited abnormally with code 1 at Sat Aug 20 23:16:25

1 0

[string_algo] Small documentation inconsistency regarding replace_all
by Eelis van der Weegen 21 Aug '05

21 Aug '05

The documentation for boost::algorithm::replace_all (at http://boost.org/doc/html/replace_all.html) lists void as the return type for the function, but further down mentions: "Returns: A reference to the modified input" Regards, Eelis

1 0

Re: [boost] asio networking proposal
by Dave Gomboc 21 Aug '05

21 Aug '05

> Sorry, I wasn't really clear before. The presence or not of the handler > parameter is the difference in the function *signatures*. How the > function actually behaves is quite different (a synchronous call blocks > the calling thread, an asynchronous call never blocks). It is not the > handler parameter that determines whether the operation is synchronous > or asynchronous; the handler is just the function that is called when > the asynchronous operation completes. Actually, I understood how you intended it to work, but I had been trying to convince myself that it's truly better for the asynchronous calls to have a different signature than the synchronous call, and I wasn't able to convince myself. So I was hoping that you'd do it. ;-) The devil's advocate position remains: synchronous operation is merely the particular case where the handling policy prevents the function from returning control to the caller until the operation has completed; no unique function signature is warranted. > What do you think of my proposal in my email earlier today where > basically I use "read" and "write" for the operations that are in the > *Stream concepts (and so could equally apply to pipes, files and so > on), but retain "send" and "receive" (and "send_to" and "receive_from") > for operations that are specific to sockets? It would be better if use of "read" and "write" were ubiquitious, but if there's an overloading clash, I guess you have to do what you have to do. Dave

2 1

[Wave] Does it do phases?
by Daryle Walker 20 Aug '05

20 Aug '05

Wave is our C++ preprocessor, but preprocessing is the third phase of translating a file. (Looking at section 2.1 in the standard). I have a gut feeling that all the compilers out there mush the first three phases together in parsing a file. Glancing over the Wave docs gives me the same impression about it. Are either one of these feelings accurate (this requires a separate answer for each parser)? If the answer for Wave is "yes", could we separate them, at least as an option? I feel that this is important so we can gain full understanding of each phases. It may be more complicated[1], and most likely slower, but it could represent a clean implementation. (BTW, what phases does Wave act like?) The first two[2] phases are: 1. Native characters that match basic source characters are converted as so (including line breaks). Trigraphs are expanded to basic source[3]. Other characters are turned into internal Unicode expansions (i.e. act like "\uXXXX" or \Uxxxxxxxx"[4]). 2. The backslash-newline soft line-break combination are collapsed, folding multiple native lines into one logical line. We should spit out an error if the folding creates Unicode escapes. For non-empty files, we need to spit out errors if the last line is not a hard line-break, either a non-newline character or a backslash-newline combination is forbidden. [1] Our "Wave-1" would convert the original text (iterators) into phase-1 tokens. Our "Wave-2" would convert phase-1 token (iterators) into phase-2 tokens, etc. Remember that any file-name and line/column positions will have to be passed through each phase. [2] I thought Wave just did phase-3, with phases 1 and 2 thrown in at the same time. But now I'm not sure which phase Wave stops at. I don't think it can go past phase-4, because doing phase-5 needs knowledge of the destination platform. [3] Only '?' characters that are part of a valid trigraph sequence are converted; all others are left unchanged. [4] But actual "\uXXXX" resolution doesn't happen until phase 5! -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

Random access and memoization in TMP
by Bruno Martínez 20 Aug '05

20 Aug '05

Hi. I was pondering the other day about the unique built in memoization capabilities of templates. It ocurred to me that if one could share more between different instantiations the compilation process would be sped up. For example, take drop :: Int -> [a] -> [a] defined so that (drop 0 list) is (list) (drop 1 list) is (tail list) (drop 2 list) is (tail (tail list)) in Haskell this would be written drop 0 list = list drop n list = drop (n-1) (tail list) So that the last clause exploits last call optimization. However, another way would be drop 0 list = list drop n list = tail (drop (n-1) list) Now, take at :: Int -> [a] -> a at n list = head (drop n list) If I construct a list in O(n) and then take the last element with at, also in O(n), then access to every element becomes O(1), because traversing to the last element precalculated all the other positions. I made a test with gcc, in which I traverse a list in forward direction but naively use at to get to the current position. There are four variants. homemade_slow uses the first drop definition. homemade_fast uses the second. mpl_vector and mpl_list use those sequence classes. The times were, in seconds: homemade_slow 41 homemade_fast 0.7 mpl_vector 4 mpl_list 11 I've been thinking the past days of other functions like drop that could be improved in a similar way, but they have eluded me. I didn't find mention of similar techniques in the MPL book, so I wonder if I'm making any sense. Regards, Bruno

3 11

[date_time] Constructor causes syntax error
by Markus Schöpflin 20 Aug '05

20 Aug '05

The latest CVS contains the following code in boost/date_time/date_generator_parser.hpp: date_generator_parser(const date_generator_parser<date_type,charT>* dgp) ------------------------------------------------------------------^ { this->m_element_strings = dgp.m_element_strings; -------------------------------^ } This is a typo, isn't it? Shoudn't this be a copy constructor? Markus

5 5

Boost regression notification (2005-08-20)
by Douglas Gregor 20 Aug '05

20 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-20T15:26:15Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 61 failures in 5 libraries: graph (11) parameter (7) python (22) serialization (20) wave (1) |graph| graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux mingw-3_4_2 vc-7_1 vc-7_1 vc-7_1 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 msvc vc-6_5 vc-6_5-stlport |python| exec: cw-8_3 cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 vc-7_1 vc-7_1 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |wave| testwave: gcc-3.3.6-linux

1 0

Who is using Boost? - 2 Submissions
by Andreas Pokorny 20 Aug '05

20 Aug '05

Hi, I am maintaining and refactoring two GPL applications at the department of bioinformatics (read: computer science and biology) at the University of Würzburg. The upcoming release of Porfdist is using a boost in many places, and the already released CBCAnalyzer is also boost powerd. It might be nice to have them mentioned on the "Who is using Boost" page. Name: CBCanaylzer Developed by: Department of Bioinformatics, at the University of Wuerzburg CBCAnalyzer (CBC = compensatory base change) is a tool to create ``small'' phylogenetic trees from sequence alignments. To measure the distance of sequences the compensatory base changes are detected and counted. The bionj algorithm is then used to construct a tree. CBCAnalyzer is available on Windows, Linux and partly works on MacOSX. Libraries: Program Options - creates really nice output, and is both easy to extend and simple to handle. Iterator, Spirit - Saved a lot of my time, and makes the vast amount of biological file formats simple to support, Shared Pointer, Lambda, URL: http://www.biozentrum.uni-wuerzburg.de/index.php?id=524 Name: Profdist Developed by: Department of Bioinformatics, at the University of Wuerzburg Profdist is a tool for the construction of large phylogenetic trees based on profile distances. The input alignment data gets extended by random picking of rows, and a clustering technique is used to create profiles of the most frequent subtrees. The iterative approach allows working on large datasets. Currently the application is very limited by the quality of wxWidgets, and only available for Windows and Linux. Libraries: String Algorithms, Ref, Iterator, Spirit, Shared Pointer, Lambda, URL: http://www.biozentrum.uni-wuerzburg.de/index.php?id=523 Regards Andreas Pokorny

2 1

boost::detail namespace
by Marcin Kalicinski 20 Aug '05

20 Aug '05

Hi, Most boost projects use boost::detail namespace to implement hidden, private functionality. What prevents name clashes in that namespace? Marcin

5 11

Re: [boost] Interest for a perl6-like-junctions-class?
by Rob Stewart 20 Aug '05

20 Aug '05

I uploaded some fixes to multivalues.zip: - Workaround for BCB's lack of EBO - Fixed some overzealous searches/replaces - Eliminated SFINAE from test program - Moved some tests out of the macros to assist in debugging, should anyone have problems with support in a particular compiler. Some questions: - What operator(s) should we use to delimit user-defined predicates? Here are some interesting candidates: if (any_of(...) << some_predicate() >> 5)... // 1 if (any_of(...) < some_predicate() > 5)... // 2 if (any_of(...) ^ some_predicate() ^ 5)... // 3 if (any_of(...) / some_predicate() / 5)... // 4 1 seems pretty good because the two-character operators stand out well. 2 works pretty well, but I'm concerned that the operators may get lost if the predicate is a specialization of a template type; the template argument list uses the same tokens. (1 is better in that case because of the doubled tokens.) 3 is an unusual operator to overload, so it is largely unique to this context. 4 works, but I'm concerned that it is gross misuse of the operator (overloading it for division and filesystem path manipulation are sensible; is this?). - Should we attempt VC6 support? If so, some functionality or syntax will have to be sacrificed. It may be that the iterator pair support is all that we must sacrifice. -- Rob Stewart stewart(a)sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

4 7

[serialization]Boost.Serialization1.33.0BreaksSerializationCodeinDLLs
by Kim Barrett 20 Aug '05

20 Aug '05

I've been reading this thread with increasing alarm. I agree with Martin Ecker and Vladimir Prus that the synchronization in question belongs inside the serialization library. The system we are building will have several inter-process communication mechanisms, which I'm hoping to be able to build on top of Boost.Serialization. (As noted in another thread, I've run across some performance issues, which might be addressed by resetting and reusing archives, rather than constructing new archives all the time.) It is expected in our system design that it will be possible to dynamically load DLLs containing new types which support serialization, and then create new IPC connections (with associated archives) to/from which instances of those newly loaded types can be serialized. It is not a requirement that previously existing IPC connections (and their associated archives, either presently in use, or available for reuse if archive resetting is used) support these new types, since the type information for the connection is specified at connection creation time. We expect a substantial number of such connections to exist at any one time, with many threads involved, and they have some latency requirements. We presently plan to punt support for unloading DLLs, on the basis that the benefit (in our system) would be small compared to the design / implementation / documentation cost for supporting unloading safely and correctly. (We might revisit the decision about unloading, but for now supporting it is not a requirement for us.) I'm pretty sure that intertwining runtime DLL loading with all of our clients of the serialization library is just not going to fly. I think that making it a configuration option whether the library protects its internal data structures is a reasonable approach, since some applications won't need it (either because they are single-threaded or are willing to deal with the issues at the application level) and might not want to pay the cost. But for some applications, having the library be responsible for the consistency of its internal data structures is really the only realistic option. I think the only way I will be able to sell the use of the serialization library for our project is to either convince you to change on this issue, or to obtain or develop a patch and carry it forward. The latter might be less work in the long term than developing the subset of serialization features that we actually need, but the long-term maintenance headache for a patch is worrisome.

2 2

Distributing subsets of Boost libraries
by Richard Hadsell 20 Aug '05

20 Aug '05

It is obvious that the Boost library collection is quite large and growing, and it probably will never decrease. It takes a long time to build the libraries that require building and to copy the headers from one place to another. It would be really nice for me (and for others, I suspect) to be able to request just the subset of libraries that I use. I would like the developers to think of a mechanism to break up the collection into subsets. Of course, there could be one subset that is common to all, and there could be other subsets that are common to a group of libraries. It would make sense to keep the number of subsets small by placing libraries with similar functionality or dependencies into a single subset. If you want to get fancy, you could include a library in multiple subsets. Whatever makes sense should be fine with most users. I just ask you to consider the desirability of restructuring the distributions. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

2 1

Plans for 1.33.1?
by John Maddock 20 Aug '05

20 Aug '05

I notice that there are already a few patches that have gone into the RC_1_33_0 branch, presumably in expectation of a 1.33.1 release? So some questions: 1) Is the release branch now officially open again for patches: I assume that it is now that the release is out. 2) Is there any interest in either a hotfix patch-release or possibly a full 1.33.1 in 4 to 6 weeks time? If yes, then I believe we really need to start a readme file with a list of patches made - this would become the readme for the patch when it's released. Thoughts? John.

12 21

Fall Review Schedule - version 2.0
by Tom Brinkman 20 Aug '05

20 Aug '05

Boost Fall Review Schedule - version 2.0 Contact Tom Brinkman at reportbase(a)gmail.com to request a review, to make updates to this document or to volunteer to be a review manager. The next library up for review is the xpressive library by Eric Niebler on September 8, 2005. It is available at http://boost-sandbox.sf.net/vault/index.php?directory=eric_niebler. This library still needs a review manager. Please contact me to volunteer. Following the review of the xpressive library is the TR1 library by John Maddock at john(a)johnmaddock.co.uk. The review is set for September 20, 2005. This library can be download at http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&di…. This library needs a review manager volunteer also. Lets all make an effort to get more involved in the review processes this fall. I know the library authors would love to get more feedback. Check out the Boost::wiki page for New Libraries Under Construction at http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?LibrariesUnd… If your one of the libray's authors or active users, please feel free to make any changes to the libraries summary description. Click the question mark to add more detailed information about the library. Review Queue as of August 16, 2005. Confirmed: 1. xpressive - Eric Niebler (September 8, 2005) 2. TR1 - John Maddock (September 20, 2005) 3. logging - John Torjo (October 5, 2005) To be Confirmed: 4. singleton - Jason Hise (postponed) 5. function types - Tobias Schwinger (mini post-review needed) 6. output formatters - Reece Dunn (new review needed) 7. policy pointer - David B. Held 8. fixed strings - Reece Dunn 9. intrusive - Olaf Krzikalla 10. interfaces - Jonathan Turkanis 11. binary_int - Scott Schurr (ready to be reviewed) 1. xpressive Author: Eric Niebler eric(a)boost-consulting.com Review Manager: needed Download: http://boost-sandbox.sf.net/vault/index.php?directory=eric_niebler Docs: http://boost-sandbox.sf.net/libs/xpressive Review Date: September 8, 2005 xpressive is a TR1 regex work-alike that also accepts regexes as expression templates and lets regexes nest and call each other recursively. Significant changes since 0.9.3 - c_regex_traits to wrap the global C locale - null_regex_traits for searching non-char data - doc and test improvements - bugs in static regexes and Unicode support squashed You can consider this the xpressive 1.0 release candidate. All that remains is to add more tests and documentation, and perhaps a tweak to the traits interface. 2. TR1 Author - John Maddock john(a)johnmaddock.co.uk Review Manager - needed Download - http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&di… Docs - in download file Review Date: September 20, 2005 (follows xpressive) The TR1 library provides an implementation of the C++ Technical Report on Standard Library Extensions. This library does not itself implement the TR1 components, rather it's a thin wrapper that will include your standard library's TR1 implementation (if it has one), otherwise it will include the Boost Library equivalents, and import them into namespace std::tr1. Functionality supported includes: Reference Wrappers, Smart Pointers, Class template result_of.,Function template mem_fn., Function Object Binders, Polymorphic function wrappers, Type Traits, Random Number Generators and Distributions, Tuples, Tuple Interface to std::pair, Fixed Size Array, Hash Function Objects, Regular Expressions, Complex Number Algorithm Overloads, Complex Number Additional Algorithms, Functionality in TR1 but not yet available in this implementation: Mathematical Special Functions, Unordered Associative Set (Hash Table), Unordered Associative Map (Hash Table), C99 C language additions. This library also makes changes to Boost.Config, and adds some new functionality to Boost.Math, reviewers should start with the readme.html in the root directory of the zip file. 3. logging Author - John Torjo john(a)torjo.com Review Manager - Hartmut.Kaiser Hartmut.Kaiser(a)gmail.com Download: http://torjo.com/code/logging.zip Docs: http://torjo.com/ Review Date: October 5, 2005 (follows TR1) The Boost Log Library is a small library, who: * makes it very easy to declare/define new logs * allows you very simple access to logs * allows for log hierarchies, and for modifying log hierarchies * allows for easy and efficient enabling/disabling of logs/log hierarchies * allows for easy manipulation of log behaviors (the log's destination(s) and/or adjusting the original message) * is thread-safe Using the library in code is easy and straightforward: int i = 1, j = 2, k = 3; BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k << std::endl; BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something...."; Recent Additions: - can be compiled as a static/dynamic runtime (works as a DLL as well) - removed dependency on boost_thread Note: I did not test this on Unix, but it should work. If anybody can take a look at detail/ts_posix.hpp, I'd appreciate it. - solved other small issues, based on feedback - slightly improved documentation 4) Singleton Author - Jason Hise chaos(a)ezequal.com Review Manager - Andreas Huber ahd6974-groups(a)yahoo.com Download: http://tinyurl.com/6qvrd (old version from previous review) Docs: http://tinyurl.com/6qvrd Review Date: Winter-2006 The singleton library provides multiple powerful methods of controlling the lifetimes of global resources. Client code can choose among the many provided methods of creation, or can easily write new creators for specialized initialization needs. Client code can additionally control precisely when a singleton instance is automatically created and destroyed, can create and destroy singleton instances explicitly any number of times, and can set up dependencies between singletons in an easy and natural way. Jason has stated that he will not be ready for the next review for a few months. 5) Function Types Author - Tobias Schwinger tschwinger(a)neoscientists.org Review Manager - John Maddock john(a)johnmaddock.co.uk Download: http://tinyurl.com/4oe7q (old version - from previous review) Docs: http://tinyurl.com/4oe7q Review Date: needed This library provides a metaprogramming facility to classify, decompose and synthesize function-, function pointer-, function reference- and member function pointer types. For the purpose of this documentation, these types are collectively referred to as function types (this differs from the standard definition and redefines the term from a programmer's perspective to refer to the most common types that involve functions). The classes introduced by this library shall conform to the concepts of the Boost Metaprogramming library (MPL). The Function Types library enables the user to: * test an arbitrary type for being a function type of specified kind, * inspect properties of function types, * view and modify sub types of an encapsulated function type with MPL Sequence operations, and * synthesize function types. This library supports variadic functions and can be configured to support non-default calling conventions. This library was reviewed June 2005 and was accepted pending a mini post-review. 6. Output formatters Author - Reece Dunn msclrhd(a)hotmail.com Review Manager - needed Download: needed Docs: needed Review Date: needed This library was reviewed september 11, 2004. It requires a second full review. 7. Policy Pointer Author - David B. Held dheld(a)codelogicconsulting.com Review Manager - Gennadiy gennadiy.rozental(a)thomson.com Download: Boost Sandbox under policy_ptr Docs: Boost Sandbox under policy_ptr Review Date: needed Smart pointers are used to automate memory management by handling the deletion of dynamically allcoated objects (and other resources). They assist in ensuring program correctness, exception safety, and memory integrity. Policy Pointer is a policy-based smart pointer framework designed to accomodate the large number of smart pointer designs. Through the use of policy classes, virtually any smart pointer type can be constructed within this framework. This library is a Boostification of the original Loki::SmartPtr type with significant modifications. 8. Fixed Strings Author - Reece Dunn msclrhd(a)hotmail.com Review Manager - Beman Dawes bdawes(a)acm.org Download: boosts-sandbox/boost/fixed_string Docs: boosts-sandbox/boost/fixed_string Review Date: needed The fixed string library provides buffer overrun protection for static sized strings (char s[ n ]). It provides a C-style string interface for compatibility with C code (for example, porting a C program to C++). There is also a std::string-style interface using a class based on flex_string by Andre Alexandrescu with a few limitations due to the non-resizable nature of the class. 9. Intrusive Author - Olaf Krzikalla krzikalla(a)gmx.de Review Manager - needed Download: http://people.freenet.de/turtle++/intrusive.zip Docs: http://people.freenet.de/turtle++/intrusive.zip Review Date: needed While intrusive containers were and are widely used in C, they became more and more forgotten in the C++-world due to the presence of the standard containers, which don't support intrusive techniques. Boost.Intrusive not only reintroduces this technique to C++, but also encapsulates the implementation in STL-like interfaces. Hence anyone familiar with standard containers can use intrusive containers with ease. 10. Interfaces Author - Jonathan Turkanis technews(a)kangaroologic.com Review Manager - needed Download: http://www.kangaroologic.com/interfaces Docs: http://www.kangaroologic.com/interfaces Review Date: needed "Boost.Interfaces provides a macro-based Interface Definition Language (IDL) which can be used to define C++ class types called interfaces. An interface is a lightweight value type associated with a set of named function signatures. An interface instance can be bound at runtime to any object which implements the interface, i.e., to any object of a type with accessible non-static member functions having the same name and signature as the set of functions associated with the interface. The functions of the bound object can then be invoked through the interface instance using the 'dot' operator. Binding is completely non-intrusive: the object's type need not declare any virtual functions or derive from any particluar base class. "Current applications of Boost.Interfaces include: * Non-intrusive dynamic polymorphism — interfaces can often be used in place of abstract base classes, and are sometimes much faster (see Performance). * Dynamic inheritance — allows function calls to be forwarded automatically to an object specified at runtime (see Delegation). * Smart Interface Pointers — smart pointers which can manage the lifetime of any object whose type implements a given interface. * Smart References — like smart interface pointers, but the managed object is accessed using the "dot" operator." 11. binary_int Author: Scott Schurr scott_schurr(a)credence.com Review Manager: pavel_vozenilek(a)hotmail.com Download: needed Docs: needed Review Date: October, 2005 (ready to be reviewed) The binary_int<> template allows the compile-time expression of integer binary literals. There is no run-time code overhead for using this template; all overhead is at compile time. I expect these binary literals to work any place that an integer literal would work at compile (not preprocessing) time. The template is designed to allow binary values up to 64-bits to be expressed, although it has only been tested up to 32-bits to date.

3 2

Re: [boost] (Vector) norm functions?
by Michael Stevens 19 Aug '05

19 Aug '05

On Friday 19 August 2005 17:48, Neal Becker <ndbecker2(a)gmail.com> wrote: > David Abrahams wrote: > > > Daryle Walker <darylew(a)hotmail.com> writes: > > > >> Should we add functions to evaluate the various norms of a (numeric) > >> sequence? > > > > I'm fairly certain that functionality is in uBlas already. > > > > Yes, but just for ublas vector, not for generic sequences, right? True. But you can adapt many STL containers (such as std::vector) into a uBLAS Storage model which can be accessed as a vector. The overhead would not be great. Such adaptors would make an interesting addition to uBLAS -- ___________________________________ Michael Stevens Systems Engineering 34128 Kassel, Germany Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

Missing archives? Early releases.
by Daryle Walker 19 Aug '05

19 Aug '05

Looking at <http://lists.boost.org/Archives/boost/>, some of the early months are missing: March 2000, February 2000, March 1999, January 1999, and anything on or before October 1998 (if any). I was looking for information on early releases. I saw an article from Beman on 1999-12-30 about v1.10.3, claiming that it was the first numbered release. And that he keeps backups of the old site. I wonder if he could find versions of Boost before 1.11.2 (that's the earliest I found in CVS). -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

Boost regression notification (2005-08-19)
by Douglas Gregor 19 Aug '05

19 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-19T15:45:26Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 64 failures in 6 libraries: graph (11) iostreams (3) parameter (9) python (20) serialization (20) wave (1) |graph| graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux mingw-3_4_2 vc-7_1 vc-7_1 vc-7_1 |iostreams| bzip2_test: mingw-3_4_2 gzip_test: mingw-3_4_2 zlib_test: mingw-3_4_2 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 cw-9_4 intel-win32-8_1 msvc vc-6_5 vc-6_5-stlport |python| exec: cw-8_3 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 vc-7_1 vc-7_1 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |wave| testwave: gcc-3.3.6-linux

1 0

OpenOffice is using Boost
by Fredrik Blomqvist 19 Aug '05

19 Aug '05

Hi, I recently browsed the OpenOffice source and noticed that it uses Boost. This seems like an excellent candidate to promote. Btw, when I look at the other entries in the users lists, I get the feeling that a lot of companies where "boosters" work must be missing? Obvious examples would be MetaCommunications (Aleksey) and I guess/assume also ReadSoft (Björn Karlsson) and Housemarque (Vesa). I guess it's up to the respective indivuduals to decide on this though, just wanted to remind :) Regards // Fredrik Blomqvist

2 1

Rational Discovery is using Boost
by Greg Landrum 19 Aug '05

19 Aug '05

I somehow have kept forgetting to submit this: Company: Rational Discovery LLC Rational Discovery provides computational modeling, combinatorial library design and custom software development services to the pharmaceutical, biotech and chemical industries. We do a substantial amount of internal research to develop new approaches for applying machine-learning techniques to solve chemical problems. Because we're a small organization and chemistry is a large and complex field, it is essential that we be able to quickly and easily prototype and test new algorithms. We have found the Boost libraries, a reliable source of high-quality code, to be indispensable. Libraries used: python, graph, smart_ptr, any, lexical_cast, random, string_algo, tuple, uBLAS, URL: http://www.rationaldiscovery.com Parts of this blurb were taking the "who's using Boost.Python" page. Best Regards, -greg

2 1

Fall Review Schedule - version 1.0
by Tom Brinkman 19 Aug '05

19 Aug '05

Boost Fall Review Schedule - version 1.0 Contact Tom Brinkman at reportbase(a)gmail.com to request a review, to make updates to this document or to volunteer to be a review manager. Review Queue as of August 14, 2005. Not in any particular: 1. xpressive - Eric Niebler 2. logging - John Torjo 3. singleton - Jason Hise (new review needed) 4. function types - Tobias Schwinger (mini post-review needed) 5. output formatters - Reece Dunn (new review needed) 6. policy pointer - David B. Held 7. fixed strings - Reece Dunn 8. intrusive - Olaf Krzikalla 9. interfaces - Jonathan Turkanis Other Libraries: 10. factory - Federico Stella f.stella(a)flashnet.it 11. TR1 1. xpressive - Author: Eric Niebler eric(a)boost-consulting.com> Review Manager: needed Download: http://boost-sandbox.sf.net/vault/index.php?directory=eric_niebler Docs: http://boost-sandbox.sf.net/libs/xpressive Review Date: to be confirmed xpressive is a TR1 regex work-alike that also accepts regexes as expression templates and lets regexes nest and call each other recursively. Significant changes since 0.9.3 - c_regex_traits to wrap the global C locale - null_regex_traits for searching non-char data - doc and test improvements - bugs in static regexes and Unicode support squashed You can consider this the xpressive 1.0 release candidate. All that remains is to add more tests and documentation, and perhaps a tweak to the traits interface. 2. logging Author - John Torjo john(a)torjo.com Review Manager - Hartmut.Kaiser Hartmut.Kaiser(a)gmail.com Download: http://torjo.com/code/logging.zip Docs: http://torjo.com/ The Boost Log Library is a small library, who: * makes it very easy to declare/define new logs * allows you very simple access to logs * allows for log hierarchies, and for modifying log hierarchies * allows for easy and efficient enabling/disabling of logs/log hierarchies * allows for easy manipulation of log behaviors (the log's destination(s) and/or adjusting the original message) * is thread-safe Using the library in code is easy and straightforward: int i = 1, j = 2, k = 3; BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k << std::endl; BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something...."; Recent Additions: - can be compiled as a static/dynamic runtime (works as a DLL as well) - removed dependency on boost_thread Note: I did not test this on Unix, but it should work. If anybody can take a look at detail/ts_posix.hpp, I'd appreciate it. - solved other small issues, based on feedback - slightly improved documentation 3) Singleton Author - Jason Hise chaos(a)ezequal.com Review Manager - Needed Download: http://tinyurl.com/6qvrd (old version from previous review) Docs: http://tinyurl.com/6qvrd The singleton library provides multiple powerful methods of controlling the lifetimes of global resources. Client code can choose among the many provided methods of creation, or can easily write new creators for specialized initialization needs. Client code can additionally control precisely when a singleton instance is automatically created and destroyed, can create and destroy singleton instances explicitly any number of times, and can set up dependencies between singletons in an easy and natural way. 4) Function Types Author - Tobias Schwinger tschwinger(a)neoscientists.org Review Manager - John Maddock john(a)johnmaddock.co.uk Download: http://tinyurl.com/4oe7q (old version - from previous review) Docs: http://tinyurl.com/4oe7q This library provides a metaprogramming facility to classify, decompose and synthesize function-, function pointer-, function reference- and member function pointer types. For the purpose of this documentation, these types are collectively referred to as function types (this differs from the standard definition and redefines the term from a programmer's perspective to refer to the most common types that involve functions). The classes introduced by this library shall conform to the concepts of the Boost Metaprogramming library (MPL). The Function Types library enables the user to: * test an arbitrary type for being a function type of specified kind, * inspect properties of function types, * view and modify sub types of an encapsulated function type with MPL Sequence operations, and * synthesize function types. This library supports variadic functions and can be configured to support non-default calling conventions. This library was reviewed June 2005 and was accepted pending a mini post-review. 5. Output formatters Author - Reece Dunn msclrhd(a)hotmail.com Review Manager - Needed Download: Docs: This library was reviewed september 11, 2005. It requires a second full review. 6. Policy Pointer Author - David B. Held dheld(a)codelogicconsulting.com Review Manager - Gennadiy gennadiy.rozental(a)thomson.com Download: Boost Sandbox under policy_ptr Docs: Boost Sandbox under policy_ptr Smart pointers are used to automate memory management by handling the deletion of dynamically allcoated objects (and other resources). They assist in ensuring program correctness, exception safety, and memory integrity. Policy Pointer is a policy-based smart pointer framework designed to accomodate the large number of smart pointer designs. Through the use of policy classes, virtually any smart pointer type can be constructed within this framework. This library is a Boostification of the original Loki::SmartPtr type with significant modifications. 7. Fixed Strings Author - Reece Dunn msclrhd(a)hotmail.com Review Manager - Beman Dawes bdawes(a)acm.org Download: boosts-sandbox/boost/fixed_string Docs: boosts-sandbox/boost/fixed_string The fixed string library provides buffer overrun protection for static sized strings (char s[ n ]). It provides a C-style string interface for compatibility with C code (for example, porting a C program to C++). There is also a std::string-style interface using a class based on flex_string by Andre Alexandrescu with a few limitations due to the non-resizable nature of the class. 8. Intrusive Author - Olaf Krzikalla krzikalla(a)gmx.de Review Manager - needed Download: http://people.freenet.de/turtle++/intrusive.zip Docs: http://people.freenet.de/turtle++/intrusive.zip While intrusive containers were and are widely used in C, they became more and more forgotten in the C++-world due to the presence of the standard containers, which don't support intrusive techniques. Boost.Intrusive not only reintroduces this technique to C++, but also encapsulates the implementation in STL-like interfaces. Hence anyone familiar with standard containers can use intrusive containers with ease. 9. Interfaces Author - Jonathan Turkanis technews(a)kangaroologic.com Review Manager - needed Download: http://www.kangaroologic.com/interfaces Docs: http://www.kangaroologic.com/interfaces "Boost.Interfaces provides a macro-based Interface Definition Language (IDL) which can be used to define C++ class types called interfaces. An interface is a lightweight value type associated with a set of named function signatures. An interface instance can be bound at runtime to any object which implements the interface, i.e., to any object of a type with accessible non-static member functions having the same name and signature as the set of functions associated with the interface. The functions of the bound object can then be invoked through the interface instance using the 'dot' operator. Binding is completely non-intrusive: the object's type need not declare any virtual functions or derive from any particluar base class. "Current applications of Boost.Interfaces include: * Non-intrusive dynamic polymorphism — interfaces can often be used in place of abstract base classes, and are sometimes much faster (see Performance). * Dynamic inheritance — allows function calls to be forwarded automatically to an object specified at runtime (see Delegation). * Smart Interface Pointers — smart pointers which can manage the lifetime of any object whose type implements a given interface. * Smart References — like smart interface pointers, but the managed object is accessed using the "dot" operator."

11 11

(Vector) norm functions?
by Daryle Walker 19 Aug '05

19 Aug '05

Should we add functions to evaluate the various norms of a (numeric) sequence? //======================================================================= template < typename Number, typename InputIterator > Number norm_1( InputIterator b, InputIterator e ) { using std::abs; return std::accumulate( b, e, Number(), abs(_1) + abs(_2) ); } template < typename Number, typename InputIterator > Number norm_2( InputIterator b, InputIterator e ) { using std::sqrt; return sqrt( std::inner_product( b, e, b, Number() ) ); } template < typename Number, typename InputIterator > Number norm_infinity( InputIterator b, InputIterator e ) { using std::abs; return abs( *std::max_element( b, e, abs(_1) < abs(_2) ) ); } template < typename Number, typename InputIterator > Number norm_x( int n, InputIterator b, InputIterator e ) { switch ( n ) { default: { using std::pow; using std::abs; Number r = Number(); for ( ; b != e ; ++b ) { r += pow( abs(*b), n ); } return root( r, n ); } case 2: return norm_2<Number>( b, e ); case 1: return norm_1<Number>( b, e ); case 0: // You can't really have a zero-norm // And you can't pass in infinity as a parameter // So we have 0 -> infinity return norm_infinity<Number>( b, e ); } } //======================================================================= I just wrote that here, so I don't know if it can work. I don't know if I used the bind/lambda stuff correctly, and there's still the problem that the "root" function doesn't exist. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 3

Re: [boost] serialization queston
by Robert Ramey 19 Aug '05

19 Aug '05

Upon (re) reading this, I'm not really sure what is being suggested here. That's why I didn't respond to the original post. I think my view that there is no problem probably reflects my lack of understanding of the original question. Anyway - here it is. Robert Ramey >Why not make include polymorphic_archive automatic? And make other >archive types resort to polymorphic_archive when no serialization for >that archive type was BOOST_CLASS_EXPORTED. As you say, the only cost >is a "teensy bit of execution time", in most cases users won't even >notice, but the code size will be reduced. I am generally not in favor of adding code not requested by the library user and not required. I much prefer that the library reflect what the user has said he wants. So my view is there are a couple of options. a) if one want's to use a polymorphic archive, include that in a (possibly precompiled) module. b) if one want's to use the template archive implementations, specify the ones you want. c) if this generates too much code bloat, make a library which includes any or all of the above. Its fairly easy to do this. Then link against your library of serialization implementations. Only ones actually used will be included in your program. So this would automatically give you access to ALL archive implementations without including dead code in your applications. The C++ module to build the library would look something like: #include <boost/archive/text_iarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/archive/xml_iarchive.hpp> ... #include <boost/archive/polymorphic_iarchive.hpp> #include <boost/archive/polymorphic_oarchive.hpp> #include A.hpp #include B.hpp ... // if class modules above don't include export then BOOST_CLASS_EXPORT(A) BOOST_CLASS_EXPORT(B) Robert Ramey

2 2

Re: [boost] It's a digraph. (was: Re: Interest in an ODBC library?)
by Jonathan Wakely 19 Aug '05

19 Aug '05

Daryle Walker wrote: > On 8/18/05 4:57 AM, "Jonathan Wakely" <cow(a)compsoc.man.ac.uk> wrote: > > > postgresql/connect.cpp accidentally uses the <:: trigraph in the > > typedefs at the top of the file. You need a space before the template > > args to avoid that. > > I think you mean the "<:" digraph. It represents the "[" (opening square > bracket) character. The official term is "alternative token" (see section > 2.5 of the standard), because some of the tokens have more than two > characters. (These include the bitwise and Boolean word operators, i.e. > "and".) They're considered after the preprocessor (phase 3 of section 2.1), > and trigraphs are done earlier than that (in phase 1). Yep, you're absolutely right -- thanks. I didn't pay a lot of attention to the exact compiler diagnostic, just added a space and got on with it. jon

1 0

[Boost-bugs] [ boost-Support Requests-1263909 ] missing boost_thread-vc71-mt1_32.dll
by SourceForge.net 19 Aug '05

19 Aug '05

Support Requests item #1263909, was opened at 2005-08-19 05:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1263909&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: missing boost_thread-vc71-mt1_32.dll Initial Comment: I installed a USB driver and now I am getting this message every time I start up my computer, either from reboot or from sleep: Title: scdclient.tmp.exe unable to locate component Message essence: boost_thread-vc71-mt1_32.dll is missing; need to reinstall application I searched the list of products that use this dll and I don't have any of those installed.I am running on Microsoft XP Pro, and have various applications such as Macromedia studio, Oracle 9i, Visio 2000, Microsoft Office XP, and others installed. And ideas what I should reinstall? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1263909&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

memory management
by Bojan �ffff8aernek 19 Aug '05

19 Aug '05

hello! I'm looking for a smart pointer that would support cycles and reference counting. Any boost lib / experimental lib that springs to mind? Thanks, Bojan. __________________________________ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html

1 0

[serialization] Performance issues serializing lots of objects
by Adrien Gervaise 19 Aug '05

19 Aug '05

Hi ! We've been successfully using the boost serialization library on various industrial projects. One one occasion though, we had to make a modification in the source code in order to improve the performance of the process : The library uses a set (in basic_oarchive.cpp) to keep track of the serialized objects. In our project, a very high number of relatively small objects are serialized through pointers and references to each other, and the number of elements in the set could rocket to several millions. This led to memory fragmentation and very high performance hits after the first serialization (on a Windows XP platform at least). We just added a boost::fast_pool_allocator on the set of serialized pointers. The set is cleared in the destructor of the archive, after which release_memory() is called on the pool. This simple patch could reduce the time to perform a whole save from several minutes to a few seconds. Best regards, -- Adrien Gervaise MasaGroup SCI

4 4

Re: [boost] asio networking proposal
by Martin Bonner 19 Aug '05

19 Aug '05

----Original Message---- From: Thorsten Ottosen [mailto:nesotto@cs.aau.dk] Sent: 19 August 2005 00:10 To: boost(a)lists.boost.org Subject: Re: [boost] asio networking proposal > > If the only performance sensible iterator types are T*, > I would't mind simply > > template< unsigned N > > void receive( char (&)[N] ); > > template< unsigned N > > void receive( char (&)[N], unsigned size ); > > void recieve( vector<char>& ); > > void recieve( vector<char>&, unsigned size ); > > or something. > > I have a hard time imagining any overhead imposed by > vector<char> compared to a heap-allocated char*. > I'm commenting from the sidelines here, and I'm in the camp that instinctively recoils from a (void*,size_t) interface. However, if we can persuade Christopher to add a slightly higher level interface, can I put in a plea for it to be in terms of "unsigned char", rather than plain char? I don't know about others, but I have a convention that "char" means "textual data", and "unsigned char" is reserved for "raw memory". (Unsigned char also makes it easier to grab bit-fields by shifting - the behaviour is more completely defined). Also: > void receive( char (&)[N], unsigned size ); > void recieve( vector<char>& ); ^^ I was going to post that there is an argument in favour of recv as opposed to receive, and Thorsten has just provided a nice example of it! -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

Re: [boost] Any (La)TeX experts here?
by Christoph Ludwig 19 Aug '05

19 Aug '05

On Mon, Aug 15, 2005 at 04:03:30PM -0400, Daryle Walker wrote: > (Some of the) Problems I see: There's a diff at <url:http://www.cdc.informatik.tu-darmstadt.de/~cludwig/boost/HyperComplex.diff> that fixes or works around the problems below. > 1. I had to bump the author's e-mail and web addresses to a footnote > instead of putting them in the main title-page text. (lines 5-7 in the > *.tex file) I am not so sure I understood what you want. Setting the two URLs centerd below the author's name is certainly no problem. (I decided to set them somewhat smaller than the author's name. If you don't like that remove the \small in front of the URLs.) I set the URLs with... the \url command. :-) That way you don't need to worry about special characters etc. > 2. There's no space between a \set? macro and the next word, outside of > math formulas. (lots of places) That's cured by adding \xspace in the appropriate command definitions. > 3. The element multiplication table isn't centered, nor does it have any > space above & below it separating it from the main text. (lines 213-224) You want the table to be "displayed". Therefore I put the table inside a display environment. (align* fom the amsmath package, but other environments would have worked as well.) And in math mode you need to use the array environment rather than tabular. > 4. The 16-element tuples aren't line-broken, so they could overflow the > column. (lines 244-248, 631-633) Here I applied a dirty hack: I defined a command that inserts a comma followed by a (non mandatory) \linebreak. It is possible to define a command \tuple that allows linebreaks after commas even within parentheses, similar to the \url command. But I am not familiar enough with the required low level TeX to come up with a quick solution. > 5. Some function blocks are inline with the text instead of put into a > separate row by themselves. (lines 273-275, 451-456, 661-663) That's essentially the same as (3). I'd prefer to keep function definitions on one line, but that's up to you. I also don't like the itemized formulas (pp. 16, 17). I'd rather employ the display and alignment environments from amsmath. But I did not want to change too much. > 6. Many equations involving large matrices overflow the column. (lines > 290-298, 321-328, 567-589, 591-613, 1442-1461) Here I did not find any better solution than to typeset the matrices in \scriptstyle. In some cases it might be better to pull the nontrivial terms out of the matrix, i.e. \begin{align*} M &= \begin{bmatrix} A & B & C \\ D & E & F \\ G & H & J \end{bmatrix} \intertext{where} A &= \alpha^2 + \beta^2 - \gamma^2 - \delta^2\\ B &= -2\alpha\delta + 2\beta\gamma\\ % and so on \end{align*} Then the matrix can probably be set in its natural size. I made some more minor modifications: I replaced the standard math blackboard bold font with the doublestroke font I like much better for the set symbols. I changed the hyperref options such that hyperlinks are no longer in frame boxes with colored frames but in colored font. The frames interferred with the surrounding text and made it harder to read. And, finally, I added \texorpdfstring to the title of section 2.4 to suppress the annoying warnings "Token not allowed in a PDFDocEncoded string". The document still offers many opportunities to improve its typesetting but I think I covered the most glaring points. HTH Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

2 1

Shared library failure under gcc
by Mat Marcus 18 Aug '05

18 Aug '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It appears that on some platforms, the boost build system is not aware of the necessary compiler flags that must be set when using shared libraries. In my experience, under gcc 4.0 if one doesn't effectively make *all* symbols visible via -fvisibility=default, for both the dynamic libraries and the executable that uses them, then compiler generated RTTI information will *not* be shared. I believe that - -fvisibility=default for dynamic libraries is the default setting but when an executable is being built it seems that -fvisibility=hidden is the default. <complaint> The fact that in order to safely use C++ with dynamic libraries on this platform one must effectively make all symbols visible is an unpleasant state of affairs with a number of ramifications. But this is a topic for another list. </complaint> We are fortunate that in one of the boost::signals test executables, this leads to a repeatable crash (boost_any_bridge fails to detect that two types are the same (because of an erroneous type info comparison). It is much worse in some other situations. I have seen silent failures (such as the "type" of a standard exception being changed between where it is thrown and where it is caught). I have tested this crash and fix (by manually recompiling the executable with all symbols visible) on the darwin gcc 4.0 platform using boost build v2. I just noticed the boost bug report #1262038 <http://sourceforge.net/tracker/?func=detail&atid=107586&aid=1262038&group_i…> with the exact same stack crawl, so I believe it is a more general phenomenon. Can anyone suggest patches to the build system to support the safe use of shared libs with gcc 4.0? Thanks, Mat -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBQwTRixIZBaoznf65EQI3aACfXHYAI5bLL1buAaNqpjsQcGkgJI8AoLQx O5LGuDL1ujZdPIx5AvOvdO3B =HhtX -----END PGP SIGNATURE-----

1 0