- Boost - lists.boost.org

Re:[serialization] Private ctor again
by Vladimir Prus 30 Mar '05

30 Mar '05

Robert Ramey wrote: >> binary_oarchive oa(...); >> Data data(....); >> oa << data; > >>Now, how do I deserialize it? I can't write > >> Data data; >> ia >> data; > >>Since ctor is private. I would guess it's still possible to deserialize >>this class, but I don't know how. > > what's the matter with > > Data data(....); > ia >> data; The wrong is that when I create and serialize data, I have something to pass as ctor parameter. But when deserializing, I don't have that something. Let's be more specific: the ctor parameter includes parse tree. I can't serialize it because it requires *lots* of work. > I don't see how the fact you want to construct different ways is related > serialization. Unless its a pointer, serialization presumes the > instance has already been constructed. How this is done is > outside the influence of the serialization library. What I'm after it telling to serialization lib: "hey, I know this data was not serialized via pointer, but I want to restore it into pointer variable, so that serialization lib creates it itself". Specifically, I look at this code from collection_load_imp.hpp: stack_allocate<type> t;^M load_construct_data(ar, t.address(), 0U);^M ar >> make_nvp("item", t.reference());^M Can the same trick be use from user code? I'm not all all sure it's better than saving Data as pointer in the first place, but I'm exploring possibilities. - Volodya

1 0

Mailing list archive change and list downtime
by Beman Dawes 30 Mar '05

30 Mar '05

DongInn Kim, Jeff Squyres, and the other sysadmins at Indiana University are planning to switch all the Boost mailing list archives they host from MHonArc to Hypermail. They report "Hypermail seems to be much more stable, faster, and more efficient than MHonArc. We've been quite pleased with it, and have deployed it across most other lists on the listserver already (the boost lists were saved until last)." The old archives will still be available, and DongInn and Jeff have made various plans to minimize disruptions. All the listservers will be down during the transition, which is planned to start at 11 PM Saturday night (Eastern US time). Thanks to all the folks at IU for their help with Boost list hosting, --Beman

1 0

[boost] [Assign] list_inserter.hpp missing include for boost::begin, boost::end
by Douglas Gregor 30 Mar '05

30 Mar '05

The BGL GraphViz test is failing on GCC 3.4.3 with this error message: In file included from /boost/head-regression/boost/boost/assign/std/map.hpp:19, from ../libs/graph/test/graphviz_test.cpp:17: /boost/head-regression/boost/boost/assign/list_inserter.hpp: In member function `boost::assign::list_inserter<Function, Argument>& boost::assign::list_inserter<Function, Argument>::range(const SinglePassRange&)': /boost/head-regression/boost/boost/assign/list_inserter.hpp:260: error: `begin' is not a member of `boost' /boost/head-regression/boost/boost/assign/list_inserter.hpp:260: error: `end' is not a member of `boost' Date: 2005-03-29 12:25 It looks like we need to include something from the range library to get these functions. Thorsten? Doug

2 2

set_property on reverse_graph fails
by Manish Mangal 30 Mar '05

30 Mar '05

Hi I am not able to use set_property function for reverse Graphs. I am using C++7.0 on .Net2003 compiler. I read an earlier question posted at http://lists.boost.org/MailArchives/boost-users/msg06970.php This sounded similar to my problem. The solution posted by Jeremy http://lists.boost.org/MailArchives/boost/msg66361.php runs fine on my machine . So I decided to use get_property instead of set_property as suggested in the solution. This did not solve my problem So I took Jeremy's solution and replaced subgraph by reverse_graph. Even that code generated: error C2784 could not deduce template argument list.. The code is: #include <string> #include <iostream> #include <boost/cstdlib.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/reverse_graph.hpp> int main() { using namespace boost; using std::string; typedef adjacency_list<vecS, vecS, directedS,no_property, property<edge_index_t, int>, property<graph_name_t, string> > graph_t; graph_t g; get_property(g, graph_name) = "graph"; std::cout << "name: " << get_property(g, graph_name) << std::endl; typedef reverse_graph<graph_t> reverse_graph_t; reverse_graph_t sg = reverse_graph_t(g); get_property(sg, graph_name) = "Reverse graph"; std::cout << "name: " << get_property(sg, graph_name) << std::endl; return exit_success; } Can anyone suggest how to make this work? Much appreciated Manish Mangal Stratagen Systems 1-425.821.8454 ext. 136

1 0

Re: Asynchronous I/O
by Don G 29 Mar '05

29 Mar '05

Of the mechanisms discussed, I am not sure I understand what you mean by async I/O with only one thread. I can imagine a nonblocking/select style approach that has no extra threads, but as soon as the main thread is not waiting on I/O itself (my interpretation of "async"), there needs to be threads to do the waiting. Unless I am missing something (which happens often<g>) or we are having terminology problems (also a frustratingly frequent occurrence). Best, Don --- Caleb Epstein <caleb.epstein(a)gmail.com> wrote: > I'd say coupling asynchronous I/O to multi-threading would be a > mistake. It is at its most useful IMHO in single-threaded cases. > > -- > Caleb Epstein > caleb dot epstein at gmail dot com __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

6 10

Warnings in Boost.Thread
by Janusz Piwowarski 29 Mar '05

29 Mar '05

Hi all, When Boost.Thread is compiled in release mode, there are a lot of warnings about unused variable 'int loop_count' in read_write_mutex.cpp. They comes from code like: int loop_count = 0; while (m_state == -1) { BOOST_ASSERT(++loop_count == 1); ++m_num_waiting_readers; m_waiting_readers.wait(l); --m_num_waiting_readers; } If loop is for second evaluation of condition only, i think it would be better to write: if (m_state == -1) { ++m_num_waiting_readers; m_waiting_readers.wait(l); --m_num_waiting_readers; BOOST_ASSERT(m_state != -1); } Regards, Janusz

2 1

Re: [boost] Re: Classpath to C++ conversion
by Iain Hanson 29 Mar '05

29 Mar '05

> Do I understand this to mean that "ClassPath" is the entire Java > API? If not, you've failed to answer Dave's query on what > "Classpath" actually is. I have no idea what it is, so I > cannot discuss the merits of the idea for Boost. > Classpath is the GNU project for the full Java API. > > You didn't explain what GCJ is, and given that you used the term "GCJ > > classes" I'm beginning to think I don't really know what you mean by > > GCJ. > > I also don't know what "GCJ" is. IOW, I have no idea what this > proposal is for and can't comment on whether it is useful. > GCJ is the Java part of gcc. /ikh

1 0

repost: [Post review] Pointer Container
by Thorsten Ottosen 29 Mar '05

29 Mar '05

Dear all, I really need some feedback. Please comment! Thanks ------------------- The Pointer Container library is very almost finished. Since the review, the following major changes has been made - improved docs with new tutorial and improved browsing - new indirect functions - new Cloneable and Clone Allocator concepts - support for null values - refactored template interface off all classes - implementation guarantees to only instantiate std::container<void*> - rewritten iterators - improved tests The new docs, and code can be downloaded from the files section: http://groups.yahoo.com/group/boost/files/pointer%20container/ptr_container… The test runs with vc7.1 and gcc.3.3.3. Comments, suggestions and portability fixes are welcome. There are one major issue and one minor I need to have resolved during the post-review. Minor issue: allocation in map:operator[] ---------------------------------------- should a default allocated object use operator new or heap_clone_allocator::allocate_default(); ? This happens in ptr_map<string,int> m; m["foo"] = 5; // will allocate an int with new Normally the use can control all allocations because he always add objects manually or via cloninin (which he also controls). But the default object is just allocated with operator new inside ptr_map::operator[]. Should some hook be provided in a new allocator concept, map_heap_allocator? Major issue: ptr_iterator implementation. ----------------------------------------- So what is the problem? Well, since void* is used internally, the iterators must cast to the proper type in operator*; that is no problem for the default indireted iterators; the problem is with the iterators from ptr_iterator ptr_begin(); ptr_iterator ptr_end(); One way to define would be to say typedef internal_container::iterator ptr_iterator; Then the reference type would be void*& and not T*& as we would like. So if the user wanted to sort the container, he would do std::sort( cont.begin(), cont.end(), void_ptr_indirect_fun< std::less<T>, T>() ); This give us a rather insecure interface where you have to cast manually to T* inside the functor. So I wish we could get a T*& reference type. I think, from discussion with David Abrahams, that the current implementation is non-portable even though my test works: typedef T*& reference; reference dereference() const { // void_type is void* or const void* // I'm not sure why this is needed, but it seems to be return reinterpret_cast<reference>( const_cast<void_type&>( *iter_ ) ); } Does anybody knows how to rewrite this crappy code propoerly? I think we're faced with three options 1. keep the current behavior and describe in the docs that it is non-portable 2. go back to making ptr_iterator the default iterator with void*& reference type; 3. add a small subset of algorithms to the classes themselves; I'm thinking that the subset from std::list is appropriate: - sort - remove_if - remove - unique - reverse - merge Let me hear what you think best regards Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

1 0

[Boost-bugs] [ boost-Bugs-1164057 ] boost::filesystem::exists has bugs with UNC paths
by SourceForge.net 29 Mar '05

29 Mar '05

Bugs item #1164057, was opened at 2005-03-15 14:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1164057&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost::filesystem::exists has bugs with UNC paths Initial Comment: boost::filesystem::exists(path("//computer")) always fails, even if the computer exists. boost::filesystem::exists(path("//computer/share")) always succeeds, even if the share doesn't exist. The attached patch fixes this by: - always succeeding for //computer (this is better than always failing) - correctly detecting the existance or not of a share. (The problem here was that the code was missing an error code check) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1164057&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

9 14

Re: [boost] type_traits: recent changes break EDG compilations
by Ralf W. Grosse-Kunstleve 29 Mar '05

29 Mar '05

--- John Maddock <john(a)johnmaddock.co.uk> wrote: > I was able to track this down to some preprocessor logic - a particular > compiler workaround was being applied when it should not have been, so > cv-qualified member functions were not being detected as such - should now > be fixed in cvs. Yes, wonderful! With the latest CVS I am back in business. Thanks!!! Ralf __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0