- Boost - lists.boost.org

Re: [boost] [serialization] request: low-level info about order of serialization
by Robert Ramey 08 Sep '04

08 Sep '04

Joaqu?n M? L?pez Mu?oz wrote: >Ummm, I guess I'm not explaining myself, let me try with an example: >consider a multi_index_container like this: >typedef multi_index_container< > int, > indexed_by< > sequenced<>, > sequenced<> > > >> bilist; >Then, when serializing such a bilist, the order maintained by indices #0 and >#1 must be recorded separately. Roughly speaking, this involves: >1. serializing the elements in the order induced by index #0. >2. traversing index #1 and serializing a record of rearrangements with >respect to index #0. >Step 2 can be accomplished in a simple manner by serializing pointers to >the (previously serialized) elements, but in the order induced by index #1. >As Boost.Serialization keeps track of previously stored objects, this will >work OK. To further exemplify this, consider a particular bilist like this: >index #0: [begin(),end) = 1 4 3 5 2 6 >index #1: [begin(),end) = 1 3 5 6 2 4 >then all the info we need to reconstruct the container can be saved as: >1 4 3 5 2 6 >&1 &3 &5 &6 &2 &4 >where & means we save a pointer to a previously serialized element. >I hope everything's clear up to this point. This looks clear to me. It seems well within the normal application of the serialization library and would seem to work as expected. Question: have you built and tested this? I think this would be a useful starting point for what follows. I will refer to this as the plain vanilla implementation. (PVI) Assuming that the above works as expected, I understand that your concern is that the sequences of pointers could be reduced to a smaller sequence. The question is what would be the best way to exploit this possibility. One way would be just keep a list when serializing index #0 and referring to it when serializing index #1. This would give you everything you need without changing anything about the serialization library. Of course, this does replicate some of the information within the serialization library. I would be extremely reluctant to make the library more elaborate to accommodate what I see as a very special case. If it were me, I would think the PVI was plenty good enough as the space for a replicated pointer is very small relative to the data as whole. The PVI also has a pleasing symmetry in that no index is "privileged" by being first and will work automatically for an arbitrary number of indexes. But that's my opinion and its your library. We have one alternative - keeping your own list of saved/loaded object addresses which can be used to streamline the process. There might be another way that would give you what you want. Rather than thinking: a) serialize data b) serialize index 0 c) serialize index 1 d)... e).serialize index n which is the way that the serialization library encourages one to think. One might consider: a) serialize data b) serialize all indexes in parallel: i) read indexes in order ii) "merge indexes" into a virtual list iii) for each unique index entry 1) serialize the list of indexes to which it applies 2) serialize the index entry itself I think this would be "sort of" equivalent to what you want to do in that replicated pointers would not be stored. This would even eliminate the need to track the addresses of the serialization of base data allowing one so designate all instances of indexed_set as not using tracking. So even the address-object id lookup inside the serialization library would be skipped. This would be maximally efficient. Personally, I'm skeptical that it would be worth the effort - but of course its up to you. One thing I would like to see is that the "Plain Vanilla Implementation" is working before something like the above is considered. Robert Ramey

1 0

Boost.Threads MinGW compiler warning patches
by Daniel Schlyder 08 Sep '04

08 Sep '04

Hello, Attached are patches to fix a few warnings I get when compiling Boost.Threads using MinGW (GCC 3.4.1): native_error-dllimport-warning.diff fixes (maybe not in a good way, but at least now you know the warning exists :)): boost/thread/exceptions.hpp:37: warning: inline function 'int boost::thread_exception::native_error() const' is declared as dllimport: attribute ignored. tss-no-newline-warning.diff fixes: boost/thread/detail/tss_hooks.hpp:78:39: warning: no newline at end of file libs\thread\build\..\src\tss.cpp:206:37: warning: no newline at end of file -- Daniel Schlyder http://bitblaze.com/

2 1

Review schedule
by Miro Jurisic 08 Sep '04

08 Sep '04

Could we keep the review schedule more up-to-date? I went there expecting to find a handy like to the library currently under review, rather than grovelling through the mail archive, but alas, it's 10 months out of date. Thanks, meeroh -- If this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist>

7 11

review for range scheduled?
by Neal D. Becker 08 Sep '04

08 Sep '04

I didn't see range scheduled for review? I hope this is planned. I vote +10.

2 1

date_time warnings on VC 7.1
by Stefan Slapeta 08 Sep '04

08 Sep '04

A single #include <boost/date_time/posix_time/posix_time.hpp> produces the following warnings on VC 7.1. Can this be fixed? Cheers, Stefan C:\views_cvs\boost\boost\date_time\time_system_counted.hpp(57) : warning C4244: 'initializing' : conversion from 'boost::date_time::counted_time_rep<config>::int_type' to 'boost::date_time::gregorian_calendar_base<ymd_type_,date_int_type_>::date_int_type', possible loss of data with [ config=boost::posix_time::millisec_posix_time_system_config ] and [ ymd_type_=boost::gregorian::greg_year_month_day, date_int_type_=boost::date_time::int_adapter<unsigned long>::int_type ] C:\views_cvs\boost\boost\date_time\time_system_counted.hpp(52) : while compiling class-template member function 'boost::date_time::counted_time_rep<config>::date_type boost::date_time::counted_time_rep<config>::date(void) const' with [ config=boost::posix_time::millisec_posix_time_system_config ] C:\views_cvs\boost\boost\date_time\time_system_counted.hpp(111) : see reference to class template instantiation 'boost::date_time::counted_time_rep<config>' being compiled with [ config=boost::posix_time::millisec_posix_time_system_config ] C:\views_cvs\boost\boost\date_time\time.hpp(52) : see reference to class template instantiation 'boost::date_time::counted_time_system<time_rep>' being compiled with [ time_rep=boost::posix_time::int64_time_rep ] C:\views_cvs\boost\boost\date_time\posix_time\ptime.hpp(32) : see reference to class template instantiation 'boost::date_time::base_time<T,time_system>' being compiled with [ T=boost::posix_time::ptime, time_system=boost::posix_time::posix_time_system ]

2 1

Container optimized for "insert once"
by Stefan Slapeta 08 Sep '04

08 Sep '04

Hi all, I'm looking for an associative container which is optimized for one-time insertion and avoids much of the overhead of std::map therefore. IIRC Andrei once published something like this: a vector of pairs that was sorted once and accessed by binary search. Is there something similar in boost? Stefan

6 7

Challenge: Implement a state machine compiler as a Cpp macro using Order
by Vesa Karvonen 08 Sep '04

08 Sep '04

Hi, During the summer, I have been designing and implementing a metalanguage for C preprocessor metaprogramming named Order. The Order language is a *complete* high-level functional programming language with features such as - lexical scoping, - first-class functions, - anonymous functions, - partial application of functions (currying), - intuitive call-by-value semantics, and - tail-recursion optimization. The Order prelude supports, among other things, - arithmetic on arbitrary precision natural numbers and small literals {0,...,100}, - sequences (with many higher-order functions), - tuples, and - so called token strings/sequences. The Order interpreter, which is implemented using the C preprocessor macro mechanism, can be used to generate arbitrary sequences of preprocessing tokens (read: code). The intepreter also provides a debug mode that checks for many kinds of programming errors (syntax-errors, run-time type errors and user assertions). The Order language has been designed to transform the feel of C preprocessor metaprogramming from "learning lots of tricky, low-level Cpp specific idioms" to "thinking in an intuitive high-level language". Here is a short example of Order code that generates the complete lyrics to the song "99 Bottles of Beer on the Wall": #define GEN_phrase(N_bottles, N_minus_1_bottles) \ N_bottles of beer on the wall, \ N_bottles of beer, take one down, pass it around, \ N_minus_1_bottles of beer on the wall. #define ORDER_PP_DEF_8bottles \ ORDER_PP_FN(8fn(8N, \ 8cond((8greater(8N, 1), \ 8separate(8N, 8quote(bottles))) \ (8equal(8N, 1), \ 8quote(1 bottle)) \ (8else, \ 8quote(no more bottles))))) ORDER_PP(8for_each_in_range (8fn(8N, 8emit(8quote(GEN_phrase), 8tuple(8bottles(8N), 8bottles(8dec(8N))))), 100, 1)) (The above is an extract from a completely documented example.) There are two known caveats. First of all, the Order interpreter requires standard C variadic macros and placemarkers, which aren't standard C++, yet. The second caveat is that the Order interpreter currently requires a standards conforming preprocessor. The interpreter has been developed on the GNU CPP (3.x). Theoretically, the interpreter should be quite portable to less conforming preprocessors, because the interpreter is a "closed system of macros", but I personally don't have the preprocessors nor the time, though I would be happy to assist in such porting work by providing information on the interpreter. I'm currently working on the Order programming manual. I have already written several completely documented examples for the programming manual, which should be enough to get one started in using the Order interpreter, but one example I'd like to have would be a state machine compiler (SMC). Instead of implementing and documenting a SMC myself, I'd like to challenge *you* to write such a SMC example to be included in the forthcoming manual. Knowing that the documentation is still unfinished, I will be happy to assist people writing such a compiler (or some other kind of code generator) through e-mail (I might setup a mailing list). This might also help me to identify specific issues (e.g. sources of confusion, important design heuristics) that need to be addressed in the forthcoming programming manual. If you are interested in seeing the future of C preprocessor metaprogramming by trying out the Order intepreter and implement a state machine compiler (or some other program generator), please contact me at vesa_karvonen(a)hotmail.com. Note that you won't need previous Boost.Preprocessr library experience. Learning to use the Order interpreter should be an order of magnitude easier than learning to use the Boost.Preprecessor library. After I've completed the Order programming manual, I will release the Order interpreter (independently) and submit it to Boost if there is enough interest. Regards, Vesa Karvonen _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

[string_algo] split suggestion
by Vladimir Prus 08 Sep '04

08 Sep '04

Hello, suppose I have a string "module.foo1.port" and want to get the second dot-separated element. I think I can use the 'split' algorithm, but it does not look very convenient, I need to declare container, then call split and then obtain the result. In Qt, there's QString::section method, which allows to do this in one line. Here's example from the docs: QString csv( "forename,middlename,surname,phone" ); QString s = csv.section( ',', 2, 2 ); // s == "surname" And the complete docs are at: http://doc.trolltech.com/3.3/qstring.html#section Maybe, something like this can be added? - Volodya

2 3

RE: [boost] Re: RFI: RMI in C++
by Schalk_Cronje＠McAfee.com 08 Sep '04

08 Sep '04

In a related vein, I have been working on a generic functionality to launch asynchronous functions be it in another thread, another process or even out-of-box. The key is the definition of a set of asynchronous function traits allowing a number of free functions such as run_task() wait_task() and task_result() to be presented. One might for instance have something like to run a task on a different thread // Assuming boost::threader is defined and != boost:thread // The following line will launch a function on a separate thread using boost:thread. task_id<boost::threader> id= run_task( boost::threader(), boost::bind( my_dns_request, "www.boost.org" ) ); // do some work here { } // and some time later wait for request to finish wait_task( id ); By specialising the asynchronous function traits it can allow for requests to performed on another host via SOAP or in a RMI-lie fashion for instance. Would anyone be interested in something like this?

1 0

Re: [boost] [serialization] request: low-level info about order of serialization
by Robert Ramey 08 Sep '04

08 Sep '04

>I'm slowly designing the addition of serialization support to >Boost.MultiIndex, and come up with a need that, AFAIK, the >current serialization library does not cover: >The serialization of a multi_index_container should ensure that >the order in which elements appear is preserved for all indices >of the container. Appear? >This implies serializing the elements and then >recording the appropriate rearrangements in each index. I'm >writing the code for serializing these rearrangements in >an efficient manner as some sort of "diff" sequences, using >an algorithm called "longest increasing subsequence" (LIS). >The algorithm would greatly benefit for some low-level API >by the serialization lib that, given an object reference, would >return the order in which that object was serialized. I guess this >information is already available internally, as the lib must keep >track of previously saved objects. >If this requirement is deemed too exotic to provide to the >general user, well, I can write something myself without aid from >the lib, but I thought I should ask at least :) It seems too exotic to me. The focus of the serialization library is to re-create exactly that which was there before. So far, that has already been possible with the API provided. Some containers (e.g. slist) required a little bit of special handling to preserve sequence but this did not require any change in the basic API. All of this special handling is part of the implementation of the container in question. I'm really not sure what your doing, so without knowing more its hard for me to comment. Robert Ramey

2 1