March 2004 - Boost - lists.preview.boost.org

[Boost-bugs] [ boost-Bugs-918570 ] 1.31.0 doesn't support inter-win32-stlport use intel8.0
by SourceForge.net 18 Mar '04

18 Mar '04

Bugs item #918570, was opened at 2004-03-17 23:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=918570&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 1.31.0 doesn't support inter-win32-stlport use intel8.0 Initial Comment: can't get compile! maybe the bug of stlport! because stlport4.6.1 can't been compiled by intel c++8.0! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=918570&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

enumeration interface for boost::signals
by E. Gladyshev 18 Mar '04

18 Mar '04

Does boost::signals have a public enumeration interface (like iterator concept) that can be used for accessing individual slots? There is some mention of it in the "Slot Call Iterator" section but not much detailed. For instance, what I'd like is to call a slot and depending on the result call some other slot. A related question is if I have an instance of boost::signals::connection, is it possible to get an access to the slot that this connection is referencing? Thanks, Eugene

5 21

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