July 2012 - Boost - lists.boost.org

[gil::io_new] Help with gcc compiler
by Christian Henning 07 Jul '12

07 Jul '12

Hi there, I'm in the process of making my gil extension ready for inclusion. The code is now stable and I'm trying to get gcc/clang to work. Since I'm no expert with gcc I would like to ask for some help with various compiler errors. Could someone get the latest from here: http://gil-contributions.googlecode.com/svn/trunk/gil_2 and try to compile the following code: ------------------- #include <boost/gil/extension/io_new/bmp_all.hpp> using namespace std; using namespace boost::gil; int main() { { const char* bmp_filename = ""; const char* bmp_out = ""; rgb8_image_t img; read_image( bmp_filename, img, bmp_tag() ); write_view( bmp_out + "all_formats_test.bmp", view( img ), bmp_tag() ); } } ----------------- It should generate some errors which I don't quite understand. I have posted the errors here: http://pastebin.com/Wps3YH1N I'm using gcc 4.4.1 . The complete test suite compiles with Visual Studio 2010 without any warnings. Thanks a lot! Christian

5 10

noncopyable && C++11
by Ben Pope 06 Jul '12

06 Jul '12

Hi all, boost::noncopyable interferes with the implicit generation of move construction and move assignment, so I was wondering if anybody had any thoughts on something like this: class noncopyable { protected: noncopyable() = default; noncopyable(noncopyable&&) = default; noncopyable& operator=(noncopyable&&) = default; noncopyable(noncopyable const&) = delete; noncopyable& operator=(noncopyable const&) = delete; }; Which would replace the existing technique when C++11 support is on. I guess it could be argued that non copyable should imply non moveable. However, you won't hear me defending that position; plenty of thought went into move semantics with the defaults chosen to have sa[f|n]e behaviour. The derived class will still be subject to that criteria, I'm just trying to prevent noncopyable from artificially inhibiting move semantics. Would anybody want nonmovable? nonmoveable? Any thoughts / comments / omissions gratefully received. Ben

2 2

[iostreams] cin wrapper
by Daniel Larimer 06 Jul '12

06 Jul '12

I am attempting to 'wrap' std::cin such that all 'blocking' occurs in a dedicated 'cin' thread. This is required because in a cooperatively scheduled thread, no fiber can call cin and block. So I went about attempting a boost::iostreams::source: class cin_source : public boost::iostreams::source { streamsize read( char* s, streamsize n ) { if( n == 0 ) return n; auto r = std::cin.readsome(s,n); if( r <= 0 ) { // post read request to another thread. // cooperatively wait for it to finish... return n; } return r; } }; The problem I have is that this code causes read to be called with 'n == 0'; boost::iostreams::stream<cin_source> my_cin; char buf[100]; my_cin.read( buf, 100 ); It doesn't matter how I attempt to read from the stream, n always equals 0. What am I doing wrong? Dan

1 0

[format] Any interest in decoupling it from std::basic_string?
by news.gmane.org 06 Jul '12

06 Jul '12

I.e. such that alternative string implementations could be used (GCC's vstring, boost's...). I've attempted two methods, both pretty simple. First is to simply template basic_format on the string type and propagate that change throughout the library (including similar for the altstream/stringbuf classes). Second was to add a template template parameter for the string, e.g.: template <class Ch, class Tr, class Alloc, template <typename, typename, typename> class StringT = std::basic_string> class basic_format; and propagate that. I would assume the first method is definitely out due to breaking the interface (especially the altstream classes which I would guess are supposed to look like the std ones). I've not looked at whether something such as templatizing the str() method on the string implementation is possible, as either of the above is sufficient for my own purposes and trivial which I suspect a templatized str() wouldn't be... Anyway, if there's any interest I can post a patch for either or both and if not continue using the first method (simpler diff from the original)! Best regards Luke Elliott.

5 11

[Range] Range adaptor approach for temporary range lifetime issue
by Michel Morin 06 Jul '12

06 Jul '12

When an rvalue range is adapted in range-based for loop, the lifetime of the rvalue range ends before the loop body begins. For example, the following code produces dangling references. for (auto x : std::string("Hello world!") | reversed) { /*...*/ } This is the temporary range lifetime issue. When I proposed BOOST_FOREACH extension for this issue, ( http://lists.boost.org/Archives/boost/2011/04/180591.php ) a solution with "moving an rvalue range into range adaptors" was suggested in the thread. I implemented this approach as a range adaptor (with the aid of rvalue references and decltype C++11 features): for (auto x : std::string("Hello world!") | moved | reversed) { /*...*/ } When an rvalue range is piped to `moved` adaptor, it returns `moved_range`. `moved_range` stores the following data: * Moved rvalue range: The rvalue range is moved and stored in `moved_range`. * Applied adaptors: When range adaptors are applied to`moved_range`, they are not invoked immediately; they are stored in fusion vector. The stored adaptors are invoked when `begin` or `end` member functions of `moved_range` are called. (To prevent repeated applications of the stored range adaptors, begin and end iterators are cached when they are first computed.) For example, in `std::string("Hello world!") | moved | reversed`, 1. By applying `moved` adaptor, `moved_range` is created. It stores `std::string` object moved from `std::string("Hello world!")`. It doesn't store any adaptors. 2. By applying `reversed` adaptor, another `moved_range` is created. It stores `std::string` object moved from the previous `moved_range`. It also stores `reversed` adaptor in fusion vector. Step 2 is repeated if more adaptors are applied. Then, in "for-init-statement" of range-based for loop, the stored adaptors are actually applied (and the result is cached). The free function version (`boost::adaptors::move`) supports `std::initializer_list`: for (auto x : move( {1, 2, 3, 4, 5} ) | reversed) { /*...*/ } Note that we cannot support it in the pipe syntax `{1, 2, 3, 4, 5} | moved` because the C++11 Standard does not allow to use list initializers in binary operators. Code attached. Comments? Regards, Michel

7 40

[exception] [type_traits] warning: unrecognized #pragma GCC system_header
by Krzysztof Czainski 06 Jul '12

06 Jul '12

Hello, Below is a list of files, that contain: #if defined(__GNUC__) #pragma GCC system_header #endif which causes a warning on my TI compiler. E:\boost\include\boost-1_50_0\boost\exception\all.hpp E:\boost\include\boost-1_50_0\boost\exception\current_exception_cast.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\error_info_impl.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\exception_ptr.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\is_output_streamable.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\object_hex_dump.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\type_info.hpp E:\boost\include\boost-1_50_0\boost\exception\diagnostic_information.hpp E:\boost\include\boost-1_50_0\boost\exception\errinfo_errno.hpp E:\boost\include\boost-1_50_0\boost\exception\exception.hpp E:\boost\include\boost-1_50_0\boost\exception\get_error_info.hpp E:\boost\include\boost-1_50_0\boost\exception\info.hpp E:\boost\include\boost-1_50_0\boost\exception\info_tuple.hpp E:\boost\include\boost-1_50_0\boost\exception\to_string.hpp E:\boost\include\boost-1_50_0\boost\exception\to_string_stub.hpp E:\boost\include\boost-1_50_0\boost\throw_exception.hpp E:\boost\include\boost-1_50_0\boost\type_traits\is_virtual_base_of.hpp In other files, i.e. boost\integer.hpp, I've found this #pragma guarded against __GNUC__ >= 4: #if defined(__GNUC__) && (__GNUC__ >= 4) #pragma GCC system_header #endif which doesn't cause a warning on my compiler, because it defines __GNUC__ to 3. Could this be fixed in the files on the list above, or are there some __GNUC__ 3 compilers, that need this pragma to be enabled? Regards, Kris

3 5

[1.50.0] Release candidates available for testing
by Beman Dawes 06 Jul '12

06 Jul '12

Release candidate files for 1.50.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --Beman --PS: I tested the 7z version, and it built without errors on Win7/VC++ Express 2010 sp1

8 16

Re: [boost] [cfe-dev] Using c++11 features in clang
by Marshall Clow 05 Jul '12

05 Jul '12

On Jul 5, 2012, at 12:41 PM, Joseph Galbraith wrote: > On 07/05/2012 12:29, Marshall Clow wrote: >> In response to a some questions on the boost-users list (and boost bug reports), I wrote up this: >> http://marshall.calepin.co/llvmclang-and-standard-libraries-on-mac-os-x.html >> >> I don't know if this should be a FAQ entry for Boost, or for clang. >> Suggestions/comments/edits welcome. > > Isn't one of both of -std=c++11 and -stdlib=libc++ an ABI change? > > If so, it should probably be noted that all code should be build with > the same settings for these flags. Yes. > In particular, I think that you can't pass a std:: classes from libstdc++ > built code to libc++ code without bad things happening. I would expect that also, but libc++ has versioned namespaces that _should_ prevent that from happening (I.e, cause linker errors). > I'm not sure whether just turning whether the following is safe or not: > > clang++ -c -stdlib=libc++ x.cpp > clang++ -c -stdlib=libc++ -std=c++11 y.cpp > clang++ -stdlib=libc++ x.o y.o I would expect either: * It would "just work" * It would fail to link depending on what the contents of x.cpp and y.cpp were. If you can come up with a good way of explaining this, I'll be happy to add it to my post. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

[interprocess] Problem building i386 binary on x86_64 MacOSX machine
by Walter Horsten 05 Jul '12

05 Jul '12

Hello, I have a program that uses boost::interprocess::message_queue, it used to compile correctly as a universal binary (i386 & x86_64) with boost version 1.47, however compiling for i386 fails with version 1.49 and 1.50. The most important parts of the error message are: - no matching function for call to 'boost::interprocess::message_queue_t<boost::interprocess::offset_ptr<void, int, long unsigned int, 0u> >::try_receive(void*, size_t, size_t&, unsigned int&)' - no matching function for call to 'get_rounded_size(long unsigned int, const unsigned int&)' ... is this a bug or is my code incorrect? (I suspect the size of the void* might have something to do with it?) The sample code in the attachment reproduces the problem on my MacBook Pro running OSX Snow Leopard (edit the boost prefix variable in the scripts to your own needs). Kind regards, Walter

1 0

[fusion] g++-4.6, deque, and c++0x compile error
by Karsten Ahnert 05 Jul '12

05 Jul '12

The following trivial program does not compile with g++-4.6.1 and std=c++0x enabled. #include <boost/fusion/container.hpp> int main( int argc , char *argv[] ) { } Seems like a bug, or should I configure something via macros?

3 5