- Boost - lists.preview.boost.org

[MultiArray] constness and documentation bugs
by Frank Mori Hess 25 Jun '09

25 Jun '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am able to modify a const multi_array through a multi_array_ref. For example: const boost::multi_array<int, 2> myarray(boost::extents[2][2]); boost::multi_array_ref<int, 2> myarrayref(myarray); myarrayref[0][1] = 2; IMO, trying to create a multi_array_ref from a const multi_array should fail to compile, only a const_multi_array_ref should work. Also, the reference doesn't include the public inheritance between multi_array, multi_array_ref, and const_multi_array in their class synopses. It is important because it seems to be the only reason you can do conversions from multi_array to multi_array_ref or const_multi_array_ref. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpDgtMACgkQ5vihyNWuA4VKgACg4+vF6iDMXKgROj6Wl0/sDDWl bZ8AoMDKVcGSY3SWGcRRvaxG6ik8VsPS =A71z -----END PGP SIGNATURE-----

1 0

Fixed point integer proposal
by Soren Holstebroe 25 Jun '09

25 Jun '09

Hi, Some years ago I wrote a fixed point template for transparent fixed point integer arithmetics and conversion. It worked well and performance was equal to that of native integer types, at least in MS VC++. The template takes a base type and the number of bits reserved for the fraction part and meta-programming works out boundary safe arithmetics and conversions. The template has been used in an image processing library, but lately I used it for seamless conversion of a 4+28 bit fixed point MAD-library decoded mp3-stream to the output buffer of the sound system, with a detour through a float-based sound effect. Would there be public interest in a template like that in the boost library? Soren

6 5

boost::test documentation typo
by Philippe Vaucher 25 Jun '09

25 Jun '09

Hi, The tutorial at http://www.boost.org/doc/libs/1_39_0/libs/test/doc/html/tutorials/new-year-… uingkeeps using BOOST_AUTO_EST_CASE when it obviously should be BOOST_AUTO_TEST_CASE. If no one replies to this mail saying he'll handle it I'll create a ticket on the trac. Philippe

1 0

Re: [boost] version conflicts: is there a solution?
by Artyom 25 Jun '09

25 Jun '09

There are many problems and this is not as simple as you think. Because if you have two versions of foo() defined in header files they may be exported and... collide. See: http://stackoverflow.com/questions/836875/ This problem is much more significant at UNIX platforms where all symbols are exported by default. Think of boost_1.38 boost/foo.hpp namespace boost { int foo() { return 1; } } boost_1.39 boost/foo.hpp namespace boost { int foo() { return 1; } } Now the library includes this header from 1.38 and automatically exports foo outside. Now, you use 1.39 and may get different values of foo(). You may do simple tests and find how bad this is. So... NO You can't use two versions of boost in same project especially at ELF platforms. ...... I just what to remind that there is a script I had written that renames boost namespace and macros preventing namespace collisions of two different versions of Boost. http://lists.boost.org/Archives/boost/2009/05/151816.php So take a look on it, and give feedback, so I would be able to submit it officially to Boost. Artyom > Having the definitions separated into different translation > units doesn't seem > to be enough to prevent ODR violations according to the > standard. It gives a > list of requirements for multiple definitions in different > translation units > in section 3.2.5. >

2 1

Linear circular buffer
by Soren Holstebroe 25 Jun '09

25 Jun '09

Hi, The boost library contains a circular buffer template by Jan Gaspar. It seems well written and STL robust, but I believe the design has some performance shortcomings in many practical usages. Every time I have used a circular buffer it has been to drag a window over a huge or real time dataset. If the dataset is non real-time and small enough to be contained in memory, there is no practical need for a circular buffer, since the window data pointer can just be dragged in memory along the full length of the dataset. In many algorithms using a dragged window, you would need to process the full length of the window for each time the window is moved. E.g. convolving signal data. Thus, you read from the window a lot more than you write. To maximize performance of your window reading and to utilize external libraries, you need linear access to the data. While Gaspar's circular buffer provide a linearize method, it requires a full reorganization of the contained data. This yields an O(N*M) efficiency, just for dragging the window (size N) over the data (size M). For internal use, the circular buffer provides iterators, but each iteration requires an internal buffer check, in order to wrap around the buffer border. Since the nature of a circular buffer in most practical scenarios (at least that I can think of) is to be involved in the processing of large amount of data, read performance is important. If you allow the internal buffer to allocate more memory than the size of the circular buffer, you can reduce the number of times you need to reorganize the internal buffer to make it linear readable. If you allocate N items more than the circular buffer size, you only need to reorganize every N+1 pushes to the window. Thus, allocating additional 100 items will reduce the reorganization overhead to 1%. I have written to Jan Gaspar, who recognizes that the buffer is not efficient for linear use, but he hasn't got the time anymore to add that feature. Is a circular buffer variant with linear access at a low maintenance cost something that would have public interest? Soren

2 1

Boost.Containers? (WAS Re: Proposal: Monotonic Containers - Comparison with boost::pool, boost::fast_pool and TBB)
by Dean Michael Berris 24 Jun '09

24 Jun '09

On Wed, Jun 24, 2009 at 10:40 AM, Christian Schladetsch<christian.schladetsch(a)gmail.com> wrote: > > What do people think of moving boost::interprocess::containers to > boost::containers? These containers are not really specific to interprocess? > I think this can easily be done through 'using' declarations: namespace boost { namespace containers { using boost::interprocess::list; using boost::interprocess::vector; /* ... */ } } I don't think it should move though to support earlier applications that are already using the interprocess namespace for the containers. -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

4 6

[range][rangex] Joining two unrelated ranges?
by Dean Michael Berris 24 Jun '09

24 Jun '09

Hi Guys, I was wondering if a utility that allows the encapsulation (and merging) of two ranges is already part of RangeEx? I was thinking along the lines of: vector<int> a, b; // populate a, populate b auto r = concat(a, b); // concatenates the ranges into a single range set<int> c(begin(r), end(r)); // r looks like a single forward range I'm not sure if this is already supported in Boost.Range and it'd be nice to know if this is already in RangeEx. TIA -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

8 12

boost::compressed_bitset
by Zachary Turner 24 Jun '09

24 Jun '09

I know there's over a zillion bitset implementations, but often times I have found myself in need of a bitset that is efficient (space-wise) at storing millions, billions, or even trillions (no joke) of bits. For this I have developed an in-house class which stores bits in a structure vaguely reminiscent of a "T-Tree" (http://en.wikipedia.org/wiki/T_tree) You can think of it basically as an std::map<boost::uint64_t, boost::uint64_t> where <key, value> represents the *interval* of bits [key, key+value-1]. So it's basically run-length encoded, with logarithmic lookups instead of linear lookups. Obviously the worst case scenario is where bits alternate 10101... throughout the entire bitset, and this structure will be terrible in that case. But where there are frequent runs of 0 and 1 bits, this gives orders of magnitude savings in space. Since a map is sorted on key, it's still a valid binary search tree and one can find the node for the k'th bit by map::lower_bound(k) and quickly check whether the bit is set by testing whether k is in [iter->first , iter->first+iter->second). The most difficult part is insertion / deletion since it involves splitting (or merging) intervals and rebalancing but the complexity is still no worse than that of a normal rebalancing avl tree. I almost exclusively use this structure in a way that interval nodes represent sequences of 1 bits, but it can just as easily be used the other way around, where intervals represent sequences of 0 bits. In fact now that I think about it probably doesn't even matter. Performing bitwise operations on such a structure is very fast. All you need to do is expand / reduce the intervals appropriately. Lookup / assignment is obviously not constant time but of course that is the tradeoff. Forward / reverse iteration is still very fast however as you only need to take the non-constant time hit once on begin(). It is also very fast to iterate only 1 bits or only 0 bits for the same reason, which can be quite slow with normal bitsets. The implementation I currently have is very unsuitable for boost for many reasons, but if there is enough interest I will (slowly) work on adapting this to be more generic / usable by a wider audience, of course with suggestions and input from the community. Zach

6 9

Re: [boost] version conflicts: is there a solution?
by Artyom 24 Jun '09

24 Jun '09

Hi, Take a look on this namespace renaming script: http://lists.boost.org/Archives/boost/2009/05/151816.php It should work, not sure about correctness of build system. I consider to submit it officially once it polished, but it seems to work. Artyom --- On Wed, 6/24/09, Lewis Hyatt <lhyatt(a)gmail.com> wrote: > From: Lewis Hyatt <lhyatt(a)gmail.com> > Subject: [boost] version conflicts: is there a solution? > To: boost(a)lists.boost.org > Date: Wednesday, June 24, 2009, 3:49 AM > Hi Everyone- > > This has been discussed before > (http://thread.gmane.org/gmane.comp.lib.boost.devel/180008) > but I think my > question is along a slightly different line so I thought I > would ask about it. > Let's say I want to compile and distribute a library > (without the source), and I > happen to use some boost header-only libraries as an > implementation detail in > some of my functions. None of the headers associated with > my library include > boost headers; it's purely an internal detail. > > Now, it seems to me that users of my library will still > have to be aware of the > fact that I used boost in my implementation -- > specifically, if they happen to > use different versions of the same boost libraries in their > code, then the ODR > is violated and the behavior is undefined. > > I realize this isn't a boost-specific problem (it would > affect any library of > template functions), but I am wondering if there is a > boost-specific solution > already worked out? Has anyone thought about this? It seems > to me that in this > case, what would be ideal would be if I could do: > > #define BOOST_NAMESPACE some_unique_namespace_for_boost > #include "boost/algorithm/string.hpp" > BOOST_NAMESPACE::shared_ptr<void> x; //or whatever > > Then I can insure there are no ODR violations and I don't > need to bother users > of my library with the fact that I used boost at all. > > Other than the sheer annoyance of having to go through all > the boost code to use > this macro, is there a strong downside to this approach? > > Alternatively, I could try: > > namespace { > #include "boost/..." > } > > But I don't know, could this work? Or are there boost > headers that rely on fully > qualified references like ::boost::algorithm::whatever? > > I'd appreciate anyone's thoughts on this issue, thanks! > > -Lewis > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] Proposal: Monotonic Containers - Comparison with boost::pool, boost::fast_pool and TBB
by Christian Schladetsch 24 Jun '09

24 Jun '09

> Updated tests (more of them, better formatting of results) for > https://svn.boost.org/svn/boost/sandbox/monotonic/libs/monotonic/test/compa… here > http://tinyurl.com/m83vll for GCC and here http://tinyurl.com/n9g8jv for > MSVC. I also added a column for std::allocator/mono. Have added comparison against TBB, as requested. These results are at the same location as linked to above. Christian.

7 39

Re: [boost] boost namespace
by Artyom 24 Jun '09

24 Jun '09

> I need to use two versions of boost in my > application. One the libs I link > against is statically linked against boost 1.34 and I'd > like to use 1.35's > asio library. First of all Asio comes as stand alone library outside of boost namespace. So, you may just use it as is or use namespace renaming: #ifdef USE_BOOST_ASIO #include <boost/asio.hpp> namespace netio = boost::asio; using boost::system::error_code; using boost::system::system_error; #else #include <asio.hpp> namespace netio = asio; using asio::error_code; using asio::system_error; #endif And then just relate to netio::... so you would keep an ability to upgrade to boost asio in future. This is the way I build CppCMS http://cppcms.sourceforge.net/ conditionally using Boost 1.33.1 and Asio or boost 1.35 and above only. > I believe I can make both versions > co-exist if I can manage > to rename boost 1.35's namespace to something like > boost135. > Take a look on a script I had written once: http://lists.boost.org/boost-build/2009/05/21911.php But note! boost 1.35 and 1.34 are not compatible nither ABI nor API. So you **must** not mix them in same module! This may be very tricky. So you can't use boost in interfaces between modules that use different versions of boost. Artyom

2 1

[Review Request] polygon
by Simonson, Lucanus J 23 Jun '09

23 Jun '09

Gtl was renamed to boost::polygon. The source is available at https://svn.boost.org/svn/boost/sandbox/gtl/boost/polygon/ And the documentation is at https://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm I have a review manager and a number of prospective reviewers lined up, so we should be able to at least get the review started smoothly. I would like the review wizard to contact me off list to discuss which dates are more suitable to have the review given my personal schedule. Thanks, Luke

2 4

SafeInt code proposal
by Omer Katz 23 Jun '09

23 Jun '09

A friend and I have started working on a SafeInt library which we hope will be included in Boost the library is composed of a template class, which excepts existing integer types as a parameter, and an exception class. not all operators have been implemented and there is still work to be done on the library, but we have reached a stage in which at least the basic operators are ready and tested. I've attached to this thread a zip file containing the code for the library and a tester we wrote (as an example for how the class should be used) I've also uploaded it to the boost vault. We would appreciate it if you took the time to review our code and give us your comments, tips and opinions (either as a reply to this thread or by email - omerktz(a)gmail.com) thanks, Omer Katz and Zil Levi

8 16

[task] boost.task-0.2
by k-oli＠gmx.de 23 Jun '09

23 Jun '09

Hi, I've uploaded a new version of boost.task (boost.threadpool) to boost vault http://www.boost-consulting.com/vault/index.php?directory=Concurrent Programming Changes: - detail/atomic.hpp with atomic_exchange (gcc + x86|ppc) - handle< R > with new function get_future() returning reference to internal shared future - moved execution-policies new_thread, own_thread and as_sub_task in separat headers - async() with as_sub_task as default execution-policy - functions interrupt_and_wait_until() and interrupt_and_wait_for() from handle< R > returning boolean indicating if op. succeeded or timed out - move semantics for task< R > and static_pool< R > - new function interrupt_all_worker() for static_pool< Channel > in order to interrupt all worker-threads without invalidating the pool - default_pool() removed because thread_resource_error exceptions thrown by static pool - support of processor-binding for FreeBSD (>=7.1) - tests updated - examples updated - documentation updated regards, Oliver

1 0

How to speed up the djikstra graph
by Lennart Berg 23 Jun '09

23 Jun '09

Hi Everybody I have had the pleasure of using the boost graph library for my project now, but I have ran into some problems, that I hope you can guide me on. First of all, let me tell a little about the project. I am a third party developer for paradox interactive, making an expansion for one of their games. Now i have implemented the djikstra alghorithm to simulate the transport capacity of countries, and it works pretty well. However I still think that the speeds to be improved somewhat (takes about 1-2 secs to compute), to make it more playable. First of all the map consists of ~2500 provinces / vertexes each with 4-8 edges / neighbours. I Find all the provinces I can access and then add all neighbours from it as edges. Each edge is allocated a cost according to infrastructure, terrain and distance from orgin to destination. Each "round" of the game is an hour, so a day is effectively 24 rounds. Right now I make a new graph once every day, one separate graph for each country, and compute it for every country once a day. However as the game has up to 300+ countries that becomes a pretty harsh computational burden. Now pretty much every variable in this setup can change hourly. ( location of units, conquest / loss of provinces, destruction of infrastructure, expansion / repair of infrastructure) So the question is how I can improve this approach. Optimally the graph should be persistant and allow me to dynamically add / remove provinces and change the cost of the edges every hour (as I understand it the boost library allows that right now with vertex_clear / add etc.), and giving new values without recomputing every single edge in the graph 300 times every hour. Is that possible? And if how would that be done? Thanks in advance Lennart Berg

8 18

[BGL] boost::add_vertex - add unique vertexes to graph
by Mariusz Kwiczala 23 Jun '09

23 Jun '09

Hi, Currently I externally check if vertex exist in graph. But it is look like boost::add_vertex can check internally if vertexes are unique. if (optional<vertex_descriptor> v = g.vertex_by_property(get_property_value(p, vertex_bundle))) return *v; Could you send me any example where boost::add_vertex just return already created vertex (line: "return *v") instead of create new one? boost_1_39_0\boost\graph\detail\adjacency_list.hpp contain: template <class Graph, class Config, class Base> inline typename Config::vertex_descriptor add_vertex(const typename Config::vertex_property_type& p, vec_adj_list_impl<Graph, Config, Base>& g_) { typedef typename Config::vertex_descriptor vertex_descriptor; Graph& g = static_cast<Graph&>(g_); if (optional<vertex_descriptor> v = g.vertex_by_property(get_property_value(p, vertex_bundle))) return *v; typedef typename Config::stored_vertex stored_vertex; g.m_vertices.push_back(stored_vertex(p)); g.added_vertex(g.m_vertices.size() - 1); return g.m_vertices.size() - 1; } Best regards, Mariusz

2 1

Re: [boost] GSoC Unicode library: second preview
by Artyom 23 Jun '09

23 Jun '09

> Of course, the library works with UTF-8 and UTF-32 just as > well, it makes no difference to the generic algorithms > (which don't exist yet, but expect substring searching and > the like), it's up to you to choose what makes the most > sense to use for your situation (for example, you may choose > to use UTF-8 because you need to interact a lot with > programming interfaces expecting that format). > Ok, this is really good. > They should be fairly easy to find. > Either you're using the algorithm that does the task > correctly, or you're fiddling with the encoding by hand > which is likely to be wrong. They are easy to find in the Unicode aware unit tests but not in real program. I did once a small test, what Unicode aware programs support characters outside of BMP, i.e. I tested a glyph that was encoded as surrogate pair in UTF-16... The results were total disaster: - Windows standard dialogs: displayed character correctly but every operation like deletion related to is as two pairs. For example file name dialog had problems. - Same behavior in notepad or any standard text-area widgets didn't work correctly. - Qt3 hadn't supported surrogate pairs at all (in Qt4 most of it was fixed) displaying two square "glyphs". - Opera Web browser, had similar problems with editing and displaying such characters. So... There is a huge problem with this encoding, because such simple QA test shouldn't give such bad results for such big amount of programs. Also, all programs that used internally utf-8 or utf-32 had passed these tests very well. So I really **do not** suggest recommending this encoding as "best" one for internal use. Artyom

1 0

boost namespace
by Igor S 22 Jun '09

22 Jun '09

Hi Everyone. I need to use two versions of boost in my application. One the libs I link against is statically linked against boost 1.34 and I'd like to use 1.35's asio library. I believe I can make both versions co-exist if I can manage to rename boost 1.35's namespace to something like boost135. I know this project could be time-consuming so I'd like you know your thoughts. What changes would I need to make to the build system? Thanks. -- Igor

1 0

GSoC Unicode library: second preview
by Mathias Gaunard 22 Jun '09

22 Jun '09

Here is the documentation of the current state of the Unicode library that I am doing as a google summer of code project: http://blogloufoque.free.fr/unicode/doc/html/ This preview comes a bit later than I planned, but after struggling to keep the documentation and the code in sync I decided to move to automatic documentation generation with doxygen, which I had trouble setting up due to my experience. The reference still lacks a lot of information, however. The library only features UTF support and the Unicode Character Database (not fully updated to latest Unicode version) at the moment, but grapheme clusters and normalization support will come very soon. I would like to get feedback on the UTF codecs, the various concepts (Pipe, Consumer, BoundaryChecker) and the whole approach of lazy ranges. Grapheme clusters (and other text boundaries facilities) support will also be provided in terms of the Consumer and BoundaryChecker concepts. The library features lazy ranges similar to that of Boost.RangeEx, and I used one of the naming conventions that was proposed during review: u8_encode is the eager algorithm, u8_encoded is the lazy one. Since it wasn't really agreed which naming to use for RangeEx, I would like this to be discussed as well.

4 7

Spice up your mobile
by lokesh755＠gmail.com 22 Jun '09

22 Jun '09

1 0

proposal for boost dynamic java styled , efficient class loading library
by dominic ibeme 22 Jun '09

22 Jun '09

Hello.. i wrote a class library that allows C++ classes to be loaded seamlessly using the class names.. just like in java... the library makes heavy use of the BOOST PREPROCESSOR library and is very stable, simple and light... however, it is subject to expansion... and review... i would like to share this library with the boost community as a sign of appreciations for their tremendous offerings... please direct me on how to go about this..

6 5

Re: [boost] GSoC Unicode library: second preview
by Artyom 22 Jun '09

22 Jun '09

Hello, > Here is the documentation of the > current state of the Unicode library that I am doing as a > google summer of code project: > http://blogloufoque.free.fr/unicode/doc/html/ [snip] Where is the source code? .... Some notes: > UTF-16 ... This is the recommended encoding for dealing with > Unicode internally for general purposes To be honest, it is most error prone encoding to work with Unicode: 1. It is variable length encoding 2. There surragate charrecters are quite rare and thus it is very hard to find bugs related with it. It was mostly born as a "mistake" at the beggining of the unicode when it was beleved that 16bit is enough for signle code point. So many software platforms adopted 16 bit encoding that supported only BMP, As a result you can **easily** find **huge** amount of bugs in the code that uses utf-16, In most of cases such bugs are hard to track because these code points are rare. For example, try to edit file-name in Windows with a charrecter that not in BMP you would see that you need to press "delete" twice, try to write such charecter in Qt3 application... that would just not work; There are many examples of it. So, I would be aware of recommending this encoding as internal encoding, just because many platforms use it. > UTF-32 ... This encoding isn't really recommended As I mentioned above, it is not quite true, it is much safer encoding to work with, So I would recommend not to write such "suggestions". More notes: ----------- - For boundary checks I'd suggest to use ICU or Qt4 like API: iterate over string and return each time next bound. Not check if there is a bound on specific character. - Examples and More description is required Artyom

3 3

Proposal: Monotonic Containers
by Christian Schladetsch 21 Jun '09

21 Jun '09

Hello, There is a need in high-performance realtime software to use containers that may only grow in size. These are typically reset at the end of each update cycle. The proposal here consists of a base 'monotonic allocator', which takes its storage from a buffer that you provide. Allocations are made from this buffer, and deallocation only calls an object's destructor; no actual memory-management is performed at all. This is very useful for realtime systems that have to do things like, for example, physics or renderering systems. These systems build up lists and other containers over the period of an update frame, however at the end of that frame the storage can just be reset. The benefit of using this system over a normal std::allocator is that memory is not fragmented, and memory allocation and deallocation is basically optimal. Within the package are: boost.monotonic.inline_storage boost.monotonic.list boost.monotonic.vector boost.monotonic.map boost.monotonic.set boost.monotonic.ptr_list I didn't bother adding the other ptr_* containers yet. The files for the proposal are in the vault at http://www.boostpro.com/vault/index.php?action=downloadfile&filename=Monoto… . I'd be happy to address any issues or comments. There are some improvements that could be made. Regards, Christian.

24 156

DateTime conversion to tm problem?
by Maciej Sobczak 21 Jun '09

21 Jun '09

Hi, The posix_time::to_tm function clears the date fields of the std::tm structure. Having zeros on year, month and day fields represent the 1900-01-00 date according to the std::tm conventions, which is a date that did not exist. Using such value with other APIs might result in out of range conditions. Is it considered to be a problem? What about setting tm_mday to 1 instead (which would represent 1900-01-01 - that is, the first legal date)? Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com

3 4

[BOOST_ASSERT] any one against improving debug support?
by Thorsten Ottosen 21 Jun '09

21 Jun '09

Hi, The current difinition of BOOST_ASSERT is a pain to use with the debugger and Boost.Test because it doesn't trigger a break-point. Does anyone object to defining it like this in <boost/assert.hpp> #if (BOOST_MSVC >= 1400) #include <crtdbg.h> #define BOOST_ASSERT _ASSERTE #endif ? -Thorsten

5 12