December 2010 - Boost - lists.preview.boost.org

Re: [boost] [SQL-Connectivity] Is Boost interested in CppDB?
by Artyom 15 Dec '10

15 Dec '10

> >Hi, >I will only refer to complain on the slow SOCI release schedule. >So, instead of deciding to join an existing project, which N.B. you have used >with some degree of success, and help >to speed its release process, help with fixing bugs and propose to add features >you are missing, you decide to fork it, tweak it and release it. CppDB is not a fork of SOCI, it is totally different library that does things very differently that does not share a single line of code with SOCI. I admit that I had took many general ideas from SOCI and made them more suitable for my vision how SQL library should look, and this is very logical since SOCI was the best SQL library I used so far (till CppDB was released :-) ). And as you know (and you are as you on soci's mailing list) that I still do my small contributions to SOCI - each time I find some issue I try to fix it, report it and even send a patch. As FOSS project developer and leader I know how valuable it is. Now I'll explain the decision more deeply: ------------------------------------------ I was considering join the SOCI project and bring some improvements, however my vision of how the stuff should work and SOCI's vision was quite different, and the internal structure of the SOCI project and class relationships did bringing new and significant features to SOCI was not as simple as I was thinking. So basically I had two options: 1. Fork SOCI and rewrite it - very bad idea, for several reasons: a. forking is bad! b. it still requires from me rewriting its internals c. I'm still not pleased with imlementation level of SOCI's sqlite3 and mysql backends. 2. Push new things to SOCI fighting to explain my vision of things, missing some of them and finally not getting what I need. 3. Create my own library that provides the vision I need. So I had chousen the 3rd. However I had **another** reason to do this as well. As you probably know I'm developer of CppCMS framework, and I need a good database connectivity solution for my customers, and what is most important I need it to be stable, useable with fast upstream bug fixes, optimized for performance and I need it **now**. SOCI couldn't do this for me, as it is still stuck in version 3.0.0 released in 2008 with no bug fixes. And I can't say to my customers - take a git version of SOCI it is very nice (that 9 hours ago was broken and probably still broken now - I've send a patch to SOCI's list) So beleive me I do like soci, I think it is great project but, it does not suit my and my customers needs. And for the last record, I still mention SOCI as one of the libraries that can be sucessefully used with CppCMS: http://art-blog.no-ip.info/wikipp/en/page/sql_connectivity > >This is not how FOSS works to make a project healthy and sustainale in long >term. Your observable disappointment about > >software here makes me asking, what's next? Boost libraries forked? > >Anyways, I'm just disappointed how much FOSS is ego-driven >where it should mean collaboration. Just pity. > Mateusz, as I explained above it is not about the ego, even thou there are many things I can be proud of. It is about having a solution. Beleive me I prefer spending my time of fixing bugs and providing new features in CppCMS then writing an SQL library. Best Regards and I hope your undersand the resasons I had. Artyom

3 3

Re: [boost] [SQL-Connectivity] Is Boost interested in CppDB?
by Mateusz Loskot 14 Dec '10

14 Dec '10

Hi, I will only refer to complain on the slow SOCI release schedule. So, instead of deciding to join an existing project, which N.B. you have used with some degree of success, and help to speed its release process, help with fixing bugs and propose to add features you are missing, you decide to fork it, tweak it and release it. This is not how FOSS works to make a project healthy and sustainale in long term. Your observable disappointment about software here makes me asking, what's next? Boost libraries forked? Anyways, I'm just disappointed how much FOSS is ego-driven where it should mean collaboration. Just pity. Regards, -- Mateusz Łoskot, http::/mateusz.loskot.net (Sent from my mobile)

1 0

[GIL] locator and cached_location_t
by fabien 14 Dec '10

14 Dec '10

Hi, I like the idea of cached_location, but I have some questions about it. //// a simple usage example: // get a temporary locator from the view const SLocator loc_ref = srcView.xy_at(0,0); // from this locator we can extract a cached_location typename SLocator::cached_location_t LT( loc_ref.cache_location(-1,-1) ); DPixel func( const SLocator& src ) { // now instead of doing this: return src(-1, -1); // we can directly retrieve the pixel // from the locator using this cached location return src[LT]; } I have 2 questions: 1) Why can't we directly get a cached_location from a view (without using a locator) ? We have all informations in the view to build it, isn't it ? typename SLocator::cached_location_t LT( srcView.cache_location(-1,-1) ); 2) Is there a good reason to not allows to get a locator from another locator using cached_location ? DLocator func( const SLocator& src ) { // we can do this return src.xy_at(-1, -1); // return a new locator // we can't do the same thing with cached_location return src.xy_at(LT); //< it can be interesting to do this ! } Same remark to get an x_iterator from a locator: src.x_at(-1, -1); //< we can do this src.x_at(LT); //< we can't do this Best regards, Fabien Castan

3 2

Re: [boost] Boost.Locale (was Re: [SQL-Connectivity] Is Boost, interested in CppDB?)
by Anders Dalvander 14 Dec '10

14 Dec '10

On 14 Dec 2010 10:08, Eric Niebler<eric(a)boostpro.com> wrote: > Please, no. std::string is not an appropriate holder for a UTF-8 string. > It encourages random-access mutation of any byte in a UTF-8 sequence, > pretty much guaranteeing data corruption. And std::wstring is not an appropriate holder for a UTF-16 string. It encourages random-access mutation of any code unit in a UTF-16 sequence, pretty much guaranteeing data corruption. // Anders Dalvander -- WWFSMD?

1 0

boost::tasks::static_pool< boost::tasks::unbounded_fifo > crashes when poolsize > 1
by Joseph Winston 14 Dec '10

14 Dec '10

I've attached a program that reproduces the problem for me. The system this is running on is the following (Yes, I know it is old but I have very little control over the OS and compiler): Distribution: RHEL 4 $ uname -a Linux jwhp8400.houston.lgc.com 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:56:44 EST 2007 x86_64 x86_64 x86_64 GNU/Linux Compiler: g++ 3.4.6 boost: 1.39.0 boost.context: 0.2.0 boost.fiber: 0.5.1 boost.task: svn revision 67209 The code of interest is: void f1() { std::cout << "\t" << "f1" << std::endl; } void f2() { std::cout << "\t" << "f2" << std::endl; } void demo() { typedef boost::tasks::static_pool< boost::tasks::unbounded_fifo > pool_type; pool_type pool(boost::tasks::poolsize(4), boost::tasks::stacksize(1024 * 128)); std::cout << "Starting" << std::endl; boost::tasks::async(boost::tasks::make_task(f1), pool); boost::tasks::async(boost::tasks::make_task(f2), pool); pool.shutdown(); std::cout << "Done" << std::endl; } Whenever poolsize is greater than 1, I sometimes receive the following sigsegv: (gdb) where #0 0x0000002a95d7d8db in boost::fibers::detail::trampoline (vp=0xffffffff96400ac0) at libs/fiber/src/detail/info_base.cpp:25 #1 0x0000003c0203e960 in __correctly_grouped_prefixwc () from /lib64/tls/libc.so.6 #2 0x0000000000000000 in ?? () (gdb) print *self Cannot access memory at address 0xffffffff96400ac0 Am I missing a fundamental concept with the way that boost::tasks::static_pool works or is there something else going on? Thanks

2 1

Re: [boost] pimpl library proposal
by Michael Bailey 14 Dec '10

14 Dec '10

On Dec 3, 2010, at 8:26 PM, Phil Endecott wrote: > which really isn't much different in terms of the amount of typing, > except for the forwarding. Can you show what your BOOST_PIMPL_METHOD > expands to? I can't immediately guess how you manage to not tell it > all the argument and return types. First of all, thanks for your input. I appreciate it. I will post the source below, so as to not clutter the conversation. > Re using the shared_ptr, this mainly gains the safety of otherwise > forgetting to implement the dtor, and has speed and space > disadvantages. I'm not convinced that is really useful, and so I would > decouple it from the concise forwarding feature. I think that the value comes in avoiding the pitfall of forgetting to free the pointer, as per all smart pointer implementations. That said, you're right in pointing out that shared_ptr just adds overhead. I think a preferable method, after taking in your considerations, is to just have the boost::pimpl<> class manage the allocating and freeing directly with new/delete. This does not add any overhead, but still gives the same safety of shared_ptr. You actually bring up an interesting idea. Perhaps the forwarding should be decoupled (which would not be hard at all) and generalized, rather than pushing the user into the pimpl paradigm. The user could easily use the forwarding for pimpl implementations or for something completely different. > Generally, I think that implementing pimpls falls more into the > category of stuff that's best done with some sort of tool, e.g. a > "pimpl wizzard" in your IDE, rather than a library. ---- boost/pimpl.hpp ---- #include <boost/typeof/typeof.hpp> #include <boost/type_traits/function_traits.hpp> #include <boost/preprocessor/repetition/enum_trailing_params.hpp> #include <boost/preprocessor/repetition/enum_shifted_params.hpp> #include <boost/preprocessor/repetition/enum_params.hpp> #include <boost/preprocessor/repetition/enum_shifted.hpp> #include <boost/preprocessor/arithmetic/inc.hpp> namespace boost { template <typename T> class pimpl { public: typedef T* ptr_type; pimpl( ptr_type p = new T() ) : m_impl( p ) {} ~pimpl() { delete m_impl; } protected: T& impl() { return *m_impl; } const T& impl() const { return *m_impl; } private: ptr_type m_impl; }; template <typename T> struct method_traits; #ifndef BOOST_METHOD_TRAITS_LIMIT # define BOOST_METHOD_TRAITS_LIMIT 10 #endif #define BOOST_METHOD_TRAITS(z,n,data) \ template <typename C, typename R \ BOOST_PP_ENUM_TRAILING_PARAMS_Z(z,n,class T) > \ struct method_traits< R(C::*)( BOOST_PP_ENUM_PARAMS_Z(z,n,T) ) data > \ : public function_traits< R( BOOST_PP_ENUM_PARAMS_Z(z,n,T) ) > { \ typedef data C class_type; \ }; BOOST_PP_REPEAT(BOOST_METHOD_TRAITS_LIMIT,BOOST_METHOD_TRAITS,) BOOST_PP_REPEAT(BOOST_METHOD_TRAITS_LIMIT,BOOST_METHOD_TRAITS,const) BOOST_PP_REPEAT(BOOST_METHOD_TRAITS_LIMIT,BOOST_METHOD_TRAITS,volatile) BOOST_PP_REPEAT(BOOST_METHOD_TRAITS_LIMIT,BOOST_METHOD_TRAITS,const volatile) } #define BOOST_PIMPL_CTOR( cls ) \ cls::cls() {} #define BOOST_PIMPL_DEFINE_METHOD_M( z, n, data ) \ BOOST_JOIN(BOOST_JOIN(data::arg,n),_type) BOOST_JOIN(a,n) #define BOOST_PIMPL_METHOD( args, cls, meth, ... ) \ ::boost::method_traits< BOOST_TYPEOF(&cls::meth) >::result_type \ cls::meth( \ BOOST_PP_ENUM_SHIFTED( BOOST_PP_INC(args), \ BOOST_PIMPL_DEFINE_METHOD_M, \ ::boost::method_traits<typeof(&cls::meth)> \ ) \ ) __VA_ARGS__ { \ return impl().meth( \ BOOST_PP_ENUM_SHIFTED_PARAMS(BOOST_PP_INC(args),a) \ ); \ }

3 7

static boost::barrier - do I need a mutex here ?
by Vokuba 14 Dec '10

14 Dec '10

Hi, Just a short question: Do you think I need a mutex for the 'static boost::barrier(nThreads)' lines in the sample code snippet below ? I always thought that static data in a function has to be protected by a mutex. But even with 16 running threads in parallel everything seems to be fine (it's a machine with 8 hardware cores, no HT). Thanks in advance - Hans int nThreads; // initialized later in main() void testing() { static boost::barrier barrier_one(nThreads); // mutex needed for 'local static' ? log("waiting on barrier_one"); barrier_one.wait(); do_complicated_stuff_simulaneously(); log("passed barrier_one"); static boost::barrier barrier_two(nThreads); // mutex needed for 'local static' ? log("waiting on barrier_two"); barrier_two.wait(); do_more_complicated_stuff_simulaneously(); log("passed barrier_two"); }

2 1

wfopen
by Christian Henning 14 Dec '10

14 Dec '10

Hi there, one of the requirements for me to fix before I include io_new to boost is to support opening files with unicode filenames. As far as I can see there is _wfopen on Windows platforms. What's the one for Linux and co? I'm a bit puzzled that no boost lib seems to use _wfopen. I searched all files. Is there something better? Thanks, Christian

7 7

[date_time] Could that be a bug in greg_month.hpp?
by Vladimir Batov 13 Dec '10

13 Dec '10

greg_month.hpp includes files in the following order: #include "boost/date_time/constrained_value.hpp" #include "boost/date_time/date_defs.hpp" #include "boost/shared_ptr.hpp" #include "boost/date_time/compiler_config.hpp" Should not compiler_config.hpp come first? As it is the date_time library fails to compile on Interix (sigh) as <time.h> is included before boost/config/user.hpp is sourced with a few function signatures omitted as a result. Best, V.

1 0

[Documentation] Does Boost-Build support Doxygen documentation for tutorials (rather then quickbook)
by Artyom 13 Dec '10

13 Dec '10

Hello, I would like to know if boost-build supports writing tutorials using Doxygen rather that using HTML or its own "quickbook" tool. At this point I have Boost.Locale documentation written with Markdown and I want to transfer it to other tool. I want to use Doxygen for it as Boost.Locale reference is already documented using Doxygen so converting the tutorials from markdown to Doxygen format seems to me much better idea then using "internal" boost documentation format. Rationale: - Doxygen is more widely available tool then quickbook. - It is independent from boost itself. - It is useful for non-boost project - Documentation generation is much simpler (requires running Doxygen) rather then using complicated tool-chain of boost-build. Thanks, Artyom

5 7

[build]Can't build libboost_unit_test_framework-vc90-mt-gdp-1_44.lib with msvc-9 and stlport
by Joachim Faulhaber 12 Dec '10

12 Dec '10

Hi all, sorry for posting this twice. But on boost-build I have to wait for moderator approval and, well, I'm a little impatient :-/ which is probably normal for little nasty problems like this one: I have built stlport-5.2 and tried to compile and link projects with it using msvc-9. Now the linker wants to see libboost_unit_test_framework-vc90-mt-gdp-1_44.lib instead of libboost_unit_test_framework-vc90-mt-gd-1_44.lib It wants the gd*p* version. So I tried to build it using bjam toolset=msvc-9.0~stlport5.2 --with-test --build-type=complete stage This generated new lib files but not the desired one. Could someone explain what the gd*p* suffix stands for and how I can build this lib-file with bjam. Thanx, Joachim

2 4

[Review] GIL io_new
by Roland Bock 11 Dec '10

11 Dec '10

Hi, here is a short review of GIL new IO (I missed the documentation of the toolbox, which is why I concentrated on IO). > - What is your evaluation of the design? Quite elegant and intuitive. I think it would be nice to add iterator pairs and boost::range as additional devices, though. > - What is your evaluation of the implementation? All the code I've looked at so far looks well organized and well readable. Some remarks: * Why are the following files in the detail folder? io_new/detail/read_and_convert_image.hpp io_new/detail/read_and_convert_view.hpp io_new/detail/read_image.hpp io_new/detail/read_image_info.hpp io_new/detail/read_view.hpp io_new/detail/write_view.hpp They define functions of the public interface like read_image(). There is no need to include them directly, but still, when I want to look at documented functions, it seems weird to go into the detail folder... * There seem to be some remnants from earlier versions. For instance: struct tiff_indexed is defined in io_new/tiff_tags.hpp, but never used anywhere else (or did I miss something?) io_new/detail/typedefs.hpp ends with } // namespace details <-- notice the 's' :-) >- What is your evaluation of the documentation? As stated above, I missed the documentation on the toolbox. The documentation is well readable and easy to understand. There seem to be broken links: * "section Extending GIL::IO with new Formats" links to index.html * "Please see section Supported Image Formats." links to index.html * "sections _Supported_Formats_ for more details." links to / It would be good to have code samples for read_and_convert_image, read_view and read_and_convert_view in the tutorial. The "Using IO" section seems to assume that they are already documented: "As the Tutorial demonstrated there are a few ways to read images." Additionally, it would be great to have a reference section. :-) I stumbled over a few typos and grammatically unusual sentences (IMHO): * s/supoorted/supported/ * "Before we can read or write image one thing." I know what that means in German, but does this make sense in English? * "If the user doesn't know what he is dealing with it can use read_and_convert_image()." s/it/he/ I think it would make much sense to give the text to an English native speaker. > - What is your evaluation of the potential usefulness of the extensions? Very useful! > - Did you try to use the extensions? With what compiler? Did you have any problems? I did not actually build anything. Sorry :-( But I am looking forward to doing so! > - How much effort did you put into your evaluation? A glance? A quick > - reading? In-depth study? About half a day of reading. > - Are you knowledgeable about the problem domain? I have used several other libraries over the last 15 years, but I never delved into the innards of image file formats... > - Do you think the extensions should be accepted as a part of Boost.GIL library? Yes, with a few wishes (see above): - documentation: - typos and grammar - add reference section - add a few more code samples in the tutorial - file structure - move parts of the public interface into the non-detail area - interface: - add support for iterators and ranges Again, I did not evaluate the toolbox part. Thanks writing this extension! Roland

2 2

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

11 Dec '10

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

9 30

[BoostCon 2011] 2nd Call for participation
by Hartmut Kaiser 11 Dec '10

11 Dec '10

Hey all, please find below the updated CfP for BoostCon 2011. Note, we extended the submission deadline. The new submission deadline is January, 10th 2011. ----------------------------------------------------------------- 5TH ANNUAL BOOST CONFERENCE 2011 Aspen CO, USA, May 15 - 20, 2011, www.boostcon.com CALL FOR PARTICIPATION We invite you to submit session proposals to the 5th Annual Boost Conference: BoostCon 2011 (Aspen CO, USA, May 15 - 20, 2011). Traditionally the main face-to-face event for all things Boost (www.boost.org) BoostCon 2011 will present leading speakers from the whole C++ community. From using the Boost libraries to writing and maintaining them, from evangelizing to deploying Boost within your organization, from infrastructure and process to vision and mission, and the new C++ Standard, BoostCon brings together the sessions, the colleagues, and the inspiration to support your work with C++ and Boost in particular for the next year. To reflect the breadth of the Boost community, the conference includes sessions aimed at three constituencies: Boost end-users, hard-core Boost library and tool developers, and academics focusing on research. The program fosters interaction and engagement within and across those groups, with an emphasis on hands-on, participatory sessions. SESSION TOPICS Topics of interest include, but are not restricted to, the following: * General tutorial sessions introducing one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * C++0x and how it changes life for users and library writers * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Software development tools and their application to C++ and or Boost * Other topics likely to be of great interest to Boost users and developers Interactive and collaborative sessions are encouraged, as this is the nature of both the on-line Boost community and the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. SESSION FORMATS Presentations ------------- Presentations focus on a practitioner's ideas and experience with anything relevant to Boost and Boost users. Panels ------------- Panels feature three or four people presenting their ideas and experiences relating to Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials ------------- Tutorials are sessions at which instructors teach conference participants specific Boost-relevant skills. Workshops ------------- Workshops provide an active arena for advancements in Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner Presentations ------------- These were introduced at BoostCon 2008, and were a great success. They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors Presentations ------------- We actively encourage tool vendors and ISP's to submit proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. SUBMITTING A PROPOSAL Standard Sessions are 90 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 90 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10-20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). SUBMISSION DETAILS All submissions have to be done through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=boostcon2011. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the BoostCon website and will be available to attendees. For general information on the BoostCon 2011 paper submission or the scope of technical papers solicited, please refer to the conference website at www.boostcon.com. For any other questions about the submission process or paper format, please contact the Program Committee at boostcon2011(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to BoostCon. IMPORTANT DATES New proposal submissions due: January 10th, 2011. Proposals decisions sent (tentative program): February 17th, 2011. Fully scheduled program available: February 25th, 2011. Session materials due: April 15th, 2011. Hartmut Kaiser: hartmut.kaiser(a)gmail.com (Program Committee Chair) David Abrahams: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

GIL.IO documentation
by Christian Henning 11 Dec '10

11 Dec '10

Hi all, I have uploaded the docs here: http://gil-contributions.googlecode.com/files/io_new_docs.zip Thank you, Nathan! Regards, Christian

2 1

Sandbox and externals
by Domagoj Saric 11 Dec '10

11 Dec '10

Hi, could someone please tell me whether the use of SVN externals is allowed in the Boost Sandbox? For example, I'm working on two projects/libraries and have a header that is a collection of various platform specifics that I'd like to use in both libraries but would also like to not have to manually update two copies of it (rather have one of the libraries use it as a SVN external)... I was unable to find this information at https://svn.boost.org/trac/boost/wiki/BoostSandbox... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

3 2

[Iterator] transform_iterator should use result_of
by Michel MORIN 11 Dec '10

11 Dec '10

Documents of Boost.Iterator say that transform_iterator uses result_of to compute "reference" nested-type. But, in Boost 1.45, transform_iterator does not use result_of; It uses result_type. This bug is fixed in trunk. See the following ticket: [iterator] transform_iterator should use boost::result_of to determine functor result type https://svn.boost.org/trac/boost/ticket/1427 Considering the fix was merged into trunk six months ago, it seems low-risk to merged into release. Does anyone merge this into release? Regards, Michel

2 5

[program_options] A couple of proposed changes (patches included)
by jcwilson.boost＠nym.hush.com 10 Dec '10

10 Dec '10

I've been making use of this library for the past week and it's been very helpful. I've found a couple of ways to improve it for my use and wanted to see if it'd be worth sending the changes upstream, too. 1) Allow default value specification at option query time. This would override the default value (if any) defined in the options_description for this particular query. buffer_size = options["buffer_size"].as<unsigned int>(1024); 2) Add the option name as a parameter to the "notifier" function signature. This became necessary when I started using the wildcard(*) functionality. How else am I to know what the matched config variable was? I just replaced boost::function1 with boost::function2. I imagine this one would need a bit more work since it would break any current users. I could take a stab at it, but if it seems useful, maybe someone more familiar with the library would rather take care of it instead. I'm pretty new to Boost development, so I'm not sure what the next steps would be. The attached patches are against the boost_1_45_0 release. -Josh

2 1

serialization crash with polymorphic classes, shared_ptr and std::map
by Allan Johns 10 Dec '10

10 Dec '10

Hi. I have hit a problem with boost serialization (occurs in all versions of boost - 1.37.0 .. 1.45.0). Summary: I have virtual base class A, derived B, and an AMap class (also A-derived) which holds shared_ptr<A>'s. I get different data written out depending on whether I serialise out an AMap stored in a shared_ptr<A> or a shared_ptr<const A>, and in one case (non-const) I get a segfault on load. The following code illustrates the problem in entirety and is the simplest case I found which generates the problem (I tried several variations - saving the map directly, removing A as AMap's base class etc, etc, to no avail). You should be able to cut'n'paste and compile into a single executable. I am testing on linux + centOS. ############################################################################################################## lib.h #ifndef __TESTLIB__H_ #define __TESTLIB__H_ #include <map> #include <boost/serialization/nvp.hpp> #include <boost/serialization/shared_ptr.hpp> #include <boost/serialization/base_object.hpp> class A { public: A(){} virtual ~A(){} template<class Archive> void serialize(Archive & ar, const unsigned int version){} }; typedef boost::shared_ptr<A> a_ptr; typedef boost::shared_ptr<const A> c_a_ptr; typedef std::map<int, a_ptr> a_map; class B : public A{ public: B(){} virtual ~B(){} template<class Archive> void serialize(Archive & ar, const unsigned int version){ ar & boost::serialization::make_nvp("base_class", boost::serialization::base_object<A>(*this)); } }; class AMap : public A { public: AMap(){} virtual ~AMap(){} template<class Archive> void serialize(Archive & ar, const unsigned int version){ ar & boost::serialization::make_nvp("base_class_a", boost::serialization::base_object<A>(*this)); ar & boost::serialization::make_nvp("map", m_map); } a_map m_map; }; #endif ############################################################################################################## lib.cpp #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> #include "lib.h" #include <boost/serialization/map.hpp> #include <boost/serialization/export.hpp> BOOST_CLASS_EXPORT(A); BOOST_CLASS_EXPORT(B); BOOST_CLASS_EXPORT(AMap); ############################################################################################################## main.cpp #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/serialization/map.hpp> #include <fstream> #include <iostream> #include "lib.h" const char* fname="/tmp/testlib.xml"; void save(*a_ptr* a) // NOTE!!! change me to c_a_ptr to get a segfault on load { std::ofstream fs(fname); boost::archive::xml_oarchive ar(fs); ar & boost::serialization::make_nvp("root", a); } int main(int argc, char** argv) { { std::cout << "saving..." << std::endl; AMap* pam = new AMap(); a_ptr a(new B()); pam->m_map.insert(a_map::value_type(1, a)); a_ptr am(pam); save(am); } { std::cout << "loading..." << std::endl; a_ptr am; std::ifstream fs(fname); boost::archive::xml_iarchive ar(fs); ar & boost::serialization::make_nvp("root", am); assert(am); } return 0; } Note that changing main's save() arg to a shared_ptr<const A> changes the data written out. Here is an example xml archive resulting from saving via a non-const shared_ptr (the case that WORKS on load): <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="5"> <root class_id="0" tracking_level="0" version="1"> <px class_id="2" class_name="AMap" tracking_level="1" version="0" object_id="_0"> <base_class_a class_id="1" tracking_level="1" version="0" object_id="_1"></base_class_a> <base_class_map class_id="3" tracking_level="0" version="0"> <count>1</count> <item_version>0</item_version> <item class_id="4" tracking_level="0" version="0"> <first>1</first> <second> <px class_id="5" class_name="B" tracking_level="1" version="0" object_id="_2"> <base_class object_id="_3"></base_class> </px> </second> </item> </base_class_map> </px> </root> </boost_serialization> Here is the same data but written out via the CONST shared_ptr (the case that FAILS on load): <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="5"> <root class_id="0" tracking_level="0" version="1"> <px class_id="2" class_name="AMap" tracking_level="1" version="0" object_id="_0"> <base_class_a class_id="1" tracking_level="1" version="0" object_id="_1"></base_class_a> <base_class_map class_id="3" tracking_level="0" version="0"> <count>1</count> <item_version>0</item_version> <item class_id="4" tracking_level="0" version="0"> <first>1</first> <second *class_id="5" tracking_level="0" version="1"*> <px class_id="6" class_name="B" tracking_level="1" version="0" object_id="_2"> <base_class object_id="_3"></base_class> </px> </second> </item> </base_class_map> </px> </root> </boost_serialization> Note the difference, which I've put in bold. If somebody could explain what is happening here I'd be very grateful. Obviously something is going on with the object tracking... and what I find most strange is that the data that loads correctly actually looks incorrect (<second> doesn't have tracking-level=0, whereas tracking-level=0 wherever else there's a shared_ptr, as I'd expect). Note: I have tested using the xml and binary archives... xml segfaults, binary throws a stream_error. Thanks in advance Allan

2 3

is there a bug in ini_parser.hpp?
by Bernd Prager 10 Dec '10

10 Dec '10

Hi, Following program does not pertain a proper "other" value: #include <iostream> #include <boost/property_tree/ptree.hpp> #include <boost/property_tree/ini_parser.hpp> using namespace std; using boost::property_tree::ptree; int main() { ptree pt; pt.put("debug.filename", "tst.log"); pt.put("other", "tst"); cout << "debug.filename: " << pt.get("debug.filename", "filename not found") << endl << "other: " << pt.get("other", "other not found") << endl; boost::property_tree::write_ini("tst.ini", pt); boost::property_tree::read_ini("tst.ini", pt); cout << "debug.filename: " << pt.get("debug.filename", "filename not found") << endl << "other: " << pt.get("other", "other not found") << endl; return EXIT_SUCCESS; } The ini file contains: [debug] filename=tst.log other=tst Do I do anything wrong or is that a bug? Thanks for help or suggestions, -- Bernd

1 0

Formal Review of IO and Toolbox extensions to Boost.GIL extended until December 17th, 2010
by Mateusz Loskot 09 Dec '10

09 Dec '10

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 0

Fwd: Formal Review of IO and Toolbox extensions to Boost.GIL starts TOMORROW
by Christian Henning 09 Dec '10

09 Dec '10

Hi Zach, > >>> There are some specific problems with the tests, though. For >>> instance, png_read_test.cpp takes an image file, reads it, then writes >>> it to a temporary file, then re-reads it from the temp file, and >>> compares the two read-in images for equality. This strikes me as a >>> bad test. It is quite possible to read an image, get the wrong >>> results, then write those wrong results to disk, re-read them, and >>> then have the re-read results compare equal to the original read >>> results. There may be other tests with a similar organization; I did >>> not check. >> >> This would assume that both png reader and writer have some bugs in >> common. I consider that less probable. > > No. > > Consider an image I that is solid red on the left half, and 0% alpha > on the right half, with a blue PNG background chunk. When loaded, it > should produce an image that is red on the left half, and blue on the > right half. > > Your PNG reading code ignores the background-color chunk (not a big > deal, as so does all other png reading code I've ever seen). I'll add this as an action item to my todo list. Although, with a lower priority. > > This means that when you read I, you get an image that is red on the > left, and transparent on the right. If you write that image to disk, > you have written an image that contains the wrong data (i.e. that is > different from the source image file). If you re-read it, it will > compare as equal to the initial read of the original image. You have > a correct writer, but an incorrect reader, and your test cannot detect > this. Yes, I agree not ideal. I have to think about what I can to better. > >>>> - Did you try to use the extensions? With what compiler? Did you have any problems? >>> >>> I only evaluated the PNG loading code, in an existing library that >>> already uses (a modified) GIL for image file loading. My library's >>> modified copy of GIL has numerous fixes to the PNG loading code. When >>> I substituted gil.io_new, I found that several files were again >>> unreadable. >> >> I just did a quick test with space_elevator.png you mention below. >> May it be that you forgot to set the BOOST_GIL_IO_ENABLE_GRAY_ALPHA >> symbol? The following code works just fine: >> >> #define BOOST_GIL_IO_ENABLE_GRAY_ALPHA 1 > > Yes, that was what I was missing. If only I had had the docs built, I > could have figured that out for myself. All the images in the > application now load correctly. > > What is the rationale for needing to define this? Why can't it be > always-on, or opt-out, instead of opt-in? gray_alpha lives in the toolbox and though it's not part of gil, yet. I'm just covering the case when a user only downloads io_new and not the toolbox. This compiler symbol should go away when io_new and toolbox are added to boost. Would you mind changing your vote? Assuming you changed your opinion. Regards, Christian

1 0

Workaround for compiler bugs
by Edward Diener 09 Dec '10

09 Dec '10

In attempting to write a library for Boost I have sometimes run into a given compiler's bug which prevents my work succeeding for a given compiler without a workaround. While I can, and have, gone to a compiler's NG or online forum to report the bug, and hopefully find a workaround, given the nature and difficulty of template metaprogramming there have often been no adequate responses. Of course I have worked to find a workaround on my own, but sometimes I can not find the "magic incantation" <g> to do so, while in other cases I can. Is this a valid NG for bringing such a compiler bug to light so that other Boost developers are not only aware of the bug but might have a solution, if they have not already developed one for themselevs ? Sometimes the bug peripherally involves some Boost library but often the bug just involves some sort of template, or template metaprogramming, construct which a particular compiler just can not handle correctly. In all cases the bug would have to do with some Boost-like library I am working on, preferably in the sandbox, else I would not feel justified in bringing up this issue in a Boost developer NG.

6 13

[gil io_new review] Reading images from in-memory sources
by Phil Endecott 09 Dec '10

09 Dec '10

> review of Christian Henning's extensions to the Boost Generic Image Library > starts on December 1st and lasts until December 10th, 2010. I've been looking at how to read images from in-memory data. For example, I have various places where I mmap() something that contains encoded images (e.g. a large map made up from many tiles in a single file). I can also imagine retrieving an encoded image from a database, for example. According to io.qbk: [h2 Reading And Writing In-Memory Buffers] Reading and writing in-mempory buffers are supported as well. See as follows: `` // 1. Read an image. ifstream in( "test.tif", ios::binary ); rgb8_image_t img; read_image( in, img, tiff_tag() ); // 2. Write image to in-memory buffer. stringstream out_buffer( ios_base::out | ios_base::binary ); rgb8_image_t src; write_view( out_buffer, view( src ), tiff_tag() ); // 3. Copy in-memory buffer to another. stringstream in_buffer( ios_base::in | ios_base::binary ); in_buffer << out_buffer.rdbuf(); // 4. Read in-memory buffer to gil image rgb8_image_t dst; read_image( in_buffer, dst, tag_t() ); In the cases that I described above, using a stringstream would require that all of the data is copied at least once. I guess that if I knew more about how streambufs work I would know how to avoid that. Can anyone help me to implement this: void read_mem_jpeg( some_gil_image_tpye& dest, const char* jpeg_mem_begin, const char* jpeg_mem_end) { ... } in a way that doesn't copy all of the encoded data? Looking at formats/jpeg/read.hpp, it seems that irrespective of that the data will be copied again (into 'buffer') before being read by libjpeg. On the subject of copying, while reading PNGs it looks like the data is always copied into a temporary buffer in read_rows<>() even when no format conversion is needed (or is there some specialisation that I have missed?). And when reading JPEGs, it seems to always read single lines, yet libjeg advises that you should get at least rec_outbuf_height lines on each call to avoid extra copying within the library. Regards, Phil.

6 16

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

09 Dec '10

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 0