- Boost - lists.boost.org

shared_ptr<>: why no operator[] ?
by dgwsoft 27 Jul '11

27 Jul '11

boost::shared_ptr<int> p(new int(42)); To access elements of the array I can do: p.get()[10] = 7; But wouldn't it be nicer to do: p[10] = 7; // ? So: why is no T& operator[](int) defined for shared_ptr ? I'm just interested in the design reasons for this. cheers Gareth -- View this message in context: http://boost.2283326.n4.nabble.com/shared-ptr-why-no-operator-tp3697208p369… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 5

[Review] Lockfree review: two more days left
by Hartmut Kaiser 26 Jul '11

26 Jul '11

Hi all, We have two more days left for the review of Tim Blechmann's Lockfree library. If you're interested in this library, please consider contributing a review! Please see the original (slightly corrected) announcement below: ----------------------------------------------------- About the library: Boost.Lockfree provides implementations of lock-free data structures. Lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. Lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. The following data structures are provided: - boost::lockfree::fifo, a lock-free fifo queue - boost::lockfree::stack, a lock-free stack - boost::lockfree::ringbuffer, a wait-free single-producer/single-consumer ringbuffer. The library is accessible from here: http://tim.klingt.org/boost_lockfree.tar.gz. Boost.Lockfree depends on C++0x atomics. They are not well supported with current compilers yet. For this reason Boost.Lockfree depends on the *unreviewed* Boost.Atomic library, that emulates C++0x atomics for C++98. This review is about Boost.Lockfree and not about Boost.Atomic, although it is included in the tarball and the git repository. If Boost.Lockfree will be accepted, it won't be merged into trunk before Boost.Atomic is accepted. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

3 2

[range] Should ranges really propagate constess to the data ?
by Samuel Debionne 26 Jul '11

26 Jul '11

Hello everyone, Here is an example code that motivates my question : typedef std::vector<int> vector_t; boost::sub_range<vector_t> three_first(vector_t& _v) {return boost::make_iterator_range(_v.begin(), _v.begin() + 3); } int main(int argc, char* argv[]) { vector_t v; boost::fill(three_first(v), 1); // Fail : you cannot assign to a variable that is const return 0; } Taken from Boost.GIL documentation, the definition of image views is : An image view is a generalization of STL's range concept to multiple dimensions. Similar to ranges (and iterators), image views are shallow, don't own the underlying data and don't propagate their constness over the data. For example, a constant image view cannot be resized, but may allow modifying the pixels. For pixel-immutable operations, use constant-value image view (also called non-mutable image view). I expected the range concept to follow these lines regarding constness, but I'm not very sure anymore... for instance sub_range have : iterator begin() { return base::begin(); } *const_iterator* begin() const { return base::begin(); } and boost::begin() is : inline range_iterator<T>::type begin( T& r ) {...} inline range_iterator<*const* T>::type begin( const T& r ) {...} which means that I'm probably wrong. Am I missing something ? Regards, Samuel

7 15

[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