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

Overload boost::program_options validate() for double?
by Joseph Turian 26 Jul '05

26 Jul '05

Hi, I am having difficulty overloading validate() of boost::program_options to do conversion of doubles. I define it like in the example code ( http://www.boost.org/doc/html/program_options/howto.html#id549525) void validate(boost::any& v, const vector<string>& values, double* target_type, int) { cerr << "TEST\n"; } However, this method is bypassed and the original validate method is used instead. How can I get it to use *my* validate implementation for the double type? Thanks, Joseph -- http://www.cs.nyu.edu/~turian/

1 0

shared_array double free problem
by Jack Nguyen 26 Jul '05

26 Jul '05

Here is the compilable code: #include <boost/shared_array.hpp> #include <iostream> template <typename T> class VectorView; template <typename T> inline std::ostream& operator << (std::ostream& os, const VectorView<T>& VOut) { os<<VOut.size()<<std::endl; for (int i=0; i<VOut.size() && os.good(); ++i){ os<<VOut(i)<<""; os<<std::endl; } return os; } template<typename T> class VectorView { private: int _size; boost::shared_array<T> _vp; public: VectorView(T* ptr, int size) { _size=size; _vp=boost::shared_array<T>(ptr); } T operator () (int pos) const { return _vp[pos]; } int size() const { return _size; } ~VectorView() { } }; int main (void) { double a[]={1,2,3,4,5,6,7}; VectorView<double>V(a,4); std::cout<<V; return 0; } Any workaround?

2 1

Two Threads sharing a mutex
by Christian Henning 26 Jul '05

26 Jul '05

Hi there, please help me out. Seems I lost my brain over the last weekend. ;-)) I'm trying to get myself familiar with the boost::thread lib, by reading an article by Bill Kempf published in the C++ magazine in 2002. Here in listing no. 4 he is using two thread (a reader and a writer ) to access a buffer. In the put() and get() he is using one mutex. If the buffer is empty he uses a condition variable to block the mutex. I don't understand how a writer can then enter the put() and write an item into the buffer? The mutex was just blocked by the reader thread? I guess my question is more fundamental to threads. But hopefully there is someone that can help me out. Thanks ahead, Christian

3 3

BGL Question/Advice which algorithm to use
by Elisha Berns 26 Jul '05

26 Jul '05

Hi, This is a request for some advice/recommendations regarding which algorithm(s) to use with Boost.Graph to solve a graph sorting problem for graphs that are *almost, but not quite* DAGs. If anybody has some insight into this type of situation help will be greatly appreciated. Ideally I do a topological sort to find the most dependent vertex (if that makes sense) which then becomes the root of an n-ary tree, and then build the tree from that vertex recursively finding the out-edges of child vertices. All that works provided the graph is actually a DAG. But sometimes it isn't because there can be small cycles(?) inside the graph where one vertex refers to its parent's parent's vertex. So everything in the graph can be suitable for a DAG except for this small set of vertices that becomes self-referential. This small set of vertices, while not expendable, is certainly never going to contain the desired vertex to create a root, for various reasons. So during the search phase they can be safely ignored, at least that's a fairly safe operating assumption as of now. I still need to find the most dependent vertex, and I can't use topological sort here, so what algorithm can I use? Or if I still need to use topological sort here, would I clone the graph object and remove this set of vertices to create a DAG for the sake of the sort? Many thanks, Elisha Berns e.berns(a)computer.org tel. (310) 556 - 8332 fax (310) 556 - 2839

3 11

problem using boost::filesystem
by Mesut Büyüktokatli 26 Jul '05

26 Jul '05

Hello... I am triing to use the boost::filesystem library. But actually i am stucked using it. I have WindowsXP without a service pack. I am using Visual Studio 6.0 installed in default folders for VS6. I am using stlport but without the iostreams. After uncompressing boost, i compiled boost with bjam with following statement: bjam "-sTOOLS=msvc-stlport" "-sSTLPORT_VERSION=4.6" "-sSTLPORT_PATH=..\stlport" "-sBUILD=debug <stlport-iostream>off" stage Compilation has no errors and all libs are build. Now i want to use boost::filesystem::path, example: #include <boost/filesystem/path.hpp> int main(int argc, char* argv[]) { boost::filesystem::path( "foo" ); } What happens, is that the program stops on that command and does nothing! If i use following code: boost::filesystem::path( "C:\\" ); System makes an kernal32 exception and crashs. Same happens when i use boost::filesystem::exists Could you please help me why that happens??? Thx Mesut

3 4

Re: [Boost-users] performance issue with graph edge removal
by Feldman, Yulik 25 Jul '05

25 Jul '05

I've also noticed that when in/out edge lists are stored in an associative container and the parallel edges are allowed, i.e multiset is used, the functions remove_edge()/clear_vertex() do not work as efficient as they could. The calls to these functions (in my case) result in the following sequence of calls: // O(E/V) template <class EdgeList, class vertex_descriptor> void erase_from_incidence_list(EdgeList& el, vertex_descriptor v, allow_parallel_edge_tag) { boost::graph_detail::erase_if(el, detail::target_is<vertex_descriptor>(v)); } Then: template <class Container, class Predicate> void erase_if(Container& c, Predicate p) { erase_if_dispatch(c, p, container_category(c), iterator_stability(c)); } Then: template <class AssociativeContainer, class Predicate> void erase_if_dispatch(AssociativeContainer& c, Predicate p, associative_container_tag, stable_tag) { typename AssociativeContainer::iterator i, next; for (i = next = c.begin(); next != c.end(); i = next) { ++next; if (p(*i)) c.erase(i); } } The complexity of the search operation is linear, so multiset doesn't provide a performance advantage over containers such as vector or set. However, the function erase_if_dispatch() could use multiset's equal_range() member function, which would result in O(log n) complexity of the search. I understand that the reason erase_if_dispatch() is written in the way it is written, is probably that the function is generic with regard to the predicate and doesn't do assumptions on it. However, in the case erase_if_dispatch() is called from erase_from_incidence_list(), where the predicate is set, the function (its special specialization) could make assumption that the predicate is actually the same as the predicate used to sort the in/out edge list itself (the target vertex), and therefore could use equal_range() to boost the performance of the function. --Yulik.

2 1

Re: [Boost-users] minimal spanning trees & Visual C++ 7.1
by Amit K. Jain 25 Jul '05

25 Jul '05

Thank you, it worked! It is bizarre behavior on the compiler's part, I hope they get it fixed eventually. -Amit > Hi! > > I suffered from ICEs using boost as well. They occured using multi_index lib, though. Turning of "Minimal Rebuild" helped for me. > > kind regards > > Alex

2 1

Missing functions in lexical_cast
by Sean Rohead 25 Jul '05

25 Jul '05

I would like to convert between std::wstring and std::string using lexical_cast and finally discovered in an old posting that you must manually provide template specializations for these types as below. My question is why these aren't provided in lexical_cast.hpp already? template<> inline std::wstring boost::lexical_cast(std::string source) { std::wstring result(source.size(), wchar_t(0)); typedef std::ctype<wchar_t> ctype_t; const ctype_t& ct = std::use_facet<ctype_t>(std::locale()); ct.widen(source.data(), source.data() + source.size(), &(*result.begin())); return result; } template<> inline std::string boost::lexical_cast(std::wstring source) { std::string result(source.size(), char(0)); typedef std::ctype<wchar_t> ctype_t; const ctype_t& ct = std::use_facet<ctype_t>(std::locale()); ct.narrow(source.data(), source.data() + source.size(), '\u00B6', &(*result.begin())); return result; }

2 1

Re: [Boost-users] minimal spanning trees & Visual C++ 7.1
by Jasper, Alexander 25 Jul '05

25 Jul '05

Hi! I suffered from ICEs using boost as well. They occured using multi_index lib, though. Turning of "Minimal Rebuild" helped for me. kind regards Alex > -----Ursprüngliche Nachricht----- > Von: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org]Im Auftrag von > Amit K. Jain > Gesendet: Montag, 25. Juli 2005 00:55 > An: boost-users(a)lists.boost.org > Betreff: [Boost-users] minimal spanning trees & Visual C++ 7.1 > > > Hello, I've got the latest version of Boost set up w/ Visual C++ 7.1. > When I try to compile kruskal-example.cpp or prim-example.cpp, I get > an internal compiler error on properties.hpp:216. > > I'm reasonably sure that I have Boost set up properly because I can > use the strongly connected components stuff w/ adjacency lists just > fine. > > Has this happened to anyone else and, if so, does anyone know how to > work around it? Thanks in advance > > -Amit > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users >

1 0

Boost.Regex error: match_results error
by reecky 25 Jul '05

25 Jul '05

hi, when I have built the Boost.Regex libarary,and then I tested the samples of the regex. Then I found the credit_card_example correct while the capture_example error. Fistly, the capture_example compiled with the error the .captures(i) is not the member function of the match_results, then I found the source file of match_results.hpp and found this MACRO as below: #ifdef BOOST_REGEX_MATCH_EXTRA typedef typename sub_match<BidiIterator>::capture_sequence_type capture_sequence_type; const capture_sequence_type& captures(int i)const { return (*this)[i].captures(); } #endif so I defined the macro BOOST_REGEX_MATCH_EXTRA, then it compiled successful. but the error occured when I runned the program. the memory leak and system dead. so I wondered what's mean of the BOOST_REGEX_MATCH_EXTRA? many thanks for you. leecky 2005.7.25

2 1