- Boost - lists.boost.org

[1.48.0] Proposed Release Schedule
by Beman Dawes 27 Jul '11

27 Jul '11

Give we are already in the middle of July, I feel strongly 1.48.0 should target the first Monday in November, thus putting us back on our usual quarterly cycle. In our earlier schedule discussion, there was some interest in a three times a year release schedule, but the arguments were not convincing to me, so I really think we should keep to our quarterly schedule. The current formula for intermediate dates goes like this: * One week after prior release ships: branches/release opens for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. New libraries may be added with permission of a release manager. * Seven weeks before release: branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries. * Six weeks before release: QA checks on snapshot doc builds, inspect status, getting started guide, and install. * Four weeks before release: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. * Three weeks before release: branches/release closed for all library changes except when specific permission given by release manager(s). * Two weeks before release: Beta target date. Further betas and/or release candidates as feedback dictates. I propose that the Beta be scheduled for *Four* weeks before the release target date. All the other intermediate dates would thus be two weeks earlier. That's more or less what we did for 1.47.0 and it allowed enough time to fix a bunch of bugs in the beta that were bothering users. --Beman

10 13

Lockfree impl comment - does not seem to be compatible with Boost::Interprocess (shared memory) [SEC=UNCLASSIFIED]
by Levy, Gabriel (Contractor) 27 Jul '11

27 Jul '11

UNCLASSIFIED Hi, Since Lockfree library (by Tim Blechmann) is in the review stage I have a comment to make. I only looked at the code just at a glance to check if it would be able to be used with Boost::Interprocess library, especially to be placed in the shared memory and to me it definitely doesn't seem to deduce the pointer types from the Allocation supplied as a template argument. For any container implementation to be useable with Interprocess shared memory the requirement is that any internal pointer types are not explicitly stated - instead they aggregate the pointer types from the Allocator's internal pointer typedefs. By this the container will use "smart" or plain pointers, whichever the Allocators specify/define. Good place to look at for how this should be done is <boost/interprocess/containers/map.hpp> and other containers' implementation in that location. Also the Interprocess documentation explains why, for instance, the std::map or std::vector containers are incorrectly (not generically enough) implemented and suggests a possibility of potential future corrections in STL implementations (that part is only speculative, of course). While in its current form it is already very useful in intra-process applications, I would consider the incompatiblity with Interprocess' shared memory a hugely missed opportunity. My recommendation would be to first to address this issue before accepting it for inclusion. Thank you all so much for the Boost - the best thing that happened to C++. Kindest regards Gabe Gabe Levy Senior Software Engineer, Contractor, Estrings Pty Ltd IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email.

2 1

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