October 2004 - Boost - lists.boost.org

boost-lite
by Andy Little 02 Oct '04

02 Oct '04

Hows about a boost-lite distro? What to include? Specifically only stuff that is a candidate for standardisation. If there is anything that is 'indispensible' but not a candidate, then one should ask why. Ideally Headers only, nothing that requires separate compilation, or bjam. And under (say ) 1MB absolute max. (exclude Docs. These can be pointed via url) Just a thought .... regards Andy Little

2 1

[hash containers in files section]
by Thorsten Ottosen 02 Oct '04

02 Oct '04

Hi Jeremy, I've been working a little with your hash containers. They should definitely be fast-track reviewed! A small problem: std::distance( m.begin(), m.end() ) != m.size() after I have filled the container (more than 100k elements). Could it be due to some caching thing? best regards Thorsten

3 2

Some questions on Boost Threads
by Parameswaran, Vinod 02 Oct '04

02 Oct '04

Hello list, My name is P. Vinod and I am currently debugging an application that was initially written using single thread but later ported to multithreads. The threading has been done using Boost library functions. I am new to Boost library and would like to clarify some of my doubts with you. Please reply to vparameswaran(a)fcg.com I have been studying William Kempf's documentation on Boost threads (http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/threads .html) and all my questions are based on the references therein: 1. <begin quote> The template thread_specific_ptr <http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/class.b oost.thread_specific_ptr.html> is useful in the following cases: * An interface was originally written assuming a single thread of control and it is being ported to a multithreaded environment. <end quote> Is there any other way by which you could port a single threaded interface to multithreaded interface using Boost threads? My debugging approach will be based on your answer to this question. 2. Does anyone have some examples of scenarios wherein each of these classes could be used (would even appreciate reference to relevant docs., if any): a. barrier b. condition c. thread_group d. thread_specific_ptr 3. Assumption: In the case of a condition object, ONLY THE FOLLOWING METHODS could be used to specify the wait condition: a. template<typename ScopedLock, typename Pred> void wait(ScopedLock& lock, Pred pred); b. template<typename ScopedLock> bool timed_wait(ScopedLock& lock, const bool::xtime& xt); c. template<typename ScopedLock, typename Pred>bool timed_wait(ScopedLock lock, Pred pred); Is this correct? 4. <begin quote> A thread object has an associated state which is either "joinable" or "non-joinable". <end quote> Is this state indicated using a type or is merely implied by whether the default or the parameterized constructor is called for the creation of the thread object? 5. Could anyone give examples of the use of void join() and void yield()? (Would even appreciate reference to relevant docs., if any) 6. <begin quote> Template thread_specific_ptr stores a pointer to an object obtained via new on a thread-by-thread basis and calls delete on the contained pointer when the thread terminates. Each thread initially stores the null pointer in each thread_specific_ptr instance. <end quote> Does each thread create its own 'object' referred to here and modify its thread_specific_ptr class by invoking void reset(T* p=0) ? 7. <begin quote> The template thread_specific_ptr is useful in the following cases: * Each thread of control invokes sequences of methods that share data that must be logically accessed through a globally visible access point, but are physically unique for each thread, instead of being explicitly passed. <end quote> <begin quote> Template thread_specific_ptr stores a pointer to an object obtained via new on a thread-by-thread basis and calls delete on the contained pointer when the thread terminates. Each thread initially stores the null pointer in each thread_specific_ptr instance. <end quote> >From the above statements, I could draw the inference that the thread_specific_ptr object stores the data that is shared amongst the various methods invoked from within a thread; however this data is not shared amongst threads and is unique for each thread. <begin quote> thread_specific_ptr construct/copy/destruct 1. thread_specific_ptr(); Requires: The expression delete get() is well formed. Effects: A thread-specific data key is allocated and visible to all threads in the process. Upon creation, the value NULL will be associated with the new key in all active threads. <end quote> <begin quote> 1. ~thread_specific_ptr(); ..... For this reason you should not destroy a thread_specific_ptr <http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/thread_ specific_ptr.html> object until you are certain there are no threads running that have made use of its thread specific storage. <end quote> The above statements seem to contradict the previous quotes, in that a thread-specific data key is visible to all the threads in the process and thread-specific storage is shared amongst multiple threads. Could anyone dispel the apparent ambiguity here? Also, what is the concept of "data key"? Gratefully appreciate your time and advice on the above. Vinod

2 1

Re:[boost] [Serialization] Remaining failures markup
by Robert Ramey 01 Oct '04

01 Oct '04

Aleksey Gurtovoy wrote: >Robert, >Pending msvc-stlport issue aside, I commented this accordingly. >the serialization library reports show >quite a few failures with other toolsets, in particular: > cw-9.3 > borland-5.6.4 > cw-8.3 > msvc > vc7 >I'm sure you've well aware of these; what I'd like to ask you is to >comment on them in the "explicit-failures-markup.xml" in the similar >way you commented on "*_warchive" tests, so that a) the library users >are not scared away by all these yellow cells, and b) the release >manager and everybody else besides the author have a simple way of >telling whether the library is in the OK state or not. I've been looking at this for a while procrastinated doing anything until I was sure what to do. So far this has been an effective strategy. Many times failures just disappeared as arcane tooI set issues were resolved. I still have some doubts about how to handle the remaining cases. Metrowerks compilers (cw*) seem to suffer from over-zealous optimization that eliminates static variables not referred to explicitly by name. Other compilers do this as well, but I've managed to workaround this in various ways. Cw* is the last hold out on this issue. I had hoped someone who is interested in this can test it might be motivated to look into it but it seems that there isn't enough interest. Unless I hear otherwise, I'll mark these tests as "expected". I would love to see this fixed - but for this Metrowerks would have an almost perfect showing. I do think its very high quality product that handles platforms that others don't. Its pains me that the serialization library test don't reflect this. A number of these (msvc, vc7, borland) have been determined to be manifestations of compiler deficiencies so I will mark them so. Some the borland test don't fail on my own test setup - so for me they are indeed "unexpected failures" - I think leaving this yellow is the correct characterization. That leaves a number of miscellaneous failures which really aren't understood or explained. Personally I would like to leave these as they are as to mey they really are "unexpected failures". I realize that some might be dissuaded from using the library because of this - but I think that's better than having someone use the library and not have it meet expectations. Robert Ramey

3 2

ulas / cw 8.3
by Stefan Slapeta 01 Oct '04

01 Oct '04

Is there a particular reason why ublas is marked unusable for cw 8.3? Stefan

1 0

[review] Formal review of the Smart Container library - 5 days left reminder
by Pavol Droba 01 Oct '04

01 Oct '04

Hi All, This the the reminder, that there are only 5 days left for the Smart Containers review. Please post your reviews if you find this library interesting. Best Regards, Pavol Droba Following is the copy of the invitation message: The review of the Smart Container library, written by Thorsten Ottosen starts today (September 26th, 2004) and runs for 10 days (until October 5th, 2004). The latest version of the library can be found at http://boost-sandbox.sourceforge.net/smart_container.zip or http://groups.yahoo.com/group/boost/files/pointer%20container/smart_contain… The package contains all you need to sucessfuly use the library with the Boost version 1.31 or later, however library tests require the latest Boost.Test, that is available from the main Boost CVS. What does the library provide? The library documentation states: >>>>>>>>>>>>>>>> Whenever a programmer wants to have a container of pointers to heap-allocated objects, there is usually only one exception-safe way: to make a container of smart pointers like boost::shared_ptr. This approach is suboptimal if 1. the stored objects are not shared, but owned exclusively, or 2. the overhead implied by smart pointers is inappropriate This library therefore provides standard-like containers that are for storing heap-allocated or cloned objects (or in case of a map, the mapped object must be a heap-allocated or cloned object). For each of the standard containers there is a smart container equivalent that takes ownership of the objects in an exception safe manner. In this respect the library is intended to solve the so-called polymorphic class problem. The advantages of smart containers are 1. Exception-safe and fool proof pointer storage and manipulation. 2. Notational convenience compared to the use of containers of pointers. 3. Can be used for types that are neither Assignable nor Copy Constructible. 4. No memory-overhead as containers of smart pointers can have (see 11 and 12). 5. Usually faster than using containers of smart pointers (see 11 and 12). 6. The interface is slightly changed towards the domain of pointers instead of relying on the normal value-based interface. For example, now it is possible for pop_back() to return the removed element. The disadvantages are 1. Less flexible than containers of smart pointers <<<<<<<<<<<<<<< As an example of how the new containers look like, consider that <code> typedef boost::shared_ptr<Foo> foo_ptr; std::vector<foo_ptr> vec; vec.push_back( foo_ptr( new Foo ) ); (*vec.begin())->bar(); </code> now becomes <code> boost::ptr_vector<Foo> vec; vec.push_back( new Foo ); vec.begin()->bar(); </code> In your reviews, please include the answers for the following questions: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Also, in the documentation you will find questions from the submitter to the reviewer; whenever you feel you have something to contribute on these issues, please don't hessitate to include that in your review. Thank you, Pavol Droba, review manager for the Smart Containers library.

1 0

RE: [boost] Re: Re: Long toolset names
by Stefan Seefeld 01 Oct '04

01 Oct '04

> From: Tony Juricic [mailto:tonygeek@yahoo.com] > Sent: October 1, 2004 12:03 > Even MS IDE has problems in some cases (very inconsistent) when space > characters are present but I thought that in most Wintel and also UNIX > command tools these issues are easily solved with adding quotes? well, that sounds simpler as it is. It's all those little details such as one shell eating quotes, another passing them through when called in a nested way that makes it really hairy. It's a can of worms that can easily be avoided by not using spaces in file names. Regards, Stefan

1 0

White spaces in regression
by Victor A. Wagner Jr. 01 Oct '04

01 Oct '04

As part of my script before I run any of the regression code, I delete all the *.xml files from the results directory. This is done because if there is a _severe_ crash while running the regressions, the *.xml files will still exist when things are "collected". I've been told that it is the responsibility of process_jam_log to create these, BUT: C:\Projects\boost\tools\regression\build>C:\Projects\boost\tools\build\jam_src\bin.ntx86\bjam.exe -sTOOLS=vc7.1 ...found 481 targets... Traceback (most recent call last): File "regression.py", line 712, in ? commands[ command ]( **accept_args( args ) ) File "regression.py", line 356, in setup build_if_needed( process_jam_log, pjl_toolset, toolsets ) File "regression.py", line 288, in build_if_needed raise 'Failed to find "%s" after build.' % tool[ 'build_path' ] Failed to find "C:\Projects\boost\bin\boost\tools\regression\build\process_jam_log.exe\vc7.1\release\process_jam_log.exe" after build. the reason it cannot find it there is because somehow it got built here instead: C:\Projects\boost\bin\boost\tools\regression\build\process_jam_log.exe\vc7.1\release\threading-multi\process_jam_log.exe I don't know if actually finding the correct version will solve the white space problem, but this clearly isn't correct. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

[Signals] New regressions
by Aleksey Gurtovoy 01 Oct '04

01 Oct '04

Doug, It seems that your last checkin broke things on a number of platforms -- see http://tinyurl.com/69npt. -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

Compilation problem with boost on SunCC (Forte 6.2 & 8)
by Puverle, Tomas (IT) 01 Oct '04

01 Oct '04

Please find attached a small program and a the resulting compilation errors on SunCC. This occurs in iterator_facade.hpp, operator != (), calling to interator_core_access::equal. I have tracked this down to the following problem: f(mpl::true_); f(mpl::false_); f(is_convertible<>()); //will not work is_convertible<> derives from mpl::bool<>, however it seems that a bug in the compiler prevents it from converting to mpl::true_/mpl::false_ in the above scenario (and in the program attached) A workaround for this is to change it to the following: f(mpl::true_); f(mpl::false_); f(mpl::bool_<is_convertible<>::value>()); Presumably this will be present in other places but this is the only one our developers have hit so far. Thanks, Tom -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

1 0