- Boost - lists.preview.boost.org

BGL: BCBuilderX compiler error
by Kaled Ahmed 04 Oct '04

04 Oct '04

The following snippet from the BGL User Guide and Reference Manual, gives an error using Borland CBX: template <typename Graph, typename TransDelayMap, typename VertexNameMap> void print_trans_delay( typename graph_traits<Graph>::edge_descriptor e, const Graph& g,TransDelayMAp delay_map, VertexNameMap name_map) { std::cout << "trans_delay(" << get(name_map, source(e,g)) << "," << get(name_map, target(e,g)) << ")= " << get(delay_map, e); } The error is: "untitled.cpp": E2449 Size of 'print_trans_delay' is unknown or zero at line 27 Please advise. --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage!

2 1

New multi_index failures (--> mpl??)
by Stefan Slapeta 04 Oct '04

04 Oct '04

http://tinyurl.com/4nrt9 Aleksey, could this be a side effect of the last mpl fix for boost.test? Stefan

3 2

Some questions on boost threads
by Parameswaran, Vinod 04 Oct '04

04 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

1 0

White cells in regression tables?
by David Abrahams 04 Oct '04

04 Oct '04

I posted this yesterday, but got no reply. Can anyone explain the vast number of white cells in the Boost.Python regression log? In particular, the tests noted below don't look like they're reported correctly in the log. ------ Due to what appears to be an MPL problem, neither libs/python/test/polymorphism.cpp nor libs/python/test/polymorphism2.cpp are compiling on vc6. This fact is reflected only strangely by the posted regression log, as white cells. ------ -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

4 7

*Attention*: ISO 9660/names with multiple dots
by Aleksey Gurtovoy 04 Oct '04

04 Oct '04

Gentelmen, Apparently, ISO 9660, including Levels 2 and 3, does not allow names containing more than one dot character (see, for instance, http://www.gnscd.com/iso.htm) The requirement has always been present in our file/directory naming guidelines -- http://www.boost.org/more/lib_guide.htm#Directory_structure, but was never checked/inforced. As the result, currently we have quite a number of files (249!) that will have to be renamed before we can put them on an ISO 9660 CD -- see http://www.meta-comm.com/engineering/boost/names_with_dots.html. Note that this doesn't include BoostBook-generated documentation (since it is not in the current CVS), which uses multiple dots convention for the generated HTMLs all over the place. It's not going to be terribly hard to fix all these issues, but I wanted to bring this to everyone's attention to make sure that there is a consensus that this is a right thing to do, and that the benefits are worth the trouble. -- Aleksey Gurtovoy MetaCommunications Engineering

3 2

[Poll] New look-n-feel for Boost documentation
by Eric Niebler 03 Oct '04

03 Oct '04

Joel de Guzman and I, with the help of many smart folks on the boost-docs list[*], have been working on improving the look-n-feel of Boost's documentation. We're ready to commit the new style, but wanted to check here first. Volodya was good enough to put up a copy of Boost's docs with the new style applied. You can preview them here: http://zigzag.lvk.cs.msu.su/~ghost/boost_docs/ Please say whether you like the new style or not. If not, be specific about why. If you are the author of Boost documentation, please have a look at your docs in the new style and see if anything is out of place. [*] Thanks to Doug Gregor, Vladimir Prus, Dave Abrahams, Reece Dunn, Jeff Garland, Rene Rivera and others for their valuable feedback regarding the new style. -- Eric Niebler Boost Consulting www.boost-consulting.com

22 52

Order of entries in the Bibliography section?
by Joaquín Mª López Muñoz 03 Oct '04

03 Oct '04

I've noticed entries do not follow any definite order. Print publications are more or less sorted by year, but other sections are seemingly listed at random. I propose the following: * Inside each section, sort lexicographically by year and author, for instance online mentions would get like this [Burnap02] [Curran02] [Siek02b] [Casad03] [Lischner03] [Stein04] * Add this policy in the "How to update this page" section. If people are happy with this, I volunteer to do the changes. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 9

Re: [boost] [Poll] New look-n-feel for Boost documentation
by brangdon＠cix.compulink.co.uk 03 Oct '04

03 Oct '04

In-Reply-To: <e094f9eb040930020665f195c5(a)mail.gmail.com> rogiervd(a)gmail.com (Rogier van Dalen) wrote (abridged): > I'd suggest either not overriding the browser's font settings > for paragraph text, or using a serif font. I feel the same. I find the text a bit too big. It's a bit like reading a children's large-print book. I'd also prefer it not to override my colour settings. My default background is not white. Overall I think it looks better. I had a quick look from my mobile phone, and it worked reasonable well. (You might want to try that yourself, if you haven't already.) -- Dave Harris, Nottingham, UK

2 1

RE: [boost] Re: [shared_ptr] Interlocked* - possible bug?
by Ben Hutchings 03 Oct '04

03 Oct '04

Peter Dimov <pdimov(a)mmltd.net> wrote: > Alexander Terekhov wrote: > > Peter Dimov wrote: <snip> > >> The observable behavior is > >> > >> write volatile @a 1 > > > > nop > > > >> read volatile @a x > > > > nop > > > >> write volatile @a x-1 > > > > nop > > > >> exit(x-1) > > > > push 0 > > call _exit > > > >> > >> in the first case, and > > > > Happy now (debugger notwithstanding)? > > No. A conforming compiler is not allowed to do that. > > > C'mon, volatile is brain-dead. > > Nobody's arguing otherwise. ;-) But a nop it isn't. I think Alexander is arguing that without a clear definition of what it means for a memory access to be "observable", the fact that volatile memory accesses are "observable behaviour" doesn't prevent them from being optimised away under the as-if rule. I expect most implementations treat "observable" as "observable by a software or hardware debugger", but of course the standard doesn't and can't say that.

3 4

[type_traits] alignment_of_test problem in Intel Linux
by Joaquín Mª López Muñoz 03 Oct '04

03 Oct '04

The problem (see for instance http://tinyurl.com/4j87e) seems to be a trivial confusion with the digraph <: I guess all it takes to fix this is to rewrite line 35 in alignment_of_test.cpp #define ALIGNOF(x) align_calc<x>::get() as #define ALIGNOF(x) align_calc< x>::get() (note the extra blank). OK to commit? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 5