- Boost - lists.boost.org

thread_specific_ptr<void>
by Edd Dawson 08 Jan '08

08 Jan '08

Hello, Currently one cannot create a thread_specific_ptr<void> as the return type of thread_specific_ptr<void>::operator* would be void&. So is there any technical reason that we cannot do the same trick as with shared_ptr? i.e. have operator* return a thread_specific_ptr_traits<T>::reference, which would be void in the thread_specific_ptr_traits<void> specialisation, allowing client code to compile so long as operator* is not called. I'd be happy to put a patch together (against the SVN trunk, I assume?). Kind regards, Edd

2 5

Re: [boost] upcoming Switch library review Jan 5th - Jan 9th
by Steven Watanabe 08 Jan '08

08 Jan '08

AMDG "Stjepan Rajko" <stipe(a)asu.edu> wrote: > Hi Alexander, > > Thanks for the example and the assembly analysis. Off the top of my > head, it doesn't seem like it would be too difficult to add support > for fall-through directly (e.g., by taking an (optional?) sequence of > MPL bool constants to specify whether a case should fall through or > break/return). Although, the difficult part might be deciding how to > deal with return values in this case. > > Steven, what do you think? > Of course, we can't use the return value of a case that should fall through to the next case... For non-void return types we could make an actual return type of void indicate fallthrough. Hmmm... That seems too error prone. How about creating a fallthrough_t for the return type? In Christ, Steven Watanabe

1 0

Simple script for checking each header file alone for proper inclusions, ...
by Jens Seidel 08 Jan '08

08 Jan '08

Hi, as most of you know I check from time to time public header files in trunk for proper inclusions and other errors. I most of the time use a g++ 4.3 snapshot and strongest compiler warning options to avoid getting errors or warnings in user code once a new version of Boost is released. There are still many bugs pending in Trac and most are ignored since more than 3 months but John asked me to publish my script. It is indeed very simple but finds nervertheless sufficient errors to be useful. It can probably be extended to check for circular dependencies, ... The usage is simple: Just start boost-check from boost/ with option -l followed by the directoy you want to test: $ ../boost-check -l iostreams It outputs each header file it checks together with possible compiler output (warnings and errors). As I start it in a Linux environment I have to skip all win32 related files as these will create errors (missing windows.h, ...). All files to be skipped can be added to a file (I call it "skip") which is respected by the script. Also all files which include skipped files will be skipped. Once an error is found I prefer to open the file in the vim editor so that I can inspect the problem. vim supports the command ":make" which calls a trivial Makefile (in /tmp) and jumps to all errors and warnings (usual :cw, :cn, :cN commands). I currently commented the call to vim out but you can outcomment it at the end of the script again. I doubt that it will currently be useful for others as I tested already all libraries with active maintainer but you maybe want to test current code changes prior to commit with it (so it found e.g. today an error in iostream introduced during the last hours). Jens

3 3

libXXX
by Lars Schouw 08 Jan '08

08 Jan '08

How come my source code that uses boost wants a libXXX in front of the libraries but boost was build without it. Lars ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

3 2

Re: [boost] Visual Studio 2008
by Lars Schouw 08 Jan '08

08 Jan '08

I seem to have been blind the file was build and is there.. Lars ----- Original Message ---- From: Lars Schouw <schouwla(a)yahoo.com> To: boost(a)lists.boost.org Sent: Tuesday, January 8, 2008 11:23:30 PM Subject: Re: [boost] Visual Studio 2008 John, Thanks that seems to work for me. When I build boost is does not libboost_serialization-vc90-mt-1_35.lib for me but only boost_wserialization-vc90-mt-1_35.dll How can I build libboost_serialization-vc90-mt-1_35.lib ? Lars ----- Original Message ---- From: John Maddock <john(a)johnmaddock.co.uk> To: boost(a)lists.boost.org Sent: Monday, January 7, 2008 7:01:16 PM Subject: Re: [boost] Visual Studio 2008 Lars Schouw wrote: > Lars > > > Does boost build and run the regression tests for Microsoft Visual > Studio 2008? For current Trunk and release branch yes, see: http://beta.boost.org/development/testing.html For Boost-1.34.1 and earlier no: VS2008 wasn't available when that was signed off on. HTH, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs

1 0

Re: [boost] Visual Studio 2008
by Lars Schouw 08 Jan '08

08 Jan '08

John, Thanks that seems to work for me. When I build boost is does not libboost_serialization-vc90-mt-1_35.lib for me but only boost_wserialization-vc90-mt-1_35.dll How can I build libboost_serialization-vc90-mt-1_35.lib ? Lars ----- Original Message ---- From: John Maddock <john(a)johnmaddock.co.uk> To: boost(a)lists.boost.org Sent: Monday, January 7, 2008 7:01:16 PM Subject: Re: [boost] Visual Studio 2008 Lars Schouw wrote: > Lars > > > Does boost build and run the regression tests for Microsoft Visual > Studio 2008? For current Trunk and release branch yes, see: http://beta.boost.org/development/testing.html For Boost-1.34.1 and earlier no: VS2008 wasn't available when that was signed off on. HTH, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

1 0

[floating point utilities] new version
by Johan Råde 08 Jan '08

08 Jan '08

Hi, I have uploaded version 3 of the floating point utilities library to the vault. The library is in the folder Math - Numerics. The library provides portable and optimized implementations of isnan, fpclassify, signbit etc. It also provides facets for portable handling of infinity and NaN in text streams. If you want text files with floating point numbers to be portable, and if the files may contain infinity or NaN, then you should use this library. This also applies to text serialization archives. Compared with version 2, there are only minor changes: 1. I have removed all use of partial template specialization and I have added BOOST_TYPENAME and BOOST_STATIC_CONSTANT macros. Now the library should work with older compilers, such as MSVC 6.5. 2. I now use the header boost/detail/endian.hpp. (I didn't before, because I didn't trust that header. But I now think it is better to use endian.hpp, and to fix any problems with the header as they show up.) 3. General code clean-up and simplification. 4. More discussion of portability issues in the docs. There are no changes to the interface. If anyone has time to test the library, I would be interested in the results. Thank you, Johan Råde

2 5

seek issue with boost::iostreams::stream
by Steve Nutt 08 Jan '08

08 Jan '08

I've created a device with the boost::iostreams::dual_seekable category to use with the boost::iostreams::stream class, but I'm having trouble implementing seek. When I call seekp on the stream, seek on my device is called with a which (openmode) of both BOOST_IOS::in and BOOST_IOS::out. I would have expected for a call to seekp the which parameter in the seek call on my device would be BOOST_IOS::out, and calling seekg would set which to BOOST_IOS::in. The following code in boost\iostream\detail\streambuf\indirect_streambuf.hpp ignores the which argument passed and passes on through both in and out. template<typename T, typename Tr, typename Alloc, typename Mode> inline typename indirect_streambuf<T, Tr, Alloc, Mode>::pos_type indirect_streambuf<T, Tr, Alloc, Mode>::seekpos (pos_type sp, BOOST_IOS::openmode) { return seek_impl( position_to_offset(sp), BOOST_IOS::beg, BOOST_IOS::in | BOOST_IOS::out ); } Is this correct, and if so how do I implement seeking when using a dual head device? Many thanks, Steve Nutt

2 2

Using Boost.Coroutine to mock threads
by Edd Dawson 07 Jan '08

07 Jan '08

Hello folks, I'm currently trying to write tests for some threaded code. However, context switching is not predictable and scheduling is unfair on the platforms concerned, so there is no deterministic behaviour on which I can rely. Here's a sketch of my task_queue class: class task_queue : noncopyable { public: // use num_threads threads to churn through tasks task_queue(unsigned num_threads); // Don't start any new tasks. // Return as soon as all active tasks are complete. ~task_queue(); // throw() // Add a task to the back of the queue void append(const function<void ()> &task); private: // ... }; The tasks should be picked up in FIFO order. Without some kind of deterministic threading implementation, I can't test this with the given interface. To truly test FIFO ordering, looking at when tasks start and/or finish is insufficient. Instead I need to see when a task is picked up by a thread. I can hack in some hooks, but that seems wrong(?). So! I had this slightly wacky thought. Would it be possible to implement the boost.Thread API using Boost.Coroutine? Coroutine yield()s would be performed inside blocking calls to whatever_lock_type::lock(), thread::join(), condition::wait() and so on, perhaps; I haven't completely thought this through, yet... :) If this is possible, I would have a deterministic threading system and therefore have some guarantees to work with in my tests. For example, I can now use the starting time of a task as a measure of the time at which a worker thread plucks a task from the queue (because there would be no context switching between the pluck and the first instruction of the task). Thus, I can test FIFO-ness. I realise Boost.Coroutine isn't an official Boost library, but I'm guessing this is still the best place to find out whether this idea has wings. Hope that's ok. Laugh me off stage if you must! Kind regards, Edd

3 4

Re: [boost] [Boost-users] upcoming Switch library review Jan 5th - Jan 9th
by Stjepan Rajko 07 Jan '08

07 Jan '08

On Jan 6, 2008 12:20 PM, Tobias Schwinger <tschwinger(a)isonews2.com> wrote: > Stjepan Rajko wrote: > > Would using > > result_of<F(boost::mpl::front<Cases>::type)> be an option for a > > non-empty case sequence? > > I think it's too complicated: We can't use 'result_of' to determine the > result of 'switch_', so it should be as simple to determine as possible > (ideally without deduction at all). > Sure - although the library could offer something along the lines of result_of::switch. > > As long as the order of the cases doesn't > > matter (btw, does it?), the user could put the desired type in the > > front of the Cases sequence if the return type differs for different > > MPLConstant types. > > Further, we still need a special-engineered function object; one of the > cases will have a special role. It might work, but it feels inelegant to > me: The function object's result type should be convertible to whatever > 'switch_' wants to return. > I agree that being able to specify the return type explicitly would be very useful, precisely because you could use function objects that are not result_of/result_type compatible, or override the return type even if one is specified by the function object. I can see overriding it to boost::any or some other "common denominator" as a frequent use case. > So what will deducing that type from the function object buy us? > > The only answer I can currently see is "nothing but trouble" :-). Please > tell me if I'm missing something. > >From what I can see, it buys simplicity when the use case is not complicated (the return type is available through result_type or result_of and does not change), or when you really want to leave it to the function object to specify what the return type should be. Granted, all of the proposed solutions for return type deduction seem slightly imperfect / inelegant, but as long as the behavior is clearly explained in the documentation they could be useful. Regards, Stjepan

2 2