November 2006 - Boost - lists.preview.boost.org

[BoostBook] documentation typo
by Michael Marcin 15 Dec '06

15 Dec '06

http://tinyurl.com/uuqvb "This section describes how to manually configure Boost Boost version 2 (BBv@) for BoostBook." I'm pretty sure that's not quite right :) Probably meant: "This section describes how to manually configure Boost Build version 2 (BBv2) for BoostBook." - Michael Marcin

2 3

property tree library not in CVS?
by Janek Kozicki 13 Dec '06

13 Dec '06

Hello, I recall that Property Tree library has been accepted into boost: http://tinyurl.com/h5nlt I can find its documentation on the web and source to download, but I have downloaded current CVS: cvs -d:pserver:anonymous@boost.cvs.sourceforge.net:/cvsroot/boost login cvs -z3 -d:pserver:anonymous@boost.cvs.sourceforge.net:/cvsroot/boost checkout boost cvs -d:pserver:anonymous@boost.cvs.sourceforge.net:/cvsroot/boost logout And I cannot find it there. Anyone can explain why it's not there? (or maybe I'm just blind) -- Janek Kozicki |

6 12

New getting started guide
by David Abrahams 11 Dec '06

11 Dec '06

I've got a first draft of the new getting started guide ready (enclosed). Comments would be appreciated. I plan to factor it out into separate documents, e.g. one just for *nix, one just for Visual Studio, etc., which should help make it more coherent... but I need to do a small amount of tool writing before I can accomplish that without duplicating information. The source file is checked in at more/getting_started.rst -- Dave Abrahams Boost Consulting www.boost-consulting.com

12 32

GIL Review: GIL extensibility example: packed pixel
by Lubomir Bourdev 10 Dec '06

10 Dec '06

A few reviewers have remarked on whether GIL can handle more complex formats, such as packed RGB565 format, (i.e. 5 bits red, 6 bits green, 5 bits blue). Since we can handle even images representing syntethic functions, we can certainly handle packed pixels. We took a stab at providing a model for packed pixel formats and posted it here: http://opensource.adobe.com/gil/packed_pixel.hpp This just serves as an example. The code could be improved and made more generic. Here is how you can define a packed pixel of three channels: typedef packed3_pixel<rgb_t,boost::uint16_t,boost::uint8_t,5,11> rgb565_pixel_t; This defines an RGB pixel over 16-bit data. The first channel always starts at bit 0. The second channel starts at bit 5, and the third at bit 11. Of course, you can define a whole range of packed pixels. Here is an LAB pixel that fits in a byte: typedef packed3_pixel<lab_t,boost::uint8_t,boost::uint8_t,2,2> lab223_pixel_t; Here is example code of using packed pixels: boost::function_requires<HeterogeneousPixelValueConcept<rgb565_pixel_t> >(); boost::function_requires<ChannelConcept<rgb565_pixel_t::kth_channel_t<0> ::reference> >(); typedef type_from_x_iterator<rgb565_pixel_t*>::view_t rgb565_view_t; typedef image<rgb565_view_t> rgb565_image_t; // Read a test image rgb8_image_t unpacked_image; jpeg_read_image("test.jpg",unpacked_image); // copy it into packed 565 form rgb565_image_t packed565_image(get_dimensions(unpacked_image)); copy_pixels(color_converted_view<rgb565_pixel_t>(view(unpacked_image),pa cked3_color_converter()),view(packed565_image)); // save it back unpacked. You will see dithering artifacts, especially for channels of low bit depth jpeg_write_view("test2.jpg",color_converted_view<rgb8_pixel_t>(view(pack ed565_image),packed3_color_converter())); // Invoke gradient on the packed data directly. Note: You need the most // generic version of x_gradient that supports heterogeneous pixels rgb8_image_t gradient(get_dimensions(unpacked_image)); x_gradient(view(packed565_image), view(gradient)); Note that everything you can do with GIL already automatically extends to packed pixels. You can run GIL heterogeneous algorithms on them. You can color convert them. You can include them in runtime types... Most importantly, GIL core does not need to change. Lubomir

2 2

[date_time]facet questions
by Martin Adrian 08 Dec '06

08 Dec '06

I have a common function to output dates to sql strings. It works like this: std::locale sqllocale(database_type db_type) { switch (db_type) { case MSAccess: return std::locale(std::locale::classic(), new dt::date_facet("#%m/%d/%Y#")); case MSSQLServer: return std::locale(std::locale::classic(), new dt::date_facet("{ d '%Y-%m-%d' }")); ... } } std::ostringstream ss; ss.imbue(sqllocale(MSAccess)); ss << "SELECT * FROM tbl WHERE somedate=" << dt::date(2006,11,24); Now I need to put dates into an excel spreadsheet which uses a date formatted as a date duration. This can't be expressed via the formatters so I created my own facet but discovered some strange things: 1. The "put" function of the date_facet calls "do_put_tm" instead of just "do_put" like standard facets. 2. The virtual "do_put_tm" function takes a struct tm instead of a date argument. Unfortunatly this means extra work. My code now looks like this: case MSExcel: { struct excel_date_facet : public dt::date_facet { excel_date_facet(::size_t ref_count = 0) : dt::date_facet(ref_count) { } virtual std::ostreambuf_iterator<char> do_put_tm( std::ostreambuf_iterator<char> next, std::ios_base& a_ios, char_type fill_char, const tm& tm_value, string_type a_format) const { // Here I now got the date as a struct tm which is pretty useless // when I want to calculate a date duration. // convert it back to a date dt::date d = dt::date_from_tm(tm_value); // +2 here because Excel starts on 1900-0-0 and treats 1900 // as a leap year (!) unsigned long days = ((d - dt::date(1900,1,1)).days() + 2); return std::use_facet<std::num_put<char> >(a_ios.getloc()).put( next, a_ios, fill_char, days ); } }; // struct excel_date_facet return std::locale(std::locale::classic(), new excel_date_facet()); } Can I recommend that the date_facet is changed so that "put" calls "do_put" which converts to a struct tm and calls a "do_put_tm" function. And another question: I asked a long time ago why the default formatting for dates is "2006-Nov-24" instead of the current locale formatting. Don't remember the answer now but I had a look in the TR2 proposal for date_time and saw that it remains that way. Why should something in a standard don't follow the current locale?

2 2

What happened with RTL (Relational Template Library)
by Oliver.Kowalke＠qimonda.com 07 Dec '06

07 Dec '06

Hi, I saw RTL from Dmitriy Arapov and Arkadiy Vertleyb in teh Vault but it seams not to reviewed yet?! Regards, Oliver

2 5

Re: [boost] Preliminary working prototypeofatomic_shared--multithreaded wrapper for shared_ptr.
by Talbot, George 02 Dec '06

02 Dec '06

> Chris Thomasson wrote: > > Sent: Wednesday, November 22, 2006 11:32 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Preliminary working prototypeofatomic_shared-- > multithreaded wrapper for shared_ptr. > > "Talbot, George" <Gtalbot(a)locuspharma.com> wrote in message > news:acfee74296c36aa7458ec7c5580b0b9c4564c67b@locuspharma.com... > > Hi, > > > I've attached to this e-mail a working prototype of a wrapper for > > shared_ptr that uses a spinlock so that the shared_ptr may be updated > > atomically from multiple threads. For example, two threads can both > > attempt to set the value of the same shared_ptr, and the last one will > > win. This wrapper includes a "compare_and_set" method for performing > > lock-free-style "read, copy, attempt swap, repeat" updating to a data > > structure, though, of course because the wrapper uses a spinlock, it > > isn't truly lock free. > > I suggest you take a look at a mostly lock-free implementation: > > http://appcore.home.comcast.net/vzoom/refcount/ > > Your wrapper uses the spinlock when it doesn't have to... A swap and a cas > to shared locations that contain pointers to the refcount > object do not need to be locked... I know. I was just doing a simple prototype first that has the interface that I want. I figure if I get everything working with the simple stupid spinlock, then I can go back and re-work with atomic operations. > Weak reference count modifications do not need to be > locked... That's good to know. > You don't need to use DWCAS either... Don't I need to do that for assignment and compare_and_set for the actual shared_ptr<>, since it's two words? (pointer to object and pointer to refcount.) This is good feedback. Thank you for the help. -- George T. Talbot gtalbot(a)locuspharma.com

2 1

Re: [boost] boost::shared_ptr<>::compare_and_swap()--AmIinsaneforwanting this?
by Talbot, George 02 Dec '06

02 Dec '06

My mistake. So that seems like a bit of a useless guarantee--basically any structure constructed with shared_ptr can only be read by the same thread that's writing to the structure unless all of the pointer operations are guarded with a mutex or spinlock, right? Ignoring compare-and-swap, have you or anyone else experimented with using a spinlock (as you mentioned previously) to remove the above restriction? What would that do to performance and complexity? Could you use a compare-and-swap type of operation to implement read/write thread safety? -- George T. Talbot <gtalbot(a)locuspharma.com> > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Peter Dimov > Sent: Friday, November 10, 2006 10:16 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] boost::shared_ptr<>::compare_and_swap()-- > AmIinsaneforwanting this? > > Talbot, George wrote: > > > I'm sorry if I'm being too dense here. I think a section in the > > documentation saying exactly what is guaranteed and what isn't would > > help a lot. > > Here you go: > > http://boost.org/libs/smart_ptr/shared_ptr.htm#ThreadSafety > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

4 6

Yet another bignum type
by Daryle Walker 01 Dec '06

01 Dec '06

This is something I've been working on for the past few months. It's in the Sandbox and I just uploaded it to the new Vault as "big_radix_whole.tar.bz2" under the "Math - Numerics" directory, i.e. <http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam e=big_radix_whole.tar.bz2&directory=Math%20-%20Numerics&>. The files might choke on some systems, since I used naked min & max and the test file has #pragma marks all over it. (My IDE function-lists all the test modules as "BOOST_AUTO_TEST_CASE()", without anything in the parentheses, so I needed the marks to navigate the huge file.) I'm using Xcode 2.4, with Apple's special GCC, on a Mac OS X 10.4.8 PowerPC system. The only documentation right now is the Doxygen comments. It's a run-of-the-mill bignum type. It uses the philosophy of the STL containers to use a separate template parameter for the memory allocations. The type is radix-specific, also given as a template parameter. It's of the simplest bignum type, an arbitrary-length unsigned integer class. (Signed integers, fixed-point, floating-point, rational, etc., variants can all be built off of this kind of bignum.) As such, the renditions of the traditional algorithms are fairly pure. The biggest issue from a mathematical standpoint is that the type can't be a proper ring, since it doesn't support additive inverses (besides zero). Every other arithmetic operation (that doesn't need negative values) can work. The work-around for subtraction is the addition of "subtract-absolutely" member functions, which compute the absolute value of the difference, and return a "bool" indicating what the sign would have been. Many of the operations are repeated, each with optimized algorithms for the different sizes of the parameters. Since the traditional method of multiplication is actually a fused-add/multiply, member functions for such fused actions were added. There are many variants for shifting-up where additions/subtractions start since it's faster than doing a separate shifting operation first. And it saves memory, which was an important goal in all the algorithms, along with the strong exception guarantee. Besides the asserts, there is generally no protection for pre-condition violations (except for exceptions for negative results, divides by zero, and conversions). There are commented-out plans for functions that do powers and (truncated) roots, especially squaring and square-roots, and pseudo-reciprocals (for an N-digit value, find another M-digit value, with M <= N, closest to giving a product of Radix**2N, useful to implement exact-division by multiply-by-reciprocal, which is cheaper for huge N). What other routines should be added? Any hints on how to do said routines? Should there be Serialization? Could Spirit and/or Regex be used for the I/O routines? Any compiler workarounds to be added? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

15 38

FW: [Boost-users] Suggestion for boost`s smart pointers
by Sohail Somani 01 Dec '06

01 Dec '06

Hi, Please see the following email about additional template parameters for scoped_ptr. The quick hack I wrote for it is below (I've used this in previous project as well). I think it would be very useful to many users and wouldn't change any source using scoped_ptr. Thanks, Sohail ==== I've been thinking something like (just something I hacked together just now). Not sure if there is a nicer way. #include <string> #include <cstdio> #include <iostream> template<typename T> struct DeletingDeleter { DeletingDeleter(T * p) { delete p; std::cout << "DeletingDeleter" << std::endl; } }; struct FileCloser { FileCloser(FILE * f) { std::cout << "Closing file" << std::endl; fclose(f); } }; template<typename T, typename Deleter=DeletingDeleter<T> > struct scoped_ptr { scoped_ptr():p_(0){} scoped_ptr(T * p):p_(p){} ~scoped_ptr() { Deleter d(p_); } T * get() {return p_;} // regular stuff private: T * p_; }; typedef scoped_ptr<FILE,FileCloser> file_ptr; int main() { scoped_ptr<int> a; // maintain old interface scoped_ptr<int> b(new int(5)); file_ptr p(fopen("myfile.txt","w")); fprintf(p.get(),"Hello world!\n"); } > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of David Klein > Sent: Tuesday, November 28, 2006 4:55 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Suggestion for boost`s smart pointers > > Sohail Somani wrote: > >> -----Original Message----- > >> From: boost-users-bounces(a)lists.boost.org > >> [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > David Klein > >> > >> Sohail Somani wrote: > >> > >>>> -----Original Message----- > >>>> From: boost-users-bounces(a)lists.boost.org > >>>> [mailto:boost-users-bounces@lists.boost.org] On Behalf > Of mark cox > >>>> > >>>> wow, this seems like a great idea, a scoped_ptr with deleter > >>>> would be v.useful. > >>>> mark > >>>> > >>>> > >>> I've been thinking something like (just something I hacked > >>> > >> together just > >> > >>> now). Not sure if there is a nicer way. > >>> > >>> > > [snip] > > > >> +1 vote for this idea :) > >> > >> i actually kind of did this for my current project, > >> because i needed a custom deleter for scoped_ptr, > >> when shared_ptr was to much overhead... > >> > > > > As did I, but it was not for performance but for readability. Shared > > pointers mean... Shared. Scoped don't. > > _______________________________________________ > > Boost-users mailing list > > Boost-users(a)lists.boost.org > > http://lists.boost.org/mailman/listinfo.cgi/boost-users > > > > > > yep exactly, > thatswhy i "ripped" scoped_ptr out of boost and added my > custom_deleter > stuff. > (i only *thought* about shared_ptr to do the job) > > so are there any objections about adding this feature to scoped_ptr? > > -- > regards dave > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users >

3 4