May 2009 - Boost - lists.boost.org

Re: [boost] Formal Review Request: Boost.String.Convert
by Vladimir.Batov＠wrsa.com.au 02 Dec '09

02 Dec '09

I understand we'll never manage to please everyone. Apologies. For now I am settling on the boost::convert interface as I very much agree with the arguments Robert's put forward for it and I feel there is the least disagreement around this interface. Surely boost::convert() has issues of its own. However, I feel the path (convert::to_string->convert::to->convert) how I myself arrived to this logical (IMHO) conclusion seemed reasonable. More so, despite its subtle (to some) directionality the interface has proven to work (as it is essentially the same interface as for lexical_cast). You cannot deny that I made considerable sacrifices (my pets "string" namespace and "to/from" are gone, something I was ready to die :-) for yesterday...). I am hoping the others could make some concessions as well and we would settle on boost::convert()... for now. If some other issues pop up that we missed so far, we'll revisit the issue. It is because I would very much like to move forward and start looking at the functionality and implementation. Do you think it is possible or I am rushing things again? I somewhat cleaned up the implementation (removed to/from, etc.). However, before going forward I'd like to discuss one important thing that's been bugging me since Scott brought it up. Namely, all conversions are now implemented as discriminated functions like // string-to-type conversion template<class TypeOut, class StringIn> typename boost::enable_if_c< !is_string<TypeOut>::value && is_string<StringIn>::value, detail::from_string<StringIn, TypeOut> >::type convert(StringIn const& from_str, TypeOut const& default_value =TypeOut()) { return detail::from_string<StringIn, TypeOut>(from_str, default_value); } However, Scott mentioned that and I feel that might be cleaner if we could implement it as namespace boost { template<class TypeOut, class TypeIn, class Enable =void> class convert; } Then for every conversion we'll be able to encapsulate *complete* implementation in the respective specialization class. Like for string-to-type template< class TypeOut, class StringIn, typename boost::enable_if_c< !is_string<TypeOut>::value && is_string<StringIn>::value, void>::type> class convert { convert(StringIn const& from_str, TypeOut const& default_value =TypeOut()); }; The reason I like it is that it eliminates other support/intermediate classes (like something used-to-called boost::string::value<...> and detail::from_string) and we can do int i = convert(str, -1); // Nothing changed. a 'convert' instance created on the stack and converted to 'int'. convert<int, string> checked(str, -1); // named 'convert' is created. convert<int, string> checked = convert(str, -1); // the same but some might like this syntax better. if (checked.good()) success // we can check the success as ussed to with boost::string::value It feels that approach gives us considerably more room for expansion as some special conversions will be able to have methods only specific to that particular conversion. For this approach to work with algorithms we'll need class convert { static TypeOut apply(TypeIn const&); }; and then std::transform( ints.begin(), ints.end(), std::back_inserter(strings), convert<string, int>::apply); Thanks, Vladimir.

9 63

[thread] #2742 Why the at_thread_exit cleanup function is const?
by vicente.botet 25 Nov '09

25 Nov '09

Hi, Anthony, could you verify the patch and test I have attached to the ticket works for other platforms that cygwin? Thanks, _____________________ Vicente Juan Botet Escribá

2 1

Boost.Variant is not EqualityComparable
by brook＠biology.nmsu.edu 12 Nov '09

12 Nov '09

I just ran into the case that Boost Variant does not satisfy the EqualityComparable concept. While it provides operator==() and operator<() (and therefore is LessThanComparable), it does not provide operator!=(), which is required for the EqualityComparable concept. Is this by design or oversight? It seems reasonable to expect that a Boost Variant model this concept, but perhaps I am missing something. In case it is by oversight, the following patch seems to provide the missing operator. Cheers, Brook --- boost/variant/variant.hpp.orig 2009-05-13 21:21:59.000000000 -0600 +++ boost/variant/variant.hpp 2009-05-25 19:21:40.000000000 -0600 @@ -1681,6 +1681,8 @@ return rhs.apply_visitor(visitor); } + bool operator!=(const variant& rhs) const { return !(*this == rhs); } + bool operator<(const variant& rhs) const { //

6 7

proposal interval container; ITL moved to the boost sandbox
by Joachim Faulhaber 11 Nov '09

11 Nov '09

Dear boosters, after completion of a lot of boostification work I moved my Interval Template Library to the boost sandbox in the boost project centric form: https://svn.boost.org/trac/boost/browser/sandbox/itl itl boost itl [itl_xt] [validate] libs itl [itl_xt] [validate] I have split up the original library into three parts: (1) itl, (2) itl_xt and (3) validate. Core part 1 'ITL' contains all interval container class templates. Only this part will be prepared for a formal submission. Part 2 'itl_xt' contains extended parts of the original library that do not belong to the core interval container data structures and might be proposed for later extensions. Part 3 'validate' contains the sources for the law based test automaton 'LaBatea' that has been used for an automated check of the ITLs correctness. Parts 2 and 3 do not yet conform boost standards and naming conventions and are not yet intended as contributions to boost. On the core ITL-part I have done the following: + Removed all virtual functions via introduction of mixins + Integrated deeper into boost libraries replacing own code by e.g. boost::type_traits and boost::mpl + Minimized the class template interfaces by transforming member functions into non member function templates. + Made interval containers more interoperable by overloading operators and global function templates. + Wrote a test suite using boost unit test tools. Tested for boost-instance types boost::date_time and boost::rational + Provided jamfiles to build and run examples and tests. + All examples and tests have been compiled, linked and run successfully with msvc_9.0 and gcc_3.4.4(cygwin). Next I am going to write boost style html-documentation. >From the boost web page I don't see a clear recommendation for a preferable way of doing that. Handcoded? Generated with BoostBook? Is there a reference library that has an exemplary standard documentation? Cheers Joachim

3 4

[utility] auto_buffer v2
by Thorsten Ottosen 07 Oct '09

07 Oct '09

Dear All, Hereby an updated class. Thanks to all who contributed with comments to the first try. I have made the following changes: 1. push_back() overloads are now growing 2. added swap() (boy, was this nasty to implement). I assume the allocator can be wapped without throwing. How do other people copy with this problem? 3. added copy-constructor + copy-assignment 4. made the min capacity equal to N, the number of elements in the stack buffer 5. the size of the internal buffer is now controlled via two policies: template< unsigned N > struct store_n_objects; template< unsigned N > struct store_n_bytes; the default is store_n_objects<256>. The reason is that we don't want the capacity to change just because we compile on a different platform. 6. added comparison operators Comments most welcome! best regards -Thorsten

4 7

[Endian] Version 0.10 available - Binary I/O added
by Beman Dawes 16 Sep '09

16 Sep '09

Version 0.10 of the Endian Integers library is available. Docs: http://mysite.verizon.net/beman/endian-0.10/libs/integer/doc/endian.html Zip: http://mysite.verizon.net/beman/endian-0.10.zip Sandbox: http://svn.boost.org/svn/boost/sandbox/endian This version adds binary I/O for both endian integers (<boost/integer/endian_binary_stream.hpp>) and C++ built-in types + std::string (<boost/integer/endian_binary_stream.hpp>). Support for C++0x features has also been added, ensuring that an Endian integer on C++0x is a POD. Comments appreciated! My Endian TODO list is pretty well cleared, so there are comments to the contrary, the library will be submitted for formal review in a few days. --Beman

3 4

[filesystem][spirit] problems with scoped enums with GCC 4.4 in C++0x mode
by Richard Webb 24 Jul '09

24 Jul '09

(forwarding from the Spirit list) As discussed in the thread @ http://www.nabble.com/-Spirit2--Regression-test-failures-on-GCC-4.4-in-C%2B…, the regression tests for Filesystem and Spirit 2 are pretty much all failing in GCC 4.4 in C++0x mode, due to problems with scoped enums and operator ==. Does anyone have any other ideas about the problem? Thanks, Richard Webb -- View this message in context: http://www.nabble.com/-filesystem--spirit--problems-with-scoped-enums-with-… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 3

RFC: interest in Unicode codecs?
by Cory Nelson 23 Jul '09

23 Jul '09

Is there interest in having a Unicode codec library submitted to Boost? Here is what I have (only tested with GCC 4.3 on Debian, and VC++ 2008): http://svn.int64.org/viewvc/int64/snips/unicode.hpp Right now it is pretty simple to use: transcode<utf8, utf16le>(forwarditerator, forwarditeratorend, outputiterator, traits [, maximum]); transcode<wchar_encoding, utf32be>(inputrange, outputrange, traits [, maximum]); There is also a codecvt facet which supports any-to-any. Supports UTF-8, UTF-16, and UTF-32, in little or big endian. Has a special wchar_encoding that maps to UTF-16 or UTF-32 depending on your platform. A traits class controls error handling. -- Cory Nelson

11 30

Re: [boost] RFC: interest in Unicode codecs?
by Graham 18 Jul '09

18 Jul '09

Dear Phil, >Having said all that, I must say that I actually use the code that I >wrote quite rarely. I now tend to use UTF8 everywhere and treat it as >a sequence of bytes. Because of the properties of UTF8 I find it's >rare to need to identify individual code points. For example, if I'm >scanning for a matching " or ) I can just look for the next matching >byte, without worrying about where the character boundaries are. Using UTF-8 can work well if you are only targeting American and Western Europe for non-literary use. If you need to support the rest of the world you really need to move to UTF-32 due to the large number of characters and the grapheme and glyph handling [e.g. in Urdu you can type 3 characters and they are displayed as a single combined glyph, and the cursor should never be placed between them]. Even in UTF-8 things can get a bit tricky. For example, where do you break the line if you needed in the middle of: joe)jack -> joe) <br> jack joe(jack -> joe <br> (jack joe+jack -> guess which is the standard ! For programmers we don't mind too much, but when you are writing text editors this can be really important. Now think how many characters there are with special rules on whether they can be split before, after, or never split, and you start to touch on the reason for the Unicode standard and why you need character properties. Yours, Graham

5 4

[convert] Now with Boost.Parameter interface.
by Vladimir.Batov＠wrsa.com.au 16 Jul '09

16 Jul '09

I've incorporated, uploaded to the Vault and started playing with the Boost.Parameter-based interface that Andrey Semashev was insisting from the set-go. And it is definitely growing on me and I like int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true); instead of the original int i = convert<int>::from(str, 0) >> new_locale >> dothrow; I think people generally did not like locales and dothrow behaving like manipulators. The more I use the Boost.Parameter-based interface the more I am inclined to push it further and apply it to manipulators as well. I.e. int i = convert<int>::from(str)(radix_ = 16); instead of the original direct handling of std manipulators. int i = convert<int>::from(str) >> std::hex; Something, again, Andrey was advocating from the start. Now it feels like allowing io-stream manipulators exposes too much implementation detail and raises some unwarranted expectations. That raises a few questions that I am hoping people could help me with: 1. Both interfaces (for locale and dothrow) are currently supported: #1 int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true); #2 int i = convert<int>::from(str, 0) >> new_locale >> dothrow; Should I remove #1? 2. Both interfaces #1 int i = convert<int>::from(str, 0) >> std::hex; #2 int i = convert<int>::from(str, 0)(radix_ = 16); are currently supported. Should I move away from direct manipulator support and remove #1? 3. I only managed to figure out how to supply only one Boost.Parameter at a time like int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true); I understand how to achieve int i = convert<int>::from(str, 0)((locale_ = new_locale, throw_ = true)); (with double quotes) but do not want to go there as it looks somewhat unorthodox. I cannot figure out how to achieve the following int i = convert<int>::from(str, 0)(locale_ = new_locale, throw_ = true); (a list inside single quotes). I remember Andrey mentioning I could do that with a Boost.Parameter macro but I admit of not being bright enough to figure it out by myself. Any help would be greatly appreciated. Thanks, Vladimir.

15 49