- Boost - lists.preview.boost.org

patch: iterator/zip_iterator.hpp
by Antony Searle 05 May '04

05 May '04

While using zip_iterator I encountered some minor bugs. Bugs: The include guard is broken (the #define has been omitted). The function "tuple_equal" causes multiple-definition linker errors. Patch: Added missing #define to header guard. Added missing "inline" keyword to "tuple_equal" definition. Please find attached the patch file. Best, Antony Searle zip_iterator.hpp.patch: *** zip_iterator.hpp.orig 2004-05-05 10:35:41.000000000 +1000 --- zip_iterator.hpp 2004-05-05 11:08:45.000000000 +1000 *************** *** 19,24 **** --- 19,25 ---- // Borland 5.5.1 (broken due to lack of support from Boost.Tuples) #ifndef BOOST_ZIP_ITERATOR_TMB_07_13_2003_HPP_ + #define BOOST_ZIP_ITERATOR_TMB_07_13_2003_HPP_ #include <stddef.h> #include <boost/iterator.hpp> *************** *** 315,321 **** // No point in bringing in a bunch of #ifdefs here. This is // going to go away with the next tuple implementation anyway. // ! bool tuple_equal(tuples::null_type, tuples::null_type) { return true; } template<typename Tuple1, typename Tuple2> --- 316,322 ---- // No point in bringing in a bunch of #ifdefs here. This is // going to go away with the next tuple implementation anyway. // ! inline bool tuple_equal(tuples::null_type, tuples::null_type) { return true; } template<typename Tuple1, typename Tuple2>

1 0

Request for mpl::empty_sequence
by Alexander Nasonov 05 May '04

05 May '04

For the purpose of forward declaration of class templates this read-only lightweight sequence might be useful. For example, one might declare class template Selector in fwd file: // empty_sequence.hpp is designed for inclusion into fwd files #include <boost/mpl/empty_sequence.hpp> template<class Variants = empty_sequence> class Selector; Another way to archieve this could be inclusion of <boost/mpl/vector_fwd.hpp> (why there is no such file in mpl?) and using mpl::vector<> instead. Although, it could extend a set of class templates with those modifying template parameter but a user would find it strange to include <boost/mpl/vector.hpp> if he only uses Selector<>. The empty_sequence definition is as simple as: namespace boost { namespace mpl { namespace aux { struct empty_sequence_iter { typedef forward_iterator_tag category; }; } struct empty_sequence { typedef aux::empty_sequence_iter begin; typedef aux::empty_sequence_iter end; }; }} This is not yet complete. I hope that support for some transformations will be added later (transformation doesn't change empty_sequence unless the size is changed) -- Alexander Nasonov Independent Developer and Consultant

2 6

[Review] Collection traits library
by Douglas Paul Gregor 04 May '04

04 May '04

We should accept the collection traits library into Boost. Collection traits address an annoying inconsistency in the use of collections. The documentation is sound, I did not find any issues when skimming the source code, and the testing looks adequate. Only two little nitpicks: - A misspelling: "funtions" in ExternalCollectionConcept synopsis. - Need to get copyright/license into files in the "test" subdirectory. Doug

1 0

connected components in adjacency_list graph
by Kommers, Jefferson 04 May '04

04 May '04

I am trying to understand why the order in which I add edges to an adjacency_list graph has some effect on the connected components I get using incremental_components. Using the listing below, with Boost release 1.30.0 (also 1.31.0) with g++ 2.95 (cygwin) I get the following: > g++ -I./boost_1_31_0 -o ok -ftemplate-depth-40 incremental-components-eg-bug.cpp > ./ok rank[0] = 0 rank[1] = 0 rank[2] = 0 rank[3] = 1 rank[4] = 0 parent[0] = 3 parent[1] = 3 parent[2] = 3 parent[3] = 3 parent[4] = 3 component 0 contains: 4 3 2 1 0 This is what I expect. If I change the order in which I add edges to the graph, I get a different answer: > g++ -I./boost_1_31_0 -DSHOWBUG -o bug -ftemplate-depth-40 incremental-components-eg-bug.cpp > ./bug rank[0] = 0 rank[1] = 0 rank[2] = 1 rank[3] = 2 rank[4] = 0 parent[0] = 3 parent[1] = 2 parent[2] = 3 parent[3] = 3 parent[4] = 3 component 0 contains: 4 3 2 0 This is not what I expect. The single connected component has lost a vertex. But it should be the same graph, the only difference being the order in which I called add_edge(). Is this a bug or a misunderstanding on my part? Any advice would be appreciated... Jeff #include <iostream> #include <vector> #include <algorithm> #include <utility> #include <boost/graph/adjacency_list.hpp> #include <boost/pending/disjoint_sets.hpp> #include <boost/graph/incremental_components.hpp> int main(int, char *[]) { using namespace boost; // Create a graph typedef adjacency_list < vecS, vecS, undirectedS > Graph; typedef graph_traits < Graph >::vertex_descriptor Vertex; const int N = 5; Graph G(N); add_edge(0, 3, G); add_edge(0, 4, G); #ifndef SHOWBUG add_edge(1, 4, G); add_edge(1, 2, G); #else add_edge(1, 2, G); add_edge(1, 4, G); #endif // create the disjoint-sets object, which requires rank and parent vertex properties std::vector < Vertex > rank(num_vertices(G)); std::vector < Vertex > parent(num_vertices(G)); typedef graph_traits<Graph>::vertices_size_type* Rank; typedef Vertex* Parent; disjoint_sets < Rank, Parent > ds(&rank[0], &parent[0]); // determine the connected components, storing the results in the disjoint-sets object initialize_incremental_components(G, ds); incremental_components(G, ds); for (unsigned int i = 0; i < rank.size(); ++i) { std::cout << "rank[" << i << "] = " << rank[i] << std::endl; } for (unsigned int i = 0; i < parent.size(); ++i) { std::cout << "parent[" << i << "] = " << parent[i] << std::endl; } typedef component_index < unsigned int >Components; Components components(parent.begin(), parent.end()); for (Components::size_type i = 0; i < components.size(); ++i) { std::cout << "component " << i << " contains: "; for (Components::value_type::iterator j = components[i].begin(); j != components[i].end(); ++j) std::cout << *j << " "; std::cout << std::endl; } return EXIT_SUCCESS; }

1 0

[signals] Deterministic slot ordering
by Douglas Paul Gregor 04 May '04

04 May '04

7 or 8 months ago, Edward Diener proposed deterministic slot ordering for Signals, allowing one to better arrange slot call order: http://article.gmane.org/gmane.comp.lib.boost.devel/25152/ I've now, finally, implemented his suggestions. The results are in CVS. The user-visible changes are: - By default, slots are called in the order they are connected. Groups still go in order, with unnamed slots at the end, but now connection order in a group determines invocation order. This probably won't change anything in user code, because multimaps tend to act this way anyway. - The "connect" methods now have an "at" parameter which may be set to "at_front" or "at_back". at_front means to connect the slot at the front of the slot list (before any grouped slots, or before any other slots in that group) whereas at_back means to connect the slot at the back of the slot list (after any grouped slots, or after any other slots in that group). The simple version of user-visible changes: sig.connect(Hello()); sig.connect(World()); sig(); Now this is guaranteed to print "Hello, world!", eliminating a massive source of confusion. With any luck, I haven't introduced too many new bugs. All regression tests pass for me, but of course I'd appreciate feedback. Doug

1 0

[multi_index][repost] ANN: Post-review version available
by Joaquín Mª López Muñoz 04 May '04

04 May '04

Some days ago I posted the following prompting for feedback on the post-review version of Boost.MultiIndex (fka Boost.IndexedSet). Just in case the post did go unnoticed, here it goes again. If nobody says anything this will go to the CVS next Friday, but I'd rather get some opinions first (and please please some tests on different compilers). Thank you! ************************************* I'm glad to announce that the post-review version of The Boost Multi-index Containers Library or Boos.MultiIndex (formerly known as Boost.IndexedSet) is available at: http://groups.yahoo.com/group/boost/files/multi_index.zip The most noticeable change is the new name for the library, which I hope will please most and bug none. Also, a new powerful feature called composite_key has been added. The complete list of changes after requests from the reviewers can be consulted at: http://groups.yahoo.com/group/boost/files/multi_index_postreview_notes.html I'd be grateful if the people interested could do the following: 1. make sure that all requests have been met. Those that haven't are justified at the post-review notes. 2. try to compile the library with different compilers. I don't think I've broken anything, but one never knows. This version has been tested with MSVC 6.5, GCC 3.3.1 and ICC 7.1 for Windows. Of special interest are MSVC 7.1, ICC 8.0, GCC 4.0 and CW 9.2. If no one raises any objection, in a week's time I'll commit the library to the main CVS, hopefully in time for Boost 1.32. Thanks everybody, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

boost::serialization Remarks
by martin.ecker＠tab.at 04 May '04

04 May '04

Hello, Even though the formal review is already over, I would like to make a couple of remarks regarding boost::serialization. First of all I like the design of the library and I'm glad it got accepted into Boost. We've started using the library about two weeks ago, at first only for serializing simple configuration data. But now we're looking into the possibility of using it fully as our serialization mechanism. Our project is rather large and it uses shared_ptrs extensively. Therefore, proper support for shared_ptr is very important to us. Unfortunately, the way shared_ptr is serialized currently is not really optimal, as has been discussed on this list before. Also weak_ptr is not yet supported, which is also a requirement for us. Apart from that, the fact that the macro BOOST_SHARED_POINTER_EXPORT has to be used to register the boost::detail::sp-counted_base_impl type is not very nice. Is there work under way to improve the serialization of shared_ptr/weak_ptr? Some kind of generic mechanism to serialize other smart pointer types, such as boost::shared_array or boost::intrusive_ptr, would be very nice. Our system consists of a number of DLLs and we need boost::serialization to be built as DLL as well. I quickly hacked a number of __declspec(dllexport) declarations into the source and created a DLL project with MSVC 7.1 and everything seemed to work fine at first. However, there are problems because of the fact that some of the template classes use static variables that are defined in header files. When included from multiple DLLs, this will cause multiple instances of that static variable to exist, one each for each DLL, although there should only be one instance for the entire program. Thus, if an attempt is made to serialize an object that belongs to one DLL from another DLL all sorts of things go wrong. For example, two template classes in boost::serialization that cause these problems are extended_type_info_no_rtti and extended_type_info_rtti, which declare static local variables in a function called get_instance in their respective header files. Also the static_initializer template class in void_cast.hpp defines a static member variable. I might have missed some others. Is there work under way to fix this and have working DLL builds of boost::serialization (just as there are DLL builds for, say, boost::regex)? In the documentation I would like to see a remark in the section on Export Keys, i.e. the BOOST_CLASS_EXPORT macro, that the export macros must not be used in header files, at least not in header files included by multiple clients, because they implement global variables that must exist only once. One thing I also find unfortunate is that the BOOST_CLASS_EXPORT macro has to be used at global scope and cannot be used inside namespaces. Is there a way to fix this? The same goes for BOOST_SERIALIZATION_SPLIT_FREE. On MSVC 7.1 serialization of a std::vector<bool> doesn't work with the default implementation of the boost::serialization library. The compiler complains in save_collection in the line save_construct_data(ar, &(*it), 0U); with the error C2101: '&' requires l-value I presume this is because dereferencing an iterator to a std::vector<bool> returns a proxy object. A simple solution to this is to specialize the serialize free function for std::vector<bool>. Best Regards, Martin Ecker TAB Austria Industrie- und Unterhaltungselektronik GmbH & CoKG http://www.tab.at

1 0

[patch] GCC 3.4 removed __GLIBCPP__ macro
by Jonathan Wakely 04 May '04

04 May '04

Hi, The version of libstdc++ that ships with GCC 3.4 has changed a number of macro names, so the boost/config/stdlib/libstdcpp3.hpp file no longer works. __GLIBCPP__ -> __GLIBCXX__ _GLIBCPP_USE_WCHAR_T -> _GLIBCXX_USE_WCHAR_T _GLIBCPP_USE_LONG_LONG -> _GLIBCXX_USE_LONG_LONG The attached patch adds a check for __GLIBCXX__ to select_stdlib_config.hpp and includes a new libstdcxx3.hpp file if it's defined. That new file is also attached. If noone's already working on this, is my approach the best one? jon -- "Surrealism aims at the total transformation of the mind and all that resembles it" - Breton

2 3

Re: [boost] [ublas] Patch for GCC 3.4
by Giovanni Bajo 04 May '04

04 May '04

[copied to the Boost mailing list] Michael Stevens wrote: > I noticed you posting a month ago and I was hoping Joerg Walter would > answer your query. I have been helping Joerg maintain uBLAS since the > end of last year. Sadly Joerg has been of the ublas-dev list for > quite some time now and I have been unable to contact him. In the > meantime I am keeping up the maintenance of the separate ublas-dev > CVS. > However I do not have Boost CVS commit access so I am unable to > propagate these changes. The ublas-dev CVS has a couple of rather > recent changes which need further testing before reaching Boost. > However the GCC 3.4 problem I think is important enough that it > should be fixed now. > I therefore want to ask you the favour of committing the attached > patch. This fixes all the missing typename's which occur in several > files. It also adds test7 to the regression tests. This shows up a > bug in VC7.1 which I am hoping Microsoft will address. OK, I'm committing this patch to the CVS trunk on your behalf. > If this goes well I would also like to ask you to add a set for > Jamfiles for BBv2 that are now a part of ublas-dev. Would that be OK? I do not have problems in doing this, but if you are maintaining uBLAS, I think it is worth you to do this *officially*, and get CVS write access. Asking on the Boost list would be a way to accomplish this. Giovanni Bajo

1 0

RE: [boost] Re: Using Serialization for binary marshalling
by Brian Braatz 03 May '04

03 May '04

"""""""""" > Now, as you rightly point out, CDR does provide for efficient binary > representation of C++ primitive types. I can see that some people > might prefer to use CDR as an on-wire format for communication between > equivalent systems, so this certainly is a candidate for complete C++ coverage. > > This is complicated, however. If you were to allow full C++ > serialization into a CDR archive, the result would be portable but not > conformant to any standard or protocol, since it relied on the > serialization library's object serialization method. Only another > user of the serialization library could recover the serialized data. Unless I'm mistaken you will have achieved a cross-platform (eg: big-endian, little-endian compatible) efficient binary format for the case where you do indeed have mirror serialization code on both sides. To me that's a huge win. I can write to binary files or across a socket to any platform and as long as I deserialize using the same code it should work. I don't believe the other binary (maybe the text) archives can claim that. I think there is one more restriction on the C++ code, however. Types would have to be coded with 'portable' types (eg: boost::uint_16, boost::uint_32, etc). But anyone doing cross-platform development already does that, right ;-) """"""""""'' Question- I was just looking for clarification. Does the boost serialization library allow me to have objects on different platforms stream to each other? To put it another way is the guess here correct? " Unless I'm mistaken you will have achieved a cross-platform (eg: big-endian, little-endian compatible) efficient binary format for the case where you do indeed have mirror serialization code on both sides. To me that's a huge win." Thanks

1 0