- Boost - lists.boost.org

[predef] RFC: Predefined version numbers library..
by Rene Rivera 01 Dec '11

01 Dec '11

Long ago, yes, years ago, I proposed normalizing the variety of ways of defining (in the preprocessor) version numbers and reflecting the predefined version information. As can be seen here <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig>. Time traveling to the present I have finally put the finishing touches on the end result of this concept as a "Predef" library. It's now grown to include detection of more types of predefs, almost complete documentation with a reference generated directly from the source, and some utilities on adding new predefs. I'm still working on cross-platform testing. But I thought now would be a good time to ask for comments and for people to try it out. The lib is in the sandbox at <http://svn.boost.org/svn/boost/sandbox/predef>. And the docs can be rad directly from <http://svn.boost.org/svn/boost/sandbox/predef/libs/predef/doc/html/index.ht…>. Enjoy. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

Interest in hardware abstraction layer library
by Szymon Gutaj 01 Dec '11

01 Dec '11

Hi Everyone, please share your comments/interest in a library that would ease writing hardware abstraction layers (HAL's) for complex devices (like large ASIC/FPGA). Here's the description: 1. Let's assume that we've got a memory mapped IO device, controlled via its registers. Each register is divided into few bitfields. Each bitfield controls separate functionality and has its properties, like: read/write/special access, numeral/enumerated value type, value signedness, valid value range(s) etc. All these are typically listed in device's specification: +----------------+--------------+ |Register offset |Register name | +----------------+--------------+ |0x12FE |CONTROL_REG1 | +----------------+--------------+ +--------------+--------------+-------+-----------+------------+ |Bits occupied |Bitfield name |Access |Signedness |Value range | +--------------+--------------+-------+-----------+------------+ |31:25 |TEMPERATURE |RA |SIGNED |- | +--------------+--------------+-------+-----------+------------+ |24:1 |FAN_RPM |WA |UNSIGNED |0:6000 | +--------------+--------------+-------+-----------+------------+ |0:0 |ENABLE |RWA |UNSIGNED |0:1 | +--------------+--------------+-------+-----------+------------+ Note: RA: Read Access, WA: Write Access, RWA: Read/Write Access 2. Let's assume that there's a whole family of these ASICs (subsequent generations/revisions). Each new revision differs from previous one only in few details. The point is that we may have few thousand bitfields per ASIC plus revision changes. Coding such amount of information "by hand" is obviously error-prone. Using text processing (perl/python) to translate the specification to code may obfuscate it's nice tabular format (and may miss features/optimisation offered by metaprogramming). 3. Our goal is to create an abstract interface (HAL). Its implementations would "talk to" corresponding bitfields via inner (intermediate) interface. The purpose of that intermediate code would be to: - present bitfield's name exactly "as is in specification", - extract bitfield's value from its register in a typed, endiannes-correct manner, - enforce correct usage (like forbidding writing read-only fields), - provide value validation, - provide value conversion (enumeration-to-numeral etc.), - provide array-style access if needed, - provide debugging features, - and few more cherries on top. The key point is to have most of this code generated from the specification using only simple regexp (to the form required by proposed library). 4. Code snippet (using specification from point 1) - simple and simplified: Let's create an interface with one member function "operate". Implementation of this function will "talk to" bitfields of CONTROL_REG1 through get<BITFIELD> and set<BITFIELD> functions. These functions (and few other utilities) are being generated by the proposed library, using provided metadata. // Definition of HAL interface --------------------------- namespace some_subsystem { namespace driver { class some_controller { public: virtual bool operate() = 0; }; }} // Definition of bitfields (metadata) -------------------- // Concrete device definition enclosed in a dedicated namespace namespace some_subsystem { namespace driver { namespace asic_ver_123 { // Legend: // BOOST_HAL_DEF_REGISTER_BEG(REGISTER_OFFSET, REGISTER_NAME) // BOOST_HAL_DEF_FIELD(MSBIT, LSBIT, BITFIELD_NAME, ACCESS, SIGNEDNESS, VALIDATOR) // BOOST_HAL_DEF_REGISTER_END() BOOST_HAL_DEF_REGISTER_BEG(0x12FE, CONTROL_REG1) // Register definition BOOST_HAL_DEF_FIELD(30, 25, TEMPERATURE, RA, SIGNED, CTP_ESC(no_check)) // CTP_ESC meant for commas escaping BOOST_HAL_DEF_FIELD(24, 1, FAN_RPM, WA, UNSIGNED, CTP_ESC(range<0, 6000>)) BOOST_HAL_DEF_FIELD(0, 0, ENABLE, WA, UNSIGNED, CTP_ESC(range<0, 1>)) BOOST_HAL_DEF_REGISTER_END() }}} // Definition of HAL implementation ---------------------- namespace some_subsystem { namespace driver { namespace asic_ver_123 { class some_controller_impl : public some_controller { public: virtual bool operate() { bool result = false; // Suitable bitfield type is deduced from its definition (but can be manually overridden) // In this case it will be signed char or bigger (CONTROL_REG1::TEMPERATURE = 6 bits) suitable<CONTROL_REG1::TEMPERATURE>::type temperature = 0; // Library automatically generates the bitfield's getter // which reads the register, masks & shifts unrelated bits, // performs (optional) value conversion and (mandatory) cast. // Debugging/logging also possible result = get<CONTROL_REG1::TEMPERATURE>(temperature); // Pass "temperature" by reference // This would not compile, CONTROL_REG1::TEMPERATURE is read-only // result |= set<CONTROL_REG1::TEMPERATURE>(temperature); // Compile error if(true == result && temperature > 20) { // Library automatically generates the bitfield's setter // which performs read-modify-write with value validation result |= set<CONTROL_REG1::FAN_RPM>(1000); result |= set<CONTROL_REG1::ENABLE>(true); // This would return "false" (7000 is an invalid value for FAN_RPM) // result |= set<CONTROL_REG1::FAN_RPM>(7000); } else { result |= set<CONTROL_REG1::FAN_RPM>(0); result |= set<CONTROL_REG1::ENABLE>(false); } return result; } }; }}} // End of snippet ---------------------------------------------- This snippet shows the very basic functionality, anyway please share your opinions if the idea is catchy and suitable for boost! Best regards, -- Szymon Gutaj

1 0

typos in boost/atomic/details/interlocked.hpp
by Clark Sims 01 Dec '11

01 Dec '11

It looks like there are a lot of typos in this file. It would not compile on Visual Studio 2005 for me. I fixed all the typos, and now I can compile with no problem. There were lots of cases where the author looks like he forgot to add the variable, order, to the argument list of the function. < atomic_thread_fence(memory_order order) --- > atomic_thread_fence(memory_order) Here is a link to my final version of the file: http://acumensoftwareinc.com/interlocked.hpp Here is the diff of the 2 versions: 10d9 < #include <boost/memory_order.hpp> 33c32 < platform_fence_before(memory_order order) --- > platform_fence_before(memory_order) 38c37 < platform_fence_after(memory_order order) --- > platform_fence_after(memory_order) 43c42 < platform_fence_before_store(memory_order order) --- > platform_fence_before_store(memory_order) 55c54 < platform_fence_after_load(memory_order order) --- > platform_fence_after_load(memory_order) 57,58c56,57 < if (order == memory_order_seq_cst) { < x86_full_fence(); --- > if (order == memory_order_seq_cst()) { > x86_full_fence(void); 89c88 < atomic_thread_fence(memory_order order) --- > atomic_thread_fence(memory_order) 91,92c90,91 < if (order == memory_order_seq_cst) { < detail::atomic::x86_full_fence(); --- > if (order == memory_order_seq_cst()) { > detail::atomic::x86_full_fence(void)

1 0

Library categories
by Vicente J. Botet Escriba 30 Nov '11

30 Nov '11

Hi, I was wondering if we can add other categories to the library catalog (http://www.boost.org/users/history/version_1_47_0.html) Here is a proposal Best, Vicente Domain Specific crc - Cyclic Redundancy Code, from Daryle Walker. units - Zero-overhead dimensional analysis and unit/quantity manipulation and conversion, from Matthias Schabel and Steven Watanabe. uuid - A universally unique identifier, from Andy Tompkins. Idioms base-from-member - Idiom to initialize a base class with a member, from Daryle Walker. compressed_pair - Empty member optimization, from John Maddock, Howard Hinnant, et al. Language Emulation: these are libraries are emulating a missing language feature exception - A library for transporting of arbitrary data in exception objects, and transporting of exceptions between threads (N2179), from Emil Dotchevski. move - Portable move semantics for C++03 and C++1 compilers, from Ion Gaztañaga scope_exit - Execute arbitrary code at scope exit, from Alexander Nasonov. typeof - Typeof operator emulation, from Arkadiy Vertleyb and Peder Holt. Patterns: libraries that implement a known pattern flyweight - Design pattern to manage large quantities of highly redundant objects, from Joaquín M López Muñoz. signals - managed signals & slots callback implementation, from Doug Gregor. signals2 - managed signals & slots callback implementation (thread-safe version 2), from Frank Mori Hess. State Machines meta state machine - High-performance expressive UML 2.0 finite state machines, from Christophe Henry. statechart - Arbitrarily complex finite state machines can be implemented in easily readable and maintainable C++ code, from Andreas Huber. System: libraries that are close to the underlying system chrono - Useful time utilities, from Howard Hinnant, Beman Dawes, Vicente J. Botet Escribá. date_time - Date-Time library from Jeff Garland. filesystem - Portable paths, iteration over directories, and other useful filesystem operations, from Beman Dawes. system - Operating system support, including the diagnostics support that will be part of the C++0x standard library, from Beman Dawes. I would add also the following to exixting categories Data structures optional - Discriminated-union wrapper for optional values, from Fernando Cacciola. tribool - 3-state boolean type library, from Doug Gregor. I have no suggestion for the following, so we can maintain them in Miscellaneous conversion - Polymorphic and lexical casts, from Dave Abrahams and Kevlin Henney. swap - Enhanced generic swap function, from Joseph Gauterin. timer - Event timer, progress timer, and progress display classes, from Beman Dawes. TR1 - An implementation of the Technical Report on C++ Library Extensions, using other Boost libraries as a basis, from John Maddock. utility - Class noncopyable plus checked_delete(), checked_array_delete(), next(), prior() function templates, plus base-from-member idiom, from Dave Abrahams and others. value_initialized - Wrapper for uniform-syntax value initialization, from Fernando Cacciola, based on the original idea of David Abrahams. The following libraries are already in another category lexical_cast - General literal text conversions, such as an int represented as a string, or vice-versa, from Kevlin Henney. numeric/conversion - Optimized Policy-based Numeric Conversions, from Fernando Cacciola. program_options - Access to configuration data given on command line, in config files and other sources, from Vladimir Prus.

7 18

[rfc] lockfree API/naming suggestions
by Tim Blechmann 30 Nov '11

30 Nov '11

hi all, i am preparing boost.lockfree so that it can be merged to trunk. however i'd request some suggestions, concerning interface and names: ringbuffer naming: there is a fixed-sized single-producer/single-consumer wait-free queue, which is implemented as ringbuffer. the linux kernel uses the name `kfifo', the jack-audio-connection-kit refers to it as `ringbuffer', herlihy/shavit discuss it under the name `BoundedQueue'. the boost.lockfree implementation is currently named `ringbuffer', but i could rename it before merging it into trunk. suggestions: ringbuffer waitfree_queue spsc_queue bounded_queue personally i'd be in favor of `ringbuffer' (because i have been using this name for years) or `spsc_queue' (because it makes clear that it doesn't support multiple produces/consumers). but i'd be curious, what other people suggest. fifo/queue bounded push: fifo and queue can be configured to use a dynamically growing freelist for memory management. in this case, the `push' operations may block if the freelist is exhausted and a new node has to be allocated from the OS. currently this can be avoided by a per-class policy. however it would be reasonable to move this policy from a per-class to a per- call policy. so instead of: queue<T, boost::lockfree::bounded<true> > q; T t; q.push(t); one could write: queue<T> q; T t; q.push_nonblocking(t); however this would imply 3 flavors of `push' * push, which may block during memory allocation * push_unsafe, which is not thread-safe (but faster) * push_nonblocking, which is guaranteed not to hit the memory allocator. so i am not sure, whether this introduces too much complexity into the API. any thoughts/comments? thanks, tim

5 8

installing 1.48 on debian squeeze
by Janek Kozicki 30 Nov '11

30 Nov '11

Hi, does anybody here know some not too complex way to install boost 1.48 on debian squeeze? Preferably using a .deb package. manual install is also acceptable, but in a way where it will not conflict with native installed boost 1.42. looking forward for your help -- Janek Kozicki http://janek.kozicki.pl/ |

2 1

[spirit] scan_keyword: scan an InputIterator for a keyword.
by Vicente J. Botet Escriba 30 Nov '11

30 Nov '11

Hi, for chrono input I'm using a scan_keyword function that adapted from libc++ library (you can find the code in[1]). Next follows the interface: // scan_keyword // Scans [b, e) until a match is found in the basic_strings range // [kb, ke) or until it can be shown that there is no match in [kb, ke). // b will be incremented (visibly), consuming CharT until a match is found // or proved to not exist. A keyword may be "", in which will match anything. // If one keyword is a prefix of another, and the next CharT in the input // might match another keyword, the algorithm will attempt to find the longest // matching keyword. If the longer matching keyword ends up not matching, then // no keyword match is found. If no keyword match is found, ke is returned // and failbit is set in err. // Else an iterator pointing to the matching keyword is found. If more than // one keyword matches, an iterator to the first matching keyword is returned. // If on exit b == e, eofbit is set in err. // Examples: // Keywords: "a", "abb" // If the input is "a", the first keyword matches and eofbit is set. // If the input is "abc", no match is found and "ab" are consumed. template <class InputIterator, class ForwardIterator> ForwardIterator scan_keyword(InputIterator& b, InputIterator e, ForwardIterator kb, ForwardIterator ke, std::ios_base::iostate& err ); What is the better way to do that (or something similar) with Spirit/Lexer? Can we hope that the Spirit solution could perform much better? What about if the strings to parse are know at compile-time? [1] https://svn.boost.org/svn/boost/trunk/boost/chrono/detail/scan_keyword.hpp Best, Vicente

2 3

temp_ptr<> - preventing use as a member
by Gottlob Frege 29 Nov '11

29 Nov '11

I'm trying to see if I can replace all raw pointers with suitable smart pointers that clearly describe the pointer's lifetime, sharing, etc. For example, a pointer passed into a function, that is only valid for the lifetime of the function call. A temp_ptr or callstack_ptr or ... some better name. So this pointer would need a copy constructor so it can be passed along into a function (I don't think requiring a ref to the pointer would be good; I'd rather pass by value). It would also need construction from a raw pointer, but to avoid having a temp_ptr being kept beyond the function call, it would not have assignment (from another temp_ptr). To prevent constructing one via the copy constructor that will be kept around, I can define a custom new operator but keep it private. The only thing, I think, that I can't prevent, is construction of a new wrapper struct that has a temp_ptr as a member (which is copy constructed in wrapper's constructor). Can anyone think of a way to prevent that? I think anyone that goes out of their way to make a wrapper struct gets what they deserve, so I don't really *need* to prevent all bad uses. But I can aslo imagine someone just using it improperly inside their class due to misunderstanding or whatever. And thoughts on the goal of specific smart pointers for all occasions? Tony

6 11

[trac] please add component
by Akira Takahashi 29 Nov '11

29 Nov '11

Hi, I seems to so that the 1.48.0 library component is not registered in Trac(container, move, and locale). Please add component.

2 2

[optional] std::tr2::optional
by Andrzej Krzemienski 29 Nov '11

29 Nov '11

Hi, I use boost::optional quite often, find it very useful, and cannot imagine that it could not get into TR2. I am considering writing a proposal for adding it myself (if it is possible to propose things without attending the committee meetings), but I would first want to know how boost::optional could be improved given the new features in C++11. I provide a list of modifications that I could think of. What is your opinion? * Conversion explicit conversion to bool should be declared as explicit. * Should exception safety guarantees for assignment operations be enforced? In boost::optional they only provide a basic guarantee. One option is to provide strong guarantee for types T which implement operator= with strong guarantee, and give basic guarantee for other cases Other option (not sure if it is possible) is to provide strong guarantee for all cases at the cost of run-time performance (heap allocation). * Add move operations optional<T> & operator=( optional<T> && ) noexcept( nothrow_move_constructible<T>::value ); optional<T> & operator=( T && ) noexcept( nothrow_move_constructible<T>::value ); * move operations for optional references? But I am not sure what optional references are for... * What are optional references for anyway? * it could add an rvalue reference overload for stored object access: T&& operator*( ) && However using this overload implies that the user is not checking if an optional has been initialized, so it may encourage a bad practice. * Are in-place factories necessary if we have perfect forwarding? Instead, we can provide a reset function and a "variadic constructor": template< typename ... Args > void reset( Args&& ...args ); template< typename ... Args > optional( Args&& ...args ); The constructor will clash with another optional constructor: optional<T>::optional( bool cond, const T& val ); but perhaps it is not needed if we have std::optional<T> std::make_optional( bool cond,const T& val ); and move construction of optionals? * noexcept default construction and destroy operations * constexpr default ctor * Use nullptr instead of boost::none? - this will make some uses of optional pointers harder, but will make usage more clear in other cases. Regards, &rzej

7 7