- Boost - lists.boost.org

Spirit file_iterator with windows/unicode
by Reece Dunn 18 Mar '04

18 Mar '04

When using <boost/spirit/iterator/file_iterator.hpp> with windows when UNICODE is defined, the following: file_iterator<> file( "foobar.txt" ); will fail to compile since the call to ::CreateFile in <boost/spirit/iterator/impl/file_iterator.ipp> line 182 maps to CreateFileW and not CreateFileA which is wanting a wide-character filename. The solution is thus: <boost/spirit/iterator/impl/file_iterator.ipp> line 182: - HANDLE hFile = ::CreateFile( + HANDLE hFile = ::CreateFileA( Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

2 1

Missing symbols from the Boost.Signals DLL's
by Nicola Musatti 17 Mar '04

17 Mar '04

Hallo, After building Boost 1.31 with the borland toolset I noticed that some symbols were missing from the Boost.Signals DLL's. More specifically all the symbols exported from libs/signals/src/signal_base.cpp are not exported. This appears to be caused by the explicit inclusion of boost/signals/detail/config.hpp in boost/signals/detail/signal_base.hpp. The effect of this inclusion is to miss the indirect inclusion of boost/config.hpp . After removing the #include <boost/signals/detail/config.hpp> line from signal_base.hpp the DLL's build correctly. Note that while I only tested with the borland toolset this problem is potentially present on all the win32 toolsets. Cheers, Nicola Musatti

2 1

RE: [boost] Is there any interest in this container?
by Peter Palotas 17 Mar '04

17 Mar '04

> >>> peter(a)smartbusiness.nu 03/16/04 03:49PM >>> wrote: > > I was wondering if there is any interest in a container that is a > > model of sequence (just like std::vector or std::list) and with an > > interface matching that of std::vector (maybe with minor > differences > > due to efficiency) but with different time complexities? > > On a related note, all the basic associative containers could > (and arguably should) have an "nth_element" method with > complexity O(log(n)). With this interface addition a > container with an interface like vector but complexity like > map could be adapted from map akin to the way queue is > adapted from deque. Are you suggesting a change in the implementation of the standard sorted associative containers? I'm not sure that would be a good idea, since maintaining information in them to find the nth element in O(log n) time would add an overhead to insert/delete operations which would be undesirable if you don't need that functionality, which in fact I think you normally don't. Just a thought. // Peter Palotas

1 0

Re: [boost] Is there any interest in this container?
by Jesse Booher 17 Mar '04

17 Mar '04

>>> peter(a)smartbusiness.nu 03/16/04 03:49PM >>> wrote: > I was wondering if there is any interest in a container that is a model of > sequence (just like std::vector or std::list) and with an interface matching > that of std::vector (maybe with minor differences due to efficiency) but with > different time complexities? On a related note, all the basic associative containers could (and arguably should) have an "nth_element" method with complexity O(log(n)). With this interface addition a container with an interface like vector but complexity like map could be adapted from map akin to the way queue is adapted from deque. Just a thought. Jesse Booher

1 0

Indexed set: reverse
by Darren Cook 17 Mar '04

17 Mar '04

I tried indexed_set with g++ 3.2.3 ("gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)") and it compiled all the examples. The reference docs need an "up" link (back to libs/indexed_set/doc/index.html). Your tutorial did not deal with using an index in reversed order; I think it is worth adding something showing using rbegin()/rend() (I modified basic.cpp to print ages oldest first and it worked first time :-). I found a reverse() function in sequenced.cpp: it seems you apply this to the indexed_set container, not to the index, but when I tried it on the container in basic.cpp I get a compile error. So I tried the sequenced example using rbegin/rend and it worked: tc.reverse(); std::copy(tc.begin(),tc.end(), std::ostream_iterator<std::string>(std::cout," ")); tc.reverse(); /* undo */ std::copy(tc.rbegin(),tc.rend(), std::ostream_iterator<std::string>(std::cout," ")); Can you explain the thinking behind reverse()? Is it any more/less efficient than using rbegin/rend? If not, I think it should either be dropped or extended to regular indices as well. Darren Joaquín Mª López Muñoz wrote: > For those interested in indexed_set, release 9 is available at: > > http://groups.yahoo.com/group/boost/files/indexed_set.zip > > the sandbox version is not in sync, it'll be by tomorrow.

2 3

autolink should not require MSC language extensions
by Paul A Bristow 16 Mar '04

16 Mar '04

Recently I puzzled why autolink did not work for some programs. After some stumbling about, I realised that this was because _MSC_EXTENSIONS is a required definition (as well as MSVC). I can't see why this should be - autolink works perfectly well regardless of the compiler setting chosen. (But I can see why most people will not see this - because MS require the language extensions). But I suggest that in autolink.hpp #if (defined(BOOST_MSVC) && defined(_MSC_EXTENSIONS)) can helpfully be replaced by #if (defined(BOOST_MSVC)) for those whose preferences are for strictness'. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

2 2

missing pthread_mutexattr_destroy in boost thread (V 1.31.0)
by Adrian 16 Mar '04

16 Mar '04

Dear William I think you have missed pthread_mutexattr_destroy() in recursive_mutex::recursive_mutex() and recursive_mutex::recursive_try_mutex(). Proposed patch: #elif defined(BOOST_HAS_PTHREADS) recursive_mutex::recursive_mutex() : m_count(0) # if !defined(BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE) , m_valid_id(false) # endif { pthread_mutexattr_t attr = 0; int res = 0; res = pthread_mutexattr_init(&attr); assert(res == 0); # if defined(BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE) res = pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE); assert(res == 0); # endif res = pthread_mutex_init(&m_mutex, &attr); pthread_mutexattr_destroy(&attr); /* missing */ if (res != 0) throw thread_resource_error(); ../.. recursive_try_mutex::recursive_try_mutex() : m_count(0) # if !defined(BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE) , m_valid_id(false) # endif { pthread_mutexattr_t attr = 0; int res = 0; res = pthread_mutexattr_init(&attr); assert(res == 0); # if defined(BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE) res = pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE); assert(res == 0); # endif res = pthread_mutex_init(&m_mutex, &attr); pthread_mutexattr_destroy(&attr); if (res != 0) throw thread_resource_error(); ___________________________________________________ Yahoo! Messenger - Nueva versión GRATIS Super Webcam, voz, caritas animadas, y más... http://messenger.yahoo.es

2 1

RE: [boost] Explicit instantiation of boost::shared_ptr<SomeClasss>
by Greg Clayton 16 Mar '04

16 Mar '04

> -----Original Message----- > From: Peter Dimov [mailto:pdimov@mmltd.net] > Sent: Friday, March 12, 2004 12:24 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Explicit instantiation of > boost::shared_ptr<SomeClasss> > > > Greg Clayton wrote: > >> -----Original Message----- > >> From: Peter Dimov [mailto:pdimov@mmltd.net] > >> Sent: Thursday, March 11, 2004 4:48 PM > >> To: boost(a)lists.boost.org > >> Subject: Re: [boost] Explicit instantiation of > >> boost::shared_ptr<SomeClasss> > >> > >> > >> Greg Clayton wrote: > >>> I am trying to do explicitly instantiate specific shared_ptr class > >>> for export from a Win32 DLL (currently with MSVC6, and > eventually in > >>> VS2003). > >> > >> First things first. Why do you need to do that? Have you > >> tried not exporting it, have you encountered any problems? > > > > Yes, shared pointers can't be created and handed off from DLL to DLL > > the way they are currently implemented. If DLL A has an STL > container > > of shared pointers, and DLL B gets _dynamically_ loaded and adds an > > item to DLL A's container (creates a shared pointer to an > object, and > > DLL B adds that shared pointer through an interface it to > DLL A's STL > > container of shared pointers), DLL B can not be unloaded. If DLL B > > does get unloaded you will crash when your STL container goes out of > > scope (when it tries to delete the owned pointer). > > Isn't it possible for the DLL C that contains the definition > of SomeClass to > export > > shared_ptr<SomeClass> createSomeClass(); > > which DLL B can now call when it needs a SomeClass? > > Since ~SomeClass lives in C, it must be available when the last > shared_ptr<SomeClass> is destroyed. > This was my initial solution, and it does work. Though I was searching for the ability to just create a shared pointer anywhere and had it to any other DLL by exporting the entire shared pointer instantiation from the main DLL.

2 1

regex_iterator and sub_match
by Darren Cook 16 Mar '04

16 Mar '04

Hi, I finally upgrade to boost 1.31; as I got compile errors around the regex_grep stuff I decided to switch to regex_iterator. 1. It would be helpful if the top page of the docs had direct links to explanations of smatch and similar classes. 2. An example of how to use sub_match would be useful. The C++ parser example for regex_iterator is not ideal because: a) the regex is rather complex; b) the callback just uses str(), and never shows the type to use if you want to iterate through each character in the match. 3. I get this error (see P.S. for my code) `iterator' is not a member of type `boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >' but this page says sub_match has an iterator type. libs/regex/doc/sub_match.html It compiles when I explicitly use std::string::const_iterator. Darren P.S. Cut down, my code looks like: bool parse(const boost::smatch::value_type &crd,const std::string &status){ //... boost::smatch::value_type::iterator p=crd.first; // <-- won't compile //std::string::const_iterator p=crd.first; // <-- compiles while(p<crd.second){ ... } //... } //In class Functor: bool operator()(const boost::match_results<std::string::const_iterator>& m){ //... bool ok=parse(m[1],m.str(2)); //... } std::string comment; //The string to parse boost::regex status_re("..."); Functor callback(...); boost::sregex_iterator m1(comment.begin(), comment.end(), status_re); boost::sregex_iterator m2; if(m1==m2)return 0; std::for_each(m1, m2, callback);

2 1

better nondeduced context workaround?
by Larry Evans 16 Mar '04

16 Mar '04

The following file: http://groups.yahoo.com/group/boost/files/cycle_basis_mgr.hpp forms part of an adaptation of policy_ptr to collect cycles in the pointer graph. Part of the difficulty was writing specializations for a curried class, e.g. template<typename ProxVisitor> class curry_prox_visitor_refcycle_counted { public: template <typename ReferentPtr> class owner ; }; due to the restrictions on "nested contexts" (see comments under namespace rm_nondeduced ). rm_nondeduced is part of a workaround, but I was wondering if there was a better way. I'm afraid I've missed some simpler way. Any help or advice appreciated.

1 1