- Boost - lists.boost.org

Boost 1.39.0 beta 1 is available for download
by Beman Dawes 26 Apr '09

26 Apr '09

Boost 1.39.0 beta 1 is available for download from SourceForge. See http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041&… New Libraries: Signals2. Updated Libraries: Asio, Flyweight, Foreach, Hash, Interprocess, Intrusive, Program.Options, Proto, PtrContainer, Range, Unordered, Xpressive. Updated Tools: Boostbook, Quickbook. Plus the usual bug fixes to numerous libraries. Please report any problems to the Boost users or developers mailing list. Thanks, --Beman Dawes, Daniel James, and all the other Boosters who help get releases out

1 0

[quick-book] suggestion about library compatibility
by Thorsten Ottosen 26 Apr '09

26 Apr '09

Hi, quickbook already has Admonitions like [note a note] which generates a nice box with an icon. I think it would be useful to have addition admonitions to indicate the following - the library can be serialized with Boost.Serialization - the library can be compiled without exceptions (BOOST_NO_EXCEPTION) - the library can be used with Boost.Interprocess so these can be stated in a consistent manner up front in the documentation. Perhaps it is better that these are written up front like [library Boost.AutoBuffer [quickbook 1.4] [copyright 2009 Thorsten Ottosen] [compatibility noexceptions serialization interprocess] ] ? Any comments? -Thorsten

2 1

[mpl] mpl::string, help needed (vacpp, sun, borland)
by Eric Niebler 25 Apr '09

25 Apr '09

A few days ago, I added mpl::string (a compile-time string class template) to trunk. I expected horrific portability problems with my use of multi-character literals, but it's not as bad as all that judging from the test results. There are only a few failures on compilers I don't have access to: vacpp, sun and borland. I invite anybody with access to these compilers to "bjam string" in the libs/mpl/test directory, try their hand at fixing the problems and submitting a patch. Thanks! -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 10

Proposed templated integer_sort
by Steven Ross 25 Apr '09

25 Apr '09

Would there be interest in an integer_sort call that is faster than std::sort? Spreadsort is an in-place hybrid radix-based and comparison-based algorithm with better worst-case and average-case (roughly 20-50%) performance than introsort on random integer data. The worst-case advantage is algorithmic, with Spreadsort taking the better of O(n(square_root(bit_sizeof(data) - log(n)))) and O(nlog(n)) time. For 32-bit integers, that's O(n(square_root(32 - log(n)))), so for a log(n) of 16 (65536 items), it's 4n (plus a small constant times n), vs 16n for introsort. For larger n, the advantage vs. pure comparison-based algorithms increases. In effect, Spreadsort smoothly transitions from pure MSB Radix sort to std::sort with its data cut up by a couple iterations of MSB Radix sort (reducing the size of the log(n) factor), depending upon the distribution and size of the data. I could write a templated version of Spreadsort for the Boost library if there is interest. It would work for anything that supports the << and - operators. It could also handle standard floats sorted as integers. Functors supporting << and - could make it more general. Multi-dimensional sorting is also sped up by Spreadsort. I could also write a similar string_sort, that should also be significantly faster than std::sort. This would look much like postal sort, just using introsort after a certain number of iterations. Is this of interest? http://sourceforge.net/projects/spreadsort

15 118

BoostCon 2009 Registrar's Report
by Kim Scheibel 24 Apr '09

24 Apr '09

I'm very happy to report that, despite the current economic climate, we currently have a very solid number of confirmed registrations for BoostCon 2009. 84 registrations to be precise, of which 6 were registered in the last two days alone. You still have time to register at the discounted price of USD599 at http://www.boostcon.com/registration, on or before Apr. 26th. After that, the fee is USD699. Best regards, Kim Scheibel BoostCon 2009 Registrar

1 0

Re: [boost] request for interest in a garbage collection library
by Kasra 24 Apr '09

24 Apr '09

>One of the advertised advantages was that is was written purely in >standard C++, which isn't the case of Boehm which isn't portable. I am sure Boehm supports so many platforms and many compilers. Even so, an interpretation from C to ISO C++ is enough for that problem. >> auto_ptr<char*> traced_buffer(new (gc_traced) char[1024]); > This raises undefined behaviour, I believe. gc allocated memory slab is always zero, so there would be no live pointers on the traced_buffer memory slab. I think we the concept of the GC should encapsulate two things separately. memory allocation/deallocation object construction/destruction [example class foo; { auto_ptr< foo > foo_bar(new (gc) foo()); } // call foo_bar->~foo(); example] the RAII call the destructor but the memory that was occupied is not necessarily free. the gc::collect(), collects the memory as well as calling the destructor for non-destructed objects. -- Kasra

7 11

Re: [boost] [soc2009] Proposal for serialization library
by uwe.arzt 24 Apr '09

24 Apr '09

Hartmut Kaiser wrote: > > >> implementation has not responded to my email. You can check out the >> code >> here: >> http://code.google.com/p/google-summer-of-code-2008- >> boost/downloads/list > > In this case you might want to contact the mentor of last year's YAML > project: Joel de Guzman (joel at boostpro dot com). > > Do you know if the merge to boost is planned in the (near) future? Who should be contacted about that? Is help needed? Thanks :q! Uwe -- View this message in context: http://www.nabble.com/-soc2009--Proposal-for-serialization-library-tp226009… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Re: [boost] Boost.Process article: Tutorial and request for comments
by Boris Schaeling 24 Apr '09

24 Apr '09

On Tue, 21 Apr 2009 16:05:04 +0200, Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> wrote: > [...]I assume the name of the executable should be in the locale > character set. > So std::string, or even const char*, appear suitable. > > Now, if you want to perform automatic translation from unicode to locale > character set, why not, but that's another layer on top of that. An > unicode string type should be convertible to the locale character set > easily enough so that you don't need to that in your library, however. > > You could eventually add support for wide characters, though. While wide > characters are Unicode on Windows, they are as far as C++ is concerned > just another locale character set, and I think considering them as > nothing more than that is best. > > As far as I know, POSIX systems simply don't have APIs for wide > characters, however. Another problem on Windows might be that new projects in VC++ 2008 automatically assume Unicode is used. Thus all Windows API functions expect wide character strings which again means for executable names std::wstring would need to be used. And I don't know if developers really think about it and not simply assume that they can use std::string in all cases. I think Ion faced a similar problem when he developed Boost.Interprocess which only accepts const char* strings (and according to http://www.boost.org/doc/libs/1_38_0/doc/html/interprocess/acknowledgements… waits for string conversion utilities which would be the additional layer you mentioned). >> * 'handle' is the underlying native file handle of a stream (file >> descriptor on POSIX systems, handle on Windows). The concept is based >> on a >> class in the detail namespace of Boost.Process. There is just one class >> and it's not meant to be used by users of the library either. Thus I'm >> not >> sure what's the benefit of having an explicit 'handle' concept at all. > > Isn't it in case Boost.Process doesn't implement the features I need, so > that I may use them directly with the native functions? Before I had added a handle() function to the stream classes there was no way to access a handle. Indeed I had added handle() because I wanted to use the file descriptor/Windows HANDLE for asynchronous I/O. I think I agree with you that it should be possible to access native handles. However I'm not sure if a concept has to be defined. Maybe I understand concept wrong but if I hear concept I think about extensibility and different types. In that sense a concept for an executable name makes sense to me (if it wasn't so difficult to support it). But I'm not sure how it fits to a handle? Boris > [...]

1 0

Boost Serialization problem
by Suhail 24 Apr '09

24 Apr '09

Hallo I have currently installl the Boost boost_1.38 . Start new program in VC2003 add following lib in my project boost_serialization-vc71-mt-1_38.lib boost_serialization-vc71-mt-gd-1_38.dll example code: #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <iostream> #include <fstream> #include <stdio.h> using namespace std; void save() { std::ofstream file("archiv.txt"); boost::archive::text_oarchive oa(file); int i = 7; oa << i; } void load() { std::ifstream file("archiv.txt"); boost::archive::text_iarchive ia(file); int i = 0; ia >> i; std::cout << i << std::endl; } //========================================================== /// Main function //========================================================== void main(int argc, char* argv[]) { save(); load(); } After executing this example "archiv.txt" only stores 22 serialization::archive 5 instead of 22 serialization::archive 5 1 Could someone help me where i am making mistake??

1 0

Interest in atomic library?
by Seth LaForge 23 Apr '09

23 Apr '09

In this day and age, running our C++ programs off fossil fuels makes a dangerous contribution to global warming and requires purchase of carbon offsets for ethical programming. Thus I think it's time for a Boost atomic power library. Oops, sorrry, wrong meaning of atomic. What would people think of an atomic integer library, along the lines of Linux's asm/atomic.h? I'd propose a class atomic<T> implementing operations like atomic read (implicit conversion to T), atomic set (assignment from T), and compare-and-exchange. For integral types it would support atomic add and return result (operator+=), atomic subtract and return result (operator-=), atomic increment and return result (prefix operator++), and atomic decrement and return result (prefix operator--). For arbitrary architectures or unhandled types of T, there would be a naive implementation using a mutex. On supported architectures there would be specializations for integral T types, using assembly to implement more efficient atomic operations. This assembly could pretty much just be borrowed from the Linux asm/atomic.h headers. What do people think? I see pros: + Cross-platform efficient atomic operations for efficient threaded apps. I see cons: - Hard to predict whether your atomic ops will be efficient (no specialization for your architecture/T). - Some architectures may implement different atomic ops, making the above ops not the most efficient. I think the pros outweight the cons. I'd personally much rather use a Boost.atomic library than asm/atomic.h. Seth

6 7