December 2011 - Boost-users

shared_ptr to object in stl set container?
by Galen 13 Dec '11

13 Dec '11

Hi, -- I'm trying to use shared_ptr in a stl set, but am having trouble with find() Any help? Documentation on this seems hard to find. -- Also, are the overloaded < and == useful or correct here? thanks! Output is: ------------------ 0 adding neighbor 1 0 adding neighbor 2 1 adding neighbor 0 2 adding neighbor 1 0's neighbors 1 has 1 neighbors 0 2 has 1 neighbors 1 NOT WORKING is 1 a neighbor of 0? 0 is 0 a neighbor of 1? 0 Code below: ------------------- #include<set> #include<iostream> #include<boost/shared_ptr.hpp> using namespace std; //use typedef instead in actual code #define NodePtr boost::shared_ptr<Node> // TODO: should this extend shared_ptr? class Node { private: int id; set<NodePtr> neighbors; public: Node() { } Node(int newID) { id = newID; } ~Node() { } int getID() { return id; } int addNeighbor(NodePtr newNode) { int newID; newID = newNode->id; // if not already a neighbor, add if (!isNeighbor(newID)) neighbors.insert(newNode); } set<NodePtr> getNeighbors() { return neighbors; } bool isNeighbor(int searchID) { set<NodePtr>::iterator it; // check if this neighbor already in list NodePtr searchNode(new Node(searchID)); it = neighbors.find(searchNode); // if not found, add to neighbors if (it == neighbors.end()) { return false; } //else return true; } //overload == for find() bool operator== (NodePtr otherNode) { cout << "==: " << otherNode->id << " " << id << endl; return (otherNode->id == id); } //overload < in case we want to sort bool operator< (NodePtr otherNode) { return (id < otherNode->id); } }; int main() { // the nodes are pointers to Node objects NodePtr n0(new Node(0)); NodePtr n1(new Node(1)); NodePtr n2(new Node(2)); cout << n0->getID() << " adding neighbor " << n1->getID() << endl; n0->addNeighbor(n1); cout << n0->getID() << " adding neighbor " << n2->getID() << endl; n0->addNeighbor(n2); cout << n1->getID() << " adding neighbor " << n0->getID() << endl; n1->addNeighbor(n0); // cout << n2->getID() << " adding neighbor " << n0->getID() << endl; // n2->addNeighbor(n0); cout << n2->getID() << " adding neighbor " << n1->getID() << endl; n2->addNeighbor(n1); set<NodePtr> neighbors = n0->getNeighbors(); set<NodePtr>::iterator NB; int id = n0->getID(); cout << id << "'s neighbors" << endl; for (NB = neighbors.begin(); NB != neighbors.end() ; NB++) { set<NodePtr> neighborsList = (*NB)->getNeighbors(); cout << (*NB)->getID() << " has " << neighborsList.size() << " neighbors" << endl; cout << (*neighborsList.begin())->getID() << endl; } // http://www.engr.sjsu.edu/wbarrett/SortFind.htm cout << "NOT WORKING" << endl; cout << "is 1 a neighbor of 0? " << n0->isNeighbor(1) << endl; cout << "is 0 a neighbor of 1? " << n1->isNeighbor(0) << endl; }

6 11

Re: [Boost-users] Boost-users Digest, Vol 2933, Issue 5
by Marat Abrarov 13 Dec '11

13 Dec '11

Hi, Rory. > Is there a reason io_service::run does not set an appropriate error on the > passed boost::system::error_code object when this is encountered? Certainly > it seems like an error case and would help circuital circumstances such as > my own. With current behavior of asio::io_service we can continue working with io_service after it was stopped by calling asio::io_service::reset(). It's like pause on io_service. It's not often used feature but it is nice to know that such behavior is possible. Also note that invocation of handlers is done only within threads that executes asio::io_service::run (run_one, poll, poll_one - http://www.boost.org/doc/libs/1_48_0/doc/html/boost_asio/overview/core/thre…) When io_service switches to the "stopped" state asio::io_service::run have to exit as fast as possible. When io_service is already in the "stopped" state asio::io_service::run have to exit immediately. So if io_service is already in stopped state before any user thread calls asio::io_service::run how can Asio pass "appropriate error" to asynchronous completion handlers? IMHO, current design of Asio is very clear. Regards, Marat Abrarov.

2 1

Re: [Boost-users] incompatible serialization format of boost::property_tree between 1.44 and 1.48 (Robert Ramey)
by kpzhang 13 Dec '11

13 Dec '11

Hi Robert, os: windows 7 compiler: visual studio 2008 sample code: #include <iostream> #include <string> #include <boost/property_tree/ptree.hpp> #include <boost/property_tree/json_parser.hpp> int main() { std::string str; { std::stringstream sstr; boost::property_tree::ptree pt; char a= '\0'; pt.put("a",a); boost::property_tree::write_json(sstr, pt); str = sstr.str(); std::cout << str << std::endl; } { std::stringstream sstr(str); boost::property_tree::ptree pt; boost::property_tree::read_json(sstr, pt); char a = '\1'; std::cout << (int)pt.get("a",a) << std::endl; } return 0; }

1 0

Request for change on Solaris platform
by Leo Carreon 12 Dec '11

12 Dec '11

Hi, I have just discovered that the Apache Standard C++ Library (stdcxx4) is now available in both Solaris 10 U10 and Solaris 11. Would it be possible to add stdcxx4 as a standard library option for Solaris on the next Boost release? Kind regards, Leo

1 0

[BGL] Default-constructibility of vertices
by Kelvin Chung 12 Dec '11

12 Dec '11

Suppose I have a class hierarchy, like so: struct Foo { virtual Output doSomething(const Input& in); }; class CompositeFoo { std::vector<Foo*> fooList; // Use your favorite smart pointer standin for Foo* here public: Output doSomething(const Input& in); }; Now, suppose I have a functor: class Functor { Foo* foo; Input input; // assume Input is copyable public: Output operator()() { foo->doSomething(input); } }; Now, the structure of doSomething() calls leads to a DAG structure with Functor as the vertices. What I want to do is create a graph with BGL that shows that structure, before topologically sorting it and doing other stuff with it. However, it would appear that the vertices of the graph (which I would assume to be of type boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, Functor>) must be default-constructible, which Functor is clearly not. Is there a nice workaround to this without changing the vertex type to Functor* (again, use your favorite smart pointer standin for Functor* here)?

2 1

[boost] [review] [Local] Review Result - ACCEPTED
by Jeffrey Lee Hellrung, Jr. 12 Dec '11

12 Dec '11

Local is ACCEPTED into Boost. After following the lively Local review discussion several weeks ago, and reviewing the discussion a second (and sometimes third) time, I have come to the above conclusion. There was quite a bit of passion on both the sides of "aisle", and thus, obviously, no decision I make would be well-received by all. Let me start by summarizing the main arguments against including Local in Boost: (a) Local functions are not very useful, at least in the presence of existing alternatives (e.g., namespace functions and Boost.Phoenix). (b) Local is really a portability library for C++03 presenting an imperfect emulation of features readily available in C++11. (c) Local's interface is primarily macro-based, making code ugly and difficult to read. In my opinion as the review manager, a sufficient number of individuals in the discussion found the library "useful" to address (a) (sometimes with additional positive adverbs); indeed, at least a couple individuals have shared positive experiences with real-world use. Namespace functions require one to move code to somewhere other than where one may prefer to have it, and often requires a significant amount of boilerplate when binding local variables. Aside from any perceived issues with Boost.Phoenix's syntax and compiler error messages, it has been noted that binding member functions within Boost.Phoenix can get ugly. As far as (b) is concerned, the community seems pretty far from reaching a consensus on whether a library described by (b) belongs in Boost. There are certainly libraries currently in Boost that could be pegged to satisfy (b) as well, though they all have other mitigating features they make their situation different from Local in some way. As far as (c) is concerned, several have acknowledged that a macro-based interface is necessary to implement local functions in C++03, and it seems to have been generally agreed that, given this limitation, Lorenzo has done an admireable job making the interface as easy-to-use as possible. Some find it ugly, others find it reasonable. In addition to the counterarguments of (a-c) above, the following facts weighed into my final decision: * Lorenzo has been engaging and in constant communication with the developer's list during the development of Local. This gives me confidence that he will continue to actively maintain (and improve?) Local. * The documentation is unanimously agreed to be of Boost quality. * The transition of some organizations from C++03 to C++11 may take several more years, and Boost has a history of supporting "ancient" compilers (for better or worse). The point being, a library that eases the transition from C++03 to C++11 has some merit based on current precedent. * There had been previous work on local functions by Alexander Nasanov and Steven Watanabe shared on the developer's list, suggesting a desire for this functionality for some time. * Local is approximately an extension of Boost.ScopeExit; indeed, it basically fulfills the request to Alexander Nasanov from the review result [2] of Boost.ScopeExit to create such an extension. Lastly, my own opinion of "what Boost is" factored in here. I view Boost as *partly* a collection of general purpose libraries that can be used in wide variety of applications (and thus Boost frequently acts as a staging ground for standard adoption). Based on review feedback, I believe Local satisfies this criterion; and based on the mailing list discussion, I believe this view of Boost is not entirely inconsistent with others on the mailing list. Ultimately, it wasn't so much a # of "yes" votes versus # of "no" votes as it was the above general considerations. Regardless, I think independent of how the votes were counted, the "yes" votes outnumbered the "no" votes. This required some discretion on my part as not everyone who expressed an opinion submitted a formal review, and some participants were only arguing in favor of some specific point supporting either acceptance or rejection of Local. "Yes" reviews (7) -------- Krzysztof Czainski Andrzej Krzemienski Pierre Morcello Nat Lindon John Bytheway Edward Diener Gregory Crosswhite "No" reviews (3) -------- Vicente J. Botet Thomas Heller Hartmut Kaiser Paul A. Bristow and Alexander Nasanov (the author of Boost.ScopeExit) both submitted reviews but did not express an opinion (as far as I could tell) on whether Local should be included in Boost, though if I had to peg Paul's, it would be to reject Local. From what I gathered, Joel de Guzman, Joel Falcou, Dean Michael Berris, and Lucanus J. Simonson were opposed to including Local in Boost (the aforementioned did not submit a formal review, though a formal review might be unnecessary if your vote is "no"). On the other hand, Brian Wood, Philippe Vaucher, Mathias Gaunard, Robert Ramey, Nathan Ridge, Brent Spillner, Thomas Klimpel, Christopher Jefferson, Daniel James, Rafael Fourquet, Matthias Schabel, and Robert Stewart participated in the discussion and argued in favor of some point that supported accepting Local in Boost. I want to be clear here that certainly not everyone in the aforementioned list even implied that they supported acceptance of Local (I would guess that only roughly half implied as much), but they indirectly helped its case by addressing arguments against inclusion. Overall, that indicates to me that more individuals support acceptance of Local into Boost than rejection. [Apologies for any name misspellings and absent accents.] Regarding Boost.ScopeExit: 4 reviews were in favor of deprecating Boost.ScopeExit; 3 reviews felt there was nothing wrong with both Boost.ScopeExit and Local coexisting; and 3 reviews mentioned the possibility of improving Boost.ScopeExit with the features provided by Local's exits. As such I'm inclined to let Alexander (who opposed any kind of merging of Local and Boost.ScopeExit) work with Lorenzo on improving Boost.ScopeExit as he sees fit, and hopefully both libraries can address this apparent duplication of functionality within their respective documentation to avoid user confusion. Regarding local::function::overload: Based on the review comments, it makes the most sense to add this to Boost.Functional. Regarding BOOST_IDENTITY_TYPE: This should be added to Boost.Utility. On the other hand, there doesn't appear to be a compelling use case for BOOST_IDENTITY_VALUE. The following are some suggested *possible* improvements that reviewers brought up. This list is by no means exhaustive. Further, I personally don't think all of these suggestions are necessarily "good", but I think it's fair for Lorenzo (and the community) to consider them nonetheless. Parenthetic comments are my own opinions. * Some aren't convinced of the utility of LOCAL_BLOCK. (It's use cases appear fairly narrow so it might be best to simplify the library and remove this capability.) * Use "this_" (as opposed to "_this") as an alias for "this" within function bodies, and possibly also within bind declarations. * Present Boost.PP sequence interface as a workaround for the variadic interface? (I don't have a problem with supporting both interfaces at the top level.) * "Local" and "Locale" look too much alike, suggesting a name change to "Scope", "Scoped", "LocalFunction", "Closure" may be a good idea? * Allow use without dependence on Boost.TypeOf. * Rename prefix and postfix macros from XXX_PARAMS/XXX_NAME to XXX/XXX_END? (I don't mind the current macros.) * Explicitly separate bound variables from function parameters. (I think this suggestion has merit but I don't know what the interface could look like.) * Remove support for default parameters to simplify interface and documentation? (It doesn't seem like default function parameters would be very useful.) * Use "capture" instead of "bind" for the bind/capture keyword? (I like and prefer "bind".) Finally, here the links to the submitted formal reviews, for reference. Of particular note are Krzysztof's and John's reviews for their comments on the documentation. Some "yes" votes were conditional, but AFAIK Lorenzo has already agreed to address the relevant conditions. Krzysztof Czainski http://permalink.gmane.org/gmane.comp.lib.boost.devel/225543 Vicente J. Botet http://permalink.gmane.org/gmane.comp.lib.boost.devel/225604 Andrzej Krzemienski http://permalink.gmane.org/gmane.comp.lib.boost.devel/225656 Paul A. Bristow [...cannot find link to review...] Pierre Morcello http://permalink.gmane.org/gmane.comp.lib.boost.devel/225694 Nat Lindon http://permalink.gmane.org/gmane.comp.lib.boost.user/71508 Thomas Heller http://permalink.gmane.org/gmane.comp.lib.boost.devel/225736 Hartmut Kaiser http://permalink.gmane.org/gmane.comp.lib.boost.devel/225745 John Bytheway http://permalink.gmane.org/gmane.comp.lib.boost.devel/225746 Alexander Nasanov http://permalink.gmane.org/gmane.comp.lib.boost.devel/225783 Edward Diener http://permalink.gmane.org/gmane.comp.lib.boost.devel/225795 Gregory Crosswhite http://permalink.gmane.org/gmane.comp.lib.boost.devel/225807 Finally, really big thanks to everyone for participating in the review and ancillary discussions. I attempted to be as transparent as possible in outlining the rationale for my decision above, but if you have any further questions, do not hesitate to ask. - Jeff, Review Manager for Local [1] http://thread.gmane.org/gmane.comp.lib.boost.devel/168612 [2] http://lists.boost.org/boost-announce/2008/05/0190.php

2 1

Calls to asio::io_service::run on io_service object in stopped state don't generate an error.
by Rory Hart 12 Dec '11

12 Dec '11

Hey I spent a day trying to work out why calls to io_service::run was returning directly without running my async operations. It was my own fault of course, the io_service was in a stopped state as I had previously called io_service::stop and needed to call io_service::reset on it. This is documented in both the stop and reset documentation if I had RTFM instead of just skimming the interface. Is there a reason io_service::run does not set an appropriate error on the passed boost::system::error_code object when this is encountered? Certainly it seems like an error case and would help circuital circumstances such as my own. If there is no obvious reason not to I will put in a feature request and attempt a patch (I haven't touched the boost code base before). Thanks -- Rory Hart http://www.roryhart.net http://www.relishment.com

1 0

incompatible serialization format of boost::property_tree between 1.44 and 1.48
by kpzhang 12 Dec '11

12 Dec '11

Hi, Several days ago I upgrade boost from 1.44 to 1.48 and I found that serialization format is not compatible for node of 'char' type. The serialization format of a "char a=0" node in boost1.44 is: { "a": "\0" } while in boost1.48 is: { "a": "\u0000" } For the format of boost1.44, read_json of boost1.48 will throw exception which complains unexpected escaped slash. Is this intended behavior or a bug or my misuse? Any suggestions is welcomed. Regards, Ivan

2 1

boost asio: Crash on timer.expires_from_now only with specific MSVC settings (whole program optimization)
by Florian Burkart 12 Dec '11

12 Dec '11

Hi, I am currently struggling with a crash that I find very hard to isolate. Please see attached three classes I am using (the one not included is FlamTimeMillis, but that is basically just my own time class). In any case, LiveTimer works absolutely fine in my unit tests. It works absolutely fine in both debug and regular release versions. However, when compiled under msvc with compile options /Ox /Oi /Ot /GL and linked with /LTCG (e.g. whole program optimization), it crashes. But only in my main program, and not in any test I try to create. But in the main program, it consistently crashes. According to the logs, it crashes between 3 and 4, e.g. the log looks like this: IN: : LiveTimer: RegisterTimedCallback 2011-12-12 07:02:00.000000: Locked mutex. IN: : LiveTimer: Expires from now -22405.5 A: 2011-12-12 07:02:00.000000 B: 2011-12-12 13:15:25.489000 C: -2.24055e+007 IN: : 1 IN: : 2 IN: : 3 This happens on the very first call to RegisterTimedCallback. Judging from it, it looks like it crashes on timer.expires_from_now(boost::posix_time::seconds((long)secondsToElapse)). I checked that I am in the correct LiveTimer, and that LiveTimer still exists. I tried loading the dump file into WinDbg, and I get the following output: XCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 77b68da9 (ntdll!RtlpWaitOnCriticalSection+0x000000bd) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000001 Parameter[1]: 00000114 Attempt to write to address 00000114 PROCESS_NAME: Test.exe ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_PARAMETER1: 00000001 EXCEPTION_PARAMETER2: 00000114 WRITE_ADDRESS: 00000114 FOLLOWUP_IP: Test!boost::asio::detail::win_iocp_io_service::cancel_timer<boost::asio::time_traits<boost::posix_time::ptime> >+4c [c:\program files (x86)\boost_1_47_0\boost\asio\detail\impl\win_iocp_io_service.hpp @ 117] 0139784c b001 mov al,1 MOD_LIST: <ANALYSIS/> NTGLOBALFLAG: 0 APPLICATION_VERIFIER_FLAGS: 0 FAULTING_THREAD: 000029b8 BUGCHECK_STR: APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_INVALID_POINTER_WRITE PRIMARY_PROBLEM_CLASS: NULL_CLASS_PTR_DEREFERENCE DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE LAST_CONTROL_TRANSFER: from 77b68cb8 to 77b68da9 STACK_TEXT: 0032ec44 77b68cb8 00000000 00000000 00000000 ntdll!RtlpWaitOnCriticalSection+0xbd 0032ec6c 0139784c 00953408 654f7f27 0032ecf0 ntdll!RtlEnterCriticalSection+0x150 0032ecac 0139e79a 0095015c 0032f93c ffffffff Test!boost::asio::detail::win_iocp_io_service::cancel_timer<boost::asio::time_traits<boost::posix_time::ptime> >+0x4c [c:\program files (x86)\boost_1_47_0\boost\asio\detail\impl\win_iocp_io_service.hpp @ 117] 0032ecdc 013d9d20 0095015c 0032ed38 00000000 Test!boost::asio::detail::deadline_timer_service<boost::asio::time_traits<boost::posix_time::ptime> >::expires_from_now+0x6a [c:\program files (x86)\boost_1_47_0\boost\asio\detail\deadline_timer_service.hpp @ 159] 0032ecfc 013d948f 0032ed28 654f7e57 0095716c Test!boost::asio::basic_deadline_timer<boost::posix_time::ptime,boost::asio::time_traits<boost::posix_time::ptime>,boost::asio::deadline_timer_service<boost::posix_time::ptime,boost::asio::time_traits<boost::posix_time::ptime> > >::expires_from_now+0x30 [c:\program files (x86)\boost_1_47_0\boost\asio\basic_deadline_timer.hpp @ 411] 0032ede0 013b1840 0032f900 00950188 0094f970 Test!Flam::Live::LiveTimer::EnqueueTimedCallback+0x33f [c:\users\florian\documents\liveenvv1\trunk\flamlib\live\livetimer.cpp @ 55] STACK_COMMAND: ~0s; .ecxr ; kb FAULTING_SOURCE_CODE: 113: // If the service has been shut down we silently ignore the cancellation. 114: if (::InterlockedExchangeAdd(&shutdown_, 0) != 0) 115: return 0; 116: > 117: mutex::scoped_lock lock(dispatch_mutex_); 118: op_queue<win_iocp_operation> ops; 119: std::size_t n = queue.cancel_timer(timer, ops, max_cancelled); 120: post_deferred_completions(ops); 121: return n; 122: } SYMBOL_STACK_INDEX: 2 SYMBOL_NAME: Test!boost::asio::detail::win_iocp_io_service::cancel_timer<boost::asio::time_traits<boost::posix_time::ptime> >+4c The source quoted is from \boost_1_47_0\boost\asio\detail\impl\win_iocp_io_service.hpp. Despite the fact that I can't isolate the error, everything I look at points to a problem somewhere within boost asio, or me not using asio correctly. Anyone any suggestions as to where to go from here? Would be much appreciated. What looks a bit suspicious to me (but that might be entirely wrong), is the line "// If the service has been shut down we silently ignore the cancellation.," because the error happens after the return statement linked to that comment was apparently not executed, and the service has actually been shut down. P.S. I know that I don't need to manage the queue myself and could just let asio handle it, however, eventually I would like to manage the queue more (e.g. edit some timers, cancel others, so I'd prefer to stick to a single timer and manage the queue myself).

1 0

is_dereferenceable.hpp fails to compile with Apple Clang 3.0
by István Csanády 12 Dec '11

12 Dec '11

Hi All, I am trying to use boost::iostreams. When I include boost/iostreams/filtering_streambuf.hpp (even if I don't declare any filtering_streambuf variables) I get the following compilation error: is_dereferencable.hpp: Parse Issue: Expected unqualified-id The problem is in this code: template <class T> struct impl { static typename boost::remove_cv<T>::type& x; BOOST_STATIC_CONSTANT( bool , value = sizeof(is_dereferenceable_::check BOOST_PREVENT_MACRO_SUBSTITUTION(BOOST_comma(*x,0))) == 1 ); }; Compiler: Apple Clang 3.0, with -std=c++0x flag Any help would be greatly appreciated. Thanks Istvan

4 4