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

hardware interfaces
by Kraus Philipp 20 Jul '11

20 Jul '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, is there any support within Boost for USB devices or anything else? I've found that the ASIO can handle with serial ports (and network interfaces) but my primary question is there a support for other devices ? Thanks a lot Phil -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk4mogUACgkQ6s0Ua5LeGumdHQCdGQrR/YXnio/cvWtHhRBGbUGz k5gAmweGD3Him5X+b8VIsTzYC/pN/cok =+Dhx -----END PGP SIGNATURE-----

1 0

thread safe queue
by Sean Farrow 20 Jul '11

20 Jul '11

Hi: Has anyone written or does anyone know of a thread safe queue that uses boost to allow it to be cross platform? Cheers Sean.

3 4

c2248 with a queue!
by Sean Farrow 20 Jul '11

20 Jul '11

Hi: I'm using a queue written I think as I remember by Antony Williams (sorry if this is incorrect but it was certainly someone in the uk). The code is below, I'm getting 2 c2248 errors indicated by visual c++ 2010 at the last line of the class i.e the line with }; Does anyone know what's causing this? The errors are: 1>d:\dropbox\mackie display reader\surface reader\surface reader\queue.hpp(18): error C2248: 'boost::mutex::mutex' : cannot access private member declared in class 'boost::mutex' c:\program files\boost\boost\thread\win32\mutex.hpp(26) : see declaration of 'boost::mutex::mutex' c:\program files\boost\boost\thread\win32\mutex.hpp(22) : see declaration of 'boost::mutex' This diagnostic occurred in the compiler generated function 'concurrent_queue<Data>::concurrent_queue(concurrent_queue<Data> &)' with [ Data=PmEvent ] 1>d:\dropbox\mackie display reader\surface reader\surface reader\queue.hpp(18): error C2248: 'boost::condition_variable::condition_variable' : cannot access private member declared in class 'boost::condition_variable' c:\program files\boost\boost\thread\win32\condition_variable.hpp(299) : see declaration of 'boost::condition_variable::condition_variable' c:\program files\boost\boost\thread\win32\condition_variable.hpp(295) : see declaration of 'boost::condition_variable' This diagnostic occurred in the compiler generated function 'concurrent_queue<Data>::concurrent_queue(concurrent_queue<Data> &)' with [ Data=PmEvent ] PmEvent is just a standard c structure: typedef struct { PmMessage message; PmTimestamp timestamp; } PmEvent; PmTimestamp and PmMessage are defined as: typedef int32_t PmMessage/PmTimeStamp; any help appreciated. Cheers Sean. --begin code- #include <queue> #include <boost/thread/mutex.hpp> #include <boost/thread/condition_variable.hpp> template <typename Data> class concurrent_queue { private: boost::mutex the_mutex; boost::condition_variable the_condition_variable; std::queue<Data> the_data; public: void push(Data const& data) { boost::mutex::scoped_lock lock(the_mutex); the_queue.push(data); lock.unlock(); the_condition_variable.notify_one(); } }; --end code--

2 2

Integer vs. Double values for link weights in Graph
by Jens Buysse 20 Jul '11

20 Jul '11

Dear all, I'm new to the BOOST library (and actually also to c++). I have the following problem: I want to use the dijkstra algorithm for computing shortest paths in a network. For this I calculate weights, which in my case take the form of double < 1. But it seems internally boost converts to an integer. Is there a way to use double without miltilplying it with e.g. 100 to get Integers? Kind regards Jens Buysse -- Jens Buysse Research Group Broadband Communication Networks (IBCN) Department of Information Technology (INTEC), Ghent University/ IBBT Gaston Crommenlaan 8 bus 201, B-9050 Gent, Belgium tel : +32 9 33 14 942 fax : +32 9 33 14 899 mobile : +32 479 32 21 72 e-mail : jens.buysse(a)intec.ugent.be skype : jens.buysse web : http://ibcn.intec.ugent.be/ web : www.myspace.com/aratf

2 2

Implementing Range Adaptor or "transformation" iterator
by John M. Dlugosz 20 Jul '11

20 Jul '11

I see the documentation "doc/html/range/reference/extending/method_3/method_3_1.html" and want to do something like that. The Adaptor I want to write will transform the elements and provide a lazy transformed view. So, I need the return range to be a pair of transformed iterators, and a transform iterator works just like the underlying iterator only the * operator will apply my function to the value as it fetches it. But, it seems to me that there should be something like that already. Is there something I'm overlooking in STL or in some other Boost library? Thanks, —John

3 6

[fusion] adapted std::pair and ostream
by Daniel James 20 Jul '11

20 Jul '11

Hi The docs: http://www.boost.org/doc/libs/1_47_0/libs/fusion/doc/html/fusion/adapted/st… seem to suggest that one can pipe an adapted std::pair 'directly' to cout. I find the following though: #include <iostream> #include <boost/fusion/adapted.hpp> // adapt pair. #include <boost/fusion/sequence.hpp> // operator<<() ? #include <boost/fusion/container.hpp> // as_vector int main(int argc, char** argv) { std::pair<std::string, int> p("foo", 7); std::cout << p << std::endl; // does not compile although docs suggest it should. std::cout << boost::fusion::as_vector(p) << std::endl; // compiles and works as expected. return 0; } Am I missing an include? Is sending to cout without first using as_vector actually supported? Daniel

3 8

[TTI] Review for The Type Traits Introspection library by Edward Diener **extended**
by Joel Falcou 20 Jul '11

20 Jul '11

The Type Traits Introspection library by Edward Diener started friday 1st have been *extended* to july 17. Comments and reviews are welcome. =========== What is it? =========== The TTI library, which is an abbreviation for the 'Type Traits Introspection' library, allows a programmer to introspect at compile time the inner elements of a C++ type. The introspection process depends on specifying the name of the inner element by different macros for different types of elements, and then using a generated metafunction to determine whether that element exists within the enclosing type. The inner elements which can be introspected are type, class template, member data, member function, static member data, and static member function. The TTI library is based on the type_traits_ext portion of the Concept Traits Library, with improvements and additions, and also reproduces functionality ( without changing existing code ), for the purposes of completeness, from Boost.MPL regarding introspection of types and templates. The purpose of the library is to provide a consistent set of interfaces for doing compile-time introspection of a type, which other template metaprogrammers can use in their code. If you are at all interested in compile-time introspection of types, please take a look at the functionality of this library. =================== Getting the library =================== The library is available at http://svn.boost.org/svn/boost/sandbox/tti/. The HTML documentation is available at http://svn.boost.org/svn/boost/sandbox/tti/libs/tti/doc/html/index.html and the PDF documentation is available at http://svn.boost.org/svn/boost/sandbox/tti/libs/tti/doc/TypeTraitsIntrospec…. =================== Writing a Review =================== The reviews and all comments should be submitted to the developers list, and the email should have "[TTI] Review" at the beginning of the subject line to make sure it's not missed. Please explicitly state in your review whether the library should be accepted. The general review checklist: - 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? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion.

2 1

Limitations / Flaws with transformed_range
by John M. Dlugosz 20 Jul '11

20 Jul '11

I've already noted that the "transformed_range", the class behind boost::adaptors::transform, is not using result_of as documented but seems to be simply looking for result_type, period. I've found another issue, and I consider it a "flaw" because it is a Limitation due to oversight or an artificial restriction, and the deeper workings should handle these cases just fine. Let me explain in detail: The template< class F, class R > struct transformed_range : takes two arguments. The R argument is used for two purposes. It gives the iterator type that will be held, via range_iterator<R>::type. It also gives the exact type of the argument expected by the constructor. Now here is an example from my experiments / work-in-progress: template< class Range > inline transformed_range<ASCII_lower,const Range> operator|( const Range& r, const ASCII_lower_forwarder ) { return transformed_range<ASCII_lower,const Range>( ASCII_lower(), // The underlying transform iterators wants this internal::src_prep(typename std::tr1::is_pointer<Range>::type() ,r) // "source" style argument processing ); } The src_prep is similar to the supplied is_literal, and used for the same purpose. It will package a primitive array as a iterator_range, handing string literals and primitive array objects in the way I intend with respect to nul terminators. It differs from is_literal in several ways, but the idea is the same. Now I don't have to do anything to the Range parameter passed as the type argument to transformed_range, because even when I change the type of the massaged argument, it still has the same underlying iterator type. After all, it gets the iterators from the original range thing passed in. But, the massaged value of r is rejected by the constructor, because it has a different type. It doesn't need to be the same type! It has the same underlying iterator type and could be assigned to it, but the constructor is too strict. It would be a simple matter of passing another template argument to the constructor, as is commonly done with constructors or assignment, and take anything that "works" in that boost::begin and boost::end returns something that can be used to initialize the range_iterator. Copying the class to my own code and changing the constructor to: template <typename R2> transformed_range( F f, R2& r ) : base( boost::make_transform_iterator( boost::begin(r), f ), boost::make_transform_iterator( boost::end(r), f ) ) indeed makes it acceptable to the compiler. (At this point I also noticed that _some_ of the types within the class are qualified by boost::, but not all of them. I know that functions are qualified to prevent argument-dependant lookup, but it is odd that some of the types (or names used in other context) are qualified and sometimes they are not.)

4 7

Re: [Boost-users] [!! SPAM] [wave] Trace output lines with single underscore
by Hartmut Kaiser 20 Jul '11

20 Jul '11

> Many of the rescanning lines in the Wave trace output for a macro I am > tracing show either just a single underscore ( _ ), where the output is > empty, or a number and and underscore ( 1_ ) where it is actually just the > number which is being output. What is the reason for the underscore ? IIRC, the _ is used as a (readable) representation for the (empty) placeholder token, which disappears from the final output, but is helpful for debugging purposes. Regards Hartmut --------------- http://boost-spirit.com

1 0

Boost BCP namespace renaming : dispelling the FUD ?
by BernardH 19 Jul '11

19 Jul '11

Hi, When implementing a library, one might want to neither require nor prevent the library users to also use any version of Boost. I believed that BCP used with namespace renaming would allow the use of (namespace-renamed) Boost in the implementation of such a library without *any* concern about conflict at link time and / or rub-time errors if the library user chooses to also use another Boost version. However, I have been reading that Boost brings some symbols that cannot be renamed because they are out of any namespace, with "C" linkage[*]. This brings the following questions : 1) can a list all such names be found ? 2) To be *completely safe*, must I : 2.1) only avoid using those symbols in my library 2.2) avoid the boost libaries that provide such symbols 2.3) avoid boost libraries that depend on such symbols (how am I to find out which ?) 2.4) avoid boost libraries that depend on the boost libraries providing such symbols (easier to do than 2.3 with bcp, I believe). 2.5) Despair ! (i.e. forgo boost usage under such constraints). Boost is a great set of libraries, I think that it is a pity that a legitimate concern (not imposing a specific Boost version on users) would prevent it's use for implementing libraries : please, help me dispel the Fear, Uncertainty and Doubt over this use case ! Best Regards, Bernard [*] http://stackoverflow.com/questions/2907882/using-concurrently-2-versions-of…

2 2