- Boost-users - lists.boost.org

Re: [Boost-users] [Serialization] 1.33 RC1 nvp.hpp gotcha
by Richard Jennings 10 Aug '05

10 Aug '05

I am a bit baffled why you can get the example to compile! I can't try it on VC7.1 today, though I will tomorrow, however I can't see anything compiler specific about it: Serialization/nvp.hpp includes serialization/traits.hpp that defines BOOST_SERIALIZATION_TRAITS_HPP. Serialization/vector.hpp includes collections_save_imp.hpp that includes archive/basic_archive.hpp that checks for BOOST_SERIALIZATION_TRAITS_HPP being defined and thereby says #error. Therefore it appears that whenever vector.hpp is included after nvp.hpp that basic_archive will choke. BTW When I said that perhaps it only worked by luck before I meant that my application worked by luck as I was not overly careful about header inclusion order or what went in the precompiled headers and what didn't. I did _not_ mean that it's lucky the serialization library works! I have found it very simple to use and very powerful. Richard -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: 09 August 2005 17:11 To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [Serialization] 1.33 RC1 nvp.hpp gotcha Richard Jennings wrote: > I have found that the requirement that no serialization headers can be > included before any archive headers means that you have to be careful > which serialization headers you include in your class headers and > indeed in what order you include them. It is my intention that this issue be addressed with the simple rule: "all headers from the serialization directory should follow and headers from the archive directory" I believe that this rule should be very easy to follow. As a beneficial side-effect of flagging any usage of "archive" headers in include modules for classes. This would accidently link a serialization definition with implementation of a specific archive. > > In particular if you include serialization/nvp.hpp before > serialization/vector.hpp and you use that class in another module that > does not use archiving at all then that module will hit the error > directive, example below. This would surprise me. Your example looks good to me. So I built on my own machine. Both main.cpp and B.cpp compiled without problems with VC 7.1 . So we're out of sync somehow. > A solution would seem to be that serialization/nvp.hpp should only be > included in the module that includes archive headers. This wouldn't work and shouldn't be necessary. Lets beat upon your example some more until we get the same results. > I guess what I would like is some guidance on using serialization as > it's become a bit more tricky in my experience. I would hope that its not too tricky. The system is designed to be as tricky as necessary - but no trickier. > At least you can't willy-nilly include serialization headers in any order > in any headers > and expect the application to compile. True >Perhaps it only worked by luck before! LOL - well I do consider myself a lucky person !!! But A very small observation on your code: #include <vector> // note this is superflous - but harmless #include <boost/serialization/vector.hpp> // as the above is included by this module Robert Ramey _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

3 2

Re: [Boost-users] shared_ptr conundrum
by Timothy Ritchey 10 Aug '05

10 Aug '05

To update, my problem with shared_ptrs not being released properly went away when I upgraded my Intel compiler from 8.1.019 to 8.1.025 on my machine at work. I hate to think how many days I have been working on this...:-) Cheers, tim

1 0

bug remains in posix_time io in 1.33RC2
by Serge Skorokhodov 10 Aug '05

10 Aug '05

Hi, In 1.33RC2, the string with wrong formatted date produce wrong date-time rather than error (vc-7_1): #include <iostream> #include <sstream> #include <string> #include <stdexcept> #include "boost/date_time/posix_time/posix_time.hpp" #include "boost/date_time/posix_time/posix_time_io.hpp" using namespace std; using namespace boost::posix_time; int main() { bool except_fg = false; string pts = "2002091"; istringstream iss(pts); iss.exceptions(ios::failbit); time_input_facet* tif = new time_input_facet; tif->set_iso_format(); iss.imbue(std::locale(std::locale::classic(), tif)); ptime pt; try { iss >> pt; } catch ( const exception& e ) { cout << "Exception reading 2002091: " << e.what() << endl; except_fg = true; } if ( !except_fg ) { cout << "Date-time from 2002091: " << pt << endl; except_fg = false; } pts = "20020913T17043"; iss.str(pts); try { iss >> pt; } catch ( const exception& e ) { cout << "Exception reading 20020913T17043: " << e.what() << endl; except_fg = true; } if ( !except_fg ) { cout << "Date-time from 20020913T17043: " << pt << endl; } return 0; } Output: Date-time from 2002091: 2002-Sep-11 00:00:00 Exception reading 20020913T17043: Parse failed. No match found for '' -- Serge

2 3

[Thread] How to wait for a thread until it stopped
by Christian Henning 10 Aug '05

10 Aug '05

Hi there, I'm still working on the transistion from an old thread lib to the boost thread lib. I have two threads, the GUI thread and a worker thread. The worker thread is always inside a loop that only breaks if someone set the flag. The GUI thread has from time to time to stop the worker thread. This is currently done by setting a flag ( _bStop ) and the worker thread will eventually stop like: void run() { boost::mutex::scoped_lock oLock( _oRunMutex ); do { ... if( _bStop ) _oRunCondition.wait( oLock ); } while( _bTerminate == false ); } I believe that this implemention can lead to deadlocks. But how can I implement the behavior that the GUI thread will break until the worker thread has stopped. Thanks, Christian

1 0

Question concerning boost::tuples::length (1.33 RC2)
by Daniel Krügler 10 Aug '05

10 Aug '05

(Note: The following contribution is essentially a copy of a former one, which was, due to several administrative problems on my side, probably overlooked by the majority of concerned programers) Dear Boosters, its quite a while that I could participate in this newsgroup, so maybe my request is ol' stuff and has been answered 100 times. In case of that I apologize for the following question: I observe that boost::tuple::length in version 1.32+1.33RC2 exist two template specializations for empty tuples, namely template<> struct length<tuple<> > { BOOST_STATIC_CONSTANT(int, value = 0); }; template<> struct length<null_type> { BOOST_STATIC_CONSTANT(int, value = 0); }; which lead to the unexpected effect that e.g. typedef const tuple<> ConstEmptyTuple; int k = length<ConstEmptyTuple>::value; (modulo namespace issues) does not compile. The reason is obvious, because deduction of boost::tuples::length<ConstEmptyTuple> extracts "const tuple<>", which leads to the generic template definition: template<class T> struct length { BOOST_STATIC_CONSTANT(int, value = 1 + length<typename T::tail_type>::value); }; which does not compile in this case, because const oost::tuples::tuple<> has no tail_type. Similar situations arise for const null_type arguments and corresponding volatile variants thereof. To my humble opinion tuples::length should work independent of cv qualification of the template arguments, but this route should of course be gone in accordance to similar situations of "template predicates" in boost::mp/type_traits. One further indirection and usage of boost::remove_cv<T> could simply resolve the described problem, such as: // Define length_impl + 2 specialisation for tuple<> and null_type as // currently done for length namespace details { template <typename T> struct length_impl { .. // as before; }; template <> struct length_impl<null_type> { .. // as before; }; template <> struct length_impl<tuple<null_type, ...> > { .. // as before; }; } // One single - not specialized - length template handling all cases: template <typename T> struct length { static const int value = details::length_impl< typename ::boost::remove_cv<T>::type >::value; }; What do you think? Greetings from Bremen, Daniel Krügler

1 0

Re: [Boost-users] shared_ptr conundrum
by Timothy Ritchey 10 Aug '05

10 Aug '05

I need to append my comments with a very import observation I just made regarding the shared_ptr issue I am having. I just copied over the binary created on my SMP machine to my UP machine, and it is showing the same problem with releasing the underlying shared pointer resource. I had been compiling the full code on both machines (including the boost threading library dll), and comparing those results, and not actually comparing the results of the same binary. The two machines are: Dell Precision 450 Workstation Dual 2.4Ghz Xeon Processors Windows XP SP2 Visual Studio 2003 Intel 8.1.??? Home Build Single AMD Athlon-64 3200+ Windows XP SP2 Visual Studio 2003 Intel 8.1.025 I just realized I don't know the exact rev of Intel I have on my machine at work, but will check it in the morning. I know it is at least 8.1.019. I seem to be looking at a problem with either SMP vs. UP builds or minor revision changes in the Intel compiler. 8.1.025 being the known working version in this case. Also, I've gotten the same results with 1.32 and 1.33 RC2. Also, thanks for a great library. We have been using it pretty extensively throughout our app; including threading, shared_ptr, spirit, date_time, bind, filesystem and multi_index (there may even be more that I can't think of right now). boost has been great fun to work with. Cheers, tim

1 0

determinant of Matrices
by Vivid Yang 10 Aug '05

10 Aug '05

Hi, I browsed the document of ublas for a long time and did not find a convenient way to compute the determinant of a matrix. Isn't it a basic function of matrix or did I miss something? And are there functions to compute the singular values/vectors of a matrix? How about the inverse of a square full-rank matrix? btw. what is new in the new boost library version 1.33? Vivid

4 3

hash function for edge_descriptor
by Wolfram Koska 09 Aug '05

09 Aug '05

Hello there, I was trying to create hash_maps with vertex_descriptors and edge_descriptors. The first one was easy with vertex_descriptors being just void*'s, and there is even an example in the boost detail namespace (although it's not activated using gcc): template <> struct hash< void* > { std::size_t operator()(void* v) const { return (std::size_t)v; } } But the edge_descriptors give me some serious headache. How could I create a hash function for them? Is using the source and target a good idea in graphs where there could easily be more than one edge between two vertices? Or is there a great method I cannot come up with? I hope that somebody can help me out here :) Thanks, Wolfram Koska

3 5

string algo problem
by Giampiero Gabbiani 09 Aug '05

09 Aug '05

hi to all, I'm trying to implementing a string class as a std::list of elements that can be common char, wchar_t or something else (as utf-16 chars, for example). In order to obtain this, I've defined a collection as a template class, and used with different value_type(s). When I try to use the collection with char or wchar_t, the boost algo to_upper works fine but, when I use the collection template with a UTF16::Char (a class that implements the UTF-16 encoding) I obtain the following exception: Exception catch:St8bad_cast The following code is the definition of the Char class and an example of its use with the standard list and the boost algo: namespace UTF16 { class Char { public: Char(); Char(const char c); // UTF-16 encoding constructor Char(wchar_t v); bool operator == (const Char& c) const; bool operator != (const Char& c) const; operator wchar_t () const; Char(const Char& chr); Char(Char& chr); ~Char(); Char& operator = (const Char& chr); Char& operator = (Char& chr); private: u_int16_t* _value; size_t _size; }; } int main(int argc, char *argv[]) { try { list<UTF16::Char> l; l.push_back(UTF16::Char('a')); // THE FOLLOWING LINE PRODUCES A 'bad_cast' exception... boost::algorithm::to_upper(l); } catch(const exception& error) { cout << "Exception catch:" << error.what() << endl; } catch(...) { cerr << "Unhandled exception.\n"; } return EXIT_SUCCESS; } Is there something wrong/missing in the definition of the Char class? Or maybe the boost string algos are usable only with char and wchar_t? Thanks in advance Giampiero.

2 1

[BGL] connected_components of filtered_graph
by Yoshi Fujiwara 09 Aug '05

09 Aug '05

With boost_1_32_0, i want to find connected components of a filtered graph. What is an appropriate second argument of algorithm, connected_components, which is applied to a filtered graph? The following obviously fails for finding components' ID for each vertex of filtered graph. // Filtered graph Graph g; // graph to be filtered typedef property_map<Graph, vertex_flag_t>::type VertexFlagMap; filter_vertex_flag<VertexFlagMap> v_filter(v_flag); typedef property_map<Graph, edge_flag_t>::type EdgeFlagMap; filter_edge_flag<EdgeFlagMap> e_filter(e_flag); typedef filtered_graph< Graph, filter_edge_flag<EdgeFlagMap>, filter_vertex_flag<VertexFlagMap> > FGraph; FGraph fg(g, e_filter, v_filter); // Connected components std::vector<int> comp(n_fg); int n_comp = connected_components(fg, make_iterator_property_map(comp.begin(), get(vertex_index,fg))); where n_fg is the number of vertices in the filtered graph. Instead make std::vector<int> comp(num_vertices(g)); and iterates over vertices in the filtered graph to see assigned components' ID, it's fine, but then i need to have extra space than necessary when a graph to be filtered is large but the filtered one is quite small. wondering what is appropriate for the second argument in my case. Though i tried to find an example in tutorial samples and checked the ML archive, i could not find a similar question before. i appreciate any help or "look at here". Yoshi

2 1