April 2004 - Boost - lists.preview.boost.org

boost::filesystem with network paths on windows
by Arne.Adams＠t-online.de 25 Aug '04

25 Aug '04

Hi, I am trying to use boost filesystem to copy files from a local directory to a directory on a network server (the latter having a path like \\databaseserver\c$\importfiles\myTabledump.txt <file:///\\databaseserver\c$\importfiles\myTabledump.txt> ) Unfortunately the leading double backslashs (\\) get converted in the constructor of filesystem::path to double slashs - yielding a different meaning. Is there a way to copy files on windows to network servers like this? Regards, Arne Adams Nerotal 23 65193 Wiesbaden Tel.: (+49) 611 3413745 Mobil: 0172 6147473 Mail: inbox(a)arneadams.com

3 2

[filesystem + iterator] directory iterator problem
by Vladimir Prus 08 Jul '04

08 Jul '04

There's a bug report on sourceforge: https://sourceforge.net/tracker/index.php?func=detail&aid=937606&group_id=7… which boils down to the fact that directory_iterator it(...); path p = *it++; does not work correctly. The exact problem is that the above line return a copy of the iterator, and increments 'it', but both iterators have shared_ptr to the same internal structure, so by time user deferences the copy, it gets the next file in the directory. The filesystem lib sources contain the following comment: The *r++ requirement doesn't appear to apply to the new single_pass_traversal category Thus I'm leaving the proxy out pending confirmation from the N1477 authors I'm not sure I understand that. It seems that *r++ should work, since signle pass iterator requires that r++ should work and return object of type X (call it r2), and the reabable iterator requires that *r2 should work. Am I wrong? And BTW, don't the above requirements mean r++ cannot return a proxy object, but only a real copy of the iterator? - Volodya

2 25

[BGL] remove_edge bug
by Vladimir Prus 30 Jun '04

30 Jun '04

Jeremy, I think your reversion 1.120 of detail/adjacency_list.hpp: 2004-04-01 05:30 jsiek * detail/adjacency_list.hpp: fixed remove_edge for bidirectional graphs actually breaks remove_edge in a different way. Please take a look at http://zigzag.cs.msu.su:7813/program_graph.cpp The code there add two vertices, an edge between them, and then removes the edge. After that 'num_edges' returns 1, not 0 as expected. I seems like now remove_edge removes elements from out_edges and in_edges storage, but not from global edges vector. Is it possible to fix this problem? TIA, Volodya

2 3

[BGL] Unused parameter "inf" in dijkstra_shortest_paths?
by Douglas Gregor 30 Jun '04

30 Jun '04

Hmmm, this could be a bug, but I don't have time to look into it now: /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp: In function `void boost::dijkstra_shortest_paths_no_init(const VertexListGraph&, typename boost::graph_traits<G>::vertex_descriptor, PredecessorMap, DistanceMap, WeightMap, IndexMap, Compare, Combine, DistInf, DistZero, DijkstraVisitor) [with VertexListGraph = boost::adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_name_t, std::string, boost::no_property>, boost::property<boost::edge_name_t, std::string, boost::property<boost::edge_length_t, double, boost::property<boost::edge_speed_limit_t, int, boost::property<boost::edge_direction_t, char, boost::property<boost::edge_snow_route_t, bool, boost::no_property> > > > >, boost::no_property, boost::listS>, DijkstraVisitor = boost::dijkstra_visitor<boost::null_visitor>, PredecessorMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<Intersection*, std::vector<Intersection, std::allocator<Intersection> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Intersection, Intersection&>, DistanceMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, double, double&>, WeightMap = boost::adj_list_edge_property_map<boost::bidirectional_tag, double, double&, size_t, boost::property<boost::edge_name_t, std::string, boost::property<boost::edge_length_t, double, boost::property<boost::edge_speed_limit_t, int, boost::property<boost::edge_direction_t, char, boost::property<boost::edge_snow_route_t, bool, boost::no_property> > > > >, boost::edge_length_t>, IndexMap = boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Compare = std::less<double>, Combine = boost::closed_plus<double>, DistInf = double, DistZero = double]': /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp:171: warning: unused parameter `double inf' /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp: In function `void boost::dijkstra_shortest_paths_no_init(const VertexListGraph&, typename boost::graph_traits<G>::vertex_descriptor, PredecessorMap, DistanceMap, WeightMap, IndexMap, Compare, Combine, DistInf, DistZero, DijkstraVisitor) [with VertexListGraph = boost::adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_name_t, std::string, boost::no_property>, boost::property<boost::edge_name_t, std::string, boost::property<boost::edge_length_t, double, boost::property<boost::edge_speed_limit_t, int, boost::property<boost::edge_direction_t, char, boost::property<boost::edge_snow_route_t, bool, boost::no_property> > > > >, boost::no_property, boost::listS>, DijkstraVisitor = boost::dijkstra_visitor<boost::null_visitor>, PredecessorMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<Intersection*, std::vector<Intersection, std::allocator<Intersection> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Intersection, Intersection&>, DistanceMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, double, double&>, WeightMap = TravelTimePropertyMap, IndexMap = boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Compare = std::less<double>, Combine = boost::closed_plus<double>, DistInf = double, DistZero = double]': /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp:171: warning: unused parameter `double inf' Doug

2 1

[iterator + lambda] transform_iterator and lambda expression
by Vladimir Prus 04 Jun '04

04 Jun '04

I'm again trying to use FP in C++, and having problems. What I wanted to do was: for_each(predecesor(v, g), /* BLL expression */ ); where predecessor(..) returns a pair of 'transform_iterator' instances. The simplest example which illustrates the problem is: struct functor { typedef int result_type; int operator()(int i) const { return i+1; }; }; transform_iterator<functor, vector<int>::iterator> it(v.begin()); (cout << _1)(*it); This does not compile, because operator* of transform_iterator return rvalue which can't be bound to non-const reference that operator() of the lambda expression accepts. Of all workarounds suggsted on BLL docs, only break_const is applicable to my case (I want to pass non-const references to the lambda, so const_parameters won't do), and break_const is scary. It looks like a serious problem with using FP, so I wonder what can be done. Maybe, transform_iterator should have yet another template parameter telling if it should store a value internally, and return reference (i.e. lvalue) in that case? It need not be enabled by default, but functions like my 'predecessor' above would make use of that extra template parameter. - Volodya

4 8

Filesystem iterator suggestion
by Martin 18 May '04

18 May '04

I have used the filesystem library for some time now and noticed that there is no portable way of iterating over files in a directory that matches a pattern. In my applications I often need to find all files in a directory that matches "*.txt" or "input.*". I think it would be a good idea to add another constructor to the directory_iterator that support some primitive wilcards. The support could be limited to "*" at the end or followed by a "." (e.g. "*", "a*.*", "*.txt", "a.*") for (path::directory_iterator itr = directory_iterator(path, "*.txt"); itr != directory_iterator(); ++itr) ... I assume this limited wildcard support could easily be ported to most operating systems. ------------------- Another small improvement that would make the directory_iterator easier to use is to somehow allow it to only list directories or files. In the current implementation you need to create a temporary to use an algorithm on all files in a directory (or use some lambda if construct). std::vector<path> tmp; std::remove_copy_if(directory_iterator(dir), directory_iterator(), back_inserter(tmp), std::ptr_fun(is_directory)) std::for_each(tmp.begin(), tmp.end(), func); instead of just std::for_each(directory_iterator(dir, files_only), directory_iterator(), func);

4 4

patch: boost/math/special_functions => compile error in asinh.hpp, acosh.hpp and atanh.hpp
by Huber, Carsten 10 May '04

10 May '04

Hello boost developers, this is my first mail to boost(a)lists.boost.org and it is already a bug that I found in the latest release 1.31.0 :-( I tried to compile boost::math::asinh, boost::math::acosh and boost::math::atanh recently and got a compile error "C2039 'abs' : is not a member of '_STL'" on my MSVC6 compiler. I have STLPort 4.5.3 installed and thought, this might be the problem, but then I found out that boost::math::sinc_pi and boost::math::sinhc_pi compile with no errors. To make it short: asinh, acosh and atanh are using ::std::abs, ::std::sqrt and ::std::log - which are not part of the STL. To fix this problem, I have created a patch - see attached files. Best regards, Carsten Huber ------------------------------------------------- Dipl.-Ing. Carsten Huber (Member of the VDE) Software Development Engineer Product Line Diagnostics (PDG) Vector Informatik GmbH Ingersheimer Str. 24 D-70499 Stuttgart Phone : +49 711 80670-0 Fax : +49 711 80670-299 Mailto : carsten.huber(a)vector-informatik.de Internet: http://www.vector-informatik.de -------------------------------------------------

2 1

[Formal review] Collection Traits library
by hartmutkaiser＠t-online.de 08 May '04

08 May '04

Hi all, The review of the Collection Traits library, written by Thorsten Ottosen starts today (April 28th, 2004) and runs for 10 days (until May 7th, 2004). The Latest version of the library is available at (yahoo files sections): http://tinyurl.com/ysbaj (72 kB) or in the Boost sandbox. What is it? The Collection Traits library is mainly a tool for writing generic algorithms that work on External Collections. A Collection is a subset of the container requirements; it is so small and essential that it can be made to work with standard containers, iterator-views, built-in arrays and strings by defining a new requirement, the External Collection Concept, where typedefs and functions have been made free-standing instead of members. The library consists of two components: (1) type generators and (2) free-standing functions. The type-generators provide types such as iterators and size_type of external collections whereas the Free-standing functions are for extracting iterators and size of the external collections. Here is a small example: // Example: extracting bounds in generic algorithms template< typename ExternalCollection, typename T > inline typename boost::iterator_of<ExternalCollection>::type find( ExternalCollection& c, const T& value ) { return std::find( boost::begin( c ), boost::end( c ), value´); } template< typename ExternalCollection, typename T > inline typename boost::const_iterator_of<ExternalCollection>::type find( const ExternalCollection& c, const T& value ) { return std::find( boost::begin( c ), boost::end( c ), value´); } // replace first value and return its index template< typename EC, typename T > inline typename boost::size_type_of< EC >::type my_generic_replace( EC& c, const T& value, const T& replacement ) { boost::iterator_of<EC>::type found = find( c, v ); *found = replacement; return std::distance( boost::begin( c ), found ); } // usage std::vector<int> my_vector; typedef vector<int>::iterator iterator; std::pair<iterator,iterator> my_view( my_vector.begin(), my_vector.begin() + N ); char str[] = "a string"; // ... std::cout << my_generic_replace( my_vector, 4, 2 ) << my_generic_replace( my_view, 4, 2 ) << my_generic_replace( str, 'a', 'b' ); As the External Concepts idea is a rather new one, I would like to ask you to comment on this. Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

20 102

signals and threads
by David Abrahams 06 May '04

06 May '04

So, we're thinking of using the signals library in one of our projects, but the lack of thread-safety is a concern for us. What issues are preventing Boost.Signals from being made threadsafe? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

4 6

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

05 May '04

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

4 6

Re: [Boost] Big integer library
by Richard Peters 05 May '04

05 May '04

"Thorsten Ottosen" <nesotto(a)cs.auc.dk> wrote in message news:c6quof$dtl$1@sea.gmane.org... > I have some questions. Will it be possible to say > > 1. typedef boost::rational< big_integer > big_rational. Yes. In fact, the big_integer_example contains an example where boost::rational<big_integer> is used. > 2. Why is faculty() a part of the interface. I have a generic version of > faculty in some prob&stat code I'm doing that I hope would work > with big_integer. Your generic version will most probably work. There is one difference, my version returns an expression instead of a value, which saves the creation of one temporary value. In this case, the gained performance is probably minimal. I'm happy to refactor this function out of the library, throw it away, or come up with a hybrid solution where the expression-returning version is included when both big_integer and your library is included. > 3. Are you planning big_float? I would be happy with focus on interface > specs and then better implementation later. Unfortunately not. I can see that big_float would have its uses, but I rarely even use float. My interests ly in algebraic computations such as cryptology. > The C++ standard could really use a "big" library and it's always nice > with a version in boost first. > > br > > Thorsten Thanks for the response, Richard Peters

10 18

Re: Big integer library
by Richard Peters 05 May '04

05 May '04

I have uploaded a new version of the big_integer library which also compiles with GCC 3.4.0 (cvs version). This version now compiles on compilers which implement two-stage name lookup. The library is available at http://groups.yahoo.com/group/boost/files/big_integer/, the version is 0.1. best regards, Richard Peters "Giovanni Bajo" <giovannibajo(a)libero.it> wrote in message news:c5mf2u$bt0$1@sea.gmane.org... > Richard Peters wrote: > > > A few months ago there was some discussion about an arbitrary > > magnitude integer library. I have now implemented such a library, > > which is located at > > http://groups.yahoo.com/group/boost/files/big_integer/. > > Compiling the code generate hundreds of failures because of two-stage name > lookup. You tested it under MSVC 71 and GCC 3.2 which both fail to implement > lookup rules correctly. I suggest you try again with GCC 3.4.0 (a pre-release > binary package should be available now) or EDG-based compilers. > -- > Giovanni Bajo

11 24

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

[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: Re: [BGL] forced client complexity
by Provisional Dissonance 02 May '04

02 May '04

>Yea, but first the original poster should indicate if this is what he's >looking for -- I never needed this myself. What I was looking for, really, was dialog on existing design strategies. It sounds like your issues with property maps mirror my confusion with the library design, though. While I can fully appreciate the desire to write generic code, it feels like BGL has pushed the complexity of creating and enforcing coupling between the generic graph/node/visitor/algorithm/etc onto the client. At a basic conceptual level, I think of a graph as a data structure composed of nodes and edges. If I'm modeling a family tree, I expect the nodes to be objects of some family-member class. C++ exposes many robust and elegant methods for modeling the family-member - why should I, as a client, have to use property-maps at all? If the node's "index" is related to the object, why would it not be a natural member of the node-type's class? If, instead, it is a synthesized construct for communication between a graph and the algorithm operating over it, why should the client be responsible for its maintenance instead of the framework? What are the advantages of this approach? What are the disadvantages of simplifying things for the client? This is the type of design issue that I intended to question with my initial post. -prs __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

6 16

bind question/request
by Max Khesin 02 May '04

02 May '04

I am refactoring code that looks something like this: if (op == LN::FILTER_IN || op == LN::FILTER_NOT_IN) { where += handle_set_operation(column, type, format, op, expr_set); } else if (op == LN::FILTER_RANGE) { where += handle_range_operation(column, type, format, op, expr_set); } else if (op == LN::FILTER_NULL || op == LN::FILTER_NOT_NULL) { where += handle_null_operation(column, op); } ... This would obviously be handled better with a map of some sort (has to map int to function). The problem here is that some functions have more arguments than others, precluding the possibility of uniform type for the function value of the map. I cannot just go and change the function sig to include dummy values ('cause it's a dumb idea). This situation made me think of boost.function/boost.bind, which allows to effectively shorten the function parameter list by binding some of the args. so given int f(int a, int b) { return a + b; } bind(f, _1, 5)(x); is equivalent to f(x, 5); and by extension bind(f, _1, _2, _0)(x, y, z) would be equivalent to f(x, y) thoughts? thanks. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

5 4

BOOST_TRY, can we make it into CVS?
by Pavel Vozenilek 01 May '04

01 May '04

I would like to ask someone with write access to CVS to create file boost/details/exception_helpers.hpp (or so) with content: #include <boost/config.hpp> #include <boost/detail/workaround.hpp> #if !(defined BOOST_NO_EXCEPTIONS) # define BOOST_TRY { try # define BOOST_CATCH(x) catch(x) # define BOOST_RETHROW throw; # define BOOST_CATCH_END } #else # if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) # define BOOST_TRY { if ("") # define BOOST_CATCH(x) else if (!"") # else # define BOOST_TRY { if (true) # define BOOST_CATCH else if (false) # endif # define BOOST_RETHROW # define BOOST_CATCH_END } #endif circular_buffer, serialization and multi_index_container may use this code. It was discussed on the list and reaction was rather positive. TIA /Pavel

2 1

looping construct
by michael toksvig 30 Apr '04

30 Apr '04

A while back, Erik Niebler was testing the waters for inclusion of his very, very clever looping construct into boost, but nothing really came of it. Erik's technique is described here: http://www.nwcpp.org/Meetings/2004/01.html Yup, macros are involved and they are yucky, and yup, there already exists a for_each in the standard that works just fine if you care to move your loop body away into a function, and yup, the name BOOST_FOREACH could use a little love. But there is no denying the notational clarity and succinctness of e.g.: foreach(double &d, container) d += 2; Versus the rather redundant: for (list<double>::iterator i = container.begin(); i !=container.end(); ++i) *i += 2; (Note that the latter stops working if container is represented using a vector or a built-in array instead) /Michael Toksvig

11 52

Can't access repositories using :ssh:
by Victor A. Wagner Jr. 30 Apr '04

30 Apr '04

Starting yesterday (it's still Thursday here) I started getting errors in my update and build scripts. When I chased it down, I was getting: WARNING - POTENTIAL SECURITY BREACH! The server's host key does not match the one PuTTY has cached in the registry. This means that either the server administrator has changed the host key, or you have actually connected to another computer pretending to be the server. The new key fingerprint is: ssh-dss 1024 4c:68:03:d4:5c:58:a6:1d:9d:17:13:24:14:48:ba:99 If you were expecting this change and trust the new key, hit Yes to update PuTTY's cache and continue connecting. If you want to carry on connecting but without updating the cache, hit No. If you want to abandon the connection completely, hit Cancel. Cancel is the ONLY guaranteed safe choice.1¦ I tried it manually a few times, then surrendered and said yes.... that didn't solve the problem now I get: C:\Projects\boost>cvs update -dPA Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Cannot access /cvsroot/boost/CVSROOT No such file or directory I get this behavio(u)r on both boost and boost-sandbox a simpler command yields (logging in just to make sure...): C:\Projects\boost>cvs login Logging in to :ssh:vawjr@cvs.boost.sourceforge.net:22:/cvsroot/boost CVS password: ******* C:\Projects\boost>cvs co -c Cannot access /cvsroot/boost/CVSROOT No such file or directory Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

3 3

cycle_iterator update
by Neal D. Becker 30 Apr '04

30 Apr '04

Here is an update to cycle_iterator. This is based on the original design by Gennadiy Rozental. After fairly extensive performance testing I am getting good results (compared to my old implementation which was hand-written, not based on boost iterators), after adding operator[]. There are two versions, both give about the same performance in my tests. One version, which I prefer, modifies the underlying base iterator for operations such as increment. The other implementation never touches the base iterator, but modifies an integral offset value. Also included is a Ring container adaptor class, which adapts a container (e.g., std::vector) to a ring. Basic operations are there, but more can be added. Also a simple test program.

4 9

boost.test XML output error
by Alex Odinaev 30 Apr '04

30 Apr '04

Hi, When I was trying to export test log to XML format I found that unit test framework doesn't convert '&' symbol to appropriate XML sequence. & shows up in log file if you have something like BOOST_CHECK(a&&b). Everything inside () goes to XML directly. Thanks, Alex Odinayev

1 0

bind.hpp needs a cwpro8 workaround
by David Abrahams 30 Apr '04

30 Apr '04

Pro8 is having trouble parsing these templates. Any ideas, Peter? template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* * pm, int) { return _mfi::dm<R, T>(*pm); } template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* const * pm, int) { return _mfi::dm<R, T>(*pm); } --- ### mwcc Compiler: # In: C:\boost\boost\bind.hpp # From: named_params_test.cpp # ------------------------------ # 131: template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* * pm, int) # Error: ^ # ')' expected ### mwcc Compiler: # 132: { # Error: ^ # declaration syntax error ### mwcc Compiler: # 133: return _mfi::dm<R, T>(*pm); # Error: ^^^^^^ # declaration syntax error ### mwcc Compiler: # 136: template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* const * pm, int) # Error: ^^^^^ # ')' expected ### mwcc Compiler: # 137: { # Error: ^ # declaration syntax error # Too many errors printed, aborting program -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 11

[type traits, mpl] small fix for BCB 6.4
by Pavel Vozenilek 30 Apr '04

30 Apr '04

BCB 6.4 doesnt't like when top level namespace is prefixed with :: type_traits/is_const.cpp contains line BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_const,T,::boost::detail::cv_traits_imp<T*>:: is_const) If the leading :: is removed to BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_const,T,boost::detail::cv_traits_imp<T*>::is _const) BCB stops complaining. There are few other places there which may be changed similarly. ---------------- The same problem appears in MPL's value_wknd.hpp: # if !defined(BOOST_MPL_MSVC_60_ETI_BUG) # define BOOST_MPL_AUX_VALUE_WKND(C) ::boost::mpl::aux::value_wknd< C > needs to be changed to # define BOOST_MPL_AUX_VALUE_WKND(C) boost::mpl::aux::value_wknd< C > These problems appeared when trying to compile Collection Traits library. /Pavel

2 2

Can libs/regex/build/gcc.mk use $(AR) instead of just "ar"
by Brad Spencer 30 Apr '04

30 Apr '04

When cross compiling, I need to use an "ar" with the correct target and not just "ar". I've patched boost/libs/regex/build/gcc.mk locally as shown in my attachment, but all I really did was replace use of "ar" with $(AR), which I can then override when invoking make. Perhaps this is reasonable to apply to the mainline copy? [BTW, I'm still locally patching iterator/iterator_facade.hpp because of conflicts with system header macros on i386-pc-solaris2.8. That thread seemed to die.] Thanks! -- ------------------------------------------------------------------ Brad Spencer - spencer(a)infointeractive.com - "It's quite nice..." Systems Architect | InfoInterActive Corp. | A Canadian AOL Company

2 1

[Boost-bugs] [ boost-Bugs-945000 ] Dereferencing invalid iterator
by SourceForge.net 30 Apr '04

30 Apr '04

Bugs item #945000, was opened at 2004-04-29 18:56 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=945000&group_i… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: Dereferencing invalid iterator Initial Comment: boost 1.31.0, subgraph.hpp, line 179, function find_vertex(vertex_descriptor u_global) const; return std::make_pair((*i).second, i != m_local_vertex.end()); //if i == m_local_vertex.end() - iterator should not be dereferenced ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=945000&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

serialization doc buglet?
by Neal D. Becker 29 Apr '04

29 Apr '04

Serialization18 reference suggests this should work (this is almost verbatim from the section on seperate load/store free function): #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/serialization/vector.hpp> template<class Archive> void load (Archive& ar, std::complex<double>& z, const unsigned int version) { double r, i; ar >> r; ar >> i; z = Complex (r, i); } namespace boost { namespace serialization { template<class Archive> inline void serialize(Archive & ar, std::complex<double>& z, const unsigned int file_version) { split_free(ar, z, file_version); } }} Claims "load" is not declared. But adding boost::serialization namespace will fix it: namespace boost { namespace serialization { template<class Archive> void load (Archive& ar, std::complex<double>& z, const unsigned int version) { double r, i; ar >> r; ar >> i; z = Complex (r, i); } }} This was tested with gcc-3.3.2. Is this a doc bug?

1 0

Re:[boost] Re: Re:RE: shared pointer serialization
by Robert Ramey 29 Apr '04

29 Apr '04

Fredrik Blomqvist wrote > Thinking about smart pointer serialization and how to generalize it, ie. > to allow serialization of any "my_ref_count_ptr", I got this idea. > > -How about extending the tracking system with a case something like: > serialization::track_ref_count? (perhaps using a is_smart_ptr<> traits > function). > Based on this tag the serializer would at load time maintain a > map<pointer_value, my_ref_count_ptr<T> > to enable the ref-copy "bumping" > of all the subsequent my_ref_count_ptrs. > Where pointer_value is used as key and obtained by boost::get_pointer > (assumed to be specialized for my_ref_ptr). > This is essentially the same approach I outlined earlier in my reviews and > seems similar to both what Peter Dimov uses and Gennadiy mentions above. > It would of course require extensions to the code but I think it would > possible to use/adapt the existing pointer code-path to some degree. As far as I can tell, this is exactly equivalent to what the shared_ptr case study in the documentation/code currently do. No special modification to the library was necessary to accomplish this. Indeed, that was the point of the demo and documentation. The question that has been raised is whether even this is more than is necessary. I have yet to address this in detail. In my opinion, any situation which required special support to be added to the library would reveal a flaw in the library design or implementation. In the future - the library will be smaller - not larger. Robert Ramey

1 0

serialization - howto build w/ boost_1_31_0?
by Neal D. Becker 29 Apr '04

29 Apr '04

What is a simple way to build serialization given a boost_1_31_0 tree? This is on Linux/gcc.

1 0

boost::test - example error
by Roman Yakovenko 29 Apr '04

29 Apr '04

Hi. I think I found error within example "The class member function based test cases". The error is in the first example: ts->add( BOOST_CLASS_TEST_CASE( &my_complex_test::test_feature1 ) ); BOOST_CLASS_TEST_CASE macro expects 2 parameters, instance parameter is missing. Roman

1 0

[patch] Iterator library docs
by Jonathan Wakely 29 Apr '04

29 Apr '04

The attached patch should be applied to the docs for the iterator library to correct a typo jon -- "Some people have a way with words. Others...not have way." - Steve Martin

2 1

Re:RE: [boost] shared pointer serialization
by Robert Ramey 28 Apr '04

28 Apr '04

Gennadiy Rozental wrote: > This is about how I expect it to work. But from this description it's > unclear: > 1. Why would you need to save counter into archive? After all value 10 > has nothing to do with resulting 5. > 2. Why would you need direct access to shared_ptr counter? After all > using regular shared_ptr copy would automatically bump it to proper value. I remember my initial implementation just restored the original state. Thinking better of it I made a change to the current system. Now that you mention it, it wouldn't seem to need the counter anymore. Just for laughs I commented out the serialization of the counter and if failed to build the test. I'll have to look into it. Robert Ramey

2 1

Re:[boost] Re: Serialization Formal Review #2
by Robert Ramey 28 Apr '04

28 Apr '04

Message: 13 Fredrik Blomqvist > * What is your evaluation of the implementation? > As I mentioned in my previous review I would like to see it handle most of > the STL and core boost components "out of the box". I believe all STL is handled. Serialization of other boost components will have to be the responsibility of their authors or others. > In particular I think the smart_ptrs (including auto_ptr) should have > core-support from the serializer, even special cased if necessary (similar > to boost::bind etc). I believe the current library is capable of implementing serialization for all boost components. Much effort was expended to that the library would not have to have special code for any serialization or archive type. In fact, my interest is just the opposite. I would like to see a significant part of the library moved outside. Anyone who wants to volunteer to take responsibility for any of the component please let us know. The library would be improved by making it smaller. > The code to serialize std::auto_ptr could easily be copied to the official > directory for example. There has been some discussion of where the serialization code for other boost libraries should reside. I don't have strong feelings about this other than I would prefer that it reside outside the serialization library itself. The only exception I would make is for the STL serialization which has no where else in boost to reside and it has a "special" status as and official C++ library. > Regarding shared_ & weak_ptr. If the implementation path Robert outlines > in the documentation is to be used I guess an official patch to > shared_count is necessary. Would be interesting to hear what the smart > pointer experts think. I agree - the silence is deafining. I know there are applications that use my smart pointer serialization code right now. I implemented and tested it but I don't really know for a fact that it addresses all aspects that need to be addressed such as exception safety, threading, and who knows what else. > Otherwise, I still think the solution I outlined in my previous review > that doesn't require modifying shared_ptr could be considered. Downside > being that it most likely adds a special-cased codepath to the serializer, > but as I said I think it would be worth it. I would hope that the developer's maintaining shared pointer will address this. putting special case code inside the serialization library would be a serious mistake. Between code, tests, and documentation, its approaching 30,000 lines. > The code is nicely written altough complex. Highly nested template code > and lots of mpl. All compile-time checks and further factorizations are > valuable. > Nitpick: serialization/scoped_ptr.hpp seems to have a typo. An extra > #pragma once is present outside the #ifdef (_MSC..) block. It also > includes serialization/pfto.hpp but doesn't seem to use it. Thanks - I love picking these nits. Its easy and satisfying - really. > * Parts of the library that might become standalone boost libraries > The library already provides good separation of components. tatic_warning, > strong typedef, pfto, stack_allocate etc are all given candidates that > would just need better documentation and (fast-track?) reviews. A little bit more is going to be required. They've been tested in the context of serialization and that's OK. I think they need to be more polished and that's a little more work than it first appears. Also a separate review would probably fine tune their interface, implementation and capability. * What is your evaluation of the documentation? > I would also like to see an improved reference documentation that clearly > states the requirements on the types/concepts involved. Hmmm - that seems pretty unanimous - pretty much a first for boost as far as I know. > I support the separation of documentation (and implementation) of other > boost components that like to support serialization. A simple index with > links would suffice I think but most importantly a _consistent_ structure > should be agreed upon which new components can follow. I followed the boost document on how to write documentation. The only wrinkle I added was the right hand index/contents window. I'm pretty pleased with this. I would appreciate VC7.1 project files for the examples and tests though. > One of my tests added support for the STL container adaptors std::stack, > queue and priority_queue. I think direct support for them could be > convinient since they hide the native containers. I attach my > implementation. Feel free to comment I took a short look. The name stack_hack sort of begs some sort of comment. The main thing is that any component of this type has got to be submitted with a test. Thanks for taking the time to study the library and submit a review. Robert Ramey

3 5

Appology
by Mohammed Iqbal 28 Apr '04

28 Apr '04

Hi.. Sorry because I didn't reply to you about my library. I felt down after three da days from my last message. My head hit the wall. I suffered very much from a headache, pain in my stomach ( ifelt that I need to vomit but I couldn't), and something wrng with my eyes. Till now I still suffer from these things but not very much. I can't tell you about my library now because of many reasons: 1. It is not a library meant for distribution at least for now. Instead, it is a pert of a large project that I am working alone on. 2. It is not complete now because it is going through changing everyday. 3. It is not totally tested. When I told you about context-oriented programming, I didn't mean what Gassassnenko wrote because a context in my technology differs completely from context in his paper. My technology is for video game creation. It consists of many components: 1. A process model for analysis, design, development, and testing. It is very powerfull because it is designed in the first place for this purpose. It is based on experiences of many researches, studies, surveys, etc. But it is not applied for real video game development. 2. A software tool for game creation that let's you develop a complete game without using any external library or software. You can do your animation, develop your code using the integrated language which is based on C++ as the main root but it is not C++ and many changes have been applied to get rid of many features we don't want, etc. The software also uses the above process for game creation. 3. Many other components. My technology is using something that you don't imagine at all. I will not give any information untill I finish eveything. I used Cubism of Picasso. Strange?? The development is done in the Medium ( a 3D space) that contains many contexts. Each context can be anything like, a function, a class, a template, a set of functions, etc. The contexts deals with each other and with the Medium through slots. Slots can accept anything like a function, a type, a class, etc. That's all for now. Mohammed

1 0

[ann] log viewer
by John Torjo 28 Apr '04

28 Apr '04

Dear boosters, Since most of us use some sort of logging, I've developed a free program that allows simple viewing/filtering of log files (for Windows). The really cool thing is that you can monitor files (you can have multiple filters for the same file) while your application is writing to it. I think it's quite simple to use and very useful. Anyway, to make a long story short, if you're interested: http://www.torjo.com/logview/EasyLogView.exe (download) http://www.torjo.com/logview/screenshot1.jpg http://www.torjo.com/logview/screenshot2.jpg It's at a very early stage, so I look forward to your feedback (menu: Help/Send Feedback ;)) Best, John

2 4

RE: [boost] shared pointer serialization
by Rozental, Gennadiy 28 Apr '04

28 Apr '04

> > what if I do not save all of the shared_ptr to the same object? > > Here is a scenario: > > a) a shared_ptr exists and it points to and object which is > pointed by 9 other shared_ptrs. > > b) we create and archive and save some objects. The set > objects saved only includes 5 of the shared_ptrs out of the > possible 10. > > c) later when we load, we create 5 new shared_ptr and one new > object. Object tracking guarantees that only one shared > object is created. As each new shared pointer is loaded, the > shared count is incremented. So the new shared pointer is > not identical to the original - its equal to 5. > > d) the process (almost?) guarantees that all the shared_ptr > are valid in that they all point to shared object and the > shared_count is maintained to be the correct number. The > intention is that this process be exception safe > - I'm not sure that this intention has been realized. This is about how I expect it to work. But from this description it's unclear: 1. Why would you need to save counter into archive? After all value 10 has nothing to do with resulting 5. 2. Why would you need direct access to shared_ptr counter? After all using regular shared_ptr copy would automatically bump it to proper value. Gennadiy.

1 0

A nice library
by Mohammed Iqbal 28 Apr '04

28 Apr '04

This seems like an interesting library: http://www.southern-storm.com.au/libjit.html It isn't even at beta yet, but it is probably something to watch. Mohammed

1 0

shared pointer serialization
by Robert Ramey 28 Apr '04

28 Apr '04

Rozental, Gennadiy wrote: > There is another counter to direct counter using (I just think out loud - > it may be that you ok): what if I do not save all of the shared_ptr to the > same object? What will happened once they will get restored? Wouldn't it > cause memory leak? > I do realize that any other solution would be more complicated, but I > think we should go for it. I don't really understand what's being said here but I can shed a little more light on the way serialization is implemented right now. It's also used as a case study in the documentation and described in detail. > what if I do not save all of the shared_ptr to the same object? Here is a scenario: a) a shared_ptr exists and it points to and object which is pointed by 9 other shared_ptrs. b) we create and archive and save some objects. The set objects saved only includes 5 of the shared_ptrs out of the possible 10. c) later when we load, we create 5 new shared_ptr and one new object. Object tracking guarantees that only one shared object is created. As each new shared pointer is loaded, the shared count is incremented. So the new shared pointer is not identical to the original - its equal to 5. d) the process (almost?) guarantees that all the shared_ptr are valid in that they all point to shared object and the shared_count is maintained to be the correct number. The intention is that this process be exception safe - I'm not sure that this intention has been realized. A fuller explanation can be found at: http://www.rrsd.com/boost/libs/serialization/doc/shared_ptr.html Robert Ramey.

1 0

Re:[boost] Re: serialization and MFC
by Robert Ramey 28 Apr '04

28 Apr '04

Eric Niebler wrote: > Forgive the possibly naive question -- I have never used the > serialization library, but I have used MFC serialization. I am curious > if the boost serialization library can be made backwards-compatible > with MFC serialization; that is, if I have an old application that > uses MFC serialization, would it be possible to switch to the boost > serialization library and still have the ability to read old (MFC) > archives? > > I'd like to know: > - if it's possible > - how hard it would be (would it require reverse-engineering the > MFC archive format? is that format stable? documented?) > - what the advantages of switching are The easiest way to switch from MFC (or any other systems is to do the following): a) add boost serialization to your code. b) when you open an archive - currently MFC, use code like the following: open stream read the first part of the stream if doesn't contain a boost serialization signature invoke MFC de-serialization else invoke boost de-serialization. c) when you save an archive - just invoke boost serialization. In this way, all your old files will be compatible and will gradually be converted to the new system. The new archives can use all the new facilities without compromise. This is much easier, and forward looking than trying to adapt to an old format wich likely isn't rich enough to support the new facilities. Robert Ramey

1 0

[Boost-bugs] [ boost-Support Requests-943555 ] Path.cpp:85: error: `portable_posix_name' undeclared in name
by SourceForge.net 28 Apr '04

28 Apr '04

Support Requests item #943555, was opened at 2004-04-28 01:07 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=943555&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Path.cpp:85: error: `portable_posix_name' undeclared in name Initial Comment: i am compiling a game and i get thru ./configure but when i goto make i get this error Path.cpp:85: error: `portable_posix_name' undeclared in namespace `boost::filesystem' i get simmilair errors on 85, 99 and 113 saying portable_posix_name is undeclared ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=943555&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

problems with boost::thread
by "Magomed Abdurakhmanov 28 Apr '04

28 Apr '04

Hello. I have some troubles with boost::thread, and think they are important: 1. condition::timed_wait dangerous to use, because waiting delay specified as time when we are will stop waiting. So this is very surprising when system time is changed! I guess that waiting for specified delay is much more safe than waiting until some time arrive. For example try launch the program bellow and change system time backward (to past) when it's working. I have tested this under win32 + msvc7 // ------------------------------- boost::condition cvar; boost::mutex monitor; void thread1() { for(;;) { boost::mutex::scoped_lock lock(monitor); boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); std::cout << "now: " << xt.sec << std::endl; xt.sec += 5; std::cout << "will wait until: " << xt.sec << std::endl; if (!cvar.timed_wait(lock, xt)) std::cout << "timed out!" << std::endl; std::cout << "next step" << std::endl; } } int main(int argc, char* argv[]) { boost::thread thrd1(&thread1); thrd1.join(); return 0; } // ------------------------------- 2. The secound trouble is that the thread function has catch(...) at the root and when unhandled exception in thread thrown, it's just silently eated and thread stopped. But the process stay alive, and now nothing about it. And ever wrong that catch(...) under VC6 will catch OS exceptions. p.s. sorry for so bad english

8 14

serialization and MFC
by Eric Niebler 28 Apr '04

28 Apr '04

Forgive the possibly naive question -- I have never used the serialization library, but I have used MFC serialization. I am curious if the boost serialization library can be made backwards-compatible with MFC serialization; that is, if I have an old application that uses MFC serialization, would it be possible to switch to the boost serialization library and still have the ability to read old (MFC) archives? I'd like to know: - if it's possible - how hard it would be (would it require reverse-engineering the MFC archive format? is that format stable? documented?) - what the advantages of switching are Thanks. -- Eric Niebler Boost Consulting www.boost-consulting.com

1 1

intel-linux toolset doc error
by Richard Hadsell 27 Apr '04

27 Apr '04

I am upgrading from Boost 1.30.0 to 1.31.0, trying to use bjam for the first time to build the libraries (including Regex). When building for intel-linux, I read (tools/build/v1/intel-linux-tools.html) that bjam would be able to find the compiler from the location of the iccvars.sh script. This did not work. Evidence: 162% which iccvars.sh /usr/local/intel/compiler80/ia32/bin/iccvars.sh 163% which icc /usr/local/intel/compiler80/ia32/bin/icc Despite both of these being in my PATH, bjam tried to look elsewhere: 168% bjam "-sTOOLS=intel-linux" --stagedir=stage "-sBUILD=debug release <threading>single" stage [snip] intel-linux-C++-action bin/boost/libs/date_time/build/libboost_date_time.so/intel-linux/debug/shared-linkable-true/greg_month.o /bin/sh: /opt/intel/compiler70/ia32/bin/iccvars.sh: No such file or directory Specifying the version number did not help: 169% bjam "-sTOOLS=intel-linux" "-sINTEL_VERSION=80" --stagedir=stage "-sBUILD=debug release <threading>single" stage [snip] intel-linux-C++-action bin/boost/libs/date_time/build/libboost_date_time.so/intel-linux/debug/shared-linkable-true/greg_month.o /bin/sh: /opt/intel_cc_80/bin/iccvars.sh: No such file or directory -- 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 2

Problems using Boost, Pls Advise
by Steve Bobrowski 27 Apr '04

27 Apr '04

Hi, I'm a C++ newbie trying to use the Boost regex libraries. Here's my situation. My system is Red Hat Linux 9, using the Borland C++BuilderX Personal IDE (which uses the g++ compiler). I downloaded and installed Boost from boost.org using the command: bjam -sTOOLS=gcc install The install seemed to complete fine, with 2900+ targets updated. The libraries install in /usr/local/include/boost-1_31/boost. I created the following link: ln -s /usr/local/include/boost-1_31/boost /usr/include/boost I then use C++BuilderX to try and compile one of the example programs for the regex libaries that I found in the documentation. The source code is: /////////////////////// #include <list> #include <boost/regex.hpp> unsigned tokenise(std::list<std::string>& l, std::string& s) { return boost::regex_split(std::back_inserter(l), s); } #include <iostream> using namespace std; #if defined(BOOST_MSVC) || (defined(__BORLANDC__) && (__BORLANDC__ == 0x550)) // // problem with std::getline under MSVC6sp3 istream& getline(istream& is, std::string& s) { s.erase(); char c = is.get(); while(c != '\n') { s.append(1, c); c = is.get(); } return is; } #endif int main(int argc) { string s; list<string> l; do{ if(argc == 1) { cout << "Enter text to split (or \"quit\" to exit): "; getline(cin, s); if(s == "quit") break; } else s = "This is a string of tokens"; unsigned result = tokenise(l, s); cout << result << " tokens found" << endl; cout << "The remaining text is: \"" << s << "\"" << endl; while(l.size()) { s = *(l.begin()); l.pop_front(); cout << s << endl; } }while(argc == 1); return 0; } /////////////////////// The compiler returns the following errors: /////////////////////// g++ -c -o /home/sbobrows/cbproject/pmetest/linux/Debug_Build/splittest.o -g2 -O0 -MD -I/usr/include -I/usr/include/g++-3 splittest.cpp g++ -o /home/sbobrows/cbproject/pmetest/linux/Debug_Build/pmetest linux/Debug_Build/splittest.o linux/Debug_Build/splittest.o(.text+0x2c9): In function `__tcf_0': "stl_vector.h": /usr/include/c++/3.2.2/bits/stl_vector.h undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::~reg_expression [in-charge]()' at line 998 linux/Debug_Build/splittest.o(.gnu.linkonce.t._ZN5boost9re_detail22get_defau lt_expressionIcEERKNS_14reg_expressionIT_NS_12regex_traitsIS3_EESaIS 3_EEES3_+0x39): In function `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> > const& boost::re_detail::get_default_expression<char>(char)': "perl_matcher_common.hpp": /usr/include/boost/regex/v4/perl_matcher_common.hpp undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::reg_expression[in-charge](char const*, unsigned, std::allocator<char> const&)' at line 734 linux/Debug_Build/splittest.o(.gnu.linkonce.t._ZN5boost11regex_splitISt20bac k_insert_iteratorISt4listISsSaISsEEEcSt11char_traitsIcESaIcENS_12reg ex_traitsIcEES8_EEjT_RSbIT0_T1_T2_ERKNS_14reg_expressionISC_T3_T4_EENS_15reg ex_constants12_match_flagsEj+0x12e): In function `unsigned boost::regex_split<std::back_insert_iterator<std::list<std::basic_string<cha r, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, char, std::char_traits<char>, std::allocator<char>, boost::regex_traits<char>, std::allocator<char> >(std::back_insert_iterator<std::list<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> > const&, boost::regex_constants::_match_flags, unsigned)': "perl_matcher_non_recursive.hpp": /usr/include/boost/regex/v4/perl_matcher_non_recursive.hpp undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::mark_count() const' at line 1059 linux/Debug_Build/splittest.o(.gnu.linkonce.t._ZN5boost9re_detail12perl_matc herIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_ 12regex_traitsIcEESaIcEEC1ES6_S6_RNS_13match_resultsIS6_S9_EERKNS_14reg_expr essionIcSB_SC_EENS_15regex_constants12_match_flagsE+0x78): In function `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char>, std::allocator<char> >::perl_matcher[in-charge](__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > >&, boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> > const&, boost::regex_constants::_match_flags)': "perl_matcher_non_recursive.hpp": /usr/include/boost/regex/v4/perl_matcher_non_recursive.hpp undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::get_traits() const' at line 869 ': "basic_string.tcc": /usr/include/c++/3.2.2/bits/basic_string.tcc undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::empty() const' at line 146 linux/Debug_Build/splittest.o(.gnu.linkonce.t._ZN5boost9re_detail12perl_matc herIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_ 12regex_traitsIcEESaIcEE24estimate_max_state_countEPSt26random_access_iterat or_tag+0x30): In function `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char>, std::allocator<char> >::estimate_max_state_count(std::random_access_iterator_tag*)': "regex_grep.hpp": /usr/include/boost/regex/v4/regex_grep.hpp undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::size() const' at line 46 linux/Debug_Build/splittest.o(.gnu.linkonce.t._ZN5boost9re_detail12perl_matc herIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_ 12regex_traitsIcEESaIcEE8find_impEv+0xc0): In function `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char>, std::allocator<char> >::find_imp()': "regex_grep.hpp": /usr/include/boost/regex/v4/regex_grep.hpp undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::mark_count() const' at line 49 Build cancelled due to errors linux/Debug_Build/splittest.o(.gnu.linkonce.t._ZN5boost9re_detail12perl_matc herIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_ 12regex_traitsIcEESaIcEE8find_impEv+0x202): In function `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char>, std::allocator<char> >::find_imp()': "perl_matcher_non_recursive.hpp": /usr/include/boost/regex/v4/perl_matcher_non_recursive.hpp undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::mark_count() const' at line 767 linux/Debug_Build/splittest.o(.gnu.linkonce.t._ZN5boost9re_detail12perl_matc herIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_ 12regex_traitsIcEESaIcEE8find_impEv+0x290): In function `__static_initialization_and_destruction_0': "perl_matcher_non_recursive.hpp": /usr/include/boost/regex/v4/perl_matcher_non_recursive.hpp undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::mark_count() const' at line 1254 linux/Debug_Build/splittest.o(.gnu.linkonce.t._ZN5boost9re_detail12perl_matc herIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_ 12regex_traitsIcEESaIcEE8find_impEv+0x2d7): In function `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char>, std::allocator<char> >::find_imp()': "perl_matcher_common.hpp": /usr/include/boost/regex/v4/perl_matcher_common.hpp undefined reference to `boost::re_detail::verify_options(unsigned, boost::regex_constants::_match_flags)' at line 821 linux/Debug_Build/splittest.o(.gnu.linkonce.t._ZN5boost9re_detail8access_tIc NS_12regex_traitsIcEESaIcEE5firstERKNS_14reg_expressionIcS3_S4_EE+0x d): In function `boost::re_detail::access_t<char, boost::regex_traits<char>, std::allocator<char> >::first(boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> > const&)': "regex_split.hpp": /usr/include/boost/regex/v4/regex_split.hpp undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::first(boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> > const&) at line 36 /////////////////////// After searching around extensively, I've not come up with any solution to my problem. Can someone please point me in the right direction? It seems like I'm just missing some configuration step along the way. Thanks in advance, Steve!

3 3

RE: RE: Re: Re:[boost] Re: Serialization Formal Review #2
by Rozental, Gennadiy 27 Apr '04

27 Apr '04

> > > The main problem I had was that certain member variable weren't > > > accessible. The STL collections don't have that issue so > there was no > > > problem. > > > Sorry if this is silly question, but why would you need an > access to > > the counter? IMO we should be able to save/load shared_ptr without > > need to save it. > > I checked the code (which was written some time ago) and the > answer to that question isn't obvious to me. I do remember > starting with the idea that it wouldn't be necessary to look > beyond shared_ptr but I had to just keep adding on to make > things work. The implementation of shared_ptr is A LOT more > involved that one would guess. > > My implementation of shared_ptr implementation may not be the > only or best one. It is pretty straight forward however in > that it follows the chain of composition - which includes > shared_count. > > Sorry I can't give a better answer. > > Robert Ramey There is another counter to direct counter using (I just think out loud - it may be that you ok): what if I do not save all of the shared_ptr to the same object? What will happened once they will get restored? Wouldn't it cause memory leak? I do realize that any other solution would be more complicated, but I think we should go for it. Gennadiy.

1 0

Re:RE: Re: Re:[boost] Re: Serialization Formal Review #2
by Robert Ramey 27 Apr '04

27 Apr '04

> > The main problem I had was that certain member variable weren't > > accessible. The STL collections don't have that issue so there was no > > problem. > Sorry if this is silly question, but why would you need an access to the > counter? IMO we should be able to save/load shared_ptr without need to > save it. I checked the code (which was written some time ago) and the answer to that question isn't obvious to me. I do remember starting with the idea that it wouldn't be necessary to look beyond shared_ptr but I had to just keep adding on to make things work. The implementation of shared_ptr is A LOT more involved that one would guess. My implementation of shared_ptr implementation may not be the only or best one. It is pretty straight forward however in that it follows the chain of composition - which includes shared_count. Sorry I can't give a better answer. Robert Ramey

1 0

shared_ptr and BOOST_DISABLE_THREADS
by Carl Daniel 27 Apr '04

27 Apr '04

Playing with a Spirit-based parser for a simple scripting language I noticed that #defining BOOST_DISABLE_THREADS resulted in a parser that was nearly 3 times faster. For reasons that aren't relevant to the discussion, this had to be an MT build, but the parser didn't need thread safety. That made me wonder though: If I #define BOOST_DISABLE_THREADS in some translation units but not in others, what's going to happen? I suppose one way of summarizing it is this: does BOOST_DISABLE_THREADS change the type of shared_ptr that's made? If not, that seems like a rather serious problem to me - especially given the enormous difference in performance that I measured (optimized build with VC8 alpha). What obvious thing am I overlooking? -cd

10 23

dynamic_bitset: work in progress...
by Gennaro Prota 27 Apr '04

27 Apr '04

Hi, for those interested in dynamic_bitset I wanted to reassure them that it will be stabilized soon. It's just, as I said, that I can work on it only for a couple of days per week, and for a couple of hours. This week, for instance, it happened that I saw the Borland regressions *after* my time expired (my timezone is in the way, too). I've integrated the new dyn_bitset_unit_test4 file in the Jamfile and fixed some errors of VACPP and gcc 3.4. Please, expect a correction time-frame of about 1/2 weeks. In the meantime, I hope to work on the documentation, which I can do from the office, during the launch break. I also wait for comments/suggestions, especially about the issues raised in http://lists.boost.org/MailArchives/boost/msg63220.php. Cheers, Genny. __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover

1 0

Serialization Formal Review #2 -- Review Period Closed
by Jeff Garland 27 Apr '04

27 Apr '04

The review period for the Serialization library is now over. Thanks to all the reviewers for their time in reviewing the library. Reviewers were unanimous in voting to accept the library. As a result, Serialization will be accepted into Boost. It will take me about a week to post a summary of the review comments and requested changes. And finally, thanks again to Robert for his unyielding effort to bring this library to Boost! Jeff

1 0

[iterator + named params] includes #error
by Vladimir Prus 27 Apr '04

27 Apr '04

When I try to compile the following code: #include <boost/named_params.hpp> #include <boost/iterator/transform_iterator.hpp> I get: ghost@zigzag:/tmp$ g++ -I ~/Work/boost -I ~/Work/boost-sandbox np.cpp In file included from /home/ghost/Work/boost/boost/iterator/detail/enable_if.hpp:15, from /home/ghost/Work/boost/boost/iterator/transform_iterator.hpp:14, from np.cpp:3: /home/ghost/Work/boost/boost/iterator/detail/config_def.hpp:22:3: #error you have nested config_def #inclusion. I suspect that the attached patch might need to be applied, but since I don't understand 'config_def.hpp' I though I'd ask first. - Volodya

1 0

[serialization, bind, vc7.1]
by Alexey Nikitin 27 Apr '04

27 Apr '04

Next example (only 2 lines) not compiled: ---- t120.cpp ----- #include <boost/bind.hpp> #include <boost/archive/text_iarchive.hpp> -------------------- D:\Alnik\cpp>cl /c /GX t120.cpp Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. t120.cpp C:\Alnik\heap\boost\boost-dev\boost\mpl\less.hpp(39) : error C2760: syntax error : expected ',' not ';' C:\Alnik\heap\boost\boost-dev\boost\mpl\less.hpp(51) : see reference to class template instantiation 'boost::mpl::less<T1,T2>' being compiled C:\Alnik\heap\boost\boost-dev\boost\mpl\less.hpp(39) : error C2144: syntax error : 'const bool' should be preceded by '}' C:\Alnik\heap\boost\boost-dev\boost\mpl\less.hpp(39) : error C2062: type 'const bool' unexpected C:\Alnik\heap\boost\boost-dev\boost\mpl\less.hpp(39) : error C2238: unexpected token(s) preceding ';' C:\Alnik\heap\boost\boost-dev\boost\mpl\less.hpp(42) : error C2065: 'value' : undeclared identifier But if to rearrange lines then compiled. Is this the bug of compiler? Regards, Alexey.

2 1

logging library?
by John Torjo 27 Apr '04

27 Apr '04

Dear boosters, I know a while ago there was some interest in a logging library. And of course, there are so many ways you can do logging, that it was somehow agreed that a unique logging library can't address them. However ;), recently I discovered a very easy way to do logging. Gradually, I've come to this class (shown at the end). Using it is extremely easy, and it totally decouples what you write from where it's written. The idea is to have a function that takes a const std::string& parameter, and it will be called whenever a new message is logged. If you want thread-safety, it's just too simple... Just implement it within your function. Example: // log.h logstream errors_log(); logstream activity_log(); // log.cpp void do_log( const std::string & msg) { // ... thread-safe writing to cout scoped_lock lock(some_static_mutex); std::cout << msg; std::cout.flush(); } logstream errors_log() { return logstream(&do_log) << "[ERROR] "; } logstream activity_log() { return logstream(&do_log) << "[activity] "; } // in code #include "log.h" activity_log() << "application started (" << ver.major_ver << "." << ver.minor_ver << ")" << std::endl; errors_log() << "too many users" << users << std::endl; // etc. Also, I have an idea of how to enable/disable (parts of) logging at runtime. Same for very easily enabling/disabling logging of different modules. Any interest in such a library? Best, John #ifndef LOG_LOGSTREAM_HPP #define LOG_LOGSTREAM_HPP #pragma once // Copyright (c) John Torjo - 2004 #include <iosfwd> #include <sstream> namespace log { // allow finding the prototype for a log function template<class char_type, class traits = ::std::char_traits<char_type>, class aloc = ::std::allocator<char_type> > struct log_func { typedef void (*type)(const std::basic_string<char_type,traits,aloc> &); }; // allow writing to a log template<class char_type, class traits = ::std::char_traits<char_type>, class aloc = ::std::allocator<char_type> > struct basic_logstream { typedef typename log_func<char_type,traits,aloc>::type log_func_type; typedef ::std::basic_ostringstream<char_type,traits,aloc> ostring_stream_type; explicit basic_logstream( log_func_type func) : m_func(func) {} basic_logstream( basic_logstream & other) : m_func(other.m_func) { m_buffer << other.m_buffer.str(); other.m_func = 0; } ~basic_logstream() { if ( m_func) m_func( m_buffer.str() ); } template< class T> basic_logstream & operator<<( const T & val) { m_buffer << val; return *this; } typedef std::ostream & (*ostream_func)(std::ostream & ); basic_logstream & operator<<( ostream_func f) { f( m_buffer); return *this; } private: ostring_stream_type m_buffer; log_func_type m_func; }; typedef basic_logstream<char> logstream; typedef basic_logstream<wchar_t> wlogstream; } #endif

7 19

[iterator] concept checking for transform_iterator
by Vladimir Prus 27 Apr '04

27 Apr '04

I've just passed argument to make_transform_iterator in the wrong order, and could not understand the problem for quite some time. Maybe, it's possible to add some concept checking to catch such errors earlier. For example, the attached patch? Thoughs? - Volodya

1 0

program-options thread problem
by Neal D. Becker 27 Apr '04

27 Apr '04

I have both added current program-options to my boost build tree, and all the usual variants of libboost_program_options-gcc.a, also libboost_python-gcc-mt.a. Linking against libboost_program_options-gcc.a I get errors about pthread symbols. Adding -pthread fixes it. It looks to me that libboost_program_options-gcc.a is referencing pthread symbols. nm /usr/local/src/boost_1_31_0.gcc34/stage/lib/libboost_program_options-gcc.a | grep thread U pthread_mutex_destroy U pthread_mutex_init w pthread_mutex_lock w pthread_mutex_unlock w pthread_mutex_lock w pthread_mutex_unlock Yup,sure is.

3 7

Re:Re: [boost] Serialization Formal Review #2
by Robert Ramey 27 Apr '04

27 Apr '04

Matthias Troyer wrote: > I have tried extending the library since I want to swap our old > serialization library used at http://alps.comp-phys.org with a Boost > serialization library as soon as possible. It was important to keep the > same archive format, since we have gigabytes of data collected over ten > years in millions of CPU-hours and need to be able to read those with > both new and old codes. With the help of Robert I managed to convince > myself that this is indeed possible Perhaps it might be possible, but I'm doubtful that it's the best way to address the problem. If the legacy format is a meta-data format it can be possible in a way similar to the way the XML was handled. But in general it will not be desirable nor necessary. To see this take an extreme example. Suppose over the last 10 years we had 10 different programmers working on a the project. Each one had to save and reload data for his classes. Now we want to convert to the new system. We would need a new archive class that tracked all the idiosyncracies in the current code. A huge job. And there exists a much simpler approach. Loading legacy data(legacy_data & ld) ==================== Ifstream is("old_data"); // read first line of old_data file // if it doesn't have the serialization signature // load the data using the legacy system. else{ Boost::binary_iarchive ia(is); ia >> ld } Save data // save in using serialization. As file are processed they are automatically converted to the new system. No special programming is required as the code to load the class instances from the legacy data format already exists - it's the legacy code ! its free at this point. > 4. Documentation of archive formats, especially what class and object > information is stored. I want to be able to predict, from reading the > documentation, what exactly will be written to the archive and in which > order. This would entail a detail paraphrasing of the operation of the code. In the case where there is no versioning, no tracking and no pointer serialization its fairly simple. When any of the others are present, its starts to get pretty complex. There is a comment in basic_archive.cpp which in fact summarizes the format - but I'm not convinced it something that belongs in user documentation. ////////////////////////////////////////////////////////////////////// // // class_information is stored as // // class_id* // -1 for a null pointer // if a new class id // [ // exported key - class name* // tracking level - always/never // file version // ] // // if tracking // [ // object_id // ] // // [ // if a new object id // data... // ] // // * required only for pointers - optional for objects This recursively defines the file format for any serialized data structure. > This is essential when exchanging data with an application that > does not use this library. I'm skeptical that this is going to be fruitful. The "other" application is going to have to effectively re-implement this whole library. Why bother, just use this one. To send data to "other" applications, there is always the XML archive. I don't think that a general purpose tool such as serialization is going to be very helpful in trying to implement some externally defined data format. Some meta-data formats (e.g. XML and windows ini files) are doable but in general it's not going to be productive. Robert Ramey

2 1

Type traits question
by Robert Ramey 26 Apr '04

26 Apr '04

Is there a type traits guru that can explain to me why the following doesn't work as I expect. It's got to be something very, very obvious but I can't see it. Thank you Robert Ramey #include <boost/static_assert.hpp> #include <boost/type_traits/is_base_and_derived.hpp> #include <boost/type_traits/remove_pointer.hpp> class Base1 { char a; }; class Base2 { int b; }; class Derived : public Base1, public Base2 { long c; }; void main(){ // this passes BOOST_STATIC_ASSERT((boost::is_base_and_derived< Base1, Derived >::value)); // this fails !? BOOST_STATIC_ASSERT((boost::is_base_and_derived< boost::remove_pointer<Base1 *>, boost::remove_pointer<Derived *> >::value)); }

3 2

RE: Type traits question
by Robert Ramey 26 Apr '04

26 Apr '04

Never mind, I see it now. Sorry I was desperate. Robert Ramey Robert Ramey wrote: > > #include <boost/static_assert.hpp> > #include <boost/type_traits/is_base_and_derived.hpp> > #include <boost/type_traits/remove_pointer.hpp> > > class Base1 > { > char a; > }; > > class Base2 > { > int b; > }; > > class Derived : public Base1, public Base2 > { > long c; > }; > > void main(){ > // this passes > BOOST_STATIC_ASSERT((boost::is_base_and_derived< > Base1, > Derived > >::value)); > > // this fails !? > BOOST_STATIC_ASSERT((boost::is_base_and_derived< > boost::remove_pointer<Base1 *>, > boost::remove_pointer<Derived *> > >::value)); > }

1 0

Re: [boost] [multi_index] composite keys: request for advice
by JOAQUIN LOPEZ MU?Z 26 Apr '04

26 Apr '04

----- Mensaje original ----- De: Rob Stewart <stewart(a)sig.com> Fecha: Lunes, Abril 26, 2004 10:16 pm Asunto: Re: [boost] [multi_index] composite keys: request for advice > From: Joaquin M Lopez Munoz <joaquin(a)tid.es> > > > > Composite keys can be specified by a new construct > > called composite_key in the following manner: > > > > struct record > > { > > int first; > > int second > > int third; > > }; > > > > multi_index_container< > > record, > > indexed_by< > > composite_key< > > record, //base value > > member<record,int,&record::first>, // first key > > Would that you could make this work to avoid the duplication and > chance for errors: > > member< &record::first > > > I know a function template can deduce the other types, but I > can't think of how to make it work here. > I'd be the happiest man on the block if I could have that, but AFAIK it is not possible. The fact that member<> is here specified in the context of composite_key does not help, either. This has been previously brought into discussion several times. If you have a typeof() utility and don't object to some macro hackery, this is an approximation: template<typename Class,typename Member> Class base_from_ptr_to_member(Member Class::*); template<typename Class,typename Member> Member member_from_ptr_to_member(Member Class::*); #define BOOST_MULTI_INDEX_SMART_MEMBER(PtrToMember) \ member< \ typeof(base_from_ptr_to_member(PtrToMember)),\ typeof(member_from_ptr_to_member(PtrToMember)),\ PtrToMember\ > ... multi_index_container< record, indexed_by< ordered_unique< BOOST_MULTI_INDEX_SMART_MEMBER(&record::x) > > > Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[multi_index] composite keys: request for advice
by Joaquin M Lopez Munoz 26 Apr '04

26 Apr '04

> I'm working through the post review changes of multi_index and hope to have something released in one or two weeks. One of the issues raised in the review was the possibility to promote what was an example of composition of keys to be part of the library. I've come up with something more ambitious, but there's a design decision of which I'm not quite certain wich way to go, and I'd like to ask you for advice. Composite keys can be specified by a new construct called composite_key in the following manner: struct record { int first; int second int third; }; multi_index_container< record, indexed_by< composite_key< record, //base value member<record,int,&record::first>, // first key member<record,int,&record::second>, // 2nd member<record,int,&record::third> // 3rd > > > mc; In the example the composite key is composed of three key extractors, and the sorting is made in lexicographical order, for instance: 0,0,1 0,0,2 0,1,0 0,5,4 1,0,0 1,0,2 1,2,3 ... Given the lexicographical order, it is possible to efficiently search for incomplete keys where only the first values are given: mc.equal_range(make_tuple(1,0)) yields 1,0,0 1,0,2 mc.equal_range(make_tuple(0)) yields 0,0,1 0,0,2 0,1,0 0,5,4 and so on. Accordingly, comparison operators between composite_key results and tuples are overloaded so that the following holds: composite_key</* as before*> ck; ck(record(1,2,3))<=make_tuple(1,2); // yields true make_tuple(1,2)<=ck(record(1,2,3)); // yields true So far, this is all IMHO perfectly consistent, but the following design decision is not obvious to me: given the previous, what should be the result of ck(record(1,2,3))==make_tuple(1,2); // true or false? As these two objects are neither greater than the other, at least they are *equivalent*, but maybe allowing operator== to return true is too much. An argument against making them equal is that, with future hashed indices in mind, hashing has to be done on the whole tuple of values returned by the composite key so that: multi_index_container< record unordered_unique< //hashed composite_key< /* as before */ > > > mc; mc.find(make_tuple(1,2,3)); //OK mc.find(make_tuple(1,2)); //KO, we need the whole tuple If we make ck(record(1,2,3))==make_tuple(1,2) return true, the impossibility of having the last line to work is puzzling. If we make it return false, it is also puzling that neverthelss operator<= is true in both senses. What do I do? a. require operator== between composite_key results and tuples to work only on full tuples. b. define operator== in the same line operator<, <= etc. are defined. Thanks for your comments. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 4

RE: Re: Re:[boost] Re: Serialization Formal Review #2
by Rozental, Gennadiy 26 Apr '04

26 Apr '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey > Sent: Monday, April 26, 2004 2:02 PM > To: boost(a)lists.boost.org > Subject: Re:Re: Re:[boost] Re: Serialization Formal Review #2 > > > Peter Dimov wrote: > > > FWIW, in my own library I do, indeed, have a special case code for > > serializing an unmodified shared_ptr, for two reasons. First, this > > shows that the library is flexible enough. Second, even if > we modify > > boost::shared_ptr to be boost::serialization-friendly, we won't be > > able to patch std::tr1::shared_ptr. > > The main problem I had was that certain member variable > weren't accessible. The STL collections don't have that issue > so there was no problem. Sorry if this is silly question, but why would you need an access to the counter? IMO we should be able to save/load shared_ptr without need to save it. Gennadiy.

1 0

RE: [boost] Re: Serialization Formal Review #2
by Rozental, Gennadiy 26 Apr '04

26 Apr '04

> > Your library cannot be used to save/load anything before main() is > > entered nor can it be used to save/load anything after > main() has been > > left. > > Correct. It never occurred to me to mention this. > > Robert Ramey It probably could be addressed by some kind of lifetime management scheme. Essentially you need to make sure that before any serialization code is invoked all static initializes gets instantiated. I am not sure it doable since you actually within the library code may not know what should be instantiated. On the other hand I an not sure that any move in this direction even worth the trouble. I guess it may be convenient in some cases. Gennadiy.

1 0

Re:Re: Re:[boost] Re: Serialization Formal Review #2
by Robert Ramey 26 Apr '04

26 Apr '04

Peter Dimov wrote: > FWIW, in my own library I do, indeed, have a special case code for > serializing an unmodified shared_ptr, for two reasons. First, this shows > that the library is flexible enough. Second, even if we modify > boost::shared_ptr to be boost::serialization-friendly, we won't be able to > patch std::tr1::shared_ptr. The main problem I had was that certain member variable weren't accessible. The STL collections don't have that issue so there was no problem. > However, should you decide to use your current scheme, I'll happily insert > whatever friend declarations are necessary in shared_count. > I'm away from my computer right now, so I can't paste my read/write > functions for shared_ptr, but the general idea is that they keep a > map< shared_ptr<void>, int > on writing, mapping every shared_ptr > ownership group to a pointer id, and a corresponding map< int, > shared_ptr<void> > on reading, for the reverse transformation. > The main problem for implementing a non-intrusive serialize() for > shared_ptr is that these pointer maps need to be held in the archive, > which requires either archive modification, or a general "extra state" > support in all archives. That's pretty much the same as what the serialization system does - albeit in perhaps in a more generic way. Its not clear to me how enhanced library code could be made to work work without granting access to shared_count. Of course, if access is granted to shared_count, then everything works already. Robert Ramey

1 0

ReL[boost] Re: Serialization Formal Review #2
by Robert Ramey 26 Apr '04

26 Apr '04

David Abrahams wrote: >"Peter Dimov" <pdimov(a)mmltd.net> writes: >>> http://www.boost.org/libs/smart_ptr/intrusive_ptr.html#Introduction >>> >>> However, the situation is different there as the called function >>> only accepts exactly one parameter. >> >> It doesn't matter. ADL should find the overload, provided that >> 'serialize' >> is not qualified at the point of the call. > >> In my own library I use very similar read/write overloads that are, >> indeed, placed in the namespace of the corresponding class and found by >> ADL. Yes, it works with VC 7.1. >The recommended "overload in the library namespace" procedure was a >big concern for me, but I didn't post anything because I couldn't >remember why it's an issue. I have in my mind, left over from my work >with Peter on this problem, a rule that in the current language you >shouldn't do that, and should rely instead on ADL. I don't know why >I think that anymore, but I *can* say that Peter should be listened >to in this area; he's more aware of the issues than almost anyone. OK, I've looked at code and found that found that my calls to "serialize" are qualified by boost::serialization. So this can be fixed. It seems that users of older compilers will have to overload in the library namespace but that it will not be necessary for users that are only concerned with newer compilers. So its not a problem for the library. Except... What about when I've overloaded from with in the library - such as when default serialization traits are overloaded. Should this namespace specification be #ifdef/#endif depending on the compiler config? Should this be dependent on BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP? Robert Ramey

1 0

Re:[boost] Re: Serialization Formal Review #2
by Robert Ramey 26 Apr '04

26 Apr '04

Andreas Huber wrote: > Ok, but IIUC this undermines the original promise that a class > implementing serialize or safe/load can be serialized to *any* archive, > even future ones without changing its implementation. I see that I > wouldn't need to change the serialization *code* but I'd need to add > an include to the .cpp file, right? Correct. But I don't see that as undermining the original promise. You will have to re-compile for future archives, but code will not have to be changed. The polymorphic archive (in progress) will lift even that restriction. > > >> 9. The library registers all kinds of stuff with static instances. > >> This precludes its use outside main(). > > > Hmmm - that would be news to me. > Your library cannot be used to save/load anything before main() is entered > nor can it be used to save/load anything after main() has been left. Correct. It never occurred to me to mention this. Robert Ramey

1 0

Re:[boost] Re: Formal review: serialization
by Robert Ramey 26 Apr '04

26 Apr '04

Jeff F wrote: > template<class Archive> > inline void serialize( > Archive& ar > , boost::filesystem::path& t > , unsigned int version ) > { > std::string lPathString; > > if( is_saving(ar) ) > lPathString = t.native_file_string(); > > ar & make_nvp( "PathString", lPathString ); > > if( is_loading(ar) ) > t = boost::filesystem::path( lPathString, > boost::filesystem::native ); > } The "real" solution here is to implement serialization for "native_file_string() So that things look like template<class Archive> void serialize( Archive &ar, boost::filesystem::native_files_sting_type & t, unsigned int version ){ ... ?; } template<class Archive> void serialize( Archive &ar, boost::filesystem::path & t, unsigned int version ){ ar & make_nvp("PathString", t); } Robert Ramey

1 0

Re:[boost] Re:Re:Re:Formal review: serialization
by Robert Ramey 26 Apr '04

26 Apr '04

Vladimir Prus wrote: >Hmm... gotta look into this. What about my second question: >>> 2. For random access I need to make sure that all saved objects have >>> export key. How do I do that? Not necessary out-of-the box but where >>> I can plug the check? Actually, its not necessary that ALL saved objects have export keys. Only those objects that are serialized through polymorphic pointers need to be exported or registered. An attempt to serialize a polymorphic pointer that has neither been exported nor explicitly registered will trigger a run-time exception "unregistered_class". If you wanted to enforce the idea that all types should be exported I believe it would be possible to something like the following in your archive class: a) override implementation of save(class_id_type & t) and save(class_id_optional_type) so that they set a flag. b) override implementation of save(class_name & t) it sets a flag c) override end_preamble so that it checks for an undesired set of flags. I never considered this before so you'll have to check the above yourself. >>> one for dynamic arrays with element-wise save >> >> I would envision one using >> >> ar << element_count >> For(i = 0; I < element_count; i++) >> ar << element[i] >> >> I'm not sure that its worth adding and documenting such an obvious and >> trivial thing as a separate wrapper. >But on loading you need to add 'new[]' call. So load and save become >non-symmetric, and you need to split serialize, which is rather >inconvenient. Actually, I forget the original question. But in any case, I'm wondering about trying to anticipate every application. OTOH, having considered again dynamic_array I'm now more inclined to include it. I'll take a look a the other ones. These would be described in the document under "serialization wrappers". > > There are cases when an object id is > > assigned but not written to the archive I don't see these as having much > > utility outside of serialization. > So, it's not easily possible to plug a different algorithm? In a general sense - NO. Any of the "bookkeeping" types in common_?archive can be overloaded to taste. Overloading these in a special way was how XML was implemented. I'm sure that these could be used for creating other special purpose archives but I really can't know for any particular case until one tries to implement them. >>> Ah, I've missed that. Do I need to provide both 'type' and 'value'? >>> Can't serialization library work with just one? > >> Could be. I just provided both so that I could interoperate with mpl >> without having to think about each specific case. > But for user this can be inconvenient. Actually I was thinking most users would use the macros. If one fails to include one that's used it should fail compilation so I don't see it's a show stopper. Actually I think it's easier just to always include both rather than trying to document/remember which ones use which. > It it possible that you make BOOST_EXPORT always > register classes with the polymoprhic archive. > and use polymoprhic archive as fallback for serializing classes? I'm still fine tuning this (smart_cast anyone?). But basically things work like this. a) Just as now, one could pre-compile a serialization instantiating code for particular archives. In this case one of the archives would be the "polymorphic_?archive" class which is nothing but a bunch of virtual function declarations. b) when the application is built, a specific archive implemenatation is selected. E.G polymorphic_text_?archive. The is archive inherits the implementation from text_?archive and the interface from polymorphic_?archive. c) the application will link with the pre-compiled classes. I'm not sure this answers your question - but there it is. Thank god no ones asked about DLL implementations yet. Robert Ramey

1 0

Re:[boost] Re: Serialization Formal Review #2
by Robert Ramey 26 Apr '04

26 Apr '04

Message: 11 Andreas Huber wrote: > 1. On compilers supporting ADL, it seems the user-supplied serialization > function for non-intrusive serialization > template<class Archive> > void serialize(Archive & ar, gps_position & g, const unsigned int > version); > could also be put into the namespace of the type that it serializes. If > this is correct it should be mentioned in the tutorial & reference. If > not, there should be a rationale why not. I did try this in my environment VC 7.1 and it failed to work. Does anyone want to assert that it should or shouldn't work? > 2. save/load naming: All functions that have to do with reading from an archive are named load*, > all functions that have to do with writing to an archive are named save*. > To me (non-native speaker) these names are generally associated with > persistence only. Since the library is more general (one could use it for > network communication, etc.) load/save are a bit missleading. I'd rather > see read/write or other names that more clearly communicate what the > functions are doing. I used save/load consistently specifically to distinguish from read/write which seemed to me too suggestive of persistence, files and streams. > 3. archive naming: > The word archive also seems to be associated with persistence. I think > serializer would much better describe the functionality. Another option I > could live with is serialization_stream (I slightly disagree with the > assertion in archives.html that an archive as modelled by this library is > not a stream. It might not be what C++ folks traditionally understand a > stream is but to me it definitely is a more general stream, i.e. a stream > of objects/things/whatever). Archive is perhaps a little too suggestive. I borrowed from MFC. Making changes would have a huge ripple effect through code, file names, namepace names and documentation. I don't find any proposals for alternate naming sufficiently compelling to justify this. > 4. Object tracking 1: Seeming contradiction > I've had difficulty determining how exactly object tracking works. I > believe the associated docs are slightly contradictory: > - Under exceptions.html#pointer_conflict I read that the pointer_conflict > exception is thrown when we save a class member through a pointer first > and then "normally" (i.e. through a reference). Correct. > - traits.html#tracking says "... That is[,] addresses of serialized > objects are tracked if and only if an object of the same type is anywhere > in the program serialized through a pointer." Correct. > The second sentence seems to contradict the first one in that it does not > specify that the sequence of saving is important I see no conflict here > (I assume that pointer_conflict exception is not thrown if we save > normally first and then through a pointer). Correct > Moreover, I don't see how the library could possibly > achieve the "anywhere in the program" bit. It is tricky and it does work. I works by instantitiating a static variable. Static variables are constructed before main() is invoked. These static variables register themselves in global table when constructed. So even though a template is used "anywhere in the program" the entry in the global table exists before execution starts. I'm reluctant to include such information in the manual. > 5. Object tracking 2: It should not be possible to serialize pointers > referencing objects of types that have track_never tracking type. LOL - tell that to library users. There are lots of things that users are convinced they have to do that I don't think are a good idea. As a library writer I'm not in position to enforce my ideas how users should use the library. On this particular point I would be very suspicious about such a usage but as practical matter I just have to include a warning and move on. special.html#objecttracking says: <quote> By definition, data types designated primitive by Implementation Level class serialization trait are never tracked. If it is desired to track a shared primitive object through a pointer (e.g. a long used as a reference count), It should be wrapped in a class/struct so that it is an identifiable type. The alternative of changing the implementation level of a long would affect all longs serialized in the whole program - probably not what one would intend. </quote> > I think serializing untracked pointers almost never makes sense. If it > does anyway the pointed-to object can always be saved by dereferencing the > pointer. Such an error should probably be signalled with an exception. I don't understand this. > 6. Object tracking 3: One should be able to activate tracking on the fly > Rarely it makes sense to save even primitive types in tracked mode (e.g. > the example quoted in 6.). That's why I think setting the tracking type > per type is not flexible enough. It should be possible to override the > default somehow. I could imagine to save such pointers as follows: > class T > { > ... > int i; > int * pI; // always points to i > }; > template<class Archive > > void T::save(Archive &ar) const > { > ar << track( i ); // save the int here, keep track of the pointer > ar << track( pI ); // only save a reference to the int > } > Since it is an error to save an untracked type by pointer even the second > line needs the track( ) call. A main function of using a trait is to avoid instantiation of code that won't ever be used. If I understand your proposal we would have to instantiate tracking code even if it isn't used. But my main objection thing about this proposal is that it introduces a runtime modality into the type traits. This sound like it would very hard to debug and verify. I see lots of difficulties and very little advantage to trying to add this. > 7. I think the enum tracking_type should rather be named tracking_mode as > the _type suffix suggests something else than an enum. I don't think the change is sufficiently compelling to justify the hassle associated with this. > 8. I don't understand how function instantiation as described under > special.html#instantiation works. The description seems to indicate that > all possible archive classes need to be included in the files of all types > that are exported. Is that true? True. All archives that might be used have to be included. This is an artifact of using templates rather than virtual functions. Templates regenerate the code for each combination of serializable type and archive. This results in faster code - but more of it. There were strong objections raised in the first review about the fact it used virtual functions rather then templates - so it was changed to templates here. > 9. The library registers all kinds of stuff with static instances. This > precludes its use outside main(). Hmmm - that would be news to me. Robert Ramey

6 7

Re: [boost] [serialization] not so formal review
by Robert Ramey 26 Apr '04

26 Apr '04

Gennadiy Rozental wrote > Unfortunately I was not able to look with proper attention onto your > submission during review. One thing I did though: all the major issues I > mentioned in my original review looks resolved. I am sure will look into > more details later, but for now it is enough for me to cast YES vote. > This library cover very important problem domain in software development > and I think we all have now solid solution. Thanks and congratulation to > Robert for being able to bring it to us. I was waiting for a comment from you. Your incredibly insightful, exhaustive and focused review of the previous version was the main driving force behind this version. Looking back, it's still hard to for me to believe that in the six hours you said you spent anyone could really understand the implementation to the depth you did. Basically, all I did was to implement all your suggestions one at a time. Early on I switched over to your test library. This permitted me to add features one at a time and test at each stage. It did result in a lot of code being rewritten several times. But I think in system like this one can't really look far enough into the future implementation to avoid this. So it's not too much to say that if this library lives up to the hopes and expectations I have for it, it will be due to a collision between your previous review and my personality flaw that inspires me to throw myself at lost causes. I was going to suggest you might separate some time to review it. On the other hand, maybe I should quite while I'm ahead. Robert Ramey

1 0

Formal review: serialization
by Jeff Flinn 26 Apr '04

26 Apr '04

I was not involved in the original review. > Do you think the library should be accepted as a Boost library? Yes. > What is your evaluation of the design? The design, from a usage standpoint is excellent. Coming from the MFC world, boost::serialization far surpasses MFC's in usability and flexibility. Particularly notable are: no need for a common base class, a single serialize method used both for input/output. The only problem I see is that programming errors in some cases can be difficult track down, but no more so than with any template intensive library. While the current methods for Free Functions and Splitting save/load methods are certainly understandable and work. It would be nice to be able (partial)specialize the "serialize" function base on its IO type. It would also be nice to utilize enable_if to generate different code when the serialize function is instantiated for input/output archives. This would allow compile time constructs similar to mfc's runtime Ar.IsLoad(). > What is your evaluation of the implementation? I've been using the serialization library since version 13. All previous version bugs/issues have been cleared up with version 18. I've been able to remove all workarounds from my code, in particular dealing with support of multiple archive types in a single translation unit including binary, text and xml. Performance is more than adequate for my purposes. My application uses binary serialization to implement drag/drop. On a 3 year old 2GHz pc, a pair of save/loads of a ~2MB including graphical updates takes less than 2 seconds. I have only briefly viewed library source code when finding workarounds in previous versions. Others here are much more qualified to render a verdict in this regard. > What is your evaluation of the documentation? The documentation allowed me to add serialization to my application without needing to look at header/implementation files. Though, I'm sure I carry some context from having worked with MFC serialization. One misleading aspect IMO is with the Non-Intrusive Version example. The example implies that you would need access to the data members. I think an example of what to do when you don't have access to the data members is needed. For example, how would one serialize a boost::filesystem::path object. namespace boost { namespace serialization { template<class Archive> void save( Archive & ar, const boost::filesystem::path & t, unsigned int version ) { std::string lPathString( t.native_file_string() ); ar << make_nvp( "PathString", lPathString ); } template<class Archive> void load( Archive & ar, boost::filesystem::path & t, unsigned int version ) { std::string lPathString; ar >> make_nvp( "PathString", lPathString ); t = boost::filesystem::path( lPathString, boost::filesystem::native ); } } } BOOST_SERIALIZATION_SPLIT_FREE( boost::filesystem::path ) I'm sure this could be improved upon, but without it, there is a danger that many will think - "can't be used for my application". Seeing an examples like this makes it a little easier to remember that the template functions need to be defined in the boost::serialization namespace. > What is your evaluation of the potential usefulness of the library? I've always considered serialization to be a major element missing from C++. Nearly every application uses some method of custom serialization today. I've saved 100's of hours already in using boost::serialization rather than spinning custom file formats or implementing connections to DBMS systems to store/retrieve data. > Did you try to use the library? With what compiler? Did you have any problems? Yes, with VC71. As stated above, all problems with versions previous to version 18 have been corrected. One, recent problem is an access violation when loading a saved shared_ptr(NULL). > How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Applied in an actual development project over the last several months. > Are you knowledgeable about the problem domain? I've some experience with MFC serialization. Thanks for a great library! ----------------- Jeff Flinn Applied Dynamics, International

2 3

[Boost-bugs] [ boost-Support Requests-942349 ] Problem compiling :/
by SourceForge.net 26 Apr '04

26 Apr '04

Support Requests item #942349, was opened at 2004-04-26 07:19 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=942349&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Problem compiling :/ Initial Comment: Hi :) I've some problems compiling code that use \boost\iterator\transform_iterator.hpp (under VC++ 7 - VS2K2) : transform_iterator.hpp(45) : error C2825 : 'UnaryFunction::result_type': cannot form a qualified name transform_iterator.hpp(45) : error C2039: 'result_type' : is not a member of 'operator``global namespace''' transform_iterator.hpp(45) : fatal error C1507 : previous user errors and subsequent error recovery halt further compilation Thanks in advance :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=942349&group_i… ------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re:[boost] Re:Re:Formal review: serialization
by Robert Ramey 26 Apr '04

26 Apr '04

Vladimir Prus wrote: > > Robert Ramey wrote: > > I guess I have two questions: > 1. Won't serialization fail in some way if I just seek the stream to the > position found in index and try reading. > 2. For random access I need to make sure that all saved objects have > export > key. How do I do that? Not necessary out-of-the box but where I can plug > the check? > I believe the original question referred the ability to "browse" the archive for purposes of debugging etc. My view would be that the best way to do this would be to create and xml_archve. Your use case suggested a 30 data would probably would end up as a 90MB XML datafile. The reason for thinking in XML would be that I would hope that here exists "XML Browser for large files" which would be suitable for this case. If such a thing doesn't exist - I would prefer spending time making this general purpose tool - (and maybe a commercial product) to making a custom archive of narrow purpose. Random access into an archive would require some thought. First, it's not clear how it would be used. In general archives are nested structures, one could de-serialize an inner piece - but to where? The original data structure was embedded in something else which is not now there. So this can really only consider in the context of a specific application. Here are a couple of plausible scenarios. a) A general purpose archive browser - this could browse the archive in a random manner but wouldn't actually de-serialize the data. I don't see any real problem here. One would need to create an index either as a side effect of archive create or with a second pass over the final archive. b) using serialization for a data-state logging. Log(Archive ar, statedata){ // save seek point to index // append to archive ar << statedata; } Recover(Archive ar, statedata &, seekpoint) // set stream seekpoint ar >> statedata } I could envision something like this being made to work. So I would say that generally, serialization would be expected to be a serial operation. (surprise!). On the other hand, in certain special situations it might be possible/convenient to provide for some random access but I would expect that to be application specific. > >> The reason why I think the other is important, it that's it's actually > >> saving/loading support for plain C++ array -- which is rather basic > >> thing. > >> > > > > Hmmm - the library already implements serialization of plane C++ arrays > by > > serializing each element. > > For *fixed-size* arrays. But not for dynamically allocated arrays. BTW, it > seems we need two wrappers for completeness: > one for dynamic arrays with element-wise save I would envision one using ar << element_count For(i = 0; I < element_count; i++) ar << element[i] I'm not sure that its worth adding and documenting such an obvious and trivial thing as a separate wrapper. > and another for dynamic arrays with binary save. I see the binary object as filling that role. Ar << make_binary_object(dynamic_array_address, element_size * element_count); I once did propose a manual section name "Serialization Wrappers" which would have a couple of examples and highlight the fact that nvp and binary_object are instances of this concept. The idea was received unenthusiastically at the time but now I'm becoming convinced It's more effective to explain and illustrate the concept rather than try to anticipate all the wrappers that users might need. Actually, I think having such a section would have avoided the confusion surrounding the intended usage and purpose of binary_object. > I agree. I actually have a *crazy* but cute idea that one can use file > offset for object id. How object ids are assigned and can I customize that > process? That would keep overhead at absolute minimum. Object_id are assigned sequentially starting with 0. They are only used for classes which require tracking (e.g. when instances are serialized through pointers) they are used as indices into a vector so using these indices keeps overhead to a minimum. There are cases when an object id is assigned but not written to the archive I don't see these as having much utility outside of serialization. > Ah, I've missed that. Do I need to provide both 'type' and 'value'? Can't > serialization library work with just one? Could be. I just provided both so that I could interoperate with mpl without having to think about each specific case. > >> It also necessary to provide overload for char*. Does not count as > >> primitive > >> type? > > > > Default implementation for char * will work as it does for other > pointers. > > Eh... I though that serialization of pointers to builtin types is just not > allowed. > Default implementation level for pointers to primitives is set to not-serializable. This is resetable as it is for any other type. I doubt that on would want to do it for something like int or double as I would expect a lot of unintended side effects. One might want to use STRONG_TYPEDEF to define another int or double type and reset the implementation level of that - but that going off on a tangent. > Actually, my archive initially have only one (non-templated) 'save' for > unsigned. I got compile error until I've declared 'save' for const char*. > I'm not sure why. Its probably because of the above (pointer to a primitive type). Attempts to serialize instances of types whose implementation level is set to not-serializable will result in compile time assertions. (these assertions are sometimes the reason for the deep nested mpl). > > I came to conclude it presented a big security risk. The problem is the > > following: > > > later: > > > > char str[MAX_STRING_SIZE] > > > > ar >> static_cast<char *>(str); // to avoid str being treated as an > array > > > > suppose the text archive gets corrupted to: > > > > 3000 abc............ > > > > The archive will load with a buffer overrun - a security risk. > > Right. I think this problem can be addressed with a wrapper for dynamic > array > > char* str(0); > ar >> make_dynarray_wrapper(str) > > so that the library allocates the string itself. How does it know what size to make the array? Maybe you meen Ar >> make_dynarray_wrapper(str, number of elements * element size) Of course for char arrays one could use Ar << binary_object(str, element_count * element_size) And it would still be portable. > >> Can I define only one 'load' for unsigned int? > > > > As oppose to ? > > As opposed to overloads for all builtin types. For polymorphic_archive we > can't have templated function which 'fallbacks' anywhere. We need to have > a > closed set of virtual functions and I wonder what's the minimal set. > > the rest. BTW this provided a huge benefit. In the original version of > > last year I got into a never-ending battle to specify virtual functions > > which was > > dependent on the compiler - long long, etc. It was hopeless - moving to > > templates solved that. > > :-( I guess we're back to those problems. > I have recently got the polymorphic array working on my machine. Only a couple really small changes to the library code were required. For the list of primitive types I included all portable C++ primitive types. (that is no long long, __int64 etc.) I'm not sure how much interest the polymorphic archive will engender and it's a little hard to understand until you've actually spent enough time with the library to appreciate the limitations of templated code in certain scenarios. So although its clean (and clever) its not going to be easy to explain. Robert Ramey

3 2

[serialization] not so formal review
by Gennadiy Rozental 26 Apr '04

26 Apr '04

Hi, Robert. Unfortunately I was not able to look with proper attention onto your submission during review. One thing I did though: all the major issues I mentioned in my original review looks resolved. I am sure will look into more details later, but for now it is enough for me to cast YES vote. This library cover very important problem domain in software development and I think we all have now solid solution. Thanks and congratulation to Robert for being able to bring it to us. Regards, Gennadiy.

1 0

Serialization Formal Review #2
by Jeff Garland 26 Apr '04

26 Apr '04

All - Today (April 13th) is the start of the formal review of the Serialization library by Robert Ramey. The review will run until Monday April 26th. I will be serving as review manager. Library details are below. I have a number of special requests for this review: 1) This is a large, complex, and important library. Please don't wait till the end of the review period to start your review -- there is no additional room in the review schedule to extend the review period. 2) I am particularly interested in hearing from parties that have tried to extend the library by adding serialization for a new type or by building a new type of archive. The ability to easily extend the library for new types and novel types of archives is critical for this library. 3) If you reviewed the library during the first review, I would like your evaluation of whether the new version of the library addresses your original concerns. Also, if this is a re-review I would appreciate if you could send me a weblink from the mail archive to your original review posting(s). 4) Finally, I would like reviewers to indicate parts of the library that might become standalone boost libraries. While this will have little bearing on the acceptance / rejection of the library it might allow a reduction in the size of the library. As usual, please state in review comments how you reviewed the library and whether the you think the library should be accepted into Boost. Further guidelines for writing reviews can be found on the website at: http://www.boost.org/more/formal_review_process.htm#Comments ********************************************** Library Details: ********************************************** >From the library synopsis: Here, we use the term "serialization" to mean the reversible deconstruction of an arbitrary set of C++ data structures to a sequence of bytes. Such a system can be used to reconstitute an equivalent structure in another program context. Depending on this context, this might used implement object persistence, remote parameter passing or other facility. In this system we use the term "archive" to refer to a specific rendering of this stream of bytes. This could be a file of binary data, text data, XML, or some other created by the user of this library. The latest package can be found at the following locations: http://www.rrsd.com/boost/index.htm http://groups.yahoo.com/group/boost/files/serialization18.zip Thanks, Jeff

5 6

documentation bug report for boost::random
by Dave Gomboc 25 Apr '04

25 Apr '04

The code sample at the top of the documentation is missing a semicolon. > boost::uniform_int<> six(1,6) // distribution that maps to 1..6 > // see random number distributions Dave

1 0

boost:filesystem::path throws eception on valid path name
by Andreas Pokorny 25 Apr '04

25 Apr '04

Hi, $ cat test.cpp #include <stdexcept> #include <iostream> #include <boost/filesystem/path.hpp> int main() { try { boost::filesystem::path p("/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/include/g++-v3/"); } catch( std::exception &e ) { std::cout << e.what() << std::endl; } catch(...) { std::cout << "Unknown exception" << std::endl; } } $ g++ test.cpp -o test -lboost_filesystem $ ./test boost::filesystem::path: invalid name "g++-v3" in path: "/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/include/g++-v3/" Is that supposed to happen? Regards, Andreas Pokorny

2 1

Quick thought on Date-Time
by Daryle Walker 25 Apr '04

25 Apr '04

[NOTE: I haven't worked on this library; I'm just going by the posts I see here.] For this increment/decrement by a month problem, is there any way to store a date with only a month resolution? Nothing smaller will be stored, so day crossovers won't be a problem. Wouldn't something similar have/already-had been done when skipping days but ignoring the exact hour? (Or does every date-time object work at the fractional-second level? If so, maybe that's what needs fixing.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

4 9

Re: [boost] [serialization+date_time] Serialization Review: serialization of dates
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Abril 25, 2004 11:19 pm Asunto: Re: [boost] [serialization+date_time] Serialization Review: serialization of dates [...] > > #include "boost/archive/basic_archive.hpp" > > #include "boost/serialization/split_free.hpp" > > #include "boost/serialization/string.hpp" > > > > I think the two first are unnecessary (could you > > try this out? thx) > > Actually none of them are necessary. Ah the wonder of templates :-) > Wonderful they are, you're right :) So, I guess this is as good as it can get. Slightly OT: this issue of POI could be taken a little further to allow interoperability between (not necessarily template-based) libraries without the headache of having to include portions of them. This is what I have in mind: suppose a header-based library A provides support for or somehow uses a non-header (i.e. requires linking) library B, like this: // lib A #include <b.hpp> inline foo(){...} // does not depend on B inline bar(){...} // does not depend on B inline mess_with_B(){...} Now, if B is not linked in the project mess_with_B won't compile, so one has to move this function to a separate header that the user will/won't include depending of whether she wishes that functionality. Instead, one can do the following: // lib A #include <b.hpp> inline foo(){...} inline bar(){...} template<typename dummy> inline mess_with_B(dummy* =0){...} Voila, A works even if B is not linked in. If the user has linked B and wants to use mess_with_B, then she just has to call mess_with_B() as usual, template instantiation model will do the rest. Maybe I'm missing something, but I think this approach could be investigated a little further. One good example of use is for interoperability with Boost.Threads, for instance. Totally OT: I've posted a question regarding multi_index and composite keys a few posts ago. You being one of the reviewers, your opinion on that is greatly appreciated :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] [serialization+date_time] Serialization Review: serialization of dates
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Abril 25, 2004 9:25 pm Asunto: Re: [boost] [serialization+date_time] Serialization Review: serialization of dates > On Sun, 25 Apr 2004 20:34:34 +0200, JOAQUIN LOPEZ MU?Z wrote > > > Regarding the need to include "greg_serialize.hpp", I think > > a better approach, from the point of view of the user, is > > that serialization support is already embedded into > > "boost/date_time/gregorian/gregorian_types.hpp" and > > automatically provided if one of the archive headers > > > >...snip details... > > > > See what I mean? For this to work with minimum > > overhead, we'd need some forward headers for serialize, > > save, load, etc. to be included by > > "boost/date_time/gregorian/gregorian.hpp". > > Yes, I agree on the user perspecitive. I'm sorry I forgot to say > that in the > first few emails. I did say it here: > http://lists.boost.org/MailArchives/boost/msg63885.php > > > I'm not sure whether this forward headers are already > > provided by Robert's library. > > Why would I need 'forward headers' for this? > Well, since serialization support is entirely contained in function templates, you don't need any actual definition till POI (I might be wrong here, but I guess I'm not.) This can help reduce compilation time if you're not going to serialize dates at all. Matter of fact, seeing the includes in your example #include "boost/archive/basic_archive.hpp" #include "boost/serialization/split_free.hpp" #include "boost/serialization/string.hpp" I think the two first are unnecessary (could you try this out? thx) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[static_assert] Bad compiler message
by Vladimir Prus 25 Apr '04

25 Apr '04

Hello, I've just found out that the following program: #include <boost/static_assert.hpp> int main() { BOOST_STATIC_ASSERT(false); return 0; } compiled with gcc 3.3 produces: sa.cpp:6: error: invalid application of `sizeof' to an incomplete type which is not as nice as sa.cpp:6: `sizeof' applied to incomplete type `boost::STATIC_ASSERTION_FAILURE<false>' that gcc 2.95 generates and sa.cpp:6: `sizeof' applied to incomplete type ` boost::STATIC_ASSERTION_FAILURE<false>' That 3.2 generates. The behaviour of 3.4 is the same as for 3.3. So, there are some questions: 1. Should I bug gcc developers about this? 2. Anybody knows another way to force better diagnostic? 3. Is it possible to make regression tests for static_assert always include compiler messages, so that we know the diagnostic is OK? - Volodya

6 7

Re: [boost] [serialization+date_time] Serialization Review: serialization of dates
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Abril 25, 2004 0:37 am Asunto: [boost] [serialization+date_time] Serialization Review: serialization of dates > All - > > Since I'm the review manager I'm not doing a formal review of the > library, but > I thought I'd share some code and a few thoughts. If > serialization is > accepted users people will ask me and other library authors to provide > serialization support for some of the types in their libraries. So > to get a > feel for the difficulty of extending serialization for new types I > wrote the > serialization code for gregorian::date and some example code to > try it out. Regarding the need to include "greg_serialize.hpp", I think a better approach, from the point of view of the user, is that serialization support is already embedded into "boost/date_time/gregorian/gregorian_types.hpp" and automatically provided if one of the archive headers are included by the user program: // case 1 "boost/date_time/gregorian/gregorian.hpp" int main() { date d(2004,Apr,25); boost::archive::text_oarchive oa(ofs); // does not work, text_oarchive not defined. oa << d; } // case 2 "boost/date_time/gregorian/gregorian.hpp" #include <boost/archive/text_oarchive.hpp> int main() { date d(2004,Apr,25); boost::archive::text_oarchive oa(ofs); // OK, no need to include anything else fromd date-time oa << d; } See what I mean? For this to work with minimum overhead, we'd need some forward headers for serialize, save, load, etc. to be included by "boost/date_time/gregorian/gregorian.hpp". I'm not sure whether this forward headers are already provided by Robert's library. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re:Re: [boost] [serialization+date_time] Serialization Review:serialization of dates
by Robert Ramey 25 Apr '04

25 Apr '04

Jeff Garland wrote: >Well, I think it belongs in the library supplying the data type not in > serialization. Few reasons for this... ... good reasons listed 4) Many serialization implementations will turn out to be trivial. An example is Thorsten O? pointer container wrapper class which resulted in 6 lines of code. Furthermore these six lines were inline template member functions (two functions 3 lines each) which required no header inclusion at all. In cases such as this, the compiler/runtime cost is zero if the application doesn't use serialization. I believe that this will be a common case for many of the "utility" classes. FWIW - this gets my vote: > So for the particular case I posted I was planning on putting this code in > boost/date_time/gregorian/greg_serialize.hpp > Time could would go into > boost/date_time/posix_time/time_serialize.hpp Considering the above, you might want to think about tweaking date time. By making a default constructor (that initializes as "not a date"), you could implement serialization as template member functions along the lines of the above. In this way adding serialization would: a) no extra compile time overhead b) no extra run-time overhead c) no extra file inclusion d) no extra "conceptual" overhead. That is one would never have to even think about it - it would always be there just lurking waiting to be of service. It would just work when used. Robert Ramey

3 3

Re:Re:Re: [boost] [serialization+date_time] Serialization
by Robert Ramey 25 Apr '04

25 Apr '04

Jeff Garland wrote: > > a) no extra compile time overhead > > b) no extra run-time overhead > > c) no extra file inclusion > > d) no extra "conceptual" overhead. That is one would never have to even > > think about it - it would always be there just lurking waiting to be > > of service. It would just work when used. > > Are you saying there is actually extra runtime overhead with the way I've > implemented serialization? If so, that needs to be in the docs b/c I was > under the impression that external versus internal implementations would > be > the same... > I didn't mean to imply your method had any runtime overhead - I was just restating all the features. However, the other points are real advantages of just putting it in with the class definition. BTW the non - intrusive version could also be put in the normal class header. However if its too complicated it might end up requiring more file inclusion so it would have to be considered on a case by case basis. I personally don't have a strong position on this. As far as serialization is concerned the alternatives are all equivalent. The decision where to but the serialization templates can be decided on other factors. Robert Ramey

2 1

New dynamic_bitset
by Gennaro Prota 25 Apr '04

25 Apr '04

Hi everybody, as I have mentioned in some post here, a new version of dynamic_bitset is in the sandbox. I've finished everything 4/5 days ago (including new and more tests) and thought to move it to the main repository, as Jeremy asked too. But I've had an important familiar problem and I'm looking for a job and an apartment at the same time. With all likelihood I'll be at my old home, where is my pc, just for a couple of hours on Saturday and Sunday (except for this weekend, where Monday is holidays too). There could be other free mornings here and there but I can't guarantee. So I ask: should I move everything to the main repository or should I wait until I can devote more time to follow discussions and fix possible regressions? If the next release is far away then 5 or 6 hours a week should be adequate to review the regression logs and fix any problems that could arise. I'll check the list again tomorrow. Sorry for the inconvenience. PS: I had a (very) quick look at the thread about the FC++ review result. Just want to say that I think Brian is a great asset to the C++ community at large. His only mistake is that he isn't posting anymore to the groups, if not sporadically. Please, come back soon, Brian :) Genny.

6 23

Re: [boost] [multi_index] composite keys: request for advice
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Brian McNamara <lorgon(a)cc.gatech.edu> Fecha: Domingo, Abril 25, 2004 6:05 am Asunto: Re: [boost] [multi_index] composite keys: request for advice > On Sun, Apr 25, 2004 at 03:54:31AM +0200, JOAQUIN LOPEZ MU?Z wrote: > > > that if you call these two object "k" and "t" (key and tuple), > > > then you should have > > > k < t false > > > t < k false > > > t == k does not compile > > > That's just my quick hunch based on what I've quoted above; I > haven't> > considered what consequences it has for the library, > but that's my > > > intuitive notion of how tuples as "partial keys" ought to work. > > > > I guess I agree with you, but I wanted to bring this > > in to the list to gather some opinions. Following your > > approach, what should we do with > > > > k <= t > > t <= k > > > > The options are: > > > > a. they hold true > > b. they do not compile > > > > I don't have any strong argument in favor of any option. > > If there are other std:: or boost:: types which model the > StrictWeakOrdering concept (without having total orders), I would see > what they do and follow their lead. > > If not, I would make the "<=" operators not compile, since > k <= t > can always be rewritten by clients as > !(t < k) > and the narrower interface reduces the likelihood of someone > mistakenlygetting the impression that there's a total ordering > here (IMO). > I've scanned Boost and results are not conclusive. At least one class (shared_ptr) does define operator< and does not define <=, >= etc. so I'm not alone. I think I'll follow your advice and be conservative here (we'll always have time to extend this; the other way around is more problematic). So, the rules I'll stick with are: 1. if k and t have the same number of elements then k==t, k!=t, k<t, k>t, k<=t, k>=t, t==k, t!=k, t<k, t>k, t<=k, t>=k, are all defined and follow the lexicographical convention. 2. If k and t have different number of elements, then k<t,k>t, t<k,t>k are the only operators defined and follow the "clipping rule" (compare lexicographically taking the minimum of the lengths of the operands.) 3. std::less and std::greater are specialized to accept comparison between composite_key results and tuples, according to the previous definition. No other std comparison object is specialized. If nobody finds a problem with this, these are the rules that'll go into the implementation of composite_key. Thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[serialization+date_time] Serialization Review: serialization of dates
by Jeff Garland 25 Apr '04

25 Apr '04

All - Since I'm the review manager I'm not doing a formal review of the library, but I thought I'd share some code and a few thoughts. If serialization is accepted users people will ask me and other library authors to provide serialization support for some of the types in their libraries. So to get a feel for the difficulty of extending serialization for new types I wrote the serialization code for gregorian::date and some example code to try it out. Of course this sort of extension is a critical aspect of the library design since everyone with a unique type will need to write serialization code. Overall I felt the docs did a pretty good job of explaining what need to be done and the code turns out to be reasonably trivial. Note that the code is more verbose than required as I did not use all of Robert's macros. Also, gregorian::date doesn't currently have a default constructor and hence it is a more challenging case (as I recall the first submission of the serialization lib required default constructors). When programming with dates and times putting them into collections is quite common. Fortunately, one of the most impressive aspects of the current serialization library is the ability to handle stl collections. So I was glad to find (as I expected) that by enabling the serialization of gregorian::date serialization of collections of date's comes along for free. I've attached the code and the serialized file for your reading enjoyment :-) Jeff

2 4

Boost Unicode support ideas
by Jeremy Maitin-Shepard 25 Apr '04

25 Apr '04

It seems that Unicode support in Boost (which could lead to Unicode support in the C++ language and standard library) would be quite desirable. The IBM International Components for Unicode (ICU) library (http://oss.software.ibm.com/icu/) is an existing C++ library with what appears to be a Boost-compatible license, which provides all or most of the Unicode support that would be desired in Boost or the C++ standard library, in addition to Unicode-equivalents of libraries already either in the standard library or in Boost, including number/currency formatting, date formatting, message formatting, and a regular expression library. Unfortunately, it does not use C++ exceptions to signal exceptional conditions (but rather it uses an error code return mechanism), it does not follow Boost naming conventions, and although there are some C++-specific facilities, most of the C++ API is the same as the C API, thus resulting in a less-than-optimal C++ interface. Nonetheless, I think Boostifying the ICU library would be quite feasible, whereas attempting to reimplement all of the desired functionality that the ICU library provides would be extremely time consuming, since the collating and other services in the ICU library already support a large number of locales, and the character-set conversion facilities support a large number of character sets. The representation of locales does present an issue that needs to be considered. The existing C++ standard locale facets are not very suitable for a variety of reasons: - The standard facets (and the locale class itself, in that it is a functor for comparing basic_strings) are tied to facilities such as std::basic_string and std::ios_base which are not suitable for Unicode support. - The interface of std::collate<Ch> is not at all suitable for providing all of the functionality desired for Unicode string collation. A suitable Unicode collation facility should at least allow for user-selection of the strength level used (refer to http://www.unicode.org/unicode/reports/tr10/) and would ideally also support customizations as extensive as the ICU library does (refer to http://oss.software.ibm.com/icu/userguide/Collate_ServiceArchitecture.html and http://oss.software.ibm.com/icu/userguide/Collate_Customization.html) - Facilities such as Unicode string collation are heavily data-driven, and it would be inefficient to load the data for facilities that are not used. This could be avoided by using some sort of lazy loading mechanism. It would still be possible to use the standard locale object as a container of an entirely new set of facets, which could be loaded from the data sources based on the name of the locale, and ``injected'' into an existing locale object, by calling some function. It is not clear, however, what advantage this would serve over simply using a thin-wrapper over a locale name to represent a ``locale,'' as is done in the ICU library. -- Jeremy Maitin-Shepard

9 36

Re: [boost] Re: [multi_index] composite keys: request for advice
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

Hi Pavel ----- Mensaje original ----- De: Pavel Vozenilek <pavel_vozenilek(a)hotmail.com> Fecha: Domingo, Abril 25, 2004 10:11 am Asunto: [boost] Re: [multi_index] composite keys: request for advice > > "Joaquin M Lopez Munoz" <joaquin(a)tid.es> wrote: > > > Composite keys can be specified by a new construct > > called composite_key in the following manner: > > > OT question 1: will it be possible to specify calculated > index as part of composite index? I take you mean "calculated key" and "composite key". Yes, it is possible, composite_key does accept any key extractor, it needs not be multi_index::member. > > > OT question 2 (I could had asked already): would it be somehow > possible for calculated index to use user supplied functor > and then sorting sequenced index according this index? > > This would create 'dynamic index', modifiable during runtime. I'm not quite getting you; the following shows how to specifiy the comparison predicate at run time, I don't know if this is what you are asking. typedef multi_index_container< employee, indexed_by< ordered_unique< identity<employee>, boost::function<bool (const employee&)> > > > employee_set; ... bool foo(const employee&); ... employee_set::ctor_args_list cal; cal.get<0>.get<1>=foo; // 2nd argument of the first index employee_set es(cal); Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] regex lib: bug with sets and back ref
by Benzinger, Ralph 25 Apr '04

25 Apr '04

> > The following behavior seems to be a bug: > > > > * regex '([a-c]+)\1' finds 'abcabc' at offset 0 in text 'abcabc' > > That looks correct. > > > * regex '([abc]+)\1' finds 'bcbc' at offset 1 in text 'abcbc' > > That looks correct. > > > * regex '([a-c]+)\1' finds nothing in text 'abcbc' ??? > > It should 'bcbc' if you're calling regex_search and nothing if you're > calling regex_match. Sorry if I wasn't clear enough. All tests use regex_grep. In the last example, however, regex_grep _doesn't_ find "bcbc", even though it should. I would assume it's an issue with regex_compile, as the only difference between (2) and (3) is the way the set is defined. Ralph

2 1

alternative stringstream class
by Samuel Krempp 25 Apr '04

25 Apr '04

I meant to mention this for a while : I've written an alternative stringstream class implementation as part of boost::format, with 2 motivations : a. make boost::format compile on platforms that don't provide std::stringstream (gcc-2.95) b. allow more efficient use of stringstream in the context of boost::format (by adding copy-less access to the stringstream's buffer, and allowing reuse of the buffer) Now it's been there working hand in hand with boost::format for a while, compiling ok on mostly all platforms, but I dont know what to do about this class, if I should leave it there undocumented and unmentionned, or document it, or make it a mini-library, or a detail or whatever. IMO this class might interest some users, as it is more flexible than std::stringstream (allowing more efficient uses in some situations), while it includes the original stringstream's interface, keeps its overall design, and ease-of-use. It lies in boost/format/alt_stringstream.hpp (and _impl.hpp) it depends on the rest of boost::format only due to workaround settings (mainly required by gcc-2.95) alt_stringstream provides the features of std::stringstream, plus : void clear_buffer(); // calls seekpos // 0-copy access : Ch * begin() const std::streamsize size() const std::streamsize cur_size() const // copy buffer to string : string_type cur_str() const // [pbase, pptr[ This cur_str() function differ from the std::stringstream str() function, which returns a copy of [pbase, epptr[, thus unaffected by calls to seekpos, actually preventing buffer-reuse. (alt_stringstream defines functions cur_str() and str(), so it can have the same behaviour as std::stringstream if used with str() ) So, what should I do with this class ? -- Samuel

1 0

Re: [boost] [multi_index] composite keys: request for advice
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- [...] > > composite_key</* as before*> ck; > > ck(record(1,2,3))<=make_tuple(1,2); // yields true > > make_tuple(1,2)<=ck(record(1,2,3)); // yields true > > > > So far, this is all IMHO perfectly consistent, > > but the following design decision is not > > obvious to me: given the previous, what should > > be the result of > > > > ck(record(1,2,3))==make_tuple(1,2); // true or false? > > > > As these two objects are neither greater than the > > other, at least they are *equivalent*, but maybe > > allowing operator== to return true is too much. > > It sounds to me like you have a partial ordering or a strict weak > ordering, but not a total ordering. > http://www.sgi.com/tech/stl/StrictWeakOrdering.html > That is, these two objects: > ck(record(1,2,3)) make_tuple(1,2) > are in the same equivalence class, but they are not equal. My > hunch is > that if you call these two object "k" and "t" (key and tuple), > then you > should have > k < t false > t < k false > t == k does not compile > That's just my quick hunch based on what I've quoted above; I haven't > considered what consequences it has for the library, but that's my > intuitive notion of how tuples as "partial keys" ought to work. > I guess I agree with you, but I wanted to bring this in to the list to gather some opinions. Following your approach, what should we do with k <= t t <= k The options are: a. they hold true b. they do not compile I don't have any strong argument in favor of any option. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [multi_index] composite keys: request for advice
by Dave Gomboc 25 Apr '04

25 Apr '04

[reformatted] > // yields true > composite_key</* as before*> ck; ck(record(1,2,3))<=make_tuple(1,2); > > // yields true > make_tuple(1,2)<=ck(record(1,2,3)); > > So far, this is all IMHO perfectly consistent, > but the following design decision is not > obvious to me: given the previous, what should > be the result of > > ck(record(1,2,3))==make_tuple(1,2); // true or false? > > As these two objects are neither greater than the > other, at least they are *equivalent*, but maybe > allowing operator== to return true is too much. operator== should return false here. The operands are equivalent, but not equal. Dave

1 0

Re: [boost] [multi_index] composite keys: request for advice
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Jeremy Maitin-Shepard <jbms(a)attbi.com> Fecha: Sábado, Abril 24, 2004 11:13 pm Asunto: Re: [boost] [multi_index] composite keys: request for advice > Joaquin M Lopez Munoz <joaquin(a)tid.es> writes: > > > [snip: composite key system] > > > composite_key</* as before*> ck; > > ck(record(1,2,3))<=make_tuple(1,2); // yields true > > This is not lexicographical order. According to lexicographical > ordering: > > (1, 2) < (1, 2, 3) > I did not claim that composite_key results and tuples are ordered lexicographically. What I said is that, given that a composite_key induces a lexicographical order on the elements of the multi_index_container it is used in, this can be taken advantage of to perform searches where only the first keys are given. For this to work, (1, 2) must be equivalent to (1,2,3) (meaning that !((1, 2)<(1,2,3)) and !((1,2,3)<(1,2)). I don't think there's any flaw with this approach, my doubt is about whether the fact that ck(record(1,2,3))<=make_tuple(1,2) and make_tuple(1,2)<=ck(record(1,2,3)) is reason enough to also make ck(record(1,2,3))==make_tuple(1,2) hold true. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

max elapsed time of boost::timer
by Toon Knapen 24 Apr '04

24 Apr '04

The documentation of boost::timer states that 'The maximum measurable elapsed time may be as low as 596.5 hours (or even less) ...'. Well on many 32bit platforms this would probably even be about 71 hours. Apparantly POSIX requires CLOCKS_PER_SEC to be 10e6, so if clock_t is 32 bit, the maximum of ( clock() / CLOCKS_PER_SEC ) is 4294 seconds. Because accuracy for clock() is generally about 1 sec, using clock() is not very usefull for doing timings of short (in time) events. Even more, for short events, the boost::timer might also influence the timing too much. So clock() is generally interesting for longer timings (from 10 sec onwards). But for long events the clock_t wraps around too fast (as mentioned above). And if you're unlucky that you _start_time = clock() is or a bit smaller than std::numeric_limits< clock_t >::max() (thus near the wrap-around point), directly afterwards the expression 'clock() - start' will result in a negative value. So I would like to suggest for boost::timer to use std::time_t and use std::time(NULL) instead of clock() and use std::difftime to calculate the elapsed time. toon

4 4

A question to preprocessor gurus
by Arkadiy Vertleyb 24 Apr '04

24 Apr '04

Hi all, The MS preprocessor has the __COUNTER__ extension that expands to the next integer every time when used. Can something like this be achieved in a portable manner, maybe with the help of Boost.Preprocessor library? Thanks, Arkadiy

4 7

[circular buffer] Status of Circular Buffer lib
by Jeff Garland 24 Apr '04

24 Apr '04

I'm looking at using circular buffer on a project. With only minor adaptation it does exactly what I need. I know it has been accepted, but isn't yet in CVS. So I have a few questions: 1) Is 3.6 from the files section the latest version? 2) Any showstopper bugs I should be aware of? 3) I'm assuming it works with VC7.1 and gcc 3.x? 4) Looks like my interface needs will be pretty basic: push_back, erase, clear. I assuming review changes won't impact these, correct? 5) Any reason it is NOT ready for prime time? Thx for the great submission! Jeff

2 2

[Boost-bugs] [ boost-Bugs-940941 ] failure in boost jam unit tests on cygwin
by SourceForge.net 23 Apr '04

23 Apr '04

Bugs item #940941, was opened at 2004-04-23 12: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=940941&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kannan Goundan (cakoose) Assigned to: Nobody/Anonymous (nobody) Summary: failure in boost jam unit tests on cygwin Initial Comment: Boost Jam Version 3.1.9 The unit tests seem to assume that the "/cygdrive" mount exists. I had changed mine to "/drive" and when I tried to build, I got an assertion failure: assertion "self->size < self->capacity" failed: file "strings.c", line 16 self->size == -165761813 self->capacity == 64 backtrace: assert_invariants (strings.c:15) string_free (strings.c:44) var_expand (expand.c:410) var_expand_unit_test (expand.c:696) run_unit_tets (jam.c:197) main (jam.c:299) Even if it's not worth it to accomodate non-standard Cygwin setups such as mine, I wouldn't expect the assertion failure to occur in strings.c. I think this can be reproduced by changing the "/cygdrive/c/foo/bar" string constants to invalid paths (in expand.c on lines 682 and 702) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=940941&group_i… ------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

gcc34: undefined reference to `__gcov_init'
by Neal D. Becker 23 Apr '04

23 Apr '04

Any clues? I am trying to rebuild an app that worked with boost_1_31_0 and gcc3.3, now with gcc3.4. I completely rebuilt boost_1_31_0 libs using: PYTHON_ROOT=/usr PYTHON_VERSION=2.3 bjam -sTOOLS=gcc -sGXX=g++34 -sGCC=gcc34 PYTHON_ROOT=/usr PYTHON_VERSION=2.3 bjam -sTOOLS=gcc -sGXX=g++34 -sGCC=gcc34 stage Then I clean out all objects from my build, and rebuilt with g++34, but I got this error: g++34 -Wl,-rpath,/usr/local/src/boost_1_31_0.gcc34/stage/lib,-rpath,./ -o Test2 Test2.o -L/usr/local/src/boost_1_31_0.gcc34/stage/lib -L. -lshannon -lboost_program_options-gcc -lrfftw -lfftw Test2.o(.text+0x7d6e): In function `global constructors keyed to _Z21DesignImpulseResponseRKN10__gnu_norm6vectorISt7complexIdESaIS2_EEE_GCOV': /home/nbecker/shannon/TestAloha/Test2.cc:360: undefined reference to `__gcov_init'

2 1

[serialization] and shared_ptr
by Jeff Flinn 23 Apr '04

23 Apr '04

The following code produces and access violation when loading the NULL shared_ptr. Is this an issue of not having registered the type pointed to? What would I need to do to appropriately handle this situation? #include <boost/serialization/shared_ptr.hpp> #include <boost/serialization/string.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> #include <fstream> typedef std::string tName; class PointedToClass { tName mName; friend class boost::serialization::access; template< class Archive > void serialize( Archive &ar, unsigned int version ) { ar & boost::serialization::make_nvp( "Name", mName ); } public: ~PointedToClass(){} PointedToClass():mName("def"){} }; typedef boost::shared_ptr<PointedToClass> tPtr; class SomeClass { tName mName; tPtr mPtr; friend class boost::serialization::access; template< class Archive > void serialize( Archive &ar, unsigned int version ) { ar & boost::serialization::make_nvp( "Name", mName ); ar & boost::serialization::make_nvp( "Ptr", mPtr ); } public: SomeClass():mName("abc"),mPtr(){} }; int main( int argc, char* argv[] ) { SomeClass lSomeClass; { std::ofstream lOut( "SomeClass.archive", std::ios_base::out | std::ios_base::trunc ); if( lOut.good() ) { boost::archive::xml_oarchive oa( lOut ); oa & boost::serialization::make_nvp( "SomeClass", lSomeClass ); } } { std::ifstream lIn( "SomeClass.archive" ); if( lIn.good() ) { boost::archive::xml_iarchive ia( lIn ); ia & boost::serialization::make_nvp( "SomeClass", lSomeClass ); } } return 0; }

1 0

numeric_cast
by Dill, John 23 Apr '04

23 Apr '04

I am wondering about the use-case of numeric_cast in this sample. unsigned char uchar_max = std::numeric_limits<unsigned char>::max(); char schar_value = 0; try { schar_value = boost::numeric_cast<char>( uchar_max ); } catch ( boost::bad_numeric_cast ) { std::cout << "Overflow occurred..." << std::endl; } When I execute this sample, I don't get the exception. What's the background on this behavior? I'm using gcc 3.3.1. John

5 6

Assignment Library Review Result
by Tom Brinkman 23 Apr '04

23 Apr '04

Assignment Library Review Result Thanks to Thorsten Otteson for creating the Assignment Library. Review Comments: * Participation by boost members in the review was minimal, but the comments were generally constructive. * Considering that library is relatively small and the scope is fairly limited, less than normal review participation by boost members is to be expected. * The basic functionality of the library relieves the c++ developer from typing redundent c++ code for inserting/appending hard-coded data into containers. * Some issues about how the library is organized remain, but are easily resolved by seperating the headers and removing global dependencies. * There are many issues regarding the advanced functionality of this library that were not resolved during the review period. An additional review period should be provided to discuss advanced/optimized techniques for container population. * The name of the library should be changed. The name 'Assignment' does not fully describe the functionality of this library and could be improved. Review Conclusion: This library should be accpeted into boost under the following conditions: 1) Add a header file for each wrapped stl container. One header file containing all of the commonly used headers should also be provided. 2) Remove the global += operator. 3) Rename routines to reflect whether they are initializing, appending or inserting data. 4) Move all routines that extend boost libraries to the examples folder. 5) Documentation should broken up into a basic section and advanced section. 6) Documentation should add a short description about the advantages and disadvantage of each method provided by the library. 7) The library needs to add a boost test file. 8) Routines provided by the Assignment library having boost dependencies will require additional discussion during the post review period. 9) Basic library useage should not require any boost libraries outside of the boost::asignment library headers itself. 10) The techniques provided in the basic functionality of the library may not be optimal. Consideration of techniques for advanced generalized container initialization should be made. A post review period will be required to address advanced library useage. Thanks again and congratulations to Thorsten Otteson for creating a useful set of routines for the boost community. Review Manager, Tom Brinkman __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25� http://photos.yahoo.com/ph/print_splash

1 0

lightweight replacement for boost::format
by John Torjo 23 Apr '04

23 Apr '04

Dear boosters, When needing to dump a lot of data into a string, we usually use boost::format. However, there have been lots of times when I needed a simple and lightweight replacement. I've used one for quite a while (see attachement). Basic usage: str_stream() << "str" << s << "int " << i; // automatic conversion to string. Example: std::string msg = str_stream() << "There have been " << users << " users logged on so far"; Also, attached an example. Any interest in something like this in boost? Best, John <cid:part1.07010200.01010400@torjo.com> ////////////////////////////////////////////////////////////////////// // example.cpp #include "str_stream.hpp" #include <iomanip> std::basic_ostream< wchar_t> & width_4( std::basic_ostream< wchar_t> & out) { out.width( 4); return out; } void print_c_like_str( const char * str) { std::cout << str << std::endl; } void test() { using namespace boost; // for wide strings. std::wstring str = wstr_stream() << std::oct << 8; str = wstr_stream() << std::setfill( L'0') << width_4 << 35 << std::endl; std::wcout << str; // for strings int users = 45; std::string s = str_stream() << "There have been " << users << " users logged on so far"; std::cout << s << std::endl; int words = 78; s = str_stream( "We found ") << words << " words."; std::cout << s << std::endl; // convert it to C-like string print_c_like_str( (str_stream() << "testing " << 1 << 2 << 3).c_str() ); std::cin.get(); } int main() { test(); } ////////////////////////////////////////////////////////////////////// // str_stream.h #ifndef BOOST_STR_STREAM__HPP_JT_2003MAR04 #define BOOST_STR_STREAM__HPP_JT_2003MAR04 // Copyright John Torjo 2003-2004 // Use, modification, and distribution is 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) #include <string> #include <sstream> #include <iosfwd> namespace boost { namespace stream_detail { template< class char_type, class char_traits> struct as_c_str_res { typedef std::basic_string<char_type,char_traits> str_type; as_c_str_res( const str_type & str) { m_str = str; } operator const char_type*() const { return m_str.c_str(); } private: str_type m_str; }; } // basic_str_stream - allow stream usage, and then conversion to string template< class char_type, class char_traits = std::char_traits<char_type> > class basic_str_stream { typedef std::basic_stringstream< char_type, char_traits> stringstream_type; typedef std::basic_string< char_type, char_traits> string_type; typedef stream_detail::as_c_str_res<char_type,char_traits> c_like_str_type; public: // default construction basic_str_stream() {} // allow to_string like usage template< class type> basic_str_stream( const type & value) { *this << value; } stringstream_type & underlying_stream() const { return m_out; } // implicit conversion operator string_type() const { return m_out.str(); } // explicit conversion to string string_type str() const { return m_out.str(); } // explicit conversion to C-like string c_like_str_type c_str() const { return c_like_str_type( m_out.str() ); } private: mutable stringstream_type m_out; #ifndef NDEBUG public: void recalculate_string() const { m_string = m_out.str(); } private: mutable string_type m_string; #endif }; // class basic_str_stream typedef basic_str_stream< char> str_stream; typedef basic_str_stream< wchar_t> wstr_stream; template< class char_type, class char_traits, class type> inline const basic_str_stream< char_type, char_traits> & operator<< ( const basic_str_stream< char_type, char_traits> & out, const type & value) { out.underlying_stream() << value; #ifndef NDEBUG out.recalculate_string(); #endif return out; } // allow function IO manipulators template< class char_type, class char_traits> inline const basic_str_stream< char_type, char_traits> & operator<< ( const basic_str_stream< char_type, char_traits> & out, std::ios_base & (*func)( std::ios_base&) ) { func( out.underlying_stream()); return out; } template< class char_type, class char_traits> inline const basic_str_stream< char_type, char_traits> & operator<< ( const basic_str_stream< char_type, char_traits> & out, std::basic_ios< char_type, char_traits> & (*func)( std::basic_ios< char_type, char_traits> &) ) { func( out.underlying_stream()); return out; } template< class char_type, class char_traits> inline const basic_str_stream< char_type, char_traits> & operator<< ( const basic_str_stream< char_type, char_traits> & out, std::basic_ostream< char_type, char_traits> & (*func)( std::basic_ostream< char_type, char_traits> &) ) { func( out.underlying_stream()); return out; } } // namespace boost #endif // End of file

5 10