- Boost - lists.boost.org

docs website unaccessible
by Andrey Asadchev 06 Aug '10

06 Aug '10

hello I seem to be getting access forbidden for any file in http://www.boost.org/doc/

2 1

[preprocessor] Can it be used with C?
by Andy Venikov 06 Aug '10

06 Aug '10

It's not explicitly stated in the documentation, but since the preprocessor is supposed to be the same between C++ and C, can boost.preprocessor be used in C code? Thanks, Andy.

2 1

[offtopic] cygwin and wchar
by Eric Niebler 05 Aug '10

05 Aug '10

I see that the cygwin toolset now expects wchar support, and I've heard that cygwin does indeed support wchar now, but I don't know what I need to do to get it. Simply running the cygwin installer and letting it update everything doesn't seem to do the trick. Help? -- Eric Niebler BoostPro Computing http://www.boostpro.com

5 10

[1.44] Beta release candidate available
by Beman Dawes 05 Aug '10

05 Aug '10

Release candidate files for the 1.44.0 beta are available at http://boost.cowic.de/rc/ As always, the release managers appreciate it if you download the candidate of your choice and give it a try. Report both success and failure. I'm concerned about the number of failures showing for Build, Python, and Thread libraries. See http://beta.boost.org/development/tests/release/developer/summary.html. We need to fix those before the final release, but I don't want to hold the beta up any more. Thanks, --Beman

7 12

[GIL] color convert and color tranfer characteristics
by fabien.castan＠free.fr 05 Aug '10

05 Aug '10

Hi, I have a problem with the distinction between colorspaces and color characteristics. I'm writing a basic transfer characteristics between lin, log, sRGB, rec601, rec709... I'm writing something like I talked for colorspaces, in the mail about "color_correct": * a specialization between each color characteristic and lin * a generic conversion to a templated type using an intermediate lin conversion I have two problems: 1) I have written a per channel functor, which seems to be the right way. But I don't know how to not apply it on the alpha channel if there is an alpha channel... without loosing performances because my common usage is rgba :). 2) I don't know how we can connect this with color_convert, because if we want to make a conversion from RGB to gray, we have to assume that RGB is linear (?) and we need to precise if we want a rec709 or rec601 luminosity... GIL code use an approximation of Rec601 to compute the luminance. Y' = 0.299 R' + 0.587 G' + 0.114 B' (Rec. 601 coefficients) Y' = 0.2126 R' + 0.7152 G' + 0.0722 B' (Rec. 709 coefficients) Best regards, Fabien

2 1

Re: [boost] [GIL] color_convert
by fabien.castan＠free.fr 05 Aug '10

05 Aug '10

Hi, > I cannot recreate your problem. Here is a little test app that works > fine on my machine ( VC10 ) The problem is that I define a generic conversion like that: /// \ingroup ColorConvert /// \brief Converting HSL to any pixel type. Note: Supports homogeneous pixels only. /// /// Done by an intermediate RGB conversion template <typename C2> struct default_color_converter_impl<hsl_t,C2> { template <typename P1, typename P2> void operator()(const P1& src, P2& dst) const { typedef hsl_t C1; typedef typename channel_type<P1>::type T1; typedef typename channel_type<P2>::type T2; pixel<T2,rgb_layout_t> tmp; default_color_converter_impl<C1,rgb_t>()(src, tmp); default_color_converter_impl<rgb_t,C2>()(tmp, dst); } }; So it's in conflict with: template <typename C1> struct default_color_converter_impl<C1, rgba_t>, if I use color_convert( hslPixel, rgbaPixel ). The goal of creating this generic conversion is that I can still make the conversion using an intermediate rgb colorspace if there is no specialization. I think we can have a good solution, if we apply this method to all colorspaces: * define a generic conversion to another colorspace using an intermediate rgb colorspace conversion, only in one direction MyColorspace -> typename C2 (so without typename C1 -> MyColorspace). That's why I would like to remove typename C1 -> rgba_t implementation. * redefine the conversion for colorspaces we want to make a direct conversion

2 1

Re: [boost] Checking library binary compatibility with respect tocompile time options [repost\
by Robert Ramey 05 Aug '10

05 Aug '10

I notice that the link I sent to a respond to the above didn't handle the attachments well. So here they are again. Robert Ramey Original post from back in may Turns out that the idea of a single boost library deployment has come up a couple of times here at BoostCon 2010. While preparing my presentation I considered the problem of what would happen if one installed one library which depended on an newer version of a different library than the user already had installed. I actually woke up in the middle of the night imagining someone would ask about that during my talk. I puzzled about it for some time and the day before I found a way to address it - in my own mind at least. It also seems that it turns out that there are tools that can also manage this. It's not that I don't trust tools but I wear a belt AND suspenders. So I would like a method which guarentees that when I build one library, I don't accidently include code from a prerequisite library which is a version so old that things won't work. I would also like to know that I'm not accidently running with a DLL built with an old version. Basically each library includes a file "manifest.hpp". This get's included when any header get's includes (once at most due to include guards). This includes a static assert that checks that the prequiste libraries are of sufficiently recent version that a dependent library (or user application) requires. There is also a manifest.cpp file included in the library which checks any prequiste DLLS. This would be an exheedingly small overhead to avoid what could be an incredibly large headache. I just verified that the code compiles so at this point it's only an idea. But it seems that some kind of check like this is un-avoidable of one want's to deploy libraries as needed rather than as a monolithic distribution. FYI - no one asked me about this problem at my presentation. Add one more confirmation of Murphy's law. Robert Ramey

2 1

Re: [boost] [GIL] kth_channel_view
by fabien.castan＠free.fr 05 Aug '10

05 Aug '10

Hi, Yes, it works fine without const. I used const automatically because I don't write in my image but I don't think it changes something. So without seems to be better because it's not the correct way to deal with const inside gil. I don't know how we can declare a parameter to be a const view... For example a simple function that takes an image v and returns if it contains a pixel p: template<class MyGilConstView> bool f( const MyGilConstView& v, const MyGilConstView::value_type& p ); This function can't garantee that it doesn't modify the image v and the pixel p. I can create a const view at the begining of the function, to get this garantee, like this: typedef MyGilConstView::const_t MyGilReallyConstView; typedef MyGilReallyConstView::value_type MyGilReallyConstPixel; // as there is no const_t typedef in pixel type... MyGilReallyConstView cv = v; MyGilReallyConstPixel cp = p; Is it correct ? Is there a better way to do it ? Regards, Fabien PS: maybe a "typedef value_type pixel_t" inside the view class can be a good thing for readability ?

2 1

Checking library binary compatibility with respect to compile time options
by joel falcou 05 Aug '10

05 Aug '10

I was pondering how to event or at least warn users when they use a .a compiled with a set of define with an application compiled with divergent options (like having different -D that may cause ODR violation). On IRC, I was linked to this page for MSVC 10: http://msdn.microsoft.com/en-us/library/ee956429.aspx That defiens some pragma that exactly do that. However, it's MSVC 10 specific. After a few brainstorming, we ended up with a simple solution to emulate this. The code source is here: http://dl.dropbox.com/u/3819406/lib_check.tar.gz Here is a use case: g++ -c foo.cpp -o foo.o -I/usr/local/include/boost-1_43 -DGOOD_LIB g++ -c main.cpp -o bmain.o -I/usr/local/include/boost-1_43 -DBAD_LIB -I./ g++ -c main.cpp -o gmain.o -I/usr/local/include/boost-1_43 -DGOOD_LIB -I./ Here, we compiel foo with some settings and try to link it with two different setup for main.o The gcc output, showing the divergence in option is detected: g++ bmain.o foo.o -o bmain bmain.o: In function `__static_initialization_and_destruction_0(int, int)': main.cpp:(.text+0x2a): undefined reference to `boost::config::test_library_version_mismatch_with_version_being_2()' collect2: ld returned 1 exit status Of course, when you link the good pair of .o : g++ gmain.o foo.o -o gmain Nothing happens I guess some details need to be hammered out like visibility and such but could this be a valuable addition to boost (liek boost config for example) or have I overengineered something useless ? Regards

4 4

Quasi-random number generators
by Justinas V. Daugmaudis 05 Aug '10

05 Aug '10

Dear fellow boosters, As the time goes on, the soft pencils down date for the Google Summer of Code project is approaching. For this date the development has to cease, only maintenance work and/or doc writing continues. I invite anyone interested into quasi-random number generators to review the work done at http://svn.boost.org/svn/boost/sandbox/SOC/2010/quasi_random/ Steven Watanabe has been a great mentor, providing guidance when it was needed and, more importantly, avoiding the common pitfall of turning into a pointy-haired boss. You rock, Steven! -- Kind regards, Justinas V. Daugmaudis

1 0