July 2011 - Boost - lists.preview.boost.org

[regex] How robust are the <boost/regex/pending/unicode_iterator.hpp> adapters?
by Beman Dawes 26 Jul '11

26 Jul '11

Boost.Filesystem needs the UTF-32 to UTF-16 and UTF-16 to UTF-32 adapters to implement char16_t and char32_t support. Do they have any known bugs or other outstanding problems? TIA, --Beman

7 20

Re: [boost] [range] Should ranges really propagate constess to the data ?
by Brian Wood 25 Jul '11

25 Jul '11

Date: Mon, 25 Jul 2011 10:01:09 +0200 From: Thorsten Ottosen <thorsten.ottosen(a)dezide.com> To: boost(a)lists.boost.org Subject: Re: [boost] [range] Should ranges really propagate constess to the data ? Message-ID: <4E2D22C5.7050701(a)dezide.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Thorsten Ottosen: >Den 24-07-2011 16:04, Mathias Gaunard skrev: >> >> I thought that was the point of sub_range: to be the same as >> iterator_range, except the template parameter it takes is a range rather >> than an iterator, simplifying things when only ranges and not iterators >> are involved. >> > > + propagation of constness. > > Consider using sub_range<T> as the type of a member variable. > > It would be very annoying in some cases that we cannot return a view > that is const-correct and which requires us to construct a temporary > view instead of just returning a reference to the existing view. > The divergent opinions on sub_range in this thread convinced me to add marshalling support for iterator_range to the code generator I'm working on and I've now done so. Previously I had only added support for sub_range. Regards, Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0

[quickbook] Revision 73337 doesn't compile with msvc-10.0
by Robert Kawulak 25 Jul '11

25 Jul '11

Here's the relevant part of the output: S:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\deque(795) : error C202 7: use of undefined type 'quickbook::id_generator::placeholder' s:\program files\boost_trunk\tools\quickbook\src\id_generator.hpp(36) : see declaration of 'quickbook::id_generator::placeholder' s:\program files\boost_trunk\tools\quickbook\src\id_generator.hpp(40) : see reference to class template instantiation 'std::deque<_Ty>' being compiled with [ _Ty=quickbook::id_generator::placeholder ] Best regards, Robert

1 0

[quickbook] Template issues
by Robert Kawulak 25 Jul '11

25 Jul '11

Hi, I have some problems using QuickBook templates. This code: [article test [quickbook 1.5]] [template link_example[name] [@[name] [name]] ] [link_example some_link] Generates: <ulink url="[name">[name</ulink> some_link] Which is obviously not what's expected. The second issue is with the code: [article test [quickbook 1.5]] [template import_example[name] [import ../temp/[name].cpp] [[name]] ] [import_example example] This generates the following error: Generating Output File: test.xml ../temp/[name: error: Could not open input file. Error: Error count: 1. Are these the fault of QuickBook or am I doing something wrong? (I'm using trunk revision 73337.) Thanks and best regards, Robert

1 0

[ggl] Congratulations
by Simonson, Lucanus J 25 Jul '11

25 Jul '11

Barend, I wanted to congratulate you on the release of your library as a part of boost. I know how hard and how long you've worked for this and your efforts are commendable. The community you have built around the library is healthy, vibrant and growing. I wish you the best continuing success. Regards, Luke

2 1

[lexical_cast] broken for std::vector<char> since last updates
by Jürgen Hunold 25 Jul '11

25 Jul '11

Hi, the last patches to lexical_cast broke some of my code which uses lexical_cast to parse values from std::vector<char> Something as simple as std::vector<char> buffer; return boost::lexical_cast<int>(&buffer[0]); fails with BOOST_ROOT/boost/lexical_cast.hpp:1091:43: error: no matching constructor for initialization of 'std::basic_ostream<char>' std::basic_ostream<CharT> stream(&stringbuffer); ^ ~~~~~~~~~~~~~ this is the start of the clang diagnostic. Both gcc (Ubuntu 4.6.0-3~ppa1) 4.6.1 20110409 (prerelease) and clang version 3.0 (trunk 135897) output contained in attached testcase. Btw. are there any lexical tests in Boost? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

3 4

[locale] UTF Iteration and conversion
by Artyom Beilis 25 Jul '11

25 Jul '11

Hello All, Following this discussion: [regex] How robust are the <boost/regex/pending/unicode_iterator.hpp> adapters? http://thread.gmane.org/gmane.comp.lib.boost.devel/221643 Boost.Locale will ship **header-only** utf_to_utf conversion functions and provide operations that would allow implementing iteration over UTF-XX sequences. This was one of the review requests and it will be integrated in few days into trunk. Functions: namespace boost { namespace locale { namespace conv { template<typename CharOut,typename CharIn> std::basic_string<CharOut> conv::utf_to_utf(CharIn const *begin,CharIn const *end,method_type how=skip); template<typename CharOut,typename CharIn> std::basic_string<CharOut> conv::utf_to_utf(CharIn const *str,method_type how=skip); template<typename CharOut,typename CharIn> std::basic_string<CharOut> conv::utf_to_utf(std::basic_string<CharIn> const &str,method_type how=skip); }}} // boost::locale::conv Also it would provide basic utf encoding/decoding operations that would allow to create iterators over generic streams namespace boost { namespace locale { namespace utf { typedef uint32_t code_point; static const code_point illegal = ... ; static const code_point incomplete = ... ; // Get one code point from UTF stream template<typename InputIterator> code_point decode(InputIterator &p,InputIterator e); // Write one code point to UTF stream template<typename OutputIterator> Iterator encode(code_point u,OutputIterator e); // Get size of code point in basic unit template<typename CharType> int units_in_code_point(code_point u); }}} // boost::locale::utf It should be ready very soon... Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

1 0

[asio] gcc visibility support patch
by Jürgen Hunold 25 Jul '11

25 Jul '11

Hi, I've found some missing patches for https://svn.boost.org/trac/boost/ticket/2114 This one enables visibility support for Boost.Asio For more information, please see http://gcc.gnu.org/wiki/Visibility Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

3 5

[lockfree review] rfc: naming and interface
by Tim Blechmann 25 Jul '11

25 Jul '11

hi all, i am starting a new thread, because i want to start a new discussion on one aspect of boost.lockfree: the naming of the data structure and the interface naming: the current names of the data structures are fifo, stack and ringbuffer. during the pre-review some people suggested to use different names, lifo instead of stack or queue instead of fifo. in general i think it is a good idea to use a consistent naming (probably fifo should be renamed to queue), but how does the ringbuffer come in? it is a queue as well, but with different characteristics (spsc and wait-free). data structure configuration: stack and fifo currently use 3 template arguments: T for the managed type, freelist_t as a tag to select the underlying freelist and Alloc as the allocator which is used for the internal nodes: template<typename T, typename freelist_t = caching_freelist_t, typename Alloc = std::allocator<T> > class fifo/stack; however i have been thinking about replacing it with a boost.parameter interface, something like: template<typename T, ... Options> class fifo/stack; with the options: boost::lockfree::freelist_can_allocate<true/false> to disable memory allocation during enqueue/push boost::lockfree::allocator<> to specify the allocator ringbuffer size: the ringbuffer currently has the signature: template<typename T, size_t max_size> class ringbuffer; if max_size is 0, the size of the ringbuffer can be configured at run-time with a constructor. this is not really the cleanest interface, but i would like to provide an interface, which supports both compile-time and run-time setting of the size. i would apprechiate a discussion about these points during the review. thanks, tim

7 10

Re: [boost] Bugs in regression/library_status.cpp on Windows
by Robert Kawulak 24 Jul '11

24 Jul '11

Hi, Could anybody please apply that patch or suggest what can I do (or whom to contact directly) to get this fixed? BTW, I wonder how it's possible that most of the bugs were introduced in one commit half a year ago and nobody even noticed - it would suffice to run this app on any platform to get obvious errors while on Windows it wouldn't even compile. Am I really the only person using this tool? :P I've also found another minor problems: - when building it, "$(BOOST_ROOT)\tools\regression\build\bin" directory is created but it's not marked with "ignore" in SVN; - char_xlate functor only translates '/' character in URLs while on Windows the character used is '\' (and it also causes problems in some browsers). The solution is very simple - add "|| c = '\\'" in line 75. I'm attaching a patch file combining the previous fixes and the '\' translation. Best regards, Robert > -----Original Message----- > From: Robert Kawulak [mailto:Robert.Kawulak@gmail.com] > Sent: Saturday, July 09, 2011 11:35 PM > To: 'boost(a)lists.boost.org' > Cc: 'bdawes(a)acm.org'; 'blelbach(a)cct.lsu.edu' > Subject: Bugs in regression/library_status.cpp on Windows > > Hello, > > I've stumbled upon several bugs in > tools/regression/src/library_status.cpp when compiling on Windows with > gcc 4.5 and msvc 10.0. I'm attaching a patch file with all necessary > fixes. The bugs are: > > - using path::native() instead of path::string() - the former is > wstring on Windows, > - calling path::string() twice to obtain begin() and end() iterators - > on Windows path::string() returns a temporary, so the iterators point > to different objects, > - using whole path for each node in build_node_tree() instead of only > the directory name, > - using whole path instead of only the test name in do_table_body(), > - the link to links file is relative to test directory, not to the > results output directory, > - generation of closing "</a>" without opening "<a>". > > Best regards, > Robert

1 0