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

Starting...
by Giordano Bruno 18 Aug '11

18 Aug '11

Hi people, I want to use boost_pp in my embedded systems development using avr-gcc (C language). I was trying to understand how boostpp works, but it looks fuzzy to me. Can you explain me what is this "0" in the line 40 from preprocessor/comparison/less.hpp: define BOOST_PP_LESS_D(d, x, y) BOOST_PP_IIF(BOOST_PP_NOT_EQUAL(x, y), BOOST_PP_LESS_EQUAL_D, 0 BOOST_PP_TUPLE_EAT_3)(d, x, y) http://www.boost.org/doc/libs/1_43_0/boost/preprocessor/comparison/less.hpp thanks Giordano >

2 1

Re: [Boost-users] : dynamically linked libraries looking for static
by Alex Perry 18 Aug '11

18 Aug '11

Pally Sandher <pally.sandher(a)iesve.com> wrote on Thu, 18 Aug 2011 15:49:07 +0000 > > I've built debug binaries of boost 1.47.0 on Windows with MSVC 10 using the > following options > snip > I can stop these errors by using the /NODEFAULTLIB option on both those > libraries but I would like to stop them in the first instance. Does anyone have > any ideas why the libraries which should be dynamically linked are looking for > statically linked libraries which don't exist? Are you using the appropriate #define in your consuming code Eg #ifndef BOOST_REGEX_DYN_LINK #define BOOST_REGEX_DYN_LINK #endif #include <boost/regex.hpp> Which would ask to link to the dynamic link version of regex library not the static one - then all you need to do is make sure that the path to the boost libraries directory is added rather than having to add specific libraries Similar defines exist for the other libraries which are not header only. HTH Alex

1 0

Why is asio clobbering my file before it can be sent?
by Andrew Yancy 18 Aug '11

18 Aug '11

I've used the same boilerplate boost::asio code for years to send a plain text file "foo.txt" from a server back to a client and it has always worked fine. Suddenly for no apparent reason, the same code I've always used with no problems now deletes the contents of foo.txt before it can actually be sent to the client. I'm creating foo.txt with a different program now, but I don't see how that could make any difference on Win32. Below is the relevant part of the code just before I use boost::asio::write to send the contents of foo.txt back to the client. As shown by the two printf statements, the contents of the file are somehow lost when the file name and size are sent to the client. Anyone know what's going on? Is there any other information I can provide to shed light on the problem? Thanks very much for any help~ std::ifstream source_file("foo.txt", std::ios_base::binary | std::ios_base::ate); if (!source_file) return __LINE__; size_t file_size = source_file.tellg(); source_file.seekg(0); printf("foo.txt size: %d\n", (int) file_size); //size is OK here boost::asio::streambuf request; std::ostream request_stream(&request); request_stream << return_fn << "\n" << file_size << "\n\n"; boost::asio::write(socket, request); file_size = source_file.tellg(); printf("foo.txt size: %d\n", (int) file_size); //size is now 0!

3 4

[IOStreams] Is such a behaviour considered as bug
by Ovanes Markarian 17 Aug '11

17 Aug '11

Hello *, I really enjoyed working with Iostreams, while testing some of my components. Using IOStreams with array_device seemed to be a very powerfull approach to test some of my stream based algorithms. But currently I face some issues which seem to be really weired to me. I produced some code snippet to better explain it. I used Boost.Test library to verify my assumptions. using namespace boost; namespace io=boost::iostreams; typedef unsinged char byte; typedef array<byte, 2> arr_buffer; //boost::array typedef io::basic_array<byte> arr_dev; arr_buffer buffer_ = {{}}; arr_dev dev_(buffer_.begin(), buffer_.end()); io::stream<arr_dev> ios_(dev_); arr_dev::pair_type range = dev_.input_sequence(); BOOST_MESSAGE("size: " << distance(range.first, range.second)); // output: size is 2 BOOST_CHECK_EQUAL(0u, ios_.tellg()); //stream is at position 0 as expected ios_.seekg(1); BOOST_CHECK_EQUAL(1u, ios_.tellg()); // stream is at position 1 as expected ios_.seekg(2); BOOST_MESSAGE("current pos: " << ios_.tellg()); // !!! stream is at position 2 ios_.seekg(3); BOOST_MESSAGE("current pos: " << ios_.tellg()); // stream is at position -1 BOOST_MESSAGE("eof: " << ios_.eof()); // !!! but eof is false If the defined stream is only 2 bytes long why is 2 a valid stream position? Why is eof always false? Do you think this behavior is buggy? I changed the same behavior to read bytes from stream and created an array of length 3, but passed the range of 2 bytes to the device ctor. This works as expected: arr_buffer buffer_ = {{'a', 'b', 'c'}}; arr_dev dev_(buffer_.begin(), buffer_.begin()+2); //range of 2 bytes is passed io::stream<arr_dev> ios_(dev_); arr_dev::pair_type range = dev_.input_sequence(); BOOST_MESSAGE("size: " << distance(range.first, range.second)); byte bt; BOOST_MESSAGE("current pos: " << ios_.tellg()); // prints 0 BOOST_CHECK_EQUAL(0u, ios_.tellg()); ios_.read(&bt, 1); BOOST_MESSAGE("retrieved: " << bt); // prints 'a' BOOST_MESSAGE("current pos: " << ios_.tellg()); //prints 1 BOOST_CHECK_EQUAL(1u, ios_.tellg()); ios_.read(&bt, 1); BOOST_MESSAGE("retrieved: " << bt); // prints 'b' BOOST_MESSAGE("current pos: " << ios_.tellg()); // !!! prints 2, why not -1??? ios_.read(&bt, 1); BOOST_MESSAGE("retrieved: " << bt); // still prints 'b' => nothing retrieved BOOST_MESSAGE("current pos: " << ios_.tellg()); // !!! now it prints -1 BOOST_MESSAGE("eof: " << ios_.eof()); // !!! now eof is true Any ideas why it behaves as described? With Kind Regards, Ovanes

2 2

[Date Time] format_date_parser.parse_date fails to compile with "treat wchar_t as builtin type" set to No
by Daniel Mitchell 17 Aug '11

17 Aug '11

Boost 1.47, using Visual Studio 2010 and Visual Studio 2008, with boost 1.47 both built myself from source and with boost from the boostpro installers. (and with boost 1.47 rebuilt myself with /Zwchar_t- in msvc.jam). If I set "treat wchar_t as builtin type" to "No", then the following code fails to compile: #include <boost/date_time/gregorian/gregorian.hpp> #include <boost/date_time/posix_time/posix_time.hpp> void parseDate() { std::locale locale; boost::date_time::format_date_parser<boost::gregorian::date, wchar_t> parser(L"", locale); boost::date_time::special_values_parser<boost::gregorian::date, wchar_t> svp; boost::gregorian::date date = parser.parse_date(L"", L"", svp); } It gives the following error: c:\users\danielm\downloads\boost_1_47_0\boost_1_47_0\boost\lexical_cast.hpp(1116): error C2535: 'bool boost::detail::lexical_stream_limited_src<CharT,Base,Traits>::operator >>(unsigned short &)' : member function already defined or declared with [ CharT=char_type, Base=base, Traits=traits ] c:\users\danielm\downloads\boost_1_47_0\boost_1_47_0\boost\lexical_cast.hpp(993) : see declaration of 'boost::detail::lexical_stream_limited_src<CharT,Base,Traits>::operator >>' with [ CharT=char_type, Base=base, Traits=traits ] c:\users\danielm\downloads\boost_1_47_0\boost_1_47_0\boost\lexical_cast.hpp(1524) : see reference to class template instantiation 'boost::detail::lexical_stream_limited_src<CharT,Base,Traits>' being compiled with [ CharT=char_type, Base=base, Traits=traits ] c:\users\danielm\downloads\boost_1_47_0\boost_1_47_0\boost\lexical_cast.hpp(1653) : see reference to function template instantiation 'Target boost::detail::lexical_cast<Target,src,false,char_type>(const std::basic_string<_Elem,_Traits,_Ax> &,CharT *,size_t)' being compiled with [ Target=short, _Elem=wchar_t, _Traits=std::char_traits<wchar_t>, _Ax=std::allocator<wchar_t>, CharT=char_type ] c:\users\danielm\downloads\boost_1_47_0\boost_1_47_0\boost\lexical_cast.hpp(1641) : while compiling class template member function 'short boost::detail::lexical_cast_do_cast<Target,Source>::lexical_cast_impl(const Source &)' with [ Target=short, Source=src ] c:\users\danielm\downloads\boost_1_47_0\boost_1_47_0\boost\lexical_cast.hpp(1813) : see reference to class template instantiation 'boost::detail::lexical_cast_do_cast<Target,Source>' being compiled with [ Target=short, Source=src ] c:\users\danielm\downloads\boost_1_47_0\boost_1_47_0\boost\date_time\format_date_parser.hpp(72) : see reference to function template instantiation 'Target boost::lexical_cast<int_type,std::basic_string<_Elem,_Traits,_Ax>>(const Source &)' being compiled with [ Target=short, int_type=short, _Elem=wchar_t, _Traits=std::char_traits<wchar_t>, _Ax=std::allocator<wchar_t>, Source=std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>> ] c:\users\danielm\downloads\boost_1_47_0\boost_1_47_0\boost\date_time\format_date_parser.hpp(365) : see reference to function template instantiation 'int_type boost::date_time::fixed_string_to_int<short,charT>(std::istreambuf_iterator<_Elem,_Traits> &,std::istreambuf_iterator<_Elem,_Traits> &,boost::date_time::parse_match_result<charT> &,unsigned int,const charT &)' being compiled with [ int_type=short, charT=wchar_t, _Elem=wchar_t, _Traits=std::char_traits<wchar_t> ] c:\users\danielm\downloads\boost_1_47_0\boost_1_47_0\boost\date_time\format_date_parser.hpp(254) : while compiling class template member function 'boost::gregorian::date boost::date_time::format_date_parser<date_type,charT>::parse_date(std::istreambuf_iterator<_Elem,_Traits> &,std::istreambuf_iterator<_Elem,_Traits> &,std::basic_string<_Elem,_Traits,_Ax>,const boost::date_time::special_values_parser<date_type,charT> &) const' with [ date_type=boost::gregorian::date, charT=wchar_t, _Elem=wchar_t, _Traits=std::char_traits<wchar_t>, _Ax=std::allocator<wchar_t> ] c:\source\dan\boost_wchar_t_test\boost_wchar_t_test\boost_wchar_t_test.cpp(18) : see reference to class template instantiation 'boost::date_time::format_date_parser<date_type,charT>' being compiled with [ date_type=boost::gregorian::date, charT=wchar_t ] If I set "wchar_t is builtin type" to Yes, then it compiles fine. Testing with #pragma message to verify things, BOOST_NO_INTRINSIC_WCHAR_T is defined (or not defined) appropriately depending on how I set that compiler option, so it looks as if Boost knows what's going on at that level. I've tried all the possible reconfigurations I can think of, but this error happens with the boostpro installs, with Boost built unchanged from the 1.47 distribution, and with Boost rebuilt with /Zwchar_t- set in msvc.jam. Is there a way to solve this? The issue originally appears when trying to build code from another library -- but this is a minimal repro it with just boost code, so I think it's a Boost problem, unless I'm missing something. thanks, -- dan

1 0

Boost.Bimap vector_of element access VS 9 compilation errors
by John Eddy 17 Aug '11

17 Aug '11

Hello, I’m having difficulty figuring out how to access elements from a vector_of view in a bimap. The following code does not compile in VS 2008. #include <string> #include <iostream> #include <boost/bimap/bimap.hpp> #include <boost/bimap/vector_of.hpp> using namespace std; using namespace boost::bimaps; int main() { typedef bimap< string, vector_of<int> > bimap_type; bimap_type bm; bm.insert(bimap_type::value_type("zero", 0)); bm.insert(bimap_type::value_type("one", 1)); const bimap_type::right_map& right = bm.right; // Both of the lines below cause compilation failure with vc++ 9.0. bm.right[0]; //bm.right.at(0); return 0; } Can anyone see what I’m doing wrong or is there some other means of accessing the elements of the map via the vector? Thanks, John

1 0

[thread] 1.47 on cygwin 1.7 -> undefined reference to boost::detail::set_tss_data::shared_ptr::tss_cleanup
by Frédéric Bron 17 Aug '11

17 Aug '11

I am trying to use boost 1.47 on cygwin 1.7 cross-compiling to win32 with i686-w64-mingw32-g++ (4.5.3). This program gives me an error: #include <boost/thread/tss.hpp> int main() { boost::thread_specific_ptr<int> ts; return 0; } $ i686-w64-mingw32-g++ -o mgw-release/obj/Tests/toto.o -c -O3 -DNDEBUG -Wall -Wextra -pipe -mthreads -I/cygdrive/d/Softs/1.7/mgw-release/boost/include -I. Tests/toto.cc In file included from /cygdrive/d/Softs/1.7/mgw-release/boost/include/boost/thread/detail/thread_heap_alloc.hpp:15:0, from /cygdrive/d/Softs/1.7/mgw-release/boost/include/boost/thread/tss.hpp:10, from Tests/toto.cc:1: /cygdrive/d/Softs/1.7/mgw-release/boost/include/boost/thread/win32/thread_heap_alloc.hpp:59:40: warning: inline function ‘void* boost::detail::allocate_raw_heap_memory(unsigned int)’ declared as dllimport: attribute ignored /cygdrive/d/Softs/1.7/mgw-release/boost/include/boost/thread/win32/thread_heap_alloc.hpp:69:39: warning: inline function ‘void boost::detail::free_raw_heap_memory(void*)’ declared as dllimport: attribute ignored $ i686-w64-mingw32-g++ -o mgw-release/bin/toto -O3 -DNDEBUG -Wall -Wextra -pipe -mthreads -I/cygdrive/d/Softs/1.7/mgw-release/boost/include mgw-release/obj/Tests/toto.o -Wl,--enable-auto-import -static -L/cygdrive/d/Softs/1.7/mgw-release/boost/lib -lboost_thread_win32 mgw-release/obj/Tests/toto.o:toto.cc:(.text+0x104): undefined reference to `__imp___ZN5boost6detail12set_tss_dataEPKvNS_10shared_ptrINS0_20tss_cleanup_functionEEEPvb' collect2: ld returned 1 exit status any help would be welcome. Regards, Frédéric

3 5

[Regex | Xpressive] Efficiently "grepping" large files
by Thomas Luzat 17 Aug '11

17 Aug '11

Hello, I am looking into Boost.Regex and Boost.Xpressive for implementing grep-like functionality on large files. More specifically I want to check whether a file contains a match for an expression which does not need that much context (a few KB). regex_search and BidirectionalIterators for the whole file work, but there is a complication: I want to do other operations on the file in other threads in parallel (such as calculating hashes and extracting other data). Given that this is mostly I/O bound I would like to avoid rereading portions of the file as much as possible. My idea was to implement a circular buffer which may block the workers (and reading, if data is ever read faster than analyzed). The circular buffer needs to know when old data is no longer required, though, that is regex_search no longer works on it or backtracks into it. The best idea so far is to read blocks of data and do slightly overlapped calls of regex_search on those blocks. This approach has got at least two problems: 1) Matches and context are potentially limited to the size of the overlap. 2) Semantics of the match might be changed if I choose an arbitrary cut for the overlap (e.g. ^ and $ might change because I cut the beginning or end of a line) I would not mind to specify a maximum context of a few KB to maybe 1 MB, but I do not want to change semantics. Is there a better approach? I was thinking about supplying some intelligent iterators, but Regex/Xpressive might leave copies around longer than I anticipate, such that I still cannot decide where they are and how far they may still backtrack. If that's not really possible with the boost libraries I would be interested in alternatives, too. I am already considering looking into some grep implementations. Thanks in advance! Thomas Luzat

3 5

cross-compiling didn't work with boost:filesystem
by rudy b 17 Aug '11

17 Aug '11

Hi, I developed a code on Linux, and the only library that I used was boost:filesystem. I was very happy with the code on Linux, and it never gave me a problem and never broke on me, I tried it on different scenarios and different file types, and I had never issue with boost::filesystem::remove(&path) function. But, now, I needed my code on a Mac machine (but I don't have a Mac) so I borrowed my friend's Mac, and installed xcode, and installed boost_1.47, and I didn't get a single error or warning when installing these packages. As a test, I even ran some simple filesystem examples that were provided. and they all passed. I even used the same "make" file that I had on linux, and it worked great on Mac. (no warnings when compiled) But, when I tried to run my code, I was getting errors with ::remove functions. I am not sure, but I think part of it was because I may have read-only permission on some of the files, and maybe that is why it complained, although I never had this problem in Linux. Also, another part of it could be because of the file naming with white space between its characters: (e.g. "my document.txt" because of this space). I don't know, but I thought that "boost::filesystem" should be independent of the developing platform, and that I could be fairly confident that if it works on one platform (Linux), it should be working on another one (Mac). Any idea, what I am doing wrong, and how this can be fixed? thanks, RB

2 1

[Containers Library Review] The review of the Containers library by Ion Gaztanaga starts today
by John Maddock 17 Aug '11

17 Aug '11

The review of the containers library by Ion Gaztanaga starts today, to summarize the library: "Boost.Container library implements several well-known containers, including STL containers. The aim of the library is to offers advanced features not present in standard containers or to offer the latest standard draft features for compilers that comply with C++03. In short, what does Boost.Container offer? * Move semantics are implemented, including move emulation for pre-C++0x compilers. * New advanced features (e.g. placement insertion, recursive containers) are present. * Containers support stateful allocators and are compatible with Boost.Interprocess (they can be safely placed in shared memory). * The library offers new useful containers: o flat_map, flat_set, flat_multiset and flat_multiset: drop-in replacements for standard associative containers but more memory friendly and with faster searches. o stable_vector: a std::list and std::vector hybrid with random-access iterators that offers iterator stability in insertions and erasures. o slist: the classic pre-standard singly linked list container." Documentation from the library may be viewed online here: file:///M:/data/boost/sandbox/move/libs/container/doc/html/index.html The source may be accessed from the "move" directory of the sandbox SVN or downloaded from http://www.drivehq.com/web/igaztanaga/boost_container.zip. Note that this download contains a copy of the accepted, but not yet release, Boost.Move library - extract the zip over a copy of Boost-1.47 to get a full working copy. Review comments might like to answer the following questions: * 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. Regards, John Maddock.

5 5