- Boost - lists.boost.org

[interprocess] promoting boost::interprocess::detail::get_current_process_id
by JOAQUIN M. LOPEZ MUÑOZ 14 Aug '08

14 Aug '08

Hello, boost::interprocess::detail::get_current_process_id is a very nice utility to have. Would it be a good idea to promote it to the public interface of Boost.Interprocess? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] Can multi-index do this?
by JOAQUIN M. LOPEZ MUÑOZ 14 Aug '08

14 Aug '08

Hi Daryle, ________________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de Daryle Walker [darylew(a)hotmail.com] Enviado el: jueves, 14 de agosto de 2008 8:08 Para: boost(a)lists.boost.org Asunto: [boost] Can multi-index do this? > > Is it possible for Boost.Multi-index, or anything else in Boost, to > make a container that is generally random-access (like vector or > deque) but efficiently allows removals anywhere (like list)? As Sebastian has already pointed out, it does not seem possible to have O(1) lookup and O(1) insertion/removal simultaneously. That said, Boost.MultiIndex has so-called random-access indices: http://www.boost.org/libs/multi_index/doc/tutorial/indices.html#rnd_indices which have O(1) lookup and very fast removal: although erasing an element is O(n), it does not actually incur any element shifting, as it is only an internal vector of pointers that gets adjusted. This can be much faster than std::vector removal when the elements are of moderate size (though, still, it is not O(1)). A drawback of random indices in comparison with std::vector is that elements of multi_index_containers are immutable. Incidentally, I happen to have recently implemented a *stable* vector, a container that mimics the interface of std::vector with the differences that element contiguity is not observed and, in exchange, the container is stable, i.e. iterators and references to the elements remain valid regarldess of the insertions/removals being performed. This container, again, has O(n) removal but no element shifting. If this is of your interest I plan to publish this little work in my blog (http://bannalia.blogspot.com ) during September. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 1

Boost.threads: Setting stack size
by Rajpal Dangi 14 Aug '08

14 Aug '08

Is it possible to set Boost thread stack size? How much is the default thread stack size? In the past also this question has been asked and I saw some answers which indicates that some work was in progress to set thread attributes at the time of its creation. http://lists.boost.org/Archives/boost/2002/06/30327.php Thanks

3 2

[fusion][parameter] a solution for named parameters / parameter packs using fusion maps
by Stjepan Rajko 14 Aug '08

14 Aug '08

Hello, I just realized that named parameters can be implemented rather nicely using fusion maps (I'm not sure whether this has been explored before). I threw together an implementation for two particular parameters/names, but the method could be easily generalized. Here are examples of functions taking parameter packs (label is a string, and size is a guigl::size_type which is a gil::point2 type) (...and don't worry about what guigl is): using namespace guigl::parameter; const std::string &function_taking_label(const pack<field::label>::type &args) { return args.label(); } const guigl::size_type &function_taking_size(const pack<field::size>::type &args) { return args.size(); } const guigl::size_type &function_taking_both(const pack<field::label, field::size>::type &args) { return args.size(); } Now you can do things like: function_taking_label(label("hello")); const guigl::size_type size_one(1,1); function_taking_size(size(size_one)); // parameters can be passed in any order function_taking_both(label("hello").size(size_one)); function_taking_both(size(size_one).label("hello")); // size has a default value function_taking_both(label("hello")); // extraneous parameters will be ignored function_taking_label(label("hello").size(size_one)); // empty parameter pack can be used for no parameters (all default values) function_taking_size(empty()); Here is the full test code: http://pastebin.com/f6b128a4b and the relevant implementation: http://pastebin.com/f584c7967 Compared to Boost.Parameter, I have a hunch that the Fusion approach would be faster to compile (haven't tested that though), and is a little bit less convoluted (esp. for certain cases like constructors using named parameters). I've never used Boost.Parameter so I'm not sure what other comparisons might apply. Any feedback welcome. Kind regards, Stjepan

7 22

Re: [boost] Unordered Link on beta.boost.org doesn't work
by Michael Goldshteyn 14 Aug '08

14 Aug '08

"Michael Goldshteyn" <mgoldshteyn(a)comcast.net> wrote in message news:<00c701c8fd9e$f8aa4e70$e9feeb50$@net>... > "Daniel James" <daniel_james(a)fmail.co.uk> wrote in message > news:<31f5f6790808130005s4b9df349xe34d161df2ba4bc3(a)mail.gmail.com>... > > On 13/08/2008, Hansi <hansipet(a)web.de> wrote: > > > > > the link under "New Libraries" "Unordered" doesn't work. > > > > Thanks for reporting this. A lot of the 1.36 documentation is > > currently missing. We're working on it. Until it's fixed, you can find > > the unordered documentation at > > http://www.calamity.org.uk/1.36/doc/html/unordered.html (I will change > > this to a redirect once the 1.36 documentation is fine). > > Speaking of Boost.Unordered, what is the reallocation strategy once a hash > table gets full, if that even makes sense (i.e., I suppose it depends on the > mechanism for collision resolution)? Is chaining used or some sort of open > addressing, in which case the hash table does need to be resized? Well, after reading the docs some more, it seems that: http://www.calamity.org.uk/1.36/doc/html/unordered/buckets.html answers most of my questions, already. Thanks

1 0

Re: [boost] Unordered Link on beta.boost.org doesn't work
by Michael Goldshteyn 13 Aug '08

13 Aug '08

"Daniel James" <daniel_james(a)fmail.co.uk> wrote in message news:<31f5f6790808130005s4b9df349xe34d161df2ba4bc3(a)mail.gmail.com>... > On 13/08/2008, Hansi <hansipet(a)web.de> wrote: > > > the link under "New Libraries" "Unordered" doesn't work. > > Thanks for reporting this. A lot of the 1.36 documentation is > currently missing. We're working on it. Until it's fixed, you can find > the unordered documentation at > http://www.calamity.org.uk/1.36/doc/html/unordered.html (I will change > this to a redirect once the 1.36 documentation is fine). Speaking of Boost.Unordered, what is the reallocation strategy once a hash table gets full, if that even makes sense (i.e., I suppose it depends on the mechanism for collision resolution)? Is chaining used or some sort of open addressing, in which case the hash table does need to be resized? Thanks, Michael Goldshteyn

1 0

Data-processing and serialization design questions
by Daryle Walker 13 Aug '08

13 Aug '08

If no one has noticed, I'm trying out a MD5 system on our Subversion server under "$ROOT/sandbox/md5/", hopefully to succeed Boost.CRC. (Let's use the skills & experience gained over the past... 7 years.) I'm sharing my design ideas to make sure I'm not missing anything. 1. The results of a MD5 run are encapsulated in the md5_digest class. It's actually a POD type, and the only supported operations are equality and streaming standard I/O. I couldn't think of anything else you would/could want to do with this type. 2. Although "everyone" writes MD5 functions as byte-running algorithms, it's actually a bit-running one. I've constructed my classes around bit-oriented operation, so maybe this'll bring a new perspective. I also use 64-bit integer types directly, instead of a pair on 32-bit integers like the "standard" implementations. (All the recent work on Boost.Integer was to enable this library.) 3. The computation of MD5 runs was completely encapsulated in the md5_computer class. Like Boost.CRC's design, this lets a run be done in piecemeal. There's also a function that does a single run over a buffer, that internally calls the computation class. Besides the actual computation work, the class had accessors to the current state of computation. I noticed that a lot of this code could be reused for other coding schemes, so I tried to create a hierarchy that spread the functionality. I felt that it got too unwieldy. I determined that the problem was that presentation and computation parts of the class burden each other. So I divided the class into the current md5_computer (presentation) and md5_context (computation) classes. The presentation class has a different hierarchy behind it, with more generics over OOP, but still contains a computation object. The computation class publicly has a producer-generator & consumer-functor interface, and its attributes cannot be accessed except for the associated presentation class, which is a friend. The system is like the I/O-streams' separation into stream and stream- buffer classes. Is this separation a good idea? 4. The presentation and computation classes have Boost.Serialization functionality. I originally planned to have serialization for the back-up classes, but I read a thread from May 2007 suggesting that the serialization model should match the user's model, not the implementation details, so those were skipped. 5. Note that the presentation and computation types only support Boost.S11n while the digest type only supports standard streams. Besides keeping the digest type POD, I didn't see a need to make the p/c types printable. (Now I just realized that you may want to save a MD5 in a data file. Maybe I'll work on serializing digests.) 6. Should the serialization routines be in the classes' headers, or move to separate implementation somewhere within Boost.Serialization (assuming this gets accepted, of course)? I think that Boost.Multi- Index puts s11n in its own headers, but that's because the design must be intrusive. It could be non-intrusive for the digest and presentation classes, but probably not the computation class. 7. I'll probably try out the framework on at least one more coding type. (I've read that a framework with only one concrete class is probably locked to just that class due to the programmer never having to confirm separation of concerns during testing.) 8. The usual byte-wise MD5 implementation probably does have a speed advantage over this library, since it can just dump bytes directly into a buffer until hashing time, then compute everything a byte at a time. This library forces CHAR_BIT calls for each byte submission, getting worse for buffer submissions. The library currently wastes space in the computation class, since it stores a 512-Boolean array. (A "bool" could rip off an unsigned-char, wasting CHAR_BIT - 1 bits, or an "int," wasting more space! This is probably why std::vector<bool> was invented.) Maybe switching to an unsigned-char array can fix both problems. 8a. After the switch at the end of [8], a byte-oriented wrapping variant of md5_context could be made that copies bytes directly into the inner object's buffer, and calls the hash-updater as needed. Note that the wrapping type would still do hash updates bit-wise; could/should they be byte-wise too? A byte-wise hashing optimization only works if CHAR_BIT is 8 (not even for higher integral powers of two), so is the potential effort worth it? How would I test both cases (octet-sized bytes and not)? Should I test both cases? Note that the direct-byte-copying part also has problems if 512 % CHAR_BIT != 0. 9. There's only Doxygen comments (which take up most of each file) for documentation. I guess that any Quickbook files would be more like general user guides. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

Thoughts & questions on adding serialization
by Daryle Walker 13 Aug '08

13 Aug '08

I was thinking about adding serialization to some times I've been working on in the sandbox. First I tried to recall how Mr. Ramey said serialization can be tested. I couldn't find the specific post I was thinking about, but others that were found gave me the answer. Reading other posts in that search prompted me to ask more questions. I could reduce the classes I'm working with to: //============================================= class computer; class context { public: typedef boost::array<uint_least32_t, 4> value_type; context(); // use auto copy-ctr, copy-=, dtr void operator ()( bool ); // consumer bool operator ==() const; // equals bool operator !=() const; // not-equals value_type operator ()() const; // producer private: friend class computer; boost::uint_fast64_t length; boost::array<uint_fast32_t, 4> buffer; boost::array<bool, 512> queue; template < class Archive > void serialize( Archive &ar, const unsigned int version ); }; class computer : public convenience_methods_base<context> { // An object of type "context" is incorporated in this object // due to the base class. A mutable/const pair of non-static // member functions named "context()" gives access to the inner // context object. public: typedef context::value_type value_type; // Put various access member functions here that forward to the // internals of the "context" type, which work because of the // friend declaration. private: template < class Archive > void serialize( Archive &ar, const unsigned int version ); }; //============================================= I initially planned to have serialization functions for these two classes, the "convenience_methods_base" base class template, plus two other class templates (a base class and a support class) that "convenience_methods_base" uses. But the e-mail search I mentioned found a thread from May 2007 (on the main Boost list) the suggested that the serialization of a non-primitive should match the user's external representation of the type, and not the type's particular internal structure. So I decided to keep the serialization protocol just for the two public-facing classes, "context" and "computer." I figured that the "computer" object can be serialized like: //============================================= template < class Archive > inline void computer::serialize( Archive &ar, const unsigned int version ) { ar & boost::serialization::make_nvp("context", this->context()); } //============================================= Which leaves how "context" objects are serialized. After thinking about it for hours, I decided to just whip out something quick & dirty and refine it later. So: //============================================= template < class Archive > inline void context::serialize( Archive &ar, const unsigned int version ) { ar & BOOST_SERIALIZATION_NVP( length ) & BOOST_SERIALIZATION_NVP( buffer ) & BOOST_SERIALIZATION_NVP( queue ); } //============================================= would give a final serialization, in my test file, of: //============================================= <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="5"> <test class_id="0" tracking_level="0" version="0"> <context class_id="1" tracking_level="0" version="0"> <length>1</length> <buffer class_id="2" tracking_level="0" version="0"> <elems> <count>4</count> <item>1732584193</item> <item>4023233417</item> <item>2562383102</item> <item>271733878</item> </elems> </buffer> <queue class_id="3" tracking_level="0" version="0"> <elems> <count>512</count> <item>1</item> <item>0</item>  <item>0</item> </elems> </queue> </context> </test> </boost_serialization> //============================================= Now I started refining, keeping the principle of not leaking implementation details in mind. The problem here is the array- counts, which I don't need since they'll never change. The first one I can fix by writing each element separately: //============================================= <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="5"> <test class_id="0" tracking_level="0" version="0"> <context class_id="1" tracking_level="0" version="0"> <length>1</length> <buffer-A>1732584193</buffer-A> <buffer-B>4023233417</buffer-B> <buffer-C>2562383102</buffer-C> <buffer-D>271733878</buffer-D> <message-tail class_id="2" tracking_level="0" version="0"> <elems> <count>512</count> <item>1</item> <item>0</item>  <item>0</item> </elems> </message-tail> </context> </test> </boost_serialization> //============================================= I've always wanted to use something like a base-64 string encoding of the bit array, because it's cool and it'd save space. I added conversion functions to/from the bit array and a std::string, and then (de)serialized the string. I also had to separate "serialize" into "save" and "load" since conversion is complementary, not identical. So now I have: //============================================= <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="5"> <test class_id="0" tracking_level="0" version="0"> <context class_id="1" tracking_level="0" version="0"> <length>1</length> <buffer-A>1732584193</buffer-A> <buffer-B>4023233417</buffer-B> <buffer-C>2562383102</buffer-C> <buffer-D>271733878</buffer-D> <message-tail>g</message-tail> </context> </test> </boost_serialization> //============================================= Then I added tests for: exactly 6 bits (i.e. one base-64 letter); a sextet (actually two) and a partial sextet together; filling a queue to capacity (actually one short of that since a full queue automatically activates a turnover); and going past capacity resulting in a new hash buffer and an empty message-tail. //============================================= <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="5"> <test class_id="0" tracking_level="0" version="0"> <context class_id="1" tracking_level="0" version="0"> <length>1</length> <buffer-A>1732584193</buffer-A> <buffer-B>4023233417</buffer-B> <buffer-C>2562383102</buffer-C> <buffer-D>271733878</buffer-D> <message-tail>g</message-tail> </context> </test> </boost_serialization> <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="5"> <test class_id="0" tracking_level="0" version="0"> <context class_id="1" tracking_level="0" version="0"> <length>6</length> <buffer-A>1732584193</buffer-A> <buffer-B>4023233417</buffer-B> <buffer-C>2562383102</buffer-C> <buffer-D>271733878</buffer-D> <message-tail>q</message-tail> </context> </test> </boost_serialization> <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="5"> <test class_id="0" tracking_level="0" version="0"> <context class_id="1" tracking_level="0" version="0"> <length>14</length> <buffer-A>1732584193</buffer-A> <buffer-B>4023233417</buffer-B> <buffer-C>2562383102</buffer-C> <buffer-D>271733878</buffer-D> <message-tail>qQg</message-tail> </context> </test> </boost_serialization> <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="5"> <test class_id="0" tracking_level="0" version="0"> <context class_id="1" tracking_level="0" version="0"> <length>511</length> <buffer-A>1732584193</buffer-A> <buffer-B>4023233417</buffer-B> <buffer-C>2562383102</buffer-C> <buffer-D>271733878</buffer-D> <message- tail>ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789- _AAAAAAAAAAH__________g</message-tail> </context> </test> </boost_serialization> <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="5"> <test class_id="0" tracking_level="0" version="0"> <context class_id="1" tracking_level="0" version="0"> <length>512</length> <buffer-A>2631642121</buffer-A> <buffer-B>80961853</buffer-B> <buffer-C>4033330630</buffer-C> <buffer-D>497373075</buffer-D> <message-tail></message-tail> </context> </test> </boost_serialization> //============================================= If you want to see the actual work, look at revision/change-set #48131 in Boost's Subversion set-up. Now to the actual questions: 1. If there's only one sub-object, base or member, that has any significant data, could someone call the "serialize" member function of that sub-object directly in the wrapping class's "serialize"? (This assumes that friendship is set up.) This would make the wrapping class look identical to the sub-object's class, right? Is this a good idea? 2. Before actually trying to serialize a string, I was worried that the string's serialization would include a length count. This would be unnecessary because the object's "length" attribute already implies the length of the string (int( ceil( double( length % 512 ) / 6.0 ) )). Here, we see that the string's length isn't explicitly included in the XML archive, so I have no worries. But what about non-XML archives? Will be string's length be directly serialized, wasting space? If so, how can I fix that? 3. Having to add std::string to support serialization makes my class header heavier. My class uses fixed-sized arrays, so is there any way that I can avoid allocating a string? For writing out, could I set up a char-array with the encoding and write that out? For reading in, can I read the string in piecemeal to a char-array just in case someone added more characters than required. My converter currently ignores illegal characters and stops when enough legal characters have been read. If what I ask is possible, would the reading routine have to seek to the end of the entry so further serialization isn't messed up? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[1.36.0] Getting Started changes (ticket #1744 plus other fixes)
by Beman Dawes 13 Aug '08

13 Aug '08

Before we can ship 1.36.0, some "Getting Started" documentation changes are needed. These changes are the only thing preventing 1.36 from shipping. Enough said. * Section 1, Get Boost, both Windows and Unix Variants: need to begin with a suggestion that users first check for the availability of platform specific installers, linked to the correct URL. [Rationale: the platform specific installers are the preferred way for users to install Boost if their platform is one of those supported.] Questions for Doug: Are the platform specific installers to be hosted on SourceForge as part of the "boost" package? What is the initial set of platform specific installers that will be provided for 1.36? * Section 1, Get Boost, Windows: current text needs to be updated if Boost Consulting is not going to be also providing installers. [Rationale: The current wording is very specific, thus needs careful adjustment to match reality.] * New section, before the current section 1: Suggest visiting http://www.boost.org/doc/libs/1_35_0/more/getting_started/index.html to see if there has been a "Getting Started" documentation update. [Rationale: that way we can push out better docs as soon as available, instead of having to wait for the next release.] * Section 5.2.4, Invoke bjam, both Windows and Unix Variants: needs to say what library variants (static/dynamic, debug/release, multi-threaded/not) are build by default. [Rationale: (1) It is too late to change the default behavior for 1.36.0. (2) The worst problem with the new defaults isn't the specific choices, but that those choices aren't documented, and (3) it needs to be crystal clear how to build the full set.] * Section 5.2.4, Invoke bjam, both Windows and Unix Variants: after the current contents, needs to give the exact command line for building all library variants. [Rationale: resolves (3) in prior item.] Since Dave is on vacation, I'm not sure he will be able to make these changes. If he can't make them, I'll give it a try. Thanks, --Beman

6 13

Re: [boost] boost::math::tools and boost::distributions
by Jesse Perla 13 Aug '08

13 Aug '08

> > >Docs here: > > > http://www.boost.org/doc/libs/1_35_0/libs/math/doc/sf_and_dist/html/math_to… > > > >Note that these are considered "experimental" in the sense that their > >interfaces haven't been reviewed for formal inclusion in Boost. They are > >all rigorously tested though as they're fundamental to the implementation > of > >the rest of the library. So... please do use them, and if you find any > >interface SNAFU's that can be improved let us know! BTW the most likely > >reason for the interfaces to change is to facilitate improvements to their > >implementation and especially their efficiency. > > > >HTH, John. (sorry John, I sent my last email before getting the digest) Perfect. Since a snapshot of the interfaces exists for 1.35, then a port over to newer versions of boost is reasonable. Hopefully we can turn this into a top level project that does the baseline optimization/root finding people need before shopping for really specific tools/algorithms. -------- A couple of other questions on this beautiful distributions library - which I see as a great starting point for a lot of operations treating them as measures: * Is there any planned or existing support in the library for multi-dimensional distributions? In particular, bivariate norms with a covariance matrix passed in? Will the library design and notation support these sorts of extensions without too many problems? * Is there any way in the current library to pass in a user created discrete valued probability measure and have it as a "distribution" here? If not, I think I may write it, but as I am not a very good library programmer I would love to exploit any other work out there. I would need this to work for at least 1 and 2 dimension measures. * If we were to use a function to bundle a discrete valued function, is there a nice class/pattern out there that already combines the x-values and y-values into a single class? (I also want this later for implementing different interpolation algorithms returning functors after passing in a discrete function in the constructor). * Then I would write a specialization of this (2nd and higher dimension) for a markov measure. * Then, I want to write a general operator for unconditional expectation passing in a function object, and over a generic distribution as a measure from this library (though I will use it for the discrete measures to begin with). Specializing for different types of distributions, this could use exact analytical calculations, quadrature, or use monte-carlo methods. * Last, I want to write a conditional expectation operator that takes in a function object mapping reals^2 to reals, a distribution (would have to be 2 dimensional), the conditional (which would be a real for now, but could be generic), and what dimension the condition applies to. * Eventually, we may be able to tie together this operator with boost::lambda and boost::bind and we could up with a very elegant way to write out functions that involve conditional expectations. It may not have the performance of hand-tweaked fortran loops, but it should be a good enough place to start and infinitely preferable to matlab. The main use case I have for this is to implement easy/flexible notation for conditional distribution functions when writing out bellman equations for dynamic programming in economics. Most cases of this involve two dimensional markov measures (often approximated by Tauchen's algorithm from ARMA processes) If anyone is interested in this topic, has ideas, wants to work jointly, or plans to tell me that I am insane, please email me. My main fear is that I am a library user with a pretty good ability to think in generics, but with absolutely no chance of ever understanding what all of the crazy non-algorithmic code in these libraries does or writing it myself. -Jesse

2 1