- Boost - lists.boost.org

[tuple] swap (also includes question about [sorting])
by Jeremiah Willcock 17 May '09

17 May '09

Thanks to Marcin Zalewski, the problem in my last email has been tracked down to the inability to swap boost::tuples that contain references. There have been a couple of proposals to add that: http://lists.boost.org/Archives/boost/2006/03/102603.php http://lists.boost.org/Archives/boost/2003/05/48488.php but it appears that none of them has made it into Boost. This feature is important because of sorting data structures using zip_iterators as in my previous message: http://www.nabble.com/-iterator--std::sort-on-zip_iterator-td23348384.html and the older posts: http://lists.boost.org/Archives/boost/2004/07/68758.php http://lists.boost.org/boost-users/2009/03/46623.php In particular, std::swap (from GCC 4.0.1) does not work correctly on the result of dereferencing a zip_iterator, which is a Boost tuple of references. The std::swap function does not work at all (fails at compile time) because the result of operator* is not a non-const reference, and std::iter_swap tries to use assignment between the tuples, producing incorrect answers at run time. Is it true that there is no standards-compliant way to solve this problem? If so, would that be a good justification for Boost.Sorting to include an algorithm similar to std::sort but that handles more generalized swappable types? -- Jeremiah Willcock

2 1

[Boost.datetime] Serialization
by Sean Farrow 17 May '09

17 May '09

Hi: Would it be possible to add the funtion Given at the url: http://www.boost.org/doc/libs/1_39_0/doc/html/date_time/serialization.ht ml To the boost.datetime or boost.serialization library for 1.40. Cheers Sean. __________ Information from ESET NOD32 Antivirus, version of virus signature database 4080 (20090515) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

2 1

[gsoc] Proposal for Generic Trie, Radix Tree, and Suffix Array Data Structures
by Chris Wagner 17 May '09

17 May '09

Hello, I am interested in writing a library consisting of generic implementations of several common data structures and algorithms primarily useful in text-processing. I believe these would be useful additions to Boost and would like to work on them for GSoC. Before I submit my proposal, I would like to hear whether or not the community agrees that this is a good idea, and I would appreciate any suggestions or comments offered. My plan is to implement a trie / prefix tree data structure, STL set/map-like classes implemented over the trie, a radix tree, a suffix tree implemented over the radix tree, and a suffix array. These would be instantiable over arbitrary sequence types, and use iterator traits to determine the contained type. I am a student at Kent State University, working on an M.S. in Computer Science in a combined undergraduate/graduate program. I have a particular interest in computational linguistics, and I will admit that am especially interested in this project because of how it could be applied to my own field, but I believe that these types would be of general utility to the programming community as a whole. Thank you for your time, Chris Wagner

5 5

[futures] is there an updated version of futures
by Yigong Liu 16 May '09

16 May '09

Hello, Is there an updated version of futures lib by Anthony after the review? Is the one dated 20090530 still the latest one publicly avaialble? Thanks Yigong

1 0

[exception] Virtual inheritance with no default constructors
by Adam Badura 16 May '09

16 May '09

The Boost.Exception library mandates that exceptions classes hierarchy should use virtual inheritance (http://www.boost.org/doc/libs/1_39_0/libs/exception/doc/using_virtual_inher…) The document notes that this does not go well with exceptions without default constructors ("(...) Note that virtual bases are initialized directly by the constructor of the most-derived-type (...)") however this should not be a concern as boost::exception provides other means to transport data. What is missing is however documentation that in normal circumstances boost::throw_exception cannot be used with exceptions types which have in their inheritance graph virtual base classes which are not default constructible. This is because boost::enable_current_exception constructs the clone_impl object which inherits the actual exception type and copy-constructs it. However this code will not compile if some base class of the callers exception type is virtual and non-default constructible. In my opinion few changes seem appropriate: 1) Note in the documentation explicitly this requirement (possibility of default construction). 2) Name an entity which should be made friend of exception class to use its non-public default constructor. This entity would be latter used by clone_impl. This way an exception could be default constructible only for this particular use case. 3) Provide means to late-initialize exception object. This would bypass the default construction problem (and goes well with private default constructor as described in 2)). 4) Allow to specify in boost::throw_exception (or similar places) not only the exception type but as well its (virtual) base types so that latter clone_impl could mention them on the initializers list as well and copy-construct them. (As far as I know there is no way of automatic detection of base types thus caller must specify them explicitly - however if I am mistaken such automation would be even better.) Adam Badura

2 11

Re: [boost] [rfc] Unicode GSoC project
by Graham 16 May '09

16 May '09

>What kind of real-world use do people have for random access, anyways? >Even UTF-32 isn't random access for the things I can think of that >people would care about, what with combining codepoints and ligatures >and other such things. I wrote a couple of Unicode text editors that would have been a nightmare if they had not been operating on UTF-32. >As an aside, I'd like to see comparisons between compressed UTF-8 and >compressed UTF-16, since neither one is random-access anyways, and it >seems to me that caring about size of text before compression is about >as important as the performance of a program with the optimizer turned >off. Actually in a few cases I have seen it is not the compressed size but the conversion performance [memory/CPU] that hurts. It is much better to get the correct encoding for the correct use case. Yours, Graham

2 1

Re: [boost] [rfc] Unicode GSoC project
by Graham 15 May '09

15 May '09

>I don't plan on supporting random access for UTF-16. >UTF-16 is still faster than UTF-8 because UTF-8 requires more complex >decoding. >UTF-16 has only two cases, making it easier to optimize branches under >the likely and unlikely case. Dear Mathias, Don't forget surrogates ! Yours, Graham

1 0

Re: [boost] [rfc] Unicode GSoC project
by Graham 15 May '09

15 May '09

>I'll be reviewing it in a while. >I'm not too sure about the memory layout it uses (__uni_char_data could >really be compressed to use less memory for example), nor about the >interface it exposes, but it does seem to work well. >About is_grapheme_break though, isn't the implementation for legacy >grapheme cluster rather than extended ones though? Dear Mathias, The uni car data was laid out in that way for speed and simplicity. Please feel free to do it better. The grapheme break worked off the character attributes and standard rules. If it needs changing or did not cover a later standard, then it should be updated. The principle would not change as it makes the string iterators quite straightforwards.

1 0

[rfc] Unicode GSoC project
by Mathias Gaunard 15 May '09

15 May '09

Hi everyone. I'm in charge of the Unicode Google Summer of Code project. I have been working on range adaptors to iterate over code points in an UTF-x string as well as converting back those code points to UTF-y for the past week and I stopped working on these for a bit to put together some short documentation (which is my first quickbook document, so it may not be very pretty). This is not a documentation of the final work, but rather that of what I'm working on at the moment. I would like to know everyone's opinion of the concepts I am defining, which assume the range that is being worked on is indeed a valid unicode range in a particular encoding, as well as the system used to enforce those concepts. Also, I put the normalization form C as part of the invariant, but maybe that should be something orthogonal. I personally don't think it's really useful for general-purpose text though. While the system doesn't provide conversion from other character sets, this can easily be added by using assume_utf32. For example, using an ISO-8859-1 string as input to assume_utf32 just works, since ISO-8859-1 is included verbatim into Unicode. The documentation contains as well some introductory Unicode material. You can find the documentation online here: http://mathias.gaunard.emi.u-bordeaux1.fr/unicode/doc/html/

7 16

[C++0x] More config macros needed
by Beman Dawes 15 May '09

15 May '09

GCC 4.3 and even more so 4.4 have implemented significant portions of the C++0x core language, and provide lots of C++0x standard library components too. Microsoft 2010 beta 1 will ship "real soon", and it too will have some major C++0x core language features, and also some C++0x standard library components. Thus we need more config macros, particularly those aimed at the standard library. A possible approach: BOOST_NO_CONCEPTS // needed to tell if headers have been conceptized BOOST_NO_*_HDR // for each new C++0x header; * is name of header For example, BOOST_NO_CHRONO_HDR is defined unless header <chrono> is present. I'm proposing we not try to identify whether or no the header is complete. If BOOST_NO_CONCEPTS is defined, the header obviously hasn't been conceptized. Ditto anything else that depends on any other new core language feature that hasn't been implemented. Other incomplete aspects will have to be dealt with by testing the library version. We don't want feature macros to proliferate unduly; they are more work to create and maintain than you might think, and if there are a lot of them it gets very confusing. Comments? --Beman

3 6