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

Borland 5 and indirect_iterator
by Stephen Love 19 May '03

19 May '03

Hi all, Using Borland C++Builder5 (which has bcc32 5.5.1) I've attempted the tests for indirect_iterator which compile fine. However, the following fails: list< shared_ptr< int > > ctr; void foo( int x ) { } for_each( make_indirect_iterator( ctr.begin() ), make_indirect_iterator( ctr.end() ), foo ); with the first error being: [C++ Error] iterator.h(125): E2404 Dependent type qualifier 'shared_ptr<int>' has no member type named 'difference_type' which then causes a failure to instantiate the iterator_traits. I'm no template guru, so I can make the full error list available if required. Anyone know what's going on? Thanks Steve -- Steve Love: steve.love(a)essennell.co.uk ACCU - accu.org Promoting Professionalism in Programming

3 3

MPL pop_back problem
by Tarjei Knapstad 19 May '03

19 May '03

I get some weird error messages which I don't really understand when I tried using mpl::pop_back today. The following example (more or less an exact copy of the one in the documentation): ------------------ start code ----------------- #include <boost/mpl/list.hpp> #include <boost/mpl/pop_back.hpp> using namespace boost::mpl; void f() { typedef list<int, double>::type ListType; typedef pop_back<ListType>::type PoppedList; } ------------------ end code ---------------------- fails on gcc 3.2 (Boost 1.30) with: pop_back.cpp: In instantiation of `boost::mpl::pop_back<f()::ListType>': pop_back.cpp:9: instantiated from here pop_back.cpp:9: base class ` boost::mpl::pop_back_traits<boost::mpl::aux::list_tag>::algorithm<f()::ListType> ' has incomplete type pop_back.cpp: In function `void f()': pop_back.cpp:9: ISO C++ forbids declaration of `type' with no type pop_back.cpp:9: typedef name may not be class-qualified pop_back.cpp:9: parse error before `;' token I'd appreciate if someone could clear this up for me. Regards, -- Tarjei

2 4

[thread] confusion about recursive_try_mutex
by Christopher Currie 19 May '03

19 May '03

I've been looking at the implementation of recursive_try_mutex, and something struck me as odd in the pthreads implementation: bool recursive_try_mutex::do_trylock() { # if defined(BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE) int res = 0; res = pthread_mutex_trylock(&m_mutex); assert(res == 0); if (res == 0) { if (++m_count > 1) { res = pthread_mutex_unlock(&m_mutex); assert(res == 0); } return true; } return false; # else // ... } It appears that if BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE is defined, in debug mode this function will never return false, because the assert will fire first instead. Am I reading this incorrectly, or is there something happening somewhere else that I'm missing? Thanks in advance, Christopher Currie [Non-text portions of this message have been removed]

1 0

initial function of boost::thread
by Mark Sizer 19 May '03

19 May '03

This is also stuff that has been answered before. I really have searched. Links to the answers will be as appreciate as an inline responses. I've been using free file-scoped functions up to now because I really don't understand what a boost::function0<void>& is. I get, I think, that it can't be a member function, because there is no 'this' attached. However, I'm having trouble with two things: #1 from: function.tutorial.html <quote> boost::function2<float, int, int> f; struct int_div { float operator()(int x, int y) const { return ((float)x)/y; }; }; f = int_div(); </quote> operator() _is_ a member function. When assigning int_div() to f, which of potentially zillions of instances of int_div is being referenced? Is a new one created on invocation? (the example uses std::cout << f(5,2) << endl;) I'm missing a theoretical bit of information that makes this hang together. Help, please. #2 from: http://www.cuj.com/articles/2002/0205/0205a/0205a.htm?topic=articles <quote> However, because Boost.Threads uses a function object instead of just a function pointer, it is possible for the function object to carry data needed by the thread. This approach is actually more flexible and is type safe. When combined with functional libraries, such as Boost.Bind, this design actually allows you to easily pass any amount of data to the newly created thread. </quote> BUT HOW?!?! Any pointers (with many examples, please) would be much appreciated. Thanks, - Mark

2 2

BGL sample code error -- edge_property.cpp
by Chuck Messenger 19 May '03

19 May '03

edge_proprety.cpp, as included in Boost release 1.30.0, generates warnings under gcc 3.2.2, since it is missing a couple of typenames. Here's the needed patch: 95c95 < property_map<Graph, edge_mycapacity_t>::const_type --- > typename property_map<Graph, edge_mycapacity_t>::const_type 97c97 < property_map<Graph, edge_myflow_t>::const_type --- > typename property_map<Graph, edge_myflow_t>::const_type - Chuck Messenger

2 1

Using time_duration::rep_type::ticks_per_second
by d_zakaib 18 May '03

18 May '03

I have written a function to convert a posix_time::ptime to a windows FILETIME (which is in essence a 64-bit value counting 100-nanosecond intervals since Jan 01, 1601). In order to do so, I do a time difference between the ptime and a time setup to the FILETIME reference time. To convert from this time_duration to the FILETIME count, I use time_duration::rep_type::ticks_per_second. Since this does not seem to be documented I just wanted to make sure I was using it correctly (or if I should be using it at all). Here is my code (which seems to work): const ULONGLONG nanosecPerFileTimeUnit = 100; using namespace boost::posix_time; using namespace boost::gregorian; FILETIME toFileTime ( const ptime& time ) { ptime refTime(date(1601,Jan,01)); time_duration sinceRefDate = time - refTime; ULARGE_INTEGER durationInFileTimeUnits; const ULONGLONG timeDurTicksPerSec = time_duration::rep_type::ticks_per_second; const ULONGLONG fileTimeUnitsPerTimeDurTick = (nanosecPerSec/timeDurTicksPerSec) / nanosecPerFileTimeUnit; durationInFileTimeUnits.QuadPart = sinceRefDate.ticks()*fileTimeUnitsPerTimeDurTick ; FILETIME ft; ft.dwLowDateTime = durationInFileTimeUnits.LowPart; ft.dwHighDateTime = durationInFileTimeUnits.HighPart; return ft; }

2 1

regex build problem
by Benedikt Weber 18 May '03

18 May '03

Hi everybody I tried to build boost out of the box. Everthing worked fine except the following: ------------------------------------- D:\boost\boost_1_30_0>bjam "-sTOOLS=cwpro8" ... FileClone libs\regex\build\bin-stage\boost_regex_debug.lib The system cannot find the file specified. ... FileClone libs\regex\build\bin-stage\boost_regex.lib The system cannot find the file specified. -------------------------------------- The actual file names generated in libs\regex\build\bin-stage are: libboost_regex_debug.lib and libboost_regex.lib, i.e. they have an extra "lib" prepended. Interestingly enough the analogous dll files are: boost_regex_debug.dll and boost_regex.dll as expected. Any ideas? Benedikt

2 1

more ublas test problems
by Benedikt Weber 18 May '03

18 May '03

When compling the bench* tests for ublas using the jamfiles, both cwpro8 and borland do not seem to know about the function rand(). I think that <stdlib.h> should be included somewhere. MSVC seems to do this implicitely. Furthermore, only debug versions are generated for all tests (test* and bench*). Benedikt

3 7

strange behaviour at setup on windows2000
by Anthony Lichnewsky 17 May '03

17 May '03

I had the following trouble setting up boost 1.29.0 on windows 2000 (using vc7, but that's not the point) the first thing bjam did (the version downloaded from sourceforge) was to erase all the files and folders in tools\ so that no build could be performed... setting those files to read-only was enough but that's an unexpected behaviour. Anthony Lichnewsky

2 3

Signals lib - causes mysterious multiple destructor calls
by Chuck Messenger 16 May '03

16 May '03

Testing out the Boost signals lib, I wrote: ----------- #include <boost/signal.hpp> #include <iostream> using namespace std; using namespace boost; struct X { void operator()(int val) { cout << "X <- " << val << endl; } X() { cout << "X constructor\n"; } ~X() { cout << "X destructor\n"; } }; int main() { { cout << " phase 1\n"; signal<void (int)> sig; cout << " phase 2\n"; X x; cout << " phase 3\n"; sig.connect(x); cout << " phase 4\n"; } cout << " phase 5\n"; return 0; } ------------------- The following output is generated (gcc3.2.2 on Mandrake 9.1): ------------------------ phase 1 phase 2 X constructor phase 3 X destructor X destructor X destructor X destructor X destructor X destructor X destructor X destructor phase 4 X destructor X destructor phase 5 ------------------------ Why the multiple calls to X's destructor? I'd have expected just one. It looks like the signals lib is misbehaving. Can anyone offer an explanation? - Chuck

3 2