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

Boost 1.49.0 release notice
by Beman Dawes 24 Feb '12

24 Feb '12

Release 1.49.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains one new library (Heap) and numerous enhancements and bug fixes for existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1_49_0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.49.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

3 2

Detecting file encoding
by norulez＠me.com 24 Feb '12

24 Feb '12

Hi, is there a way in boost to detect the encoding of a file? Thanks in advance Best Regards NoRulez

1 0

iterator_adaptor: making dereference of adapted tree node* return node value
by Rob Desbois 24 Feb '12

24 Feb '12

I have the following iterator_adaptor type: template< class NODE > struct node_iterator: public boost::iterator_adaptor< node_iterator<NODE>, // Derived NODE*, // Base typename NODE::value_type // Value > { typename NODE::value_type dereference() const { return this->base_reference()->data(); } }; // and later: typedef detail::node_iterator<node_type> iterator; typedef detail::node_iterator<const node_type> const_iterator; This throws up the issue that in const_iterator, Value is not const, producing the following error: /usr/include/boost/iterator/iterator_facade.hpp:517:32: error: invalid initialization of non-const reference of type ‘container::detail::node_iterator<const container::detail::node<long unsigned int> >::reference {aka long unsigned int&}’ from an rvalue of type ‘container::detail::node<long unsigned int>::value_type {aka long unsigned int}’ I could do some type traits magic with is_same, is_const and add_const to add the constness to Value if present on NODE, but is this the right way to do it? I've also thought about indirect_iterator - but adding operator*() to the node type seems not quite right. Perhaps transform_iterator...or is there some different method that might be more suitable? TIA, --rob -- Rob Desbois Blog: http://theotherbranch.wordpress.com/ "I disapprove of what you say, but I’ll defend to the death your right to say it", Voltaire

3 5

[posix_time] from_time_t bug
by Matthew Jenks 24 Feb '12

24 Feb '12

Hello, I am running into a problem with boost::posix_time::from_time_t() on a PC with, windows xp, visual studio 2010. When I input a number larger than the decimal equivalent of 0x7FFFFFFF (maximum posssible int32) into the function it returns a ptime with a date of 1902 or something close to. I assume the UNIX equivalent of time_t is a int32 and that is why I am having this problem, but I know a time_t is the equivalent to __int64 in windows xp. Is there is a MACRO define I am missing or is this a bug that needs to be fixed with this function so that it can accept the windows equivalent of time_t? Shouldn't this function accept and convert larger intigers thank int32 to a ptime or do I have to write my own? Thanks, Matt

2 1

Getting Mac address once ip address
by radha bhavani 24 Feb '12

24 Feb '12

Hi, Is there any api available in boost library to get mac addess of the device if ip address is know. Regards, Bhavani

2 1

[MultiIndex] how to rebuild index
by Igor R 24 Feb '12

24 Feb '12

Hello, What's the most simple way to rebuild an index? If elements change without notifying the container, would iterating from begin to end and calling modify() with no-op - do the job? (I remember there already was such a question, but can't find it.) Thanks.

3 3

[asio] Issue with resolver query for 64-bit browsers (IE)
by Jacques, Keiko 23 Feb '12

23 Feb '12

I am writing a browser plugin which needs to get the size of a file using the HTTP HEAD request. In order to send the request I am using the boost socket and the boost::asio::ip::tcp::resolver::query to get the ip address and service port. I am basically using code from the asio sync_client sample provided with Boost 1.48.0. using boost::asio::ip::tcp; boost::asio::io_service io_service; tcp::resolver resolver(io_service); tcp::resolver::query query(hostname, "http"); tcp::resolver::iterator endpoint_iterator = resolver.resolve(query); tcp::resolver::iterator end; This works fine when I run this on a Windows platform (Windows 7) using 32-bit browsers such as Firefox, Chrome, and IE. This also works fine when I run this as a desktop application through a test driver on a Windows (Vista , Windows7)64-bit platform. However, when I run this as a browser plugin on the Windows Vista 64-bit platform using IE (64-bit) it seems to crash on the line: tcp::resolver resolver(io_service); I'm not sure if this is a Boost issue or an IE issue, so I was wondering if anyone knows of any incompatibility issues and/or limitations with Boost and IE (64-bit) which could cause this to happen. Thanks Keiko ________________________________ This e-mail and any attachments may contain confidential material for the sole use of the intended recipient. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Thank you for your cooperation.

1 0

REGEX Don't understand the matching behavior: regex_search vs. regex_match
by Andy Falanga (afalanga) 23 Feb '12

23 Feb '12

Hi, I understand enough that regex_match() searches for matches based on the entire input string and apparently regex_search() allows for matches of the expression within the input string (i.e. the expression need not match the entire input string). However, I'm not understanding why the following happened: const char* pInput("Loc info: Channel 2, Target 0, Lun 0"); boost::cmatch found; boost::regex expression(".*Channel ([[:digit:]]{1,3})); // looking for the channel number only if(boost::regex_match(pInput, found, expression, boost::regex_constants::match_partial)) { std::cout << "Matched: " << std::atoi(found[1].first) << std::endl; } When using the above, with regex_match(), the match succeeded but the output string was: "Matched: 0". What?!? If the expression was matched, why did the capture group 1 contain 0? How should the expression have been made? That's what I don't understand. I've found that what I want is accomplished with altering the above thusly: const char* pInput("Loc info: Channel 2, Target 0, Lun 0"); boost::cmatch found; boost::regex expression("Channel ([[:digit:]]{1,3})); // looking for the channel number only if(boost::regex_search(pInput, found, expression)) { std::cout << "Matched: " << std::atoi(found[1].first) << std::endl; } This gives me: "Matched: 2." Which is what I'm looking for. I'd like to understand why regex_match() wasn't giving me what I wanted. Thanks everyone, Andy

2 2

problem with interprocess queue in boost 1.39
by orialtman 23 Feb '12

23 Feb '12

Hi All! I am using boost 1.39 on windows. i have implemented a simple client server application and ran the client and server simultaneously. The client pushes request using 'send' api with no timeout. it then sleeps for 3 seconds and sends another request and so on. the server pops messages from the queue with a timeout of 1 second. it then sleeps for 1 seconds and pops again and so on. this was created to simulate a problem i have in a more complicated server which actually performs work on received items. After some random time has passed i see that the client is locked and unable to push messages. it is locked in the 'notify' function which takes place at the end of do_send method of message_queue.hpp. while it is locked there i also see that the number of waiters on the condition is 1. when i pause the server application i see that it is not inside the do_receive method and therefore there is no appearent reason for the lock to be unavailable and for the number of waiters to be 1. has anyone come across something similar? is this a known issue for 1.39 or am i using the queue in a bad form? -- View this message in context: http://boost.2283326.n4.nabble.com/problem-with-interprocess-queue-in-boost… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0

[variant] 'which' out of range assertion
by Igor R 23 Feb '12

23 Feb '12

Hello, It appears that since 1.47 Boost.Variant has a bug that can be reproduced as follows (MSVC10, Debug mode): #include <boost/variant.hpp> #include <boost/mpl/vector/vector30.hpp> struct struct1{}; struct struct2{}; struct struct3{}; struct struct4{}; struct struct5{}; struct struct6{}; struct struct7{}; struct struct8{}; struct struct9{}; struct struct10{}; struct struct11{}; struct struct12{}; struct struct13{}; struct struct14{}; struct struct15{}; struct struct16{}; struct struct17{}; struct struct18{}; struct struct19{}; struct struct20{}; struct struct21{}; typedef boost::mpl::vector21< struct1, struct2, struct3, struct4, struct5, struct6, struct7, struct8, struct9, struct10, struct11, struct12, struct13, struct14, struct15, struct16, struct17, struct18, struct19, struct20, struct21 >::type vec_type; typedef boost::make_variant_over<vec_type>::type var_type; int main() { var_type v; v = struct21(); } The last line generates assertion in variant_impl.hpp, line 264, visitation_impl() function: "Boost.Variant internal error: 'which' out of range." According to the release notes, variant wasn't changed in 1.47, but I recalled teh following discussion: http://boost.2283326.n4.nabble.com/large-variant-performance-compared-50-el… It seems that the above issue is somehow related to this change. Igor'.

3 12