January 2011 - Boost - lists.boost.org

[string] --> [text] ?
by Gregory Crosswhite 28 Jan '11

28 Jan '11

Hey everyone, Since there has been a lot of talk about what the name of a new immutable string class should be, may I toss the name "boost::text" into the ring? The advantage of this name is that it explicitly conveys what it is meant for: working with human-readable text encoded in some implementation-specific form. The name "string" would then continue to have its current interpretation as a string of contiguous 8-bit chars. It has also been suggested that different classes be created for different UTF encodings. I propose that boost::text have the internal encoding be an implementation (and potentially platform-specific) detail. Since at the end of a serious of manipulations with the rope-like data structure one will have to do a final transformation to convert the text into a string of bytes anyway, that provides a natural point at which the desired encoding of the string of bytes can be specified. That is, given a boost::text object "t", one could convert it into a UTF-8 string by calling "t.utf8_c_str()", a UTF-16 string by calling "t.utf16_c_str()", and so on, depending on what the underlying API is expecting. Some of these calls might require recoding the text to a different encoding, so the internal encoding of boost::text could be optimized to whatever is most likely to be needed on that platform so that it is least likely to need recoding. Alternatively, the encoding could be specified as a parameter to the constructor and be carried around as a runtime parameter since nobody needs to know what it is until the final encoding of the string. Thoughts? Cheers, Greg

4 3

[Review][GIL] Boost.GIL IO and Toolbox extensions have been ACCEPTED into Boost
by Mateusz Loskot 27 Jan '11

27 Jan '11

Dear All, The formal review of IO and Toolbox extensions for Boost.GIL [1] ended on December 17th, 2010 [2] The review subject was not a standalone library but a part of whole - an extension to existing Boost.GIL. The review result: ACCEPTED Number of received discussion and feedback posts is ~140. I consider most of them in-topic, significant and also insightful. Reviewers pointed issues already known from previous discussions on the mailing list as well as new topics regarding the design and implementation of the extensions. Also, issues related to the library itself (Boost.GIL) were addressed. Some of them could be considered ideas for future works and improvements. It is remarkable, most (if not all) of the discussions were focused on the IO extension. None of the submitted reviews include comments to the Toolbox extension. Formally, the review concluded with 1 NO and 7 YES votes. Some of the YES votes are considered as conditional and number of changes were requested by the reviewers. The following changes should be addressed before the extensions appear in the Boost mainstream: 1. Documentation is adequate, but requires clean-up and fixing of lots of typos. 2. Additional tests are added to exercise currently untested error cases that result in a longjmp should be added. They should pass on all platforms officially supported by Boost. 3. Make sure the test images are license-free. If the license status is unknown, change them to other license-free images. 4. The requirements for adding new file formats / backends to be made more explicit. This means defining concept for a file format reader/writer, etc. and adding new file formats would constitute providing models for these concepts. 5. Support for reading images whose file format is unknown at compile time. That involves the ability to register file formats / backends, associate them with given extensions and then call the appropriate reader based on the extension of the file name. 6. Support for different backends for the same image formats. It appears that this can be done simply the same way a file format can be extended, i.e. have "png_libpng" and "png_lodepng" tags. 7. Support for efficient reading/writing of parts of images that are too large to fit in memory. There are two ways to proceed: one is to have an input/output iterator that enforces sequential access, and another is to allow for user-driven access at the cost of sometimes severe performance. The reviewers also posted a few suggestions that could improve quality of the two extensions, 1. Name of functions like read_int8, read_int16, read_int32, write_int8 in Device models suggest they return and accept signed integers, but they return and accept unsigned integers. The naming could be improved.. 2. Do some profiling and performance optimization of the most common formats. Add some test cases to measure speed of common scenarios. 3. Make sure the test cases provide complete coverage. For example, set a breakpoint in every method, every switch statement and branch. Run your tests and remove any breakpoints that are encountered. Look at the breakpoints that were not hit and add tests for them. 4. It would be great if Christian and Domagoj could join their efforts to take the best of their libraries (IO extension implementations) to the IO extension included in Boost.GIL and collaborate for the advanced features discussed in reviews. I would like to thank Edd Dawson, Zach Laine, Domagoj Saric, Roland Bock, Lubomir Bourdev, Tom Brinkman, Phil Endecott, Kenny Riddile for reviews and others who participated in discussions. Thanks also go to Christian Henning for great work. I would like conclude recalling short comment Lubomir Bourdev included in his review. In my opinion, it is a good summary of the Boost.GIL IO and Toolbox review and generally all discussions on this subject: *** The problem with I/O is that you can never declare success. All we can hope for is push the boundary as much as we can, and leave the rest for the next update. *** [1] http://lists.boost.org/boost-announce/2010/11/0273.php [2] http://lists.boost.org/boost-announce/2010/12/0279.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

2 1

[context] other version with stack
by Oliver Kowalke 27 Jan '11

27 Jan '11

I've uploaded another version (0.5.0) which accepts an stack (instead of an stack-allocator) which will be stored (moved) inside boost::context. the implicit interface of the stack looks like: class my_stack { public: void * address() const; std::size_t size() const; }; boost::protected_stack stack( 1024); boost::context ctx( boost::context::create( my_fn, 0, stack) ); Oliver

1 0

[static_assert.hpp] Add BOOST_STATIC_ASSERT_MSG?
by Beman Dawes 27 Jan '11

27 Jan '11

BOOST_STATIC_ASSERT predated C++0x static_assert, so it doesn't take advantage of static_assert's message argument when static_assert is available. It would break too much code to change BOOST_STATIC_ASSERT, but we can add a new macro that does take advantage of C++0x static_assert if available. After adding this to <boost/static_assert.hpp>: + #ifndef BOOST_NO_STATIC_ASSERT + # define BOOST_STATIC_ASSERT_MSG( B, Msg ) static_assert(B, Msg) + #else + # define BOOST_STATIC_ASSERT_MSG( B, Msg ) BOOST_STATIC_ASSERT( B ) + #endif This test program: #include <boost/static_assert.hpp> int main() { BOOST_STATIC_ASSERT_MSG( true, "should never fire" ); BOOST_STATIC_ASSERT_MSG( false, "should always fire" ); return 0; } Compiling with VC++ 10, which supports static_assert, produced: temp.cpp(7) : error C2338: should always fire Compiling with VC++ 9, which does not support static_assert, produced: temp.cpp(7) : error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>' with [ x=false ] Comments? --Beman

6 6

[mpl] Metafunction to extract type
by Edward Diener 27 Jan '11

27 Jan '11

Does MPL already have a metafunction which takes a type, which is a nullary metafunction, and returns the nullary metafunction's nested type ? As in: template < class T > struct get_type : T { };

2 3

RE process (prospective from a retired FreeBSD committer)...
by Sean Chittenden 27 Jan '11

27 Jan '11

I originally sent this to Eric but am cleaning it up and reposting here per his suggestion. From an outsider's perspective it appears as though the lack of branching/merging tied to release management is the biggest issue for Boost at present. I'm a retired FreeBSD committer, I wanted to point out how the FreeBSD community deals with release engineering and see if there are a few nugget policies that could be cherry picked for boost. FreeBSD's process has been in place and refined for the last 15 years and comes with already written documentation as a starting point. It's not perfect, but there's a pound of prevention that comes via policy that no tool can replicate. head/trunk/tip is known as the -CURRENT branch. Released versions for production used (or are in prep for being released) are known as -STABLE branches. When FreeBSD 8 was being developed, people committed to HEAD (aka -CURRENT). When the re@ team called for a freeze for release and -CURRENT was in sufficiently good condition, they branched HEAD in to RELENG_8_STABLE. Everything in RELENG_8_* is expected to be production quality (or nearing it). Upon release of 8.0, RELENG_8 was branched again to RELEASE_8_0. 8.1, 8.2, etc were all created from RELENG_8_STABLE. Fixes for things in stable go to -CURRENT first, then are back patched to the appropriate stable releases, colloquially known as MFC's or Merge From -CURRENT. -CURRENT is the wild west of OS development and repo trash. Use at your own risk. Stability and likelihood of all tests passing is marginal, at best. Towards the end of a given major version -CURRENT becomes more stable, but once -STABLE has been branched it quickly degenerates some as people implement the impetus to checkin new features. -STABLE should always be passing 100% of the regression tests present in the branch at all times. A quick doc on merging between branches: http://wiki.freebsd.org/SVN_Merging I don't know how wide spread it is and despite svk having gone in to maintenance mode, use of svk has merit (partial checkouts): http://svk.bestpractical.com/view/HomePage http://www.freebsd.org/releng/ Anyway, the way that FreeBSD handles its permissions and merging from one branch to the next is via the commit message and commit hooks and approvals from different people wearing different hats. A few examples: http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008657.html has an MFC line in there to denote the changes included. The commit handler verifies that the diffed files largely match (at least it used to back in the day when I was committing via CVS). http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008683.html Reviewed by commit header. This gives greater latitude in terms of what can be included in the commit. http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008808.html And the 'Approved by' commit header. Once a release is frozen, all commits need to have this tag. The commit will fail without it and if someone commit with that line and didn't have permission to do so, as a policy, the commit is always reverted 100% of the time as a matter of principle. Frequently it's re-committed, but it's a big slap to the back of the hands to have to go through the process again. Needless to say, the commit mailing list is the most active and widely read list as a result. And tons of code gets reviewed with many eyes viewing it as a result. There are other bits worth noting, acls apply to different parts of the tree (doc-re vs src-re), but I don't know how many people actually follow boost's commit log on a per commit basis, but given 100% of all commits go to a single mailing list, it seems like the current list infrastructure makes that kind of review process unsustainable for Joe Reviewer (vs. the shorter abridged commit messages w/ a link to the actual diff). Lots of people fork FreeBSD to do experimental work out of the tree via git and hg, but the monolithic and serialized commit/review process seems to be working quite well from my perspective. A little bureaucratic but very stable and democratic without reliance on any one person to push the release forward. Anyway, food for thought. Hopefully there's something there that you can pick out of value. If you have questions, feel free to ask. -sc -- Sean Chittenden sean(a)chittenden.org

1 0

Re: [boost] [string] proposal
by Ivan Le Lann 27 Jan '11

27 Jan '11

----- "Robert Stewart" <Robert.Stewart(a)sig.com> wrote : > > That's a bad analogy. std::auto_ptr was deprecated, but not in favor > of another std::auto_ptr but rather by std::shared_ptr. That's off-topic but I think you meant unique_ptr instead of shared_ptr. Ivan.

2 1

[V1.46] [Iterator] Ask for release notes modification
by Michel MORIN 27 Jan '11

27 Jan '11

Hi, I have some comments on the Boost 1.46 release notes for Boost.Iterator. (http://svn.boost.org/svn/boost/website/public_html/beta/feed/history/boost_…) Here are the release notes for Boost.Iterator: * fixed problem with `implicit_cast` ([@https://svn.boost.org/trac/boost/ticket/3645 #3645]) * added `function_input_iterator` ([@https://svn.boost.org/trac/boost/ticket/2893 #2893]) * `transform_iterator` now uses `boost::result_of` to determine functor result type ([@https://svn.boost.org/trac/boost/ticket/1427 #1427]) The first item seems OK :) The second item needs to be deleted, since `function_input_iterator` is not merged into release branch. The third item also needs to be changed. As the release notes say, `transform_iterator` now uses `boost::result_of` to determine functor result type (in prior versions, it uses `result_type`). But there is a bug: it should use `boost::result_of<Iterator::reference>` as the documentation says, but it uses `boost::result_of<Iterator::value_type>`. (This was fixed in trunk a week ago, but it was too late to merged to release.) This bug makes subtle errors and confuses the users. Is it better to mention the bug in the release notes explicitly? Something like: * BUG: `transform_iterator` uses `boost::result_of<Iterator::value_type>` to determine functor result type instead of `boost::result_of<Iterator::reference>` ([@https://svn.boost.org/trac/boost/ticket/1427 #1427]) Or simply delete this item? Regards, Michel

6 11

Re: [boost] [string] proposal
by Ivan Le Lann 27 Jan '11

27 Jan '11

Artyom wrote : > > > > So you do not consider the fact the following code compiles (and > runs!) > > cleanly as a painful problem? > > > > std::string s = get_utf8_string(); > > s[42] = '?'; > > > > It is fine code. Why? Because if you assign s[42] you probably > know why you are do it and you most likely know that there is > a some ASCII character there. > I want more safety. And opacity is one way to it. I consider that stating "The code is OK because you know what you're doing" is an offense to all safety efforts put into C++ and its standard library. Sorry for the tone, but I failed to express my views in another way. Non throwing failures somewhat disturb me. Especially if you can design a failsafe interface. > > > I consider that std::string is cool as an internal for a > Boost.Locale > > implementor, not as a standard API for encoded strings that should > be > > used by all C++ developpers. > > > > Seems to me you hadn't seen Boost.Locale code and what does it > does. > I've seen it and toyed with it, and it's great. I have no problem with Boost.Locale, I have a problem with all the mess than can be done with the string type it has to publicly use today. And by the way, you're the one who stated that encoded string processing should be done by a domain expert library. I'm only exspecting you to translate this into : we need a more opaque string. Ivan

1 0

[threads] namespace & externs
by scot shinderman 27 Jan '11

27 Jan '11

Boosters, In boost/thread/src/pthread/thread.cpp we see extern "C" {} around code such as tls_destructor. Is this needed so it interfaces w/ native pthread local storage? When a vendor program is built against a specific version of boost it usually becomes necessary to isolate other users via a namespace. However, anything with extern "C" style defeats this. Aside from explicit linking to native c api's are there reasons for this; also what's considered the best style to isolate different versions -- currently we modify every header with a version-ed namespace wrapper. thanks! -s-

3 3