December 2010 - Boost - lists.boost.org

reducing file size after I am done with an mmap
by Clark Sims 18 Dec '10

18 Dec '10

Is there some way to downsize a file? More specifically, if I open a filebuff: f( "foo.txt",std::ios_base::in|std::ios_base::out|std::ios_base::trunc|std::ios_base::binary); then space forward, write a character, f.pubseekoff( 10000, std::ios_base::beg); write a character, f.sputc(0); f.pubsync(); Is there someway for me to "unwrite the character", and reduce the file size? I am in a situation where I am allocating big files for mmap's, and then when I am done, I have a lot of unused space which I would like to release.

2 1

Formal Review of IO and Toolbox extensions to Boost.GIL ends TOMORROW
by Mateusz Loskot 18 Dec '10

18 Dec '10

Folks, According to the extended schedule and to my UTC-based watch, we have literally two days to complete the review. Best regards, Mateusz On 09/12/10 22:26, Mateusz Loskot wrote: > Dear All, > > Today, I announced we are close to the end of the review: > > http://lists.boost.org/boost-announce/2010/12/0275.php > > Later on, Christian asked for extension of the review. > The Review Wizards agreed and suggested to extend the review until > > Friday, December 17th, 2010 > > So, I'm happy to announce that the new cut-off date of the reviews > submission is December 17th. Let's say Midnight, UTC Time. > > Thanks to all reviewers who submitted their comments, to the Review > Wizards for the extension and we are hoping to receive more > feedback from the reviewers. > > > Mateusz > Review Manager for the proposed Boost.GIL.IO and > Boost.GIL.Toolbox extensions > > > On 09/12/10 11:37, Mateusz Loskot wrote: >> Dear All, >> >> The formal review of the IO and Toolbox extensions terminates >> tomorrow. I'd like to set the cut-off time at Midnight on Saturday, >> 11 December 2010, UTC Time >> >> > (http://www.timeanddate.com/worldclock/fixedtime.html?day=11&month=12&year=2…) >> >> >> I think we have been doing well and received decent amount of >> feedback. However, anyone feels there is a need for extension, >> please let me know as soon as possible, so I will have time to >> negotiate it with the Review Wizards. >> >> Mateusz Review Manager for the proposed Boost.GIL.IO and >> Boost.GIL.Toolbox extensions >> >> >> On 30/11/10 18:01, Mateusz Loskot wrote: >>> Dear All, >>> >>> According to the Boost Formal Review Schedule [1], review of >>> Christian Henning's extensions to the Boost Generic Image Library >>> (Boost.GIL, [2]), it is: * Boost.GIL.IO * Boost.GIL.Toolbox starts >>> on December 1st and lasts until December 10th, 2010. >>> >>> [1] http://www.boost.org/community/review_schedule.html [2] >>> http://www.boost.org/doc/libs/release/libs/gil/doc/index.html >>> >>> =========== What is it? =========== >>> >>> The Boost.GIL.IO extension provides an easy to use interface for >>> reading and writing various image formats. It also includes a >>> framework for adding new formats. The Boost.GIL.IO is indent to >>> replace the current IO extension which is part of Boost for >>> several years now. >>> >>> Features: >>> >>> * A unified way to read and write image encoded in BMP, JPEG, PNG, >>> PNM, and TIFF formats. The capabilities to read and write in >>> various formats have improved dramatically. >>> >>> * Image data can be provided via standard file or string streams >>> >>> The Boost.GIL.Toolbox provides new color spaces and other small >>> code to ease programming with Boost.GIL. >>> >>> Features: >>> >>> * Implementation of color spaces: Gray_Alpha, HSL, HSV, LAB, and >>> XYZ * Utilities to support dynamic image workflows and color >>> conversions. * Collection of metafunctions to determine alignment, >>> similarity and homogeneity at pixel level. >>> >>> The Boost.GIL as well as the proposed extensions are provided in >>> form of a headers-only library Although, some image formats come >>> with their format dependency, it is corresponding third-party >>> libraries: >>> >>> JPEG - libjpeg PNG - libpng TIFF - libtiff >>> >>> =================== Getting the library =================== >>> >>> The latest version of both extensions can be downloaded as Zip >>> package: >>> >>> http://gil-contributions.googlecode.com/files/boost_review.zip >>> >>> or directly from the Subversion repository: >>> >>> http://code.google.com/p/gil-contributions/source/browse/trunk/gil_2/ >>> >>> >>> >>> > and the docs can built as usual with bjam and quickbook tools >>> from within libs/gil/io_new/doc directory >>> >>> The libs/gil/io_new/test/readme.txt provides a step by step guide >>> to configuring, building and running the unit tests. >>> >>> The boost_review.zip is about 20MB due to its extensive collection >>> of test images. They are part of the test suite to make sure that >>> different variations of each image format is read and written >>> correctly. >>> >>> Please, be aware no guarantee can be given that all formats in >>> their all variants are completely supported. >>> >>> ================ Writing a review ================ >>> >>> If you feel the new IO and Toolbox are interesting extensions to >>> the Boost.GIL library, then please submit your review to the >>> developer list (preferably), or to the review manager (mateusz at >>> loskot dot _n_e_t_) >>> >>> Here are some questions you might want to answer in your review: >>> >>> - What is your evaluation of the design? - What is your evaluation >>> of the implementation? - What is your evaluation of the >>> documentation? - What is your evaluation of the potential >>> usefulness of the extensions? - Did you try to use the extensions? >>> With what compiler? Did you have any problems? - How much effort >>> did you put into your evaluation? A glance? A quick - reading? >>> In-depth study? - Are you knowledgeable about the problem domain? >>> >>> And finally, every review should answer this question: >>> >>> - Do you think the extensions should be accepted as a part of >>> Boost.GIL library? >>> >>> Be sure to say this explicitly so that your other comments don't >>> obscure your overall opinion. >>> >>> Mateusz Review Manager for the proposed Boost.GIL.IO and >>> Boost.GIL.Toolbox extensions >> >> > > -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

1 1

Re: [boost] [GIL] locator and cached_location_t
by fabien.castan＠free.fr 18 Dec '10

18 Dec '10

Thanks for your answer. > To answer both of your questions, I don't see any particular obstacle to adding those APIs to image_view, > but we didn't add them because that will be a lot of methods for something that is advanced and not frequently used (cached_location). > Not to mention it doesn't make sense to use for all image views, but only "memory-based" ones, as opposed to virtual ones, for example. Ok for my first question. I understand the idea of not polluting the "image_view" class with something specific that can not be used in all cases. But what about the second question: adding 2 functions inside the locator class. The idea is to allows to get a locator or an iterator from a locator using cached_location ? Currently we have an operator[] inside the locator class which takes a cached_location_t and returns a pixel. It seems interesting to add x_at(const cached_location_t&) and xy_at(const cached_location_t&) versions which returns respectively iterator or locator, isn't it ?

3 2

[Config] Macro for C++0x range-based for
by Michel MORIN 18 Dec '10

18 Dec '10

Hi, C++0x range-based for is available on GCC 4.6 (Pre-release). There is no BOOST_NO_RANGE_BASED_FOR macro, so I made a patch against trunk and made a test case. Please see attached files. Is it reasonable to add this macro? Regards, Michel

5 10

boost-build for ps3?
by Emil Dotchevski 18 Dec '10

18 Dec '10

Has anyone got the MinGW cross-compiling of PS3 code working with boost-build? Thanks, Emil

1 0

Solaris, iterator_traits, wrong number of template arguments
by Jeremy C. Reed 17 Dec '10

17 Dec '10

I upgraded from 1.41.0 to 1.45.0 and started getting the following: /udir/jreed/pkg/include/boost/array.hpp:94: error: wrong number of template arguments (2, should be 1) I looked at config.log output from the /boost_1_45_0/libs/config and it showed: "./../../libs/config/test/boost_no_std_iter_traits.ipp", line 34: Error: iterator_traits is not a member of std. So BOOST_NO_STD_ITERATOR_TRAITS was defined in my user.hpp. This is on Solaris 10 with g++ (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) Anyone using boost with gcc 3.4.x on Solaris 10? I know the gcc is old. My workaround is to comment out the BOOST_NO_STD_ITERATOR_TRAITS macro in my /udir/jreed/pkg/include/boost/config/user.hpp. Anyone have a workaround for this? Jeremy C. Reed echo 'EhZ[h ^jjf0%%h[[Zc[Z_W$d[j%Xeeai%ZW[ced#]dk#f[d]k_d%' | \ tr '#-~' '\-.-{'

1 0

Provisional Boost.Generic and Boost.Auto_Function (concepts without concepts)
by Matt Calabrese 16 Dec '10

16 Dec '10

For those of you who were following the Boost.Auto_Function call for interest, this thread sort of spawned off of that. Boost.Generic (not a part of boost) is a C++0x library intended to replace BCCL as a way of specifying concepts and concept maps, and, when used in conjunction with Boost.Auto_Function (also not a part of boost, though it's in the sandbox and has online documentation at http://www.rivorus.com/auto_function ) as a way to get concept-based function template overloading. For anyone who followed the original thread, I'm happy to say that I'm just a few days away from being able to fully and automatically recognize standard library and user-defined iterator types, though I've had a [not so] surprising amount of compiler crashes and workarounds along the way. For an example of how concept mapping will look (revised from earlier versions as I've made much more progress with implementation), see http://codepaste.net/n47ocu And for an example of how this will be used by Boost.Auto_Function, see http://codepaste.net/1faj21 . At this point I'm not trying to do the equivalent of what would have been C++0x "scoped" concept maps, though at some point I may try to support them, but it would imply calling algorithms through macro invocations (yuck). During development, I've come to some realizations that I'd like discussion about here, mostly concerning concept map lookup and ODR. Essentially, the way the library works is by assembling a compile-time list of concept maps piecewise throughout a translation unit for a given type or combination of types via a clever use of overload resolution that I talked about briefly in the BOOST_AUTO_FUNCTION call for interest thread. Underneath the hood, there is something that resembles tag-dispatching, however it is all done entirely within decltype. In short, the way the concept-based overloading works is that the macro used for specifying a function that dispatches based on concept maps generates something along the lines of this. The "magic" shown in comments is something I'm able to already do, as talked about in the other thread: ///// template< class It > void foo( It&& it ) { typedef decltype ( function_returning_type_with_a_nested_static_function ( /* magical way to get a type that inherits from all concept tags */() ) ) fun_holder; fun_holder::impl( std::forward< It >( it ) ); } ///// Now, this is great, but I'm wondering what this means with respect to ODR. If the user is working with the algorithm "correctly", the typedef will resolve to the same type regardless of the translation unit, however, the "path" taken when inside of the decltype via overload resolution may vary depending on the translation unit when different, orthogonal concept maps are specified for the same type in one translation unit but not in the other (or if concept maps are specified in a different order I.E. via different #include orders). My question is, does this violate ODR in any meaningful sense? Since technically the typedefs should resolve to the same type in each translation unit, not including user error, is there a problem? The next question is much more devious and I have a feeling implies a blatant violation of ODR. Consider the following code, assuming "foo" does concept-based dispatching in a way similar to the above: ///// foo( 5 ); /* a concept map that specifies "int" models a concept that may affect dispatching */ foo( 5 ); ///// With the definition of foo given above, what would effectively happen is that the second call to "foo" will not be able to dispatch based on the new concept map! The reason why is because both calls will use foo< int >, and since it was already instantiated once for int, that first definition will be used. Note that this problem technically even exists with traditional tag dispatch, though I wonder if there may be some sort of solution that is standard. A hackish workaround I've come up for this is if we change the defintion of "foo" to be generated as the following: ///// // Uses C++0x function template default arguments template< class It, class TagType = /* magical way to get a type that inherits from all concept tags */ > void foo( It&& it ) { typedef decltype ( function_returning_type_with_a_nested_static_function ( TagType() ) ) fun_holder; fun_holder::impl( std::forward< It >( it ) ); } ///// Going back to the example calling code, "foo" will now correctly dispatch differently if the intermediate concept map should affect concept-based dispatch. This might seem like a perfect solution, but now we are pretty much definitely violating ODR, since a function that calls "foo" in different translation units will very possibly see different TagTypes even though the overload resolution internal to "foo" would resolve the same. Am I clear on this problem and why I believe my solution only works if you don't consider ODR violations? The final solution that I believe sidesteps all ODR violations would be if I force calls to such algorithms to be done via a macro. The macro would internally do the trick that is currently shown inside of the definition of "foo", only it would now do it at the caller's scope. If I decide to eventually try to support scoped concept maps I would be forced down such a route anyway, so my question ends up being at what point does the library cease being a convenience? Is it worth supporting concepts as accurately as possible, including the above desired behavior, if the calling code has to become: ///// BOOST_GENERIC_CALL( (foo)( 5 ) ); /* a concept map that specifies "int" models a concept that may affect dispatching */ BOOST_GENERIC_CALL( (foo)( 5 ) ); ///// or, if you want a more practical example: ///// BOOST_GENERIC_CALL( (advance)( vector_.begin(), 5 ) ); ///// This is a problem that I would prefer to be resolved sooner rather than later since I want to reduce code rewrites. Any feedback is greatly appreciated, especially if you have insight into these problems. I'll try to get Boost.Generic in its current, very limited form up on the sandbox and the docs online as soon as possible. -- -Matt Calabrese

6 32

compilation error in tokenizer
by Sorin Manolache 16 Dec '10

16 Dec '10

Hello, This code does not compile: #include <boost/tokenizer.hpp> #include <iostream> const char test_string[] = "|abc|def||g|u|||"; int main(int argc, char *argv[]) { typedef boost::tokenizer<boost::char_separator<char>, const char *, const char *> tokenizer_t; const boost::char_separator<char> sep("|"); const tokenizer_t tok(test_string, test_string + sizeof(test_string) - 1, sep); tokenizer_t::const_iterator i = tok.begin(); return 0; } The compilation error is: In file included from /usr/include/boost/token_iterator.hpp:24, from /usr/include/boost/tokenizer.hpp:20, from tokenizer.cc:1: /usr/include/boost/token_functions.hpp: In static member function ‘static void boost::tokenizer_detail::assign_or_plus_equal<IteratorTag>::assign(Iterator, Iterator, Token&) [with Iterator = const char*, Token = const char*, IteratorTag = std::random_access_iterator_tag]’: /usr/include/boost/token_functions.hpp:458: instantiated from ‘bool boost::char_separator<Char, Traits>::operator()(InputIterator&, InputIterator, Token&) [with InputIterator = const char*, Token = const char*, Char = char, Traits = std::char_traits<char>]’ /usr/include/boost/token_iterator.hpp:70: instantiated from ‘void boost::token_iterator<TokenizerFunc, Iterator, Type>::initialize() [with TokenizerFunc = boost::char_separator<char, std::char_traits<char> >, Iterator = const char*, Type = const char*]’ /usr/include/boost/token_iterator.hpp:77: instantiated from ‘boost::token_iterator<TokenizerFunc, Iterator, Type>::token_iterator(TokenizerFunc, Iterator, Iterator) [with TokenizerFunc = boost::char_separator<char, std::char_traits<char> >, Iterator = const char*, Type = const char*]’ /usr/include/boost/tokenizer.hpp:86: instantiated from ‘typename boost::token_iterator_generator<TokenizerFunc, Iterator, Type>::type boost::tokenizer<TokenizerFunc, Iterator, Type>::begin() const [with TokenizerFunc = boost::char_separator<char, std::char_traits<char> >, Iterator = const char*, Type = const char*]’ tokenizer.cc:12: instantiated from here /usr/include/boost/token_functions.hpp:227: error: request for member ‘assign’ in ‘t’, which is of non-class type ‘const char*’ The compiler is g++ 4.4.5. The version of boost is 1.42 but the token_functions.hpp, token_iterator.hpp, and tokenizer.hpp files are almost identical in 1.45. I've traced the error to the fact that get_iterator_category<const char *>::iterator_category is std::random_access_iterator_tag but the assign_or_plus_equal<IteratorTag> is specialized for std::input_iterator_tag only and not for std::random_access_iterator_tag. Sorin

1 0

[icl] Permission to merge to release branch
by Joachim Faulhaber 16 Dec '10

16 Dec '10

Hi, Interval Containers [Boost.Icl] are release ready now. It passes the regression tests on boost/trunk, is warning free, has updated html-docs etc. I have updated libs/libraries.htm, maintainers.txt and merged the latest version from trunk to my branches/release/-workspace (which was no fun ... slowly and error prone). I have tested the merge result locally. Everything works. Do I have the permission to commit my sources to the release branch now? Best regards, Joachim

6 8

boost::python: to-python conversion on polymorphic class
by Allan Johns 15 Dec '10

15 Dec '10

Hi, Is it possible to register to-python converters for polymorphic types held in shared_ptr? This does not seem to work for me. I have a virtual base class Object, and derived classes TypedAttribute<T> (with method 'value()' that returns a simple type - float, int etc). My boost.python registration code looks like so: template<typename Attrib> struct typed_attrib_topython { static PyObject* convert(const Attrib& a) { return bp::incref(bp::object(a.value()).ptr()); } }; template<typename T> struct TypedAttribBind { typedef TypedAttribute<T> attrib_t; TypedAttribBind() { boost::python::to_python_converter<attrib_t, typed_attrib_topython<attrib_t> >(); } }; However this doesn't work. I have other bound functions that return a boost::python::object(boost::shared_ptr<Object>), but these do not get converted. Am I misunderstanding to-python conversion? Should I expect this to work on polymorphic types? thanks in advance, Allan

2 6