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

RE: (unknown)
by Mark Storer 24 Sep '02

24 Sep '02

Nope. Container-agnostic code is a red herring. Don't bother, you'll only be waisting your time. "Effective STL" covers this in detail in Chapter 1, item 2, far better than anything I could come up with. You might be able to come up with 'map' and 'everything else' versions of your code, but even that will have some unexpected side effects. Now, having said all that, here's an idea (I seem to be developing a habit of contradicting myself): Accept as part of the enumerator template an 'accessor', one that would default to returning the contents of the iterator, but could be replaced with something that extracted "->second". Your code would end up looking something like this: // WARNING: This code hasn't been anywhere near a compiler. template <typename T> struct accessor { typedef T::value_type accessee; accessee &operator()( T &t ) { return *T; } }; template <typename T> struct map_accessor { typedef T::value_type::second accessee; accessee &Map_Accessor( T &t ) { return t->second; } }; template <typename T, typename acc = Accessor<T>> EnumCols( T &begin, T &end, acc accessor ) { T cur; if(begin == end) return; // get matrix width size_t rows = acc( begin ).size(); for(int i = 0; i < rows; ++i) { cur = begin; while(cur != end) { // a useful EnumCols would have to take some // sort of function as a paramenter and use // it to replace DO_STUFF below DO_STUFF( acc(cur)[i] ); ++cur; } } } EnumCols( matrix.begin(), matrix.end(), Map_Accessor<matrix's type> ); // for maps or EnumCols( matrix.begin(), matrix.end()); // for everything else These function templates could either exist stand-alone, or as some sort of 'container-traits'. The traits tact would force you to wrap all the containers you actually wanted to use with templates that defined the appropriate traits, but would allow the actual enumeration code to be considerably cleaner (through default template params). But all this involves rolling your own code, which would place this conversation firmly in the "other" boost list. --Mark Storer Software Engineer Cardiff Software #include <disclaimer> typedef std::disclaimer<Cardiff> Discard; -----Original Message----- From: Antonio Piccolboni [mailto:antonio_piccolboni@affymetrix.com] Sent: Tuesday, September 24, 2002 12:01 PM To: Boost-Users(a)yahoogroups.com Subject: [Boost-Users] (unknown) Dear Boosters Suppose you have a matrix represented raw-wise with a vector< vector <float > > and you want to iterate over the coloumns. Easy with the projection adaptor. But life is never so easy. My matrix is represented raw wise by a map <vector <float> > and I need the same kind of iterator. There is no way I can get my code to compile. I think the problem is that vector iterators return values, map iterators retun pairs <key,value> (that is, references to the above). And this seems not only to doom my attempt at defining this n-th dim projection iterator, but even more so and fundamentally, it seem to preclude my ultimate goal of defining a projection for any container1 <containr2 < element_type > > where container2 two is random access. Any help would be appreciated and if I make it to the larger goal, I will return it to the community. Thanks Antonio Header #ifndef GRAPH_H #define GRAPH_H #include <boost/config.hpp> #include <vector> #include <iostream> #include <iterator> #include <algorithm> #include <boost/iterator_adaptors.hpp> //typedef pair<long, vector<float> > graph_element; typedef vector<float> graph_element; template <int index> struct select_component { typedef pair < long, graph_element > argument_type; typedef float result_type; const float & operator()(const graph_element & r) const { return r.second[index]; } float & operator()(graph_element & r) const { return r.second[index]; } }; #endif Would be test code #include "graph.h" #include <map> #include<vector> int main(int, char*[]) { typedef map < long, graph_element > graph; graph aGraph; aGraph[0].push_back(0.00); aGraph[0].push_back(0.01); aGraph[0].push_back(0.02); aGraph[1].push_back(0.10); aGraph[1].push_back(0.11); aGraph[1].push_back(0.12); aGraph[2].push_back(0.20); aGraph[2].push_back(0.21); aGraph[2].push_back(0.22); aGraph[3].push_back(0.30); aGraph[3].push_back(0.31); aGraph[3].push_back(0.32); boost::projection_iterator_generator < select_component < 0 >, graph::iterator >::type graph_first(aGraph.begin()), graph_last(aGraph.end()); copy(graph_first, graph_last, ostream_iterator<float>(cout, "\n")); cout << endl; } Post-modern error message cd /home/apicco/src/analysis/transcriptome/transmap/ g++ -g -I/home/apicco/install/boost_1_28_0 -o graph-test graph-test.C /home/apicco/install/boost_1_28_0/boost/iterator_adaptors.hpp: In method `typename IteratorAdaptor::reference boost::projection_iterator_policies<AdaptableUnaryFunction>::dereferen ce (const IteratorAdaptor &) const [with IteratorAdaptor = boost::iterator_adaptor<_Rb_tree_iterator<pair<const long int, graph_element>, pair<const long int, graph_element> &, pair<const long int, graph_element> *>, boost::projection_iterator_policies<select_component<0> >, float, float &, float *, boost::detail::default_argument, boost::detail::default_argument>, AdaptableUnaryFunction = select_component<0>]': /home/apicco/install/boost_1_28_0/boost/iterator_adaptors.hpp:867: instantiated from `boost::iterator_adaptor<Base, Policies, Value, Reference, Pointer, Category, Distance>::operator* () const [with Base = _Rb_tree_iterator<pair<const long int, graph_element>, pair<const long int, graph_element> &, pair<const long int, graph_element> *>, Policies = boost::projection_iterator_policies<select_component<0> >, Value = float, Reference = float &, Pointer = float *, Category = boost::detail::default_argument, Distance = boost::detail::default_argument]' /usr/include/g++-3/stl_algobase.h:129: instantiated from `__copy (_InputIter, _InputIter, _OutputIter, input_iterator_tag, _Distance *) [with _InputIter = boost::iterator_adaptor<_Rb_tree_iterator<pair<const long int, graph_element>, pair<const long int, graph_element> &, pair<const long int, graph_element> *>, boost::projection_iterator_policies<select_component<0> >, float, float &, float *, boost::detail::default_argument, boost::detail::default_argument>, _OutputIter = ostream_iterator<float>, _Distance = ptrdiff_t]' /usr/include/g++-3/stl_algobase.h:161: instantiated from `__copy_dispatch<_InputIter, _OutputIter, _BoolType>::copy (_InputIter, _InputIter, _OutputIter) [with _InputIter = boost::iterator_adaptor<_Rb_tree_iterator<pair<const long int, graph_element>, pair<const long int, graph_element> &, pair<const long int, graph_element> *>, boost::projection_iterator_policies<select_component<0> >, float, float &, float *, boost::detail::default_argument, boost::detail::default_argument>, _OutputIter = ostream_iterator<float>, _BoolType = __true_type]' /usr/include/g++-3/stl_algobase.h:188: instantiated from `copy (_InputIter, _InputIter, _OutputIter) [with _InputIter = boost::iterator_adaptor<_Rb_tree_iterator<pair<const long int, graph_element>, pair<const long int, graph_element> &, pair<const long int, graph_element> *>, boost::projection_iterator_policies<select_component<0> >, float, float &, float *, boost::detail::default_argument, boost::detail::default_argument>, _OutputIter = ostream_iterator<float>]' graph-test.C:30: instantiated from here /home/apicco/install/boost_1_28_0/boost/iterator_adaptors.hpp:1247: no match for call to `(const select_component<0>) (pair<const long int, graph_element> &)' graph.h:19: candidates are: const float &select_component<index>::operator() (const graph_element &) const [with int index = 0] graph.h:22: float &select_component<index>::operator () (graph_element &) const [with int index = 0] Compilation exited abnormally with code 1 at Tue Sep 24 11:14:11 Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

1 0

projection iterator onto the k-th dimension
by Antonio Piccolboni 24 Sep '02

24 Sep '02

Reporting some progress wrt my previous post and adding a meaningful title. The code doesn't break on the iterator def but at the first usage. Error is (translated) can't convert return value of unary func obj to float &. Note that () returns float & Current code #ifndef GRAPH_H #define GRAPH_H #include <boost/config.hpp> #include <vector> #include <iostream> #include <iterator> #include <algorithm> #include <boost/iterator_adaptors.hpp> typedef vector<float> graph_element; template <int index> struct select_component { typedef pair < long, graph_element > argument_type; typedef float result_type; const float & operator()(const argument_type & r) const { return r.second[index]; } float & operator()(argument_type & r) const { return r.second[index]; } }; #endif Use case #include "graph.h" #include <map> #include<vector> int main(int, char*[]) { typedef map < long, graph_element > graph; graph aGraph; aGraph[0].push_back(0.00); aGraph[0].push_back(0.01); aGraph[0].push_back(0.02); aGraph[1].push_back(0.10); aGraph[1].push_back(0.11); aGraph[1].push_back(0.12); aGraph[2].push_back(0.20); aGraph[2].push_back(0.21); aGraph[2].push_back(0.22); aGraph[3].push_back(0.30); aGraph[3].push_back(0.31); aGraph[3].push_back(0.32); boost::projection_iterator_generator < select_component < 0 >, graph::iterator >::type graph_first(aGraph.begin()), graph_last(aGraph.end()); // copy(graph_first, graph_last, // ostream_iterator<float>(cout, "\n")); cout << *graph_first; cout << endl; } Postmodern error message: cd /home/apicco/src/analysis/transcriptome/transmap/ g++ -g -I/home/apicco/install/boost_1_28_0 -o graph-test graph-test.C /home/apicco/install/boost_1_28_0/boost/iterator_adaptors.hpp: In method `typename IteratorAdaptor::reference boost::projection_iterator_policies<AdaptableUnaryFunction>::dereferen ce (const IteratorAdaptor &) const [with IteratorAdaptor = boost::iterator_adaptor<_Rb_tree_iterator<pair<const long int, graph_element>, pair<const long int, graph_element> &, pair<const long int, graph_element> *>, boost::projection_iterator_policies<select_component<0> >, float, float &, float *, boost::detail::default_argument, boost::detail::default_argument>, AdaptableUnaryFunction = select_component<0>]': /home/apicco/install/boost_1_28_0/boost/iterator_adaptors.hpp:867: instantiated from `boost::iterator_adaptor<Base, Policies, Value, Reference, Pointer, Category, Distance>::operator* () const [with Base = _Rb_tree_iterator<pair<const long int, graph_element>, pair<const long int, graph_element> &, pair<const long int, graph_element> *>, Policies = boost::projection_iterator_policies<select_component<0> >, Value = float, Reference = float &, Pointer = float *, Category = boost::detail::default_argument, Distance = boost::detail::default_argument]' graph-test.C:31: instantiated from here /home/apicco/install/boost_1_28_0/boost/iterator_adaptors.hpp:1247: could not convert `(this + 1)->select_component<index>::operator()((&pair<long int,vector<float, allocator<float> > >((+(+(+iter)->boost::iterator_adaptor<Base, Policies, Value, Reference, Pointer, Category, Distance>::base())->_Rb_tree_iterator<_Value, _Ref, _Ptr>::operator* ()))))' to `float &' Compilation exited abnormally with code 1 at Tue Sep 24 14:52:21

1 0

grid graph for BGL
by toddgleason 24 Sep '02

24 Sep '02

Hi, I'm new to using the BGL, and have been working on a problem that uses a directed acyclic grid graph and subgraphs, and computes shortest paths. In my problem, the subgraphs are determined by paths from one end to the other. It is possible to determine in constant time whether a grid point or edge is within the graph, by looking at the paths bounding the subgraph. I started out using adjacency_list and filtered_graph to limit the graph, but this is not optimal because adjacency_list iterates over all vertices in the original graph to filter them. Ideally I'd like to use the indices from the master graph but be able to dynamically iterate over them according to the computations the code performs to limit the scope of the graphs. However, I'm not sure if anyone has done anything like this, and I'm a little frightened of trying to write my own graph class into the BGL structure. (I've never dealt with such heavily templated code before, and am even more confused than when looking at the STL!) Are there any pointers anyone can give me that would make it easier to construct such a class? Another option I'll throw out: Might it be simpler to hack one of the shortest paths algorithms to do a better job of restricting itself based on the dynamic subgraph filtering? I considered this (the code looks shorter and simpler), but it'd be cleaner to have a new graph class. Thanks to any who can help me. Also, I'm using VC++ 6 so all the problems with partial template specialization (which I don't even understand) apply to me. --Todd C. Gleason

3 3

None
by Antonio Piccolboni 24 Sep '02

24 Sep '02

Dear Boosters Suppose you have a matrix represented raw-wise with a vector< vector <float > > and you want to iterate over the coloumns. Easy with the projection adaptor. But life is never so easy. My matrix is represented raw wise by a map <vector <float> > and I need the same kind of iterator. There is no way I can get my code to compile. I think the problem is that vector iterators return values, map iterators retun pairs <key,value> (that is, references to the above). And this seems not only to doom my attempt at defining this n-th dim projection iterator, but even more so and fundamentally, it seem to preclude my ultimate goal of defining a projection for any container1 <containr2 < element_type > > where container2 two is random access. Any help would be appreciated and if I make it to the larger goal, I will return it to the community. Thanks Antonio Header #ifndef GRAPH_H #define GRAPH_H #include <boost/config.hpp> #include <vector> #include <iostream> #include <iterator> #include <algorithm> #include <boost/iterator_adaptors.hpp> //typedef pair<long, vector<float> > graph_element; typedef vector<float> graph_element; template <int index> struct select_component { typedef pair < long, graph_element > argument_type; typedef float result_type; const float & operator()(const graph_element & r) const { return r.second[index]; } float & operator()(graph_element & r) const { return r.second[index]; } }; #endif Would be test code #include "graph.h" #include <map> #include<vector> int main(int, char*[]) { typedef map < long, graph_element > graph; graph aGraph; aGraph[0].push_back(0.00); aGraph[0].push_back(0.01); aGraph[0].push_back(0.02); aGraph[1].push_back(0.10); aGraph[1].push_back(0.11); aGraph[1].push_back(0.12); aGraph[2].push_back(0.20); aGraph[2].push_back(0.21); aGraph[2].push_back(0.22); aGraph[3].push_back(0.30); aGraph[3].push_back(0.31); aGraph[3].push_back(0.32); boost::projection_iterator_generator < select_component < 0 >, graph::iterator >::type graph_first(aGraph.begin()), graph_last(aGraph.end()); copy(graph_first, graph_last, ostream_iterator<float>(cout, "\n")); cout << endl; } Post-modern error message cd /home/apicco/src/analysis/transcriptome/transmap/ g++ -g -I/home/apicco/install/boost_1_28_0 -o graph-test graph-test.C /home/apicco/install/boost_1_28_0/boost/iterator_adaptors.hpp: In method `typename IteratorAdaptor::reference boost::projection_iterator_policies<AdaptableUnaryFunction>::dereferen ce (const IteratorAdaptor &) const [with IteratorAdaptor = boost::iterator_adaptor<_Rb_tree_iterator<pair<const long int, graph_element>, pair<const long int, graph_element> &, pair<const long int, graph_element> *>, boost::projection_iterator_policies<select_component<0> >, float, float &, float *, boost::detail::default_argument, boost::detail::default_argument>, AdaptableUnaryFunction = select_component<0>]': /home/apicco/install/boost_1_28_0/boost/iterator_adaptors.hpp:867: instantiated from `boost::iterator_adaptor<Base, Policies, Value, Reference, Pointer, Category, Distance>::operator* () const [with Base = _Rb_tree_iterator<pair<const long int, graph_element>, pair<const long int, graph_element> &, pair<const long int, graph_element> *>, Policies = boost::projection_iterator_policies<select_component<0> >, Value = float, Reference = float &, Pointer = float *, Category = boost::detail::default_argument, Distance = boost::detail::default_argument]' /usr/include/g++-3/stl_algobase.h:129: instantiated from `__copy (_InputIter, _InputIter, _OutputIter, input_iterator_tag, _Distance *) [with _InputIter = boost::iterator_adaptor<_Rb_tree_iterator<pair<const long int, graph_element>, pair<const long int, graph_element> &, pair<const long int, graph_element> *>, boost::projection_iterator_policies<select_component<0> >, float, float &, float *, boost::detail::default_argument, boost::detail::default_argument>, _OutputIter = ostream_iterator<float>, _Distance = ptrdiff_t]' /usr/include/g++-3/stl_algobase.h:161: instantiated from `__copy_dispatch<_InputIter, _OutputIter, _BoolType>::copy (_InputIter, _InputIter, _OutputIter) [with _InputIter = boost::iterator_adaptor<_Rb_tree_iterator<pair<const long int, graph_element>, pair<const long int, graph_element> &, pair<const long int, graph_element> *>, boost::projection_iterator_policies<select_component<0> >, float, float &, float *, boost::detail::default_argument, boost::detail::default_argument>, _OutputIter = ostream_iterator<float>, _BoolType = __true_type]' /usr/include/g++-3/stl_algobase.h:188: instantiated from `copy (_InputIter, _InputIter, _OutputIter) [with _InputIter = boost::iterator_adaptor<_Rb_tree_iterator<pair<const long int, graph_element>, pair<const long int, graph_element> &, pair<const long int, graph_element> *>, boost::projection_iterator_policies<select_component<0> >, float, float &, float *, boost::detail::default_argument, boost::detail::default_argument>, _OutputIter = ostream_iterator<float>]' graph-test.C:30: instantiated from here /home/apicco/install/boost_1_28_0/boost/iterator_adaptors.hpp:1247: no match for call to `(const select_component<0>) (pair<const long int, graph_element> &)' graph.h:19: candidates are: const float &select_component<index>::operator() (const graph_element &) const [with int index = 0] graph.h:22: float &select_component<index>::operator () (graph_element &) const [with int index = 0] Compilation exited abnormally with code 1 at Tue Sep 24 11:14:11

1 0

Borland C++ Builder 5.5 & scoped_ptr
by Brian Neal 24 Sep '02

24 Sep '02

I'm new here; I searched the Yahoo archive and didn't see anything about this so I apologize if this has been discussed before. Today I learned (the hard and painful way) that there is a bug in Borland C++ Builder 5.5 such that when compiling with debug support, the compiler thinks it needs to generate destructors in the wrong translation units. We noticed this because we were using the "handle-body" idiom with auto_ptr's (taking all the precautions from Herb Sutter's Exceptional C++ books) and our destructors were not getting called. We switched over to boost::shared_ptr's and the handy-dandy compile time check in the destructor for incomplete types was firing...but in the code that uses and declares objects of the classes that have the handle-body idiom...a pretty serious bug in my view. We then tried to compile the example code from boost for scoped_ptr and it would not compile for the same reason. A quick search of the newsgroups reveals that others have found this bug, and C++ Builder is the only major compiler that has this flaw. I've heard that it has been fixed in version 6. Can others verify this? So I am posting this for 2 reasons: 1) to let others know about it (in case you don't know already), and 2) I noticed that in the Boost compiler status web-page it says that smart_ptr passed all its tests with C++ Builder 5.5.1. I didn't look at the tests, but was this handle-body type usage tested to make sure the destructor was called? Or perhaps it was but without debug support turned on? Thanks, Brian Neal

6 12

Using regex++ with non-standard character types
by miles_gould 24 Sep '02

24 Sep '02

Our application stores all characters internally as XMLCh, which is a typedef to either wchar_t or unsigned short, depending on platform and various other things. My questions are 1) Is it even possible to use regex++ with types which are not char or wchar_t? The documentation gives no examples of any other types, and at one point says "the character type, ie char or wchar_t". When I try to construct a reg_expression<XMLCh>, I get the following error message: ../../src/boost/boost/regex.hpp: In instantiation of `boost::regex_traits<unsigned int>': ../../src/boost/boost/regex.hpp:461: instantiated from `boost::reg_expression<unsigned int, boost::regex_traits<unsigned int>, allocator<size_t> >' regex.cpp:33: instantiated from here ../../src/boost/boost/regex.hpp:461: base class `boost::c_regex_traits<unsigned int>' has incomplete type ../../src/boost/boost/regex.hpp: In instantiation of `boost::reg_expression<unsigned int, boost::regex_traits<unsigned int>, allocator<size_t> >': regex.cpp:33: instantiated from here ../../src/boost/boost/regex.hpp:461: no type named `size_type' in `class boost::regex_traits<unsigned int>' ../../src/boost/boost/regex.hpp:462: no type named `uchar_type' in `class boost::regex_traits<unsigned int>' ../../src/boost/boost/regex.hpp:463: no type named `string_type' in `class boost::regex_traits<unsigned int>' ../../src/boost/boost/regex.hpp:471: no type named `locale_type' in `class boost::regex_traits<unsigned int>' [compilation is on GCC 2.96 under Red Hat Linux 7.2] 2) Does this mean I need to define a custom traits class? (or rather a custom traits class for every possible definition of XMLCh?) Is there anything else I need to do?

3 2

VxWorks was Re: shared_ptr documentation suggestion
by Brian Neal 23 Sep '02

23 Sep '02

> From: "Peter Dimov" <pdimov(a)mmltd.net> > From: "Brian" <bneal(a)zeus.ia.net> > >... > > BTW, can I submit a VxWorks version of shared_count? Does boost have > > an interest in expanding beyond Win32/Posix/Linux? > > Yes. Platform-specific implementations of detail::atomic_count (used by > 1.27) and detail::lightweight_mutex (used by the later versions) are > welcome. Please take the time to read the comments in (the latest versions > of) atomic_count.hpp and lightweight_mutex.hpp, though, as > writing optimized > threading primitives by hand is very difficult and error prone, > as I learned > the hard way. Of course a realtime OS should already have such primitives; > I'm not familiar with VxWorks. I am interested in doing this. I will take a look at those files. VxWorks has primitives for these operations already. I would also like to take on getting boost threads running under VxWorks, but I am not sure if I have the time right now. I'll look into it. We already have thread classes that wrap both VxWorks and Win32 so our software runs on both. Last time I looked, boost threads were pretty simplistic (understandably at this point in time). Why is the boost 1.28.0 zip distro 5.6 Megs COMPRESSED! Is it really that big or is it all those pictures and documentation files? Thanks, Brian

1 0

Compiling boost under gcc 2.95.3/solaris
by Wen Yu 23 Sep '02

23 Sep '02

Hi! I'm running into the brickwall now while trying to port "boost" containing codes from VC7 to gcc. Anyone has a pointer to a makefile for this combination. The codes works flawlessly inside Microsoft .NET IDE. I've tried ./configure script, manually edit the "user.hpp" and many fruitless hours to no aval. The "bjam" build of the library seems to be at least partially sucesful. Please help before I had to abandon the ship. Thanks! Wen

2 2

pointer traints ?
by Bohdan 23 Sep '02

23 Sep '02

I have following code: template < typename PointerT > void f( PointerT ptr ) { ReferenceT ref = *ptr; // ... do something with ref ... } The problem is that ReferenceT is unknown inside f( ... ). If i had similar code for InteratorT instead of PointerT i was using iterator_traits. AFAIK there is no pointer traits for a raw and smart pointers and i can not use type_traits for smart pointers. So, the question is: "Is there some simple solution for this problem or this is just lack of pointer_traits in boost (std?) ?" regards, bohdan

1 0

what's the purpose of the typedef in check_delete.hpp?
by zhangwusheng 23 Sep '02

23 Sep '02

Why?And for what purpose? I cannot understand the following words: // verify that types are complete for increased safety thanks

4 4

Bind problems
by judoka1981 23 Sep '02

23 Sep '02

Hi, I'm trying to find the first non-space character of a string using boost::bind, but I simply can't get this to compile: --- static void Trim(std::string& stringToTrim) { std::string::iterator firstNonSpace = std::find_if(stringToTrim.begin(), stringToTrim.end(), boost::bind(std::not_equal_to<int>(), boost::bind(&isspace, _1), 0)); .... --- Am I doing something seriously wrong, or is this a compiler limitation (VC.NET)? (If anyone has a method to do this without using isspace, I'd be happy to see it). Thanks // Johan

3 4

Include directories
by sashang＠ihug.co.nz 23 Sep '02

23 Sep '02

This is a silly question. I feel silly asking it. How do I tell the compiler via the jamfile about extra directories to look in for include files? I've tried adding "-sHDRS=e:/mystuff/include" to the command line when invoking bjam. I've tried placing : <include>e:/mystuff/include at various places withing the jam file. Thanks Sashan

1 0

shared_ptr documentation suggestion
by Brian 22 Sep '02

22 Sep '02

Thank you boost developers for your great work. I've already started using some smart_ptr's, regex, and the any type. I started to look at shared_ptr for my needs (working in a realtime embedded systems environment). I started wondering how it protects its reference count but was surprised to not see anything about this in the documentation. Examining the code I see it uses a platform specific mutex type mechanism if it is available. Otherwise the reference count is not thread safe. I was also alarmed to see that the #error "your reference count is not thread safe" was commented out! Just a suggestion: mention in the documentation whats going on here. The operating system I am using (VxWorks) is not supported by shared_count right now, and had I not been curious I would have not noticed this. Also, even if it was, it can be very expensive for a realtime embedded system (e.g. running on a very slow processor) to take a mutex, especially if done at a very high rate, which is a concern of mine in a few places in my code. BTW, can I submit a VxWorks version of shared_count? Does boost have an interest in expanding beyond Win32/Posix/Linux? Again, thanks for the great software, Brian Neal

3 3

newbie question on tokenizer and unicode text
by elqed1 21 Sep '02

21 Sep '02

Hi all, I'm a newcomer to boost and am rewriting one of my text characterization programs to use some boost libraries. I'm running into a problem with non ascii text. I'm using MSVC 7.0 to compile my program and the project is setup to link to the unicode CRT. The problem is when boost::char_delimiters_separator<>::is_nonret is calling MSVC's CRT std::isspace() which takes an int; and isspace() is (of course) choking on a '©' (for example) in my training data. Is there something obvious I'm missing? Thanks in advance. -Eric Lucas

1 0

RE: [Boost-Users] newsgroup
by Jim.Hyslop 20 Sep '02

20 Sep '02

Ihsan Ali Al Darhi [mailto:iad929@joinnet.com.jo] wrote: > how can i access the boost newsgroups? Boost and Boost Users are both mirrored through gmane.org. You should be able to point your newsreader at news.gmane.org. You can get more details at http://www.boost.org/more/mailing_lists.htm, or by going directly to gmane http://www.gmane.org -- Jim

1 0

RE: [Boost-Users] Slightly Off-Topic, Books
by Jim.Hyslop 20 Sep '02

20 Sep '02

Your post is not "slightly" off topic, it is entirely off topic. -- Jim Hyslop moderator, boost-users(a)yahoogroups.com

1 0

RE: [Boost-Users] Re: [BGL] Best way to abort an algorithm from w ithi n a visitor?
by Mark Storer 20 Sep '02

20 Sep '02

Using exceptions in this way just bugs me. Religious reasons I guess. As the Esteemed Mr. Hylsop ;) mentioned earlier, exceptions are for "oops". This seems alot like the whole "do{}while(0)" with various 'break' statements sprinkled in to avoid multiple returns/nested ifs. Useful, but Just Not Right. Your code has cooties! Nobody's going to want to sit next to it during recess... >So there's no way to affect feedback to the algorithm's dispatcher >without actually making modifications to the algorithm code. So modify away. Seems like a "breath_first_until" sort of thing would be quite useful. Pass in some sort of predicate, and away you go. I'm sure the community at large would be grateful. --Mark Storer Software Engineer Cardiff Software #include <disclaimer> typedef std::disclaimer<Cardiff> Discard; -----Original Message----- From: Chris Russell [mailto:cdr@encapsule.com] Sent: Wednesday, September 18, 2002 1:27 PM To: boost-users(a)yahoogroups.com Subject: [Boost-Users] Re: [BGL] Best way to abort an algorithm from withi n a visitor? > Now if you've got more than a hundred or so entries left to go, exceptions > really are the greener grass. > The size of the graph is not known a-priori (not at coding time anyway) but is likely to be quite large. > What's wrong with 'return', perhaps along-side some sort of 'done' status > variable? I'm only vaguely familiar with the visitor pattern, but these > would seem to be the obvious choice. > See my earlier reply. In this case I'm deriving my visitor from a base and overriding "event" handlers that receive their marching orders via const references and return void. So there's no way to affect feedback to the algorithm's dispatcher without actually making modifications to the algorithm code. "Mark Storer" <mstorer(a)cardiff.com> wrote in message news:E840F0B7E6189547BDB91DA8BF2228AB016255F8@csmail.cardiff.com... > If efficiency is your goal, exceptions are not the answer. Just enabling > exceptions at compile time makes a noticable performance hit. Actually > throwing an exception can gobble up a 1000 cycles, give or take. That's per > throw. If you catch and throw again, you'll pay again. > > Now if you've got more than a hundred or so entries left to go, exceptions > really are the greener grass. > > What's wrong with 'return', perhaps along-side some sort of 'done' status > variable? I'm only vaguely familiar with the vistor pattern, but these > would seem to be the obvious choice. > > --Mark Storer > Software Engineer > Cardiff Software > > #include <disclaimer> > typedef std::disclaimer<Cardiff> Discard; > Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

7 11

Slightly Off-Topic, Books
by James Zappia 20 Sep '02

20 Sep '02

Hello, I'm a long time C/Perl programming and would like to transition into C++. What are some books I should pick up? I have the C++ Complete Reference for all the syntax sugar. I'm more interested in books that teach how to program in the mindset of objects. Also, books that don't read like RFCs ;) I learn better with examples and such -- not just brain dumps. Thank you in advance. Regards, James

1 0

boost::shared_ptr confusion...
by someuserat 20 Sep '02

20 Sep '02

First, many thanks to Peter Dimov for answering my earlier questions. I've gotten hung up on something that may not be directly related to shared_ptr, but it's in the mix here. I suspect the real problem is my lack of experience using the STL algorithms, but I'm making an effort not to go back to writing my own loops with this project. Using my Widget theme, here's what I've got. A WidgetManager class contains a stl::list of shared_ptr<Widget> objects. It also contains a stl::vector of shared_ptr<WidgetMap> objects. WidgetMap objects contain a B+tree. (I know, I should probably change this to stl::map or multimap, I'll do that later) The index maps a data member of a Widget to a shared_ptr to the Widget for fast lookups. It is possible that new data members can be added or removed from the Widgets, and we have functions for handling that. Additional WidgetMap objects are added to the WidgetManager for Widget data members as needed. When adding a new WidgetMap, I need to loop through the existing set of Widgets and add them to the new WidgetMap. This is the simplest example I can think of as to what I'm trying to do, however obviously this does not work... void WidgetManager::addMap(const WidgetMapPtr i){ maps_.push_back(i); // have to write a function adapter here? for_each(widgetset_.begin(),widgetset_.end(),i->insert); } Along a similar line, when a Widget's data member collection is changed, I need to remove any WidgetMap objects fromm the WidgetManager that referenced the member being deleted. void WidgetManager::dropWidgetMember(const DataMemberPtr d){ // delete any maps using the target member // how to fix this bloody line? getIndexedMember returns a DataMemberPtr to the member it is keyed on. maps_.erase(remove_if(maps_.begin(),maps_.end(),(boost::mem_fn(&WidgetMap::getIndexedMember)).equals(d))); // get rid of the member itself members_.erase(remove_if(members_.begin(),members_.end(),boost::bind(&DataMember::equals,_1,d))); // rewrite the data file, we're all dirty anyway. this->compact(); } I feel like I understand what I want to do, but I cannot find a reference that explains how to do it the 'correct' way. At least not that I can grasp. Can someone point me in the right direction? Thanks, Mark

3 4

Regex and Unicode
by Fr�d�ric Mayot 20 Sep '02

20 Sep '02

Hi, I'm trying to use Unicode with Regex in an MFC app. The preprocessor variable UNICODE is defined. But I obtain an error on the line : regex_search(sText, oResults, pRegExp); error C2665: none of the 4 overloads can convert parameter 1 from type 'class CString' sText is a CString which has a "const wchar_t*" operator. The problem is why doesn't the regex_search prototype require a "const wchar_t*" when UNICODE is defined ? Thanks. Fred (I read the documentation, but maybe I missed something...)

2 3

BJam output directories on NT
by yg-boost-users＠m.gmane.org 20 Sep '02

20 Sep '02

Building my application using msvc-stlport. I've set ALL_LOCATE_TARGET=d:/src/pegdevbin/build. During processing, the paths get too deep for NT and eventually the mkdir fails and then of course the build stops. Anyway to shorten the deep paths that are automatically created or should I start chopping up allyourbase.jam? I won't be doing any build variants on a per platform basis so I don't need the deep paths that specify the various options in effect. Thanks for the help (and all the great work too...) Rob

1 0

RE: [Boost-Users] Re: Borland C++ Builder 5.5 & scoped_ptr
by Mark Storer 19 Sep '02

19 Sep '02

>>Are you saying that if I switch from >> scoped_ptr to shared_ptr the destructor will get called? Is he saying that the destructor is NOT getting called with scoped_ptr? (!) --Mark Storer Software Engineer Cardiff Software #include <disclaimer> typedef std::disclaimer<Cardiff> Discard; -----Original Message----- From: Peter Dimov [mailto:pdimov@mmltd.net] Sent: Thursday, September 19, 2002 11:07 AM To: Boost-Users(a)yahoogroups.com Subject: Re: [Boost-Users] Re: Borland C++ Builder 5.5 & scoped_ptr From: "Brian" <bneal(a)zeus.ia.net> > --- In Boost-Users@y..., "Gennadiy E. Rozental" <rogeeff@m...> wrote: > > This was discussed during Boost.Test review. > > Peter some time ago made a changes in boost::shared_ptr that allows > > it to be used with Borland 5.5 namely in the situation you > described. > > > > Gennadiy. > > Hi...could you clarify this? All I noticed was that shared_ptr had > that compile time check for an incomplete type removed, whereas > scoped_ptr still has it. Are you saying that if I switch from > scoped_ptr to shared_ptr the destructor will get called? Yes, shared_ptr will call the destructor. It only requires a complete type at construction time. Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

2 1

RE: [Boost-Users] Re: [BGL] Best way to abort an algorithm from w ithi n a visitor?
by Mark Storer 19 Sep '02

19 Sep '02

>Using the Boost library as it currently stands, >it appears the best way to abort the algorithm >is to throw an exception. Granted. I'd even go so far as to say "the only way" (based on my vast experience... I've actaully vistor's code once). >Whether or not throwing an exception is >acceptable from a general programming standpoint >is a topic more suited to a general C++ >discussion list Any recommendations? Preffereably something with an archive/FAQ so we don't drag up Holy War #42... --Mark Storer Software Engineer Cardiff Software #include <disclaimer> typedef std::disclaimer<Cardiff> Discard;

1 0

RE: [Boost-Users] Re: [BGL] Best way to abort an algorithm from w ithi n a visitor?
by Jim.Hyslop 19 Sep '02

19 Sep '02

Mark Storer [mailto:mstorer@cardiff.com] wrote: > If Boost's source were a closed book, and the only option was > to throw an > exception, then so be it. But that is not the case. On that note, I'm going to bring this thread back to discussion of how to use the current Boost library. Using the Boost library as it currently stands, it appears the best way to abort the algorithm is to throw an exception. Whether or not throwing an exception is acceptable from a general programming standpoint is a topic more suited to a general C++ discussion list (if anyone decides to take it there, let me know - I'd like to follow it). Whether or not to add a return value to the BGL is a topic more suited to the main Boost mailing list. -- Jim

1 0

RE: [Boost-Users] Re: [BGL] Best way to abort an algorithm from w ithi n a visitor?
by Mark Storer 19 Sep '02

19 Sep '02

In general, I agree that taking personal issue with the use of some language feature is a little silly. In specific, I'm going to disagree with you both for exceptions and the whole do{}while(0) thang. I'm sitting next to my copy of Stroustrup's "The C++ Programming language" (2nd edition). Chapter 9 covers exceptions. This chapter makes it clear that the purpose of exceptions is to handle errors: " The fundamental idea is that a function that finds a problem that it cannot cope with /throws/ an exception, hoping that its (direct or indirect) caller can handle the problem. " Same thing with the do{}while(0) construct. Using a loop as an error handler is quite similar. One could argue that a break is far more efficient than a throw. A counter-argument is that the throw carries a great deal more information about what went wrong. Once the excreta impacts the air-pusher-thingy, speed becomes a secondary concern (far more often than not). If you want to abort a function due to an error then throw an exception. If you want to return a value then do so. And while using a language feature for something other than its original intent is not criminal, there are usually 'proper' ways to do things already built into the language, ways that often work better than subjecting some poor unsuspecting feature to your vile, unnatural manipulations. <Dudly Do-Right>You fiend!</Dudly Do-Right> In the case that brought all this up (returning a value from a graph's visitor to avoid iterating through the whole graph) the proper way to handle it is to alter the algorithm to allow for early termination. If Boost's source were a closed book, and the only option was to throw an exception, then so be it. But that is not the case. So do it right... as Chris Russell (the original poster) has decided to do. --Mark Storer Software Engineer Cardiff Software #include <disclaimer> typedef std::disclaimer<Cardiff> Discard; -----Original Message----- From: Peter Dimov [mailto:pdimov@mmltd.net] Sent: Thursday, September 19, 2002 9:20 AM To: Boost-Users(a)yahoogroups.com Subject: Re: [Boost-Users] Re: [BGL] Best way to abort an algorithm from withi n a visitor? From: "Mark Storer" <mstorer(a)cardiff.com> > Using exceptions in this way just bugs me. Religious reasons I guess. As > the Esteemed Mr. Hylsop ;) mentioned earlier, exceptions are for "oops". > This seems alot like the whole "do{}while(0)" with various 'break' > statements sprinkled in to avoid multiple returns/nested ifs. Useful, but > Just Not Right. A common misconception. Many people try to project their own ideas/expectations on language features, rather than simply using them as tools where appropriate. There is nothing "oops"-y about exceptions. They are a control flow mechanism; one that has interesting properties, but a control flow mechanism nonetheless. If it works and leads to a better code, it's foolish to avoid it without a technical reason. A similar example is when people don't use "struct" for C++ classes because it "doesn't feel right", or when trying to choose between "typename" and "class" for template parameters. The language features simply do not carry this kind of religious/emotional payload. It's all in your mind. Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

2 1