- Boost - lists.boost.org

[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

Cache flushing in the constructors
by Sid Sacek 05 Aug '10

05 Aug '10

I've been struggling with these thoughts lately, and am curious how the boost "class" writers deal with it, or if there's any problem at all to begin with. If I want to write a boost class that's going to be compiled for all the supported CPU types, do I have to perform a core-cache flush at the end of my class constructors? I know that there are the "Strong Memory Model" CPU's out there, like the Intel x86 cores, that auto-magically take care of cache-coherency for you, and the "Weak Memory Model" CPU's where the code has to do all of the work for cache-coherency. When developing a boost class that's going to be an object that's used in multi-threaded applications; do these classes use some BOOST utility to performs cache flushes on the newly constructed objects, or am I just thinking about this in the wrong way, which I'm starting to believe is true. I'm new to thinking about these things, and my head hurts! Your views would be appreciated. Thanks, -Sid

5 9

Cannot close ticket #2373
by Christian Henning 04 Aug '10

04 Aug '10

Hi there, it's been a while since I used trac. When I updated ticket #2373 there were no option for closing the ticket. Do I have to login somewhere? My username is chhenning Regards, Christian

2 3

[bcp] Bcp namespace rename causes compile errors on multiple libraries (type_traits, range, spirit, foreach, regex, iostreams) in 1.43
by Cliff Green 04 Aug '10

04 Aug '10

Has bcp namespace renaming been tested against all Boost libraries in 1.43? I'm getting compile errors in (or caused by) the following libraries: type_traits, range, spirit, foreach, regex, iostreams (more details later in this message). The compile errors are from a full bjam build of Boost. I haven't compiled tests or built against my work project code, so I suspect there's more errors in header-only libraries. I'm using g++ 4.1.2 on Linux (although these errors are not compiler specific - I'll also be compiling with VC++ 8.0 at some point). All of these errors are easily fixed, and are "boost" text substitution problems. I was able to get all libraries to build after my changes, but I would rather not use hacked-up source (I prefer to work with the Boost developers and install non-modified Boost source into our Clearcase COTS VOB). However, with these (obvious) compile errors, I'm wondering if the bcp namespace facilities are being tested with all Boost libraries? If not, can I work with John Maddock or someone to set up a test process? Besides doing a full extract / rename and build of the libraries, as many examples and tests as possible should also be compiled to find errors in header-only libraries not brought in to the library source build. Of course it's possible all of the errors I've found have been introduced with new code in 1.43 (which still brings up the need to do a full bcp test before a Boost release), or that I somehow incorrectly used bcp, or there's fixes that haven't been applied to the mainline in SVN. My use case is a perfect fit for the bcp namespace facilities - my work team delivers an SDK (which links to and uses various Boost libraries) to another group which also links to and uses Boost libraries in their own application (everything builds into the same executable). Currently our work team is constrained to using the same Boost version, but we'd like to break this constraint (in particular, for other groups to use our SDK). We use (or will use) enough Boost libraries that bcp on the ones we care about pulls in about 80% of Boost, so I went ahead and ran bcp on all of Boost. Details of the compile failures: -- In type_traits: integral_promotion.hpp, promote.hpp, floating_point_promotion.hpp, header guard probs - original code #ifndef FILE_boost_type_traits_integral_promotion_hpp_INCLUDED #define FILE_boost_type_traits_integral_promotion_hpp_INCLUDED After running bcp with "MyProj_Boost" for the namespace, the header guard is: #ifndef FILE_boost_type_traits_integral_promotion_hpp_INCLUDED #define FILE_MyProj_Boost_type_traits_integral_promotion_hpp_INCLUDED -- In range/config.hpp there's two macros where bcp namespace substitution is incorrectly being applied to the "boost" prefix in boost_range_array: #define BOOST_RANGE_ARRAY_REF() (boost_range_array) #define BOOST_RANGE_ARRAY_REF() (&boost_range_array) Similarly, in range/detail/implementation_help.hpp, the following lines have incorrect substitution: boost_range_silence_warning( boost_range_array ); -- In Phoenix and Wave, there's a bit of namespace substitution problems, where "namespace phoenix" (in multiple files, such as spirit/home/classic/phoenix) is being replaced with "MyProjectphoenix", and in wave/grammars/cpp_intlit_grammer.hpp and cpp_chlit_grammar.hpp there's "namespace phx=phoenix". -- In regex/v4/regex_traits.hpp: BOOST_MPL_HAS_XXX_TRAIT_DEF(boost_extensions_tag) The "boost" prefix in boost_extensions_tag is improperly substituted. -- In foreach.hpp, "boost_foreach_argument_dependent_lookup_hack_value" is not substituted in the enum, but in macros where the enum is used, the substitution is occurring. In iostreams/close.hpp, close_boost_stream on line 143 is being improperly substituted. --- As already mentioned, there's easy changes for each of these. But, is a better answer to make the bcp search and substitution smarter? (I have no idea how easy or hard that would be.) Cliff

3 5