- Boost - lists.preview.boost.org

Re: [boost] [string] proposal
by Brent Spillner 29 Jan '11

29 Jan '11

On Jan 29, 2011, at 8:43 AM, David Bergman wrote: >There are four layers in play here: >1. The sequence of characters/symbols, as in CS string; totally abstract but precise... (one such CS string can be represented as Unicode or Latin-1 at #2, for instance.) >2. The sequence of code points, in a given character set. Yes, one CS string (as in #1) can have multiple distinct manifestations at this level. They could be identical in >integral sequences. >3. The sequence of code values, using an encoding form such as UTF-8 or UTF-16 for a Unicode code point. >4. The byte storage representing the code values; could be a contiguous sequence of bytes or chunks, etc. Which, IMHO, is exactly why it's (past) time to radically rethink the standard string interface. Your four layers share the properties that: (a) They can all be physically represented within the same data structure (i.e. layer #4), and (b) For any layer, there already exists a lot of legacy code that conceptualizes passed-in strings at that layer and that makes corresponding assumptions. To me, these facts imply that a 'view'-based approach is the right way to go. Furthermore, views should not be concrete data structures themselves, but simply iterator pairs (ranges) that internally point to some arbitrary data structure, and externally present a model of a linear sequence of atomic characters/codepoints/etc. In software development Nirvana, APIs and algorithms will operate on iterator_ranges at the appropriate conceptual level, rather than intruding into the underlying data structures, and at the interfaces with reality we'll just copy data to and from more concrete representations using the chosen encoding. Some of those interfaces (with low-level device drivers or with memory-mapped hardware itself) might never go away, but many (e.g. a GUI API that accepts a string and returns a texture of its glyphs) would hopefully eventually migrate to the iterator model. For example, one might write std::string underlying_data = obtain_validated_data_from(somewhere); text<ucs4, codept_view, decltype(underlying_data)> codepoints(assume_utf8(underlying_data)); text<utf8, char_view, decltype(underlying_data)> characters(assume_utf8(underlying_data)); if (codepoints.length() > characters.length()) contains_multipoint_characters = true; // converse not necessarily true if there are codepoints for multi-character ligatures const char *byteptr = linear_representation(underlying_data); // may or may not accurately track later changes, especially if the underlying data is non-contiguous, but that's really a usage protocol question and not for the data structure to solve--- anyway, strdup() if you want a snapshot from a given point in time text<utf8, char_view, characters::internal_representation> substring = all_after(characters.begin(), characters.end(), "phrase to match"); std::vector<wide_char_t> char_array; std::copy(substring.begin(), substring.end(), char_array.begin()); etc. When you think your usage pattern favors a rope or a chain over a std::string, you only have to change the declaration of the underlying_data object and the rest works seamlessly. I think Dean favors immutability because that makes it easy for the iterator-adaptors to cache data in the representation they need (or in more local storage in a NUMA environment), but like specifying a particular byte encoding for the underlying data this would be more for convenience and performance optimization than a firm requirement. When the underlying representation is a mutable type, read-only view adapters are still free to cache chunks of data as long as they check for a fingerprint that writable view adapters leave on the underlying structure whenever they commit a change. Consider the underlying data structure as a sequence of arbitrary 'tokens' (bytes, characters, codepoints, variable-length compressed bitstrings... whatever makes sense); a read-only substring cache that depends on tokens i though j (inclusive) of version v of the underlying representation can be described by the tuple r(v, i, j), while a serialized write operation that changes the tokens in positions i though j from version v to version v+1 can be described by the tuple w(v+1, i, j). A write w(v, x, y) invalidates all or part of a read cache r(v', x', y') if and only if v' < v && x' <= y && y' >= x (and if partially invalidated, we know exactly which segment(s) are still OK.) The dereference operator of the read-only iterator then needs to check its cached v' against the underlying data structure's latest version, and if necessary skim through a small ring buffer of recent w(v, x, y) tuples to see if part of its cache must be invalidated (if v' + 1 is less than the earliest v in the ring, the reader can conservatively invalidate its entire cache.) This is a negligible amount of overhead (in the common case, a single fetch, compare, and predictable branch, and in the worst case a new transcoding that you would have had to perform anyway) per character/codepoint/byte access, and when even that is unacceptable you can simply cache a representation of the string in a buffer of known encoding and make everything else adapt to /your/ data layout. I'm intentionally not delving into the details of synchronizing reads and writes between different threads, as std::string and char[] don't provide that either, but if you really need some views to provide their own synchronization this is a (relatively) straightforward place to build it in. >1. Why can't this byte storage type not be used for all kinds of things; is not 'string' a quite bad name for it, since it is neither a string according to most programming >languages (see above) nor according to that CS definition that you are alluding to (unless you consider uninterpreted bytes to be symbols, but be quite aware that those >'symbols' would have nothing - or very little - to do with the symbols of the text represented through your construct.) Wholeheartedly agree; the view should have a name like 'text' (or 'characters', 'codepoints', 'bytes', etc.) and the underlying data structure can be string, rope, vector<char>, or boost::not_invented_yet. Sure, views don't completely solve the problem of legacy APIs that require a persistent, writable reference to a block of text (e.g.a text entry widget that maps its input to a character buffer); if you're lucky to can map the widget to the underlying_representation structure and create the views you need for other parts of the program. If you're not lucky, you might have to make a separate copy for each legacy interface and check periodically or on-demand for changes, but I'd still much rather use a data structure that forces me to make explicit copies than one that encourages me to risk sharing a single buffer between APIs that may not make the same encoding assumptions.

1 0

Survey: What should an immutable byte sequence data structure be named?
by Gregory Crosswhite 29 Jan '11

29 Jan '11

Hey everyone, To gather more data about what the community thinks an immutable byte sequence data structure should be called (given that "string" has already been taken), I have created the following poll: https://catalyst.uw.edu/webq/survey/gcross/123312 If you have an opinion on the matter, please consider visiting the above link and submitting your favorite name. Some names that have been tossed around are istring, immutable_string, chain, rope, yarn, twine, cord, but don't feel limited to these choices. Cheers, Gregory Crosswhite

7 7

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

29 Jan '11

----- "Dean Michael Berris" <mikhailberis(a)gmail.com> wrote : > On Sat, Jan 29, 2011 at 8:07 PM, Ivan Le Lann <ivan.lelann(a)free.fr> > wrote: > > > > Dean Michael Berris wrote : > > > >> > >> But c_str() doesn't have to be part of the string's interface. > > > > *My* *guess* is that Artyom think that: > > > > os_func ((s1 + s2 + s3 + ... + s100).c_str()); // s for std::string > > > > is dramatically faster than: > > > > os_func ((c1 + c2 + c3 + ... + c100).to_string().c_str()); // c for > "boost::chain" > > > > And this is precisely my point as well: the one that uses boost::chain > is perfectly suited for this kind of use case in both efficiency and > clear-cut semantics. I for one don't like to make to_string() a member > either -- I much rather make it a conversion operator so boost::chain > (if we're going to call it that) can be used where interfaces take a > std::string. > [Note: I'm all for chains/ropes/etc, only looking for corner cases] I definitely agree for my example, which is a pure rope demo. linearize(chain) can give a c_str at no cost for trivial chains, and is not heavier than std::string::operator+ for non-trivial chains. Cool. Now looking at Artyom example makes me consider the quite common case where the desired output is not c_str but std::string itself. Add move optimizations on top of that: func_taking_std_string ( /*linearize*/ (my_chain_func ())); func_taking_std_string ( (my_string_func ())); No matter the way you put it, you have one unnecessary allocation, because std::string has no move constructor from chain (yet). For people eventually throwing their boost::chain into std::string, we're basically killing all move/RVO optimizations. Am I missing something? Ivan

2 1

Re: [boost] [string] Realistic API proposal
by Joe Mucchiello 29 Jan '11

29 Jan '11

Anders Dalvander wrote: > On 2011-01-28 20:12, Joe Mucchiello<jmucchiello(a)yahoo.com> wrote: >> // conversion for Windows API >> std::vector<wchar_t> vec; >> vec.resize(count_codepoints<utf8>(mystring.begin(), mystring.end())); >> convert<utf8,utf16>(mystring.begin(), mystring.end(), vec.begin()); > >I spy with my little eye a potential crash waiting to happen. >Code-points != Code-units. Dang, you're right. I used the wrong term. This is why Unicode correctness is so hard. So much for my graceful introduction to the mailing list. :-) Joe

1 0

Re: [boost] Survey: What should an immutable byte sequence data structure be named?
by Andrew Sutton 29 Jan '11

29 Jan '11

I agree with Dave. Buffer. Python uses "frozen" to describe the same (similar?) property for sets. On Jan 28, 2011 3:10 PM, "Dave Abrahams" <dave(a)boostpro.com> wrote:

5 7

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

29 Jan '11

----- "Yakov Galka" <ybungalobill(a)gmail.com> wrote: > On Sat, Jan 29, 2011 at 14:07, Ivan Le Lann <ivan.lelann(a)free.fr> > wrote: > > > > > *My* *guess* is that Artyom think that: > > > > os_func ((s1 + s2 + s3 + ... + s100).c_str()); // s for > std::string > > > > is dramatically faster than: > > > > os_func ((c1 + c2 + c3 + ... + c100).to_string().c_str()); // c > for > > "boost::chain" > > > > Aren't they perform the same? Actually with lazy evaluation the latter > will > be faster. > For this example, I agree. I'm only stressing the marketing issue. Eventually, we'll need figures here. Big-sized font figures. Ivan

1 0

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

29 Jan '11

Dean Michael Berris wrote : > On Sat, Jan 29, 2011 at 5:24 PM, Artyom <artyomtnk(a)yahoo.com> wrote: > > - > >> From: Dean Michael Berris <mikhailberis(a)gmail.com> > >> > >> On Sat, Jan 29, 2011 at 3:02 PM, Artyom <artyomtnk(a)yahoo.com> wrote: > >> > > >> > It would turn away 90% of users. > >> > > >> > >> It might turn you away because you obviously love std::string. > >> Generalizing is a different matter and is largely a hot-air blowing > >> exercise that is futile for convincing anybody. > >> > > > > I would say it more clear: > > > > 1. All users that use C libraries and need c_str() at boundaries > > And this is a huge amount of users that need to communicate > > with modules that are already working and ready but written in C. > > > > And this is about of half of libraries there is C is the lowest > > level API that allows easy bindings to all languages. > > > > But c_str() doesn't have to be part of the string's interface. *My* *guess* is that Artyom think that: os_func ((s1 + s2 + s3 + ... + s100).c_str()); // s for std::string is dramatically faster than: os_func ((c1 + c2 + c3 + ... + c100).to_string().c_str()); // c for "boost::chain" Regardless of the validity of my present guess, I'm quite sure that this concern (and other similar ones) will be shared many developpers. Ivan

3 2

Re: [boost] [string] Realistic API proposal
by Anders Dalvander 29 Jan '11

29 Jan '11

On 2011-01-28 20:12, Joe Mucchiello<jmucchiello(a)yahoo.com> wrote: > // conversion for Windows API > std::vector<wchar_t> vec; > vec.resize(count_codepoints<utf8>(mystring.begin(), mystring.end())); > convert<utf8,utf16>(mystring.begin(), mystring.end(), vec.begin()); I spy with my little eye a potential crash waiting to happen. Code-points != Code-units. vec has room for N code-units, but 2*N code-units may be written to it if mystring contains non-BMP characters. "Corrected" code: std::vector<wchar_t> vec; vec.resize(count_codeunits<wchar_encoding>(mystring.begin(), mystring.end())); convert<wchar_encoding>(mystring.begin(), mystring.end(), vec.begin()); I think a lot of these potential crashes could be prevented if the iterator of the new string-type (chain,text,tier,yarn) would only expose (const) code-points. Actual code-units would be hidden, and only accessed using a facade/adapter view/iterator. auto u8v = make_view<utf8_encoding>(mystring); auto u16v = make_view<utf16_encoding>(mystring); for (auto codepoint : mystring) {...} for (auto u8codeunit : u8v) {...} for (auto u16codeunit : u16v) {...} I also think there isn't a reason that the new string-type *has* to be UTF-8 internally. It could be UTF-16, UTF-32, SCSU, or CESU-8 internally for that matter. Making a view from the internal encoding to an external encoding when both encodings are the same should be a no-op. Regards, Anders Dalvander -- WWFSMD?

1 0

Re: [boost] [string] Realistic API proposal
by Anders Dalvander 29 Jan '11

29 Jan '11

On 2011-01-28 23:04, Artyom<artyomtnk(a)yahoo.com> wrote: >> > // conversion for Windows API >> > std::vector<wchar_t> vec; >> > vec.resize(count_codepoints<utf8>(mystring.begin(), mystring.end())); >> > convert<utf8,utf16>(mystring.begin(), mystring.end(), vec.begin()); >> > HRESULT hr = WriteFile(handle, vec.data(), vec.size(),&dwBytesWritten, >> > NULL); >> > ... >> > > Notice vector is not string and it requires additional copy If std::string is UTF-8 encoded (as you are suggesting, correct?), then you also requires additional copy: // conversion for Windows API std::string u8s = ...; std::wstring u16s = convert_to_utf16(u8s); HANDLE h = CreateFileW(u16s.c_str(), ...); Regards, Anders Dalvander -- WWFSMD?

2 1

[web] Broken link.
by Mostafa 29 Jan '11

29 Jan '11

FYI: on https://svn.boost.org/trac/boost/ , the following link is broken: "http://svn.boost.org/trac/boost/browser", see "You can browse the Boost Subversion repository online or retrieve Boost via ...". Mostafa

1 0

Re: [boost] [string] Realistic API proposal
by Ivan Le Lann 29 Jan '11

29 Jan '11

----- "Artyom" <artyomtnk(a)yahoo.com> wrote : > Hello All, > > I'd like to provide a realistic string API proposal: Thanks for your contribution. I do have a naïve question: What happens to your extensions when "Char" template argument is not char? Do they still have a meaning ? Ivan

2 1

Re: [boost] [string] proposal
by Joe Mucchiello 28 Jan '11

28 Jan '11

On Jan 28, 2011, at 12:59 PM, Dean Michael Berris wrote: > > And I stopped before I write too much -- the initial version is > already up: >https://github.com/downloads/mikhailberis/cpp-string-theory/cpp-string-theo… > > > -- I'll give it more information and the actual interfaces and > implementation as soon as I get some Z's. :) > Hi, I have a question. You keep saying that the string (or chain) has no encoding the string is "just a sequence of bytes" but that doesn't make sense. The bytes have to have some form of encoding otherwise how do the adapter classes know how to convert the sequence of bytes into an encoded sequence? When you say the string has no encoding do you simply mean the default encoding is implementation dependent? Did I miss where you said this somewhere? Oh, and I see the value in an immutable string. I just think you are still at such a high level that it's hard to see where you are going for some people. Joe

2 1

Re: [boost] [Boost-users] Git vs SVN (was: Re: What's happened to Ryppl?)
by Dave Abrahams 28 Jan '11

28 Jan '11

[moved to developers' list] On Fri, Jan 28, 2011 at 8:48 AM, Vladimir Prus <vladimir(a)codesourcery.com> wrote: > May I suggest that to keep signal/noise ratio on the list to acceptable > level, we don't have a general VC shootout discussion. It will never lead > to anything. +1, but I don't think anyone intended to do that. > Rather, the parties interested in having Boost switch to any > version control system that is not SVN should propose a specific plan, > including hosting, administration, adjustment of all scripts, new workflows > for Boost maintainers and authors of proposed libraries, etc? > > If would be seriously not funny if 1000 messages later we'll find that > git is about to solve every problem on earth, but there's nobody to > do *complete* transition and onging maintenance. I think what you've just said is an important part of the discussion we should be having right here and now. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 1

[mpl] Using transform problem and solution
by Edward Diener 28 Jan '11

28 Jan '11

I have a boost::mpl::vector of nullary metafunctions and I need to transform it into a sequence of the metafunction's inner types. As in: typedef boost::mpl::vector<boost::mpl::identity<int> > tvec; typedef boost::mpl::vector<int> tvecinner; So I try boost::mpl::transform: typedef typename boost::mpl::transform<tvec,_1>::type ttrans; BOOST_MPL_ASSERT((boost::mpl::equal<tvecinner,ttrans>)); But that does not work and the assert fails. Evidently my _1 is not working by itself although it seems as if it should because it is a placeholder expression and its inner type is what I want. So I try: template <class T> struct tself : T { }; and now instead: typedef typename boost::mpl::transform<tvec,tself<_1> >::type ttrans; BOOST_MPL_ASSERT((boost::mpl::equal<tvecinner,ttrans>)); works fine and the assert succeeds. But that 'tself' hack seems like it should be really unnecessary. Have I missed something cleaner and easier ?

3 3

Trac down?
by Beman Dawes 28 Jan '11

28 Jan '11

I'm getting a blank page when I try to access svn.boost.org/trac/boost/ That's a serious impediment to building the 1.46.0 beta. I really need the release manager's checklist from the trac. Are others able to access Trac? --Beman PS: The good news is that SVN seems to be running really well, with none of the slowness and server errors that were a problem several weeks ago.

5 8

[Boost.Algorithm] Proposal for addition of a new algorithm: ThreeWayMerge
by Aleric Inglewood 28 Jan '11

28 Jan '11

Greetings everyone. I don't think that Boost.Algorithm exists: I only saw it refered to on mailinglists. I looked at the existing libraries, but I'm not sure where this would fit in. I'd like to propose the addition of a new algorithm, very much like std::set_union and companions, that I came up with recently. This algorithm does a three-way merge of containers. Comparing it to std::set_union, which needs five iterators to be passed, and a compare functor (two iterators for the range of input 1, two iterators for the range of input 2 and one output iterator), the three_way_merge algorithm takes three iterator ranges and one output iterator, so it takes seven iterators. The algorithm also takes two functors: a compare and an is_equal. The former should be the ordering Predicate used with the containers (they must be ordered containers, like std::set or set::map), while the is_equal functor is usd to compare the "payload" of the data (which is not part of the sorting key). The algorithm applies trivial merge rules in all cases where the merge is trivial, and calls a third functor to perform the three-way merge of the payload in those cases that a three-way merge is not trivial. In it's current form, my algorithm looks as follows: https://github.com/AlericInglewood/contribmerge/blob/master/src/three_way_m… I used it (in that project) to three-way-merge a file with a specific format: a list of contributors, each with a list of contributions. The algorithm is used recursively (which is very neatly showing it's true power, of course). For this usage example, please see https://github.com/AlericInglewood/contribmerge/blob/master/src/contribmerg… Aleric

1 0

Re: [boost] [string] proposal
by Anders Dalvander 28 Jan '11

28 Jan '11

On Thu, 27 Jan 2011 12:51, Nevin Liber <nevin(a)eviloverlord.com> wrote: > I'd like to see this broken up into three discussions: > > 1. Immutable strings. Immutable or not, I don't see a direct use for modification of individual code-units (e.g. char, wchar_t) in a string. Too many things can go wrong. Some kind of manipulation of code-points, yes, but not code-units. Anyway, code-points are not the end either. Multiple code-points may be needed to represent a grapheme, using combining characters. And sometimes a single code-point can represent several graphemes, such as ligatures. > 2. utf8 strings. Although I personally prefer UTF-8 encoded strings, the internal encoding is more or less irrelevant for an implementation based on rope or similar non-contiguous data structure. I believe this is what Dean Michael Berris is suggesting. I think this is especially true if direct access to individual code-units are prevented. For an implementation using a contiguous data structure and providing a constant time c_str member function I'd really want to see some option to set the internal encoding of strings. Performance-wise it may be preferred to use UTF-16 internally when using for example Win32 API, if an extra copy can be avoided. > 3. Unrealistic pipe dream about replacing std::string. Replacing std::string will never happen. Deprecating std::string in favor of std::text/std::unicode/std::xstring may happen in the long run. Regards, Anders Dalvander -- WWFSMD?

2 1

[signals2] -no instance of overloaded function
by Tal Agmon 28 Jan '11

28 Jan '11

Hi All, I get error no instance of overloading ... when using <memory> shared_ptr can anyone explain why? tested on: windows7 vc100 // not working //#include <memory> // fail to compile //using std::tr1::shared_ptr; // works #include <boost/shared_ptr.hpp> // works find using boost::shared_ptr; [code] #include <iostream> #include <boost/signals2/signal.hpp> class Reporter { public: explicit Reporter(const std::string& s) : s_(s) {} void says() const { std::cout<< "news : " << s_ << std::endl; } private: std::string s_; }; class NewsStation{ public: void displayNews(const Reporter& r) const { r.says(); } }; int main() { using namespace boost::signals2; typedef signal<void (const Reporter&) > signal_type; shared_ptr<signal_type> signalPtr(new signal_type); typedef shared_ptr<NewsStation> news_station_ptr; Reporter tal("when using std:tr1::shared_ptr --> no instance of overloaded function, matches the argument list) "); news_station_ptr newsStationPtr(new NewsStation); signal_type sigNews; sigNews.connect( signal_type::slot_type( &NewsStation::displayNews, newsStationPtr.get(), _1).track(newsStationPtr)); sigNews(tal); } [code]

1 1

Re: [boost] [signals2] -no instance of overloaded function
by Ivan Le Lann 28 Jan '11

28 Jan '11

----- "Tal Agmon" <tal.boost(a)gmail.com> wrote : > Hi All, > > > I get error no instance of overloading ... when using <memory> > shared_ptr > can anyone explain why? > > tested on: > windows7 vc100 > > (snip) > sigNews.connect( signal_type::slot_type( > &NewsStation::displayNews, newsStationPtr.get(), > _1).track(newsStationPtr)); > sigNews(tal); > } Just a bet : I suspect the track method exspects a boost::shared_ptr. Or something a boost::shared_ptr can convert to. Ivan.

2 1

[iterator] Unmerged changes
by Daniel James 28 Jan '11

28 Jan '11

Hi, I've been looking through the unmerged changes in the iterator library. I think it should all be merged/fixed/reverted for 1.47. These seem to be the outstanding changes: An old fix from David Abrahams: https://svn.boost.org/svn/boost/changeset/58012 function_input_iterator from Dean Michael Berris: https://svn.boost.org/svn/boost/changeset/62615 https://svn.boost.org/svn/boost/changeset/62710 The result_of changes (partially merged, but will be reverted for 1.46): https://svn.boost.org/svn/boost/changeset/62625 https://svn.boost.org/svn/boost/changeset/68205 Any comments on these? Anyone willing to take charge, or shall I deal with them? Daniel

2 1

[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