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

Problems going from Serialization 1.32 to 1.33
by Stefan Arentz 17 Sep '05

17 Sep '05

Hello fellow Boost users, Consider the following program: #include <sstream> #include <string> #include <vector> #include <boost/archive/text_oarchive.hpp> #include <boost/serialization/base_object.hpp> #include <boost/serialization/string.hpp> #include <boost/serialization/vector.hpp> template <typename T> std::string archive(T thing) { std::ostringstream oss; boost::archive::text_oarchive oa(oss); oa << thing; return oss.str(); } typedef std::vector< std::string > parameters_t; int main() { parameters_t parameters; parameters.push_back("a"); parameters.push_back("b"); std::string s = archive<parameters_t>(parameters); return 0; } When I compile this with Boost 1.32 it compiles and works fine. However, with Boost.1.33 it fails with: /usr/local/include/boost/archive/detail/oserializer.hpp: In function `void boost::archive::save(Archive&, T&) [with Archive = boost::archive::text_oarchive, T = std::vector<std::string, std::allocator<std::string> >]': /usr/local/include/boost/archive/basic_text_oarchive.hpp:78: instantiated from `void boost::archive::basic_text_oarchive<Archive>::save_override(T&, int) [with T = std::vector<std::string, std::allocator<std::string> >, Archive = boost::archive::text_oarchive]' /usr/local/include/boost/archive/detail/interface_oarchive.hpp:85: instantiated from `Archive& boost::archive::detail::interface_oarchive<Archive>::operator<<(T&) [with T = parameters_t, Archive = boost::archive::text_oarchive]' test.cpp:16: instantiated from `std::string archive(T) [with T = parameters_t]' test.cpp:28: instantiated from here /usr/local/include/boost/archive/detail/oserializer.hpp:566: error: incomplete type `boost::STATIC_ASSERTION_FAILURE<false>' does not have member `value' I'm not sure what to change. Is this correct behaviour? S.

2 1

Re: [Boost-users] Help on Boost.MultiArray
by Adewole, Mike 16 Sep '05

16 Sep '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Sohail Somani > Sent: Friday, September 16, 2005 2:44 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Help on Boost.MultiArray > > > > -----Original Message----- > > From: boost-users-bounces(a)lists.boost.org > > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > > Adewole, Mike > > Sent: Friday, September 16, 2005 10:46 AM > > To: boost-users(a)lists.boost.org > > Subject: [Boost-users] Help on Boost.MultiArray > > > > > > Hi all, > > > > Does anyone know how to insert and delete a range of rows > > and/or columns in the multiarray class documented at > > http://www.boost.org/libs/multi_array/doc/ ? What > > performance guarantees can I expect for these operations ? > > > > I'm a little pressed for time and haven't been able to figure > > out how to do this on my own. The statement that "The number > > of elements will remain fixed for the duration of a > > multi_array's lifetime" on the documentation page suggests > > that these operations may not even be supported, but I'm not > > sure if I'm misunderstanding the statement or not. > > I don't think you can insert/delete stuff like in a vector. > Seemed to me too that the library doesn't support insertions/deletions but I had to be sure before doing this thing the hard way. Thanks a million. Mike

1 0

[filesystem] function to determine available space
by Beman Dawes 16 Sep '05

16 Sep '05

I'm planning to add a filesystem function to determine available disk space. Perhaps something like: struct space_status { boost::uintmax_t available; // free space available to user boost::uintmax_t total; // total space on volume }; space_status filesystem_space( const path & p ); Comments? Better suggestions for the names? --Beman

6 11

Re: [Boost-users] Help on Boost.MultiArray
by Sohail Somani 16 Sep '05

16 Sep '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Adewole, Mike > Sent: Friday, September 16, 2005 10:46 AM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] Help on Boost.MultiArray > > > Hi all, > > Does anyone know how to insert and delete a range of rows > and/or columns in the multiarray class documented at > http://www.boost.org/libs/multi_array/doc/ ? What > performance guarantees can I expect for these operations ? > > I'm a little pressed for time and haven't been able to figure > out how to do this on my own. The statement that "The number > of elements will remain fixed for the duration of a > multi_array's lifetime" on the documentation page suggests > that these operations may not even be supported, but I'm not > sure if I'm misunderstanding the statement or not. I don't think you can insert/delete stuff like in a vector.

1 0

Help on Boost.MultiArray
by Adewole, Mike 16 Sep '05

16 Sep '05

Hi all, Does anyone know how to insert and delete a range of rows and/or columns in the multiarray class documented at http://www.boost.org/libs/multi_array/doc/ ? What performance guarantees can I expect for these operations ? I'm a little pressed for time and haven't been able to figure out how to do this on my own. The statement that "The number of elements will remain fixed for the duration of a multi_array's lifetime" on the documentation page suggests that these operations may not even be supported, but I'm not sure if I'm misunderstanding the statement or not. Thanks a lot. -------------------------------------------------------- Mike Adewole ACNielsen, Global Decision Support Services ph: 905-475-3344x2411 fx: 905-475-8357 mike.adewole(a)acnielsen.ca --------------------------------------------------------

1 0

Could the BGL graph algorithms be improved to automatically work with VertexList = listS graphs?
by Tony Cook 16 Sep '05

16 Sep '05

Hi, If I define a BGL graph of the type typedef boost::adjacency_list <boost::vecS, boost::listS, boost::undirectedS, boost::no_property, boost::no_property, boost::no_property> BadGraphType ; Then many of the standard BGL graph algorithms such as boost::graph_copy will not compile (e.g you get "binary '+' : no operator found which takes a left-hand operand of type <type>" with VC7.1 - this did not help me understand what the problem really was - i.e. a missing vertex_index property!) This "no-compiler" problem is only fixed if either a vertex_index property map is made explicitly present on this graph type via VertexProperties template argument (See #5 on the BGL FAQ page (http://www.boost.org/libs/graphd/oc/faq.html .)) OR the particular graph algorithm is passed an external (or internal - if not of the vertex_index_t type) property map as a named parameter as in: boost::graph_copy (graph_in, graph_out, boost::vertex_index_map (i_map)) ; In either case prior to copying (or whatever) you need to ensure this property map is numbered contiguously from 0 to n - 1, where n is the number of graph vertices. My graph does not support an implicit vertex_index property, nor do I *want* to add an explicit vertex_index compatible property *just* to make these algorithms work. Especially as my graphs are dynamic and I would have to remember to renumber the property values to eliminate gaps after vertices are deleted. The BGL algorithms in this situation are particularly weak as first the "no-compile" messages are remote from the real problem, and when you have solved that then you have to prepare the graph properly prior using the algorithm! (if not you get memory scribbles if the indices are not contiguous and confined to 0 to n-1) These lead me to wonder if this problem can be eliminated and be automated as part of the algorithm itself, i.e. if no vertex_index property was supplied by any means, then the algorithm creates a temporary vertex index map, loads it with vertices mapped to indices 0 to n-1 and runs the algoritm out-of-the-box. It should be possible for the compiler to detect that the internal property map is missing AND the named parameter alternative is missing (in fact the implementations of these BGL algorithms *do* set out to discover that this is the case, but unfortunately a final vertex "descriptor-is-the-index" map (which is only true when VertexList=vecS) is assumed and hence the compilation failure and a lot grief and a steep learning curve is experienced :( ) Now to the point I wanted to make :). There IS a solution that can do this. However I'm not expert enough to merge this into the heart of each BGL graph algorithm algorithm that requires a vertex_index property. I have however developed crude wrappers that do this. Here is an example solution for boost::copy_graph that handles any graph type out of the box /** copy_graph_ex. A wrapper for boost::copy_graph that sets up the required vertex to 0 -> n - 1 index translation map @param g_in the graph to copy @param g_out the graph copy */ template <class G1, class G2> void copy_graph_ex (const G1& g_in, G2& g_out) { // Create a temporary external property map that maps vertex // descriptors to indices that will run 0 to n-1 typedef std::map<typename G1::vertex_descriptor, typename G1::vertices_size_type> i_type ; typedef boost::associative_property_map<i_type> i_map_type ; i_type i ; i_map_type i_map (i) ; // Load the external property map with values 0 to n-1 G1::vertices_size_type n = 0 ; G1::vertex_iterator vi ; G1::vertex_iterator vi_end ; for (boost::tie (vi, vi_end) = boost::vertices (g_in) ; vi != vi_end ; ++vi) { boost::put (i_map, *vi, n++) ; } // Get the BGL graph algorithm to use the constructed index map boost::copy_graph (g_in, g_out, boost::vertex_index_map (i_map)) ; } It would be much nicer if this external setup code was made part of the default handling of BGL graph algorithms that require it. What do to BGL experts/implementers say? Would it not be **saner** to get these algorithms to work automatically no matter what graph type was chosen? TIA Tony Cook (who went insane with this problem for two days)

7 14

[Graph] how to obtain the complement of a graph?
by Tzu-Chien Chiu 16 Sep '05

16 Sep '05

Given a graph G=(V,E) and its complete graph G'=(V,E'), what is the shortest code lines to obtain the complement of G_c=(V,E'-E) ?

2 1

[signal/bind/mem_fn] std::vector< boost::signal<> >
by kartoffelsack 16 Sep '05

16 Sep '05

Hi! I'd like to save any kind of functions/functors with void as parameter and as return-value in a container. I thought to use boost::bind: Let me show you some code: void bar( ) { } struct Foo { void operator(); }foo; typedef boost::signal<void ()> voidFunctionSig; std::vector< voidFunctionSig> voidFunctions; voidFunctionSig signal1; voidFunctionSig signal2; signal1.connect( &bar); signal2.connect( &foo); voidFunctions.push_back( signal1); //error voidFunctions.push_back( signal2); //same error I'm getting a Compiler-errors in the push_back-Lines: 'boost::signal<Signature>::__ctor': no nonexplicit constructor for implicit conversion: with [ Signature=void (void) ] and [ Signature=void (void) ] well, i'm not shure if boost::bind is the right choice at all, because I do not need multiple slots. Perhaps boost::bind/boost::mem_fn was enough but i cannot think how to use it. Can anybody help me to save my void (*)(void)-functions/functors and in a container? I could do it writing a superclass and a virtual op() but I would prefer to use ready-to-use boost-classes for this task. PS: using VC 7.1

2 2

Exception occurred in "boost::thread" cannot be caught by vs.net.
by 蹬三轮的 16 Sep '05

16 Sep '05

When an "access violation" exception occurred and didn't be caught by the program, it would be caught by debugger such like vs.net. 1: int main() 2: { 3: int *i = 0; 4: *i = 1; 5: } If I debug this program in vs.net, program will be broken at line 4 and an exception dialog box will be displayed. So I can know the origin of the exception. The problem is when the exception occurred in the thread started by boost::thread, program cannot be broken at the line from which exception been thrown. 01: void func() 02: { 03: int *i = NULL; 04: *i = 1; 05: } 06: int _tmain(int argc, _TCHAR* argv[]) 07: { 08: thread *t = new thread(func); 10: t->join(); 11: delete t; 12: return 0; 13: } The program should be broken at line 4, but it didn't. This makes the debugging boost::thread more difficult. How can I resolve the problem? thanks.

4 4

[Boost.Python] Infinite recursion attempting to_python conversion
by Nat Goodspeed 16 Sep '05

16 Sep '05

For some purposes we have a special string class derived from std::wstring. Simplified declaration: class cbstring: public std::wstring { public: cbstring(const wchar_t* that): std::wstring(that) {} cbstring(const std::wstring& that): std::wstring(that) {} ... }; I want to return such objects from C++ as Python Unicode strings, e.g.: cbstring produceWString() { return L"This is a test Unicode string"; } If produceWString() returns std::wstring, the conversion happens by magic. But with the cbstring return type, I get: TypeError: No to_python (by-value) converter found for C++ type: class cbstring The corresponding conversion problem (passing u"Foo" from Python to a function accepting const cbstring&) can be handled with the following call in the extension module: implicitly_convertible<std::wstring, cbstring>(); However, implicitly_convertible<cbstring, std::wstring>(); does NOT allow the produceWString() function to succeed: I still get the aforementioned TypeError. So I declared a type converter: struct cbstring_to_python { static PyObject* convert(const cbstring& cbs) { return PyUnicode_FromUnicode(cbs.c_str(), cbs.length()); } }; and registered it with: to_python_converter<cbstring, cbstring_to_python>(); The result is a stack overflow. I'm not clear on exactly why it happens, but something inside the cbstring_to_python converter is apparently recursively invoking cbstring_to_python::convert(). How *should* I go about returning our specialized string type as a Python Unicode string? OS: Microsoft Windows XP Pro, SP1 Compiler: Microsoft VC++ 7.1 with STLport 4.6 Boost version: 1.31

2 1