July 2011 - Boost - lists.boost.org

BOOST_CLASS_EXPORT in C++
by Eric Maes 27 Jul '11

27 Jul '11

Hello all, I am new to the boost community and libraries and need some help. I am taking over a small project which uses boost serialization. We are having trouble using the BOOST_CLASS_EXPORT macro with version 1.39. We are in the process of upgrading to v1.47, but have not yet complete the transition on our other supporting DLLs. My question is this: When we include the macro in our CPP file, it builds ok and appears to be ready to rock, however when we attempt to serialze the object, an exception is thrown. after stepping deeply, we see that the derived class load_construct_data and save_construct_data methods are not getting called. We have followed the documentation and it appears we have it implemented properly. Shown here are code snippets of what we are doing... When the macro use was in the HPP files, the serialization worked, but then an exception was thrown when the application ends. Either way, there is an issue. From what I can tell in boost docs, the macro use needs to be in the CPP and not in the HPP If anyone can give assistance that would be great. I am so new to Boost that I'm not sure I am using the right nomanclature to describe what is occuring. Any help that I can get will be much appreciated. Eric emaes(a)miengsrv.com // ************ derived class (Calculator) load/save definition ********* // template inline void save_construct_data (Archive& ar, const LpsTktMDO::Calculator* t, const unsigned int file_version) { // save data required to construct instance Lps::CharString name; Lps::CharString expression; name=t->getName (); expression=t->getExpression (); ar << boost::serialization::make_nvp ("name", name); ar << boost::serialization::make_nvp ("expression", expression); } //! //! Serialization method for loading a Calculator object //! //! \return None //! template inline void load_construct_data (Archive& ar, LpsTktMDO::Calculator* t, const unsigned int file_version) { // retrieve data from archive required to construct new instance Lps::CharString name; Lps::CharString expression; ar >> boost::serialization::make_nvp ("name", name); ar >> boost::serialization::make_nvp ("expression", expression); // invoke inplace constructor to initialize instance of my_class ::new(t)LpsTktMDO::Calculator (name, expression); } // ************ base class (Function) serialize definition ********* // template void serialize (Archive & ar, const unsigned int version) { ar & BOOST_SERIALIZATION_NVP (theNameM); ar & BOOST_SERIALIZATION_NVP (thePmmIdM); ar & BOOST_SERIALIZATION_NVP (theDataMgrM); }; // ************ call to serialize the map of calculator/function objects (which is a member of a PreDef object) ********* // template void serialize (Archive & ar, const unsigned int version) { ar & BOOST_SERIALIZATION_NVP (theDesignVariablesM); // <<-------- this works ar & BOOST_SERIALIZATION_NVP (theVariablesM); // <<-------- this works ar & BOOST_SERIALIZATION_NVP (theFunctionsM); // <<-------- this call issues the exception! ar & BOOST_SERIALIZATION_NVP (theDataMgrM); // <<-------- this works }; // ************ call to serialize the PreDef object ********* // BOOST_CHECK_NO_THROW(theOa << BOOST_SERIALIZATION_NVP(thePreDefM)); -- View this message in context: http://boost.2283326.n4.nabble.com/BOOST-CLASS-EXPORT-in-C-tp3696005p369600… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[lockfree] review
by Artyom Beilis 27 Jul '11

27 Jul '11

Hello, Please consider it as a 1/2 or 1/3 review as I hadn't much time to review this library: I'd start answering the questions in little bit different order: ------------------------------------------------------ - What is your evaluation of the design? Basically it looks quite simple and straight forward. As the data structures are based (according to the author) on the current papers and studies; it uses quite standard features and seems fine. ------------------------------------------------------ - What is your evaluation of the implementation? It seems to be clear, however I miss following: As it is virtually impossible to test concurrent data structures I expect that every critical part in the code that describes concurrent operation would have a reference to specific article or book and include full description and even a small proof that it is right taken from the resources. I think it is very critical for maintenance of the library and in ensuring the fact that it can be maintainable. Finally it looks like a solid code written with good knowledge of what is going on. ------------------------------------------------------ - What is your evaluation of the documentation? I think it is too brief and misses important parts. For example: html/boost/lockfree/ringbuffer.html Should include in the reference general requirements like it should be single writer single reader and not mentioned in some other places. In the first glance I assumed that it was multiple-readers-writers ring buffer. ------------------------------------------------------ - Did you try to use the library? With what compiler? Did you have any problems? I've tested it with gcc-4.3 on cygwin using CMake scripts,no particular problems. ------------------------------------------------------ - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I've spend 2-3 hours reading the code, comparing my own "ringbuffer" with a provided ring buffer and fifo. ------------------------------------------------------ - What is your evaluation of the potential usefulness of the library? ok... This is probably the biggest problem with this library. I understand that Linked List, Stack, Ring are actually the implementable data structures (most of others are much harder to do if possible at all, even thou there are few that can be implemented: hash tables and some others) I understand that this is "lock-free" library not generic-concurrent-data-structures library but this is why I think that it may not be as useful as it seems. I'd like to see more: 1. Queues with OS support like waiting - non-waiting with lock-free access when the queue not-empty and not-full 2. Queues with different optimization for different cases. 3. There are several ways to optimize stacks to reduce contention. 4. Some transactional memory blocks that allow to implement optimistic strategies 5. Combination of locking and lock-free parts. 6. Hash tables And more. ------------------------------------------------------ - Are you knowledgeable about the problem domain? Yes: - I had implemented several concurrent data structures for professional needs. - I had took Prof. Nir Shavit's course in concurrent programming (The author of the The Art of Multiprocessor Programming) ------------------------------------------------------ Should the library be accepted into Boost? I have doubts, mostly because my considerations about the usability of the library in the real applications. I'd expect the author to provide more data structures more available policies, for example there are several ways to optimize stack object see "The Art of Multiprocessor Programming" chapter 11 section 4. Also I'd like to see some more helpful objects in the interface: Tagged ptr is something that would be seen for many data structures I don't think should it be in details? I really hesitate between "Conditional YES" and "YES" - Finally it seems to be doing what it does - It is not concurrent data structures library but lock-free one. So I vote "Yes" but I strongly recommend and expect from the author: - Make some building blocks available in detains to library interface allowing users to implement other data-structures easier. - Improve documentation about what and how it should be done - Provide more data structures in future and provide data structures with different policies Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

3 2

Boost.Locale 'Status'?
by Joshua Boyce 27 Jul '11

27 Jul '11

I was wondering what the 'status' of the Boost.Locale library is now that it has been accepted into Boost. I can't see it on the SVN, what are the current plans for its integration into mainline Boost? Thanks.

4 12

[chrono] gcc visibility support patch
by Jürgen Hunold 27 Jul '11

27 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.Chrono 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 !

2 2

[Opaque] Request for interest in Opaque typedefs library emulation
by vicente.botet 27 Jul '11

27 Jul '11

Hi, I have started to play with a class to define opaque typedefs on funcdamental types. It is based on the C++ proposal " Progress toward Opaque Typedefs for C++0X" by Walter E. Brown http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1706.pdf Please take a look on the preceding links to understand the motivation. Boost.Sericalization provide a BOOST_STRONG_TYPEDEF already, but in my opinon the implementation is not complete,as only the order operators are defined (But maybe I'm wrong). Evidently it can not provide everything we can have with a language approach, but IMO this could yet be useful. The library include two class templates (CRTP) to define opaque types: * public_opaque_type<OT,UT> : implicit conversion from OT to UT * private_opaque_type<OT,UT> : no conversion from OT to UT An opaque type (OT) is a new type, different from the underlying type (UT) and other OT. It defines explicit constructor from the UT, and defines all the operators the UT support but this time applied to the OT. To define a new OT with this mixin classes struct serial_number: public_opaque_type<serial_number, unsigned> { BOOST_OPAQUE_PUPLIC_FORWARD_CONSTRUCTORS(serial_number,unsigned); }; struct game_score: private_opaque_type<game_score, unsigned> { BOOST_OPAQUE_PRIVATE_FORWARD_CONSTRUCTORS(game_score,unsigned); }; In addition, defines macros that make this simpler BOOST_OPAQUE_PUBLIC_TYPEDEF(unsigned, serial_number); BOOST_OPAQUE_PRIVATE_TYPEDEF(unsigned, game_score); Next follows the definition of the public_opaque_type template <typename Final, typename T> class public_opaque_type : boost::totally_ordered< Final , boost::integer_arithmetic< Final , boost::bitwise< Final , boost::unit_steppable< Final , boost::totally_ordered< T, Final // public specific conversions , boost::integer_arithmetic< T, Final // public specific conversions , boost::bitwise< T, Final // public specific conversions > > > > > > > { protected: T val_; typedef public_opaque_type opaque_type; public: typedef T underlying_type; explicit public_opaque_type(const T v) : val_(v) {}; public_opaque_type() {}; public_opaque_type(const opaque_type & rhs) : val_(rhs.val_) {} public_opaque_type & operator=(const opaque_type & rhs) { val_ = rhs.val_; return *this; } public_opaque_type & operator=(const T rhs) { val_ = rhs; return *this; } T const& underlying() const { return val_; } T& underlying() { return val_; } operator const T & () const { return val_; } operator T & () { return val_; } #if 0 bool operator==(const opaque_type & rhs) const { return val_ == rhs.val_; } #endif bool operator<(const Final & rhs) const { return val_ < rhs.val_; } Final& operator+=(const Final & rhs) { val_ += rhs.val_; return static_cast<Final&>(*this); } Final& operator-=(const Final & rhs) { val_ -= rhs.val_; return static_cast<Final&>(*this); } ... }; I have started to make some tests and it works well for the moment. Limitations: * As we can not specialize the behaviour of static_cast/dynamic_cast the library sould provide two specific casts opaque_static_cast and opaque_dynamic_static_cast (Not yet implemented). * As operator.() can not be overloaded, it works transparently only for underlying types that don't defines member functions (C++ fundamental types, as int, char, ...). For the others an explicit use of the underlying() member function is needed :( * Others I have not catched yet :( Do you think it is worth continuing? Please, let me know if you see a error on the design. _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 8

[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