- Boost - lists.boost.org

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

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

23 Apr '09

>This library is not better than Boehm's gc (certainly slower than Boehm's), >but it is portable C++. I have looked at the library more thoroughly now. If you are interested in improving performance I have a method that could improve the performance big time. Just drop me a personal email. -- Kasra

1 0

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

23 Apr '09

I have interest in garbage collection. However, I have few questions about this library. * How is it going to be better than The Boehm GC? * Why isn't it a wrapper for Bohem? This header is what is used within our organisation for GC memory management. [C++ =============================================== C++] #ifndef __GC__ #define __GC__ #define GC_NOT_DLL #include <bohem/gc.h> #include <bohem/gc_allocator.h> #undef GC_NOT_DLL #ifdef BOOST_MSVC # pragma comment(lib, "gc.lib") #endif namespace { using gc_allocator; using gc_traceable; extern const struct gc_memory_t { } gc; extern const struct gc_traceable_t { } gc_traced; inline void* operator new(size_t size, const gc_memory_t&) throw(bad_alloc); inline void* operator new[](size_t size, const gc_memory_t&) throw(bad_alloc); inline void operator delete(void* memory, const gc_memory_t&) throw(bad_alloc); inline void operator delete[](void* memory, const gc_memory_t&) throw(bad_alloc); inline void* operator new(size_t size, const nothrow_t&, const gc_memory_t&) throw(); inline void* operator new[](size_t size, const nothrow_t&, const gc_memory_t&) throw(); inline void operator delete(void* memory, const nothrow_t&, const gc_memory_t&) throw(); inline void operator delete[](void* memory, const nothrow_t&, const gc_memory_t&) throw(); inline void* operator new(size_t size, const gc_traceable_t&) throw(bad_alloc); inline void* operator new[](size_t size, const gc_traceable_t&) throw(bad_alloc); inline void operator delete(void* memory, const gc_traceable_t&) throw(bad_alloc); inline void operator delete[](void* memory, const gc_traceable_t&) throw(bad_alloc); inline void* operator new(size_t size, const nothrow_t&, const gc_traceable_t&) throw(); inline void* operator new[](size_t size, const nothrow_t&, const gc_traceable_t&) throw(); inline void operator delete(void* memory, const nothrow_t&, const gc_traceable_t&) throw(); inline void operator delete[](void* memory, const nothrow_t&, const gc_traceable_t&) throw(); } #endif /* __GC__ */ [C++ =============================================== C++] [example auto_ptr<char*> gc_buffer(new (gc) char[1024]); auto_ptr<char*> traced_buffer(new (gc_traced) char[1024]); example] -- Kasra

3 2

[1.39.0] [Lambda] [Iterator] Warnings with gcc 4.3?
by Beman Dawes 22 Apr '09

22 Apr '09

In an email about something else, someone asked: ... we will be eager to use your upcoming version 1.39. One point we would be interested is to remove the following warnings on gcc 4.3. Would you know if those were fixed? <warning value="boost-1_38/boost/lambda/detail/lambda_functors.hpp:137: warning: type qualifiers ignored on function return type" /> <warning value="boost-1_38/boost/lambda/detail/select_functions.hpp:55: warning: type qualifiers ignored on function return type" /> <warning value="boost-1_38/boost/lambda/detail/select_functions.hpp:60: warning: type qualifiers ignored on function return type" /> <warning value="boost-1_38/boost/lambda/detail/select_functions.hpp:65: warning: type qualifiers ignored on function return type" /> <warning value="boost-1_38/boost/iterator/iterator_facade.hpp:652: warning: type qualifiers ignored on function return type" /> Does anyone know the status of these? --Beman

2 2