September 2004 - Boost - lists.boost.org

[thread] test_read_write_mutex* failures
by Stefan Slapeta 27 Sep '04

27 Sep '04

Hi all, there are some failures at runtime for this testcase which look like this: [...] timed test, sp=0 ../../../libs/thread/test/test_read_write_mutex.cpp(293): error in "test_read_write_mutex": test w1.m_value == 10 failed ../../../libs/thread/test/test_read_write_mutex.cpp(294): error in "test_read_write_mutex": test r1.m_value == -1 failed ../../../libs/thread/test/test_read_write_mutex.cpp(295): error in "test_read_write_mutex": test r2.m_value == 10 failed I didn't investigate too much so far, but something is very strange with this: (1) If I compile this test with bjam using the Intel toolset, it fails (exactly like in the regression results). (2) If I compile this test with bjam using the vc 7.1 toolset, it passes (exactly like in the regression results). Now here comes the interesting part: (3) If I compile this test in the VS IDE using Intel Compiler, it fails, but has a slightly different output from bjam. (4) If I compile this test in the VS IDE using VC, it fails, too (!!), with the same output as above. I've already checked the compiler and linker options that are passed by bjam, there is nothing suspicious. I'll continue my investigations tomorrow, in between any ideas about where these differences could come from are _very_ appreciated! Stefan

3 3

[shared_ptr] Interlocked* - possible bug?
by John Torjo 27 Sep '04

27 Sep '04

Hi Peter, I think there is a bug in your Interlocked* implementation of shared_ptr (http://www.pdimov.com/cpp/shared_count_x86_exp2.hpp) In atomic_read you have: inline long atomic_read(long volatile const & value) { return value; } I don't believe this is thread-safe. In order to make sure you're receiving the latest value, I assume you could do something like: inline long atomic_read(long volatile & value) { const int IMPOSSIBLE_VALUE = -100; return InterlockedCompareExchange(&value, IMPOSSIBLE_VALUE, IMPOSSIBLE_VALUE); } Am I missing something? Best, John -- John Torjo -- john(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)

4 13

RE: [boost] Python/GCC 3.4.1/Linux failures
by Stefan Seefeld 27 Sep '04

27 Sep '04

> From: Jonathan Brandmeyer [mailto:jbrandmeyer@earthlink.net] > Sent: September 27, 2004 15:55 > > > Just an observation, g++ 3.4.2 (Debian 3.4.2-2) passes > all of the tests. > > > > The tests fail for gcc 3.4.2 here. > > > > Which Python version do you use? > > 2.3.4 (Debian package 2.3.4-12) unfortunately debian has the bad habit to assign its own version numbers, so it could well be that what it refers to as 'gcc 3.4.2' is actually only a prerelease or something. I'v always found this very confusing... FWIW, Stefan

1 0

Unit Test Framework documentation/usage...
by Boost Rookie 27 Sep '04

27 Sep '04

Hello, I've just started to play around with Boost and I thought that I could use the Unit Test Framework, hence I opened up the documentation page at: http://www.boost.org/libs/test/doc/components/unit_test_framework/index.html I found the section I was looking for: Usage. In that part I expected to find information what files are needed to be included and what libraries I have to link against - but not so. What do I have to do to *use* the Unit Test Framework? Thanks in advance!

3 4

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

27 Sep '04

John Torjo <john.lists(a)torjo.com> wrote: > Alexander Terekhov wrote: > > > John Torjo wrote: > > [...] > > > >>Whenever a thread (other than main) wants to access this window, it > >>will query the weak_pointer. The weak_pointer needs to know the > >>LATEST reference count in order to know if the weak pointer is still > >>valid. Thus, atomic_read that simply returns the value is not > >>enough. However, the weak_ptr doesn't just use atomic_read. If atomic_read returns 0 that means the use count has dropped to 0 [*] and can never increase again, so it must be the latest version. Otherwise weak_ptr makes a second test that is properly protected. So it can never use an old value. [*] I think this is right but I'm not certain that it can't return a 0 that the processor read during creation of an object that uses enable_shared_from_this. Having said all that, I feel the naming of functions may give a false sense of generality and encapsulation when they actually only work in the way they are being used currently. <snip> > Here's my scenario: > (remember - we're talking about: > http://www.pdimov.com/cpp/shared_count_x86_exp2.hpp) This is still unaccessible. why don't you mail the code to Alexander and me (or to the list, in case anyone else is interested)? > class test { ... }; > > [thread1] > shared_ptr<test> p1( new test); // refcount = 1 > > ---------------- thread switch Switches between threads running on a single processor can't cause problems here, because the use of "volatile" ensures that the compiler won't reoder access to the use count and the processor will only reorder memory access in a way that is invisible to the code it's running. There might conceivably be problems that occur when multiple threads run concurrently on multiple processors, in which case reordering by one processor can affect another. So I'll ignore the "thread switches". > [thread2] > shared_ptr<test> p2(p1); // refcount = 2 > weak_ptr<test> weak(p2); > p2 = shared_ptr<test>(); // refcount = 1 > > ------------------thread switch > [thread1] > p1 = shared_ptr<test>(); // refcount = 0 - object gets destroyed > ---------------- thread switch > [thread2] > > // here - you need InterlockedCompareExchange > // to realize that refcount is 0 (zero) > shared_ptr<test> p3 = weak.lock(); expired() may read the count as still being 1 and so return false, but I believe the wnd_shared_ptr constructor will catch the fact that the pointer really has expired. Unfortunately I can't yet see the code to confirm this! > Also, see my other post to Peter Dimov. Seen it. Ben.

4 4

[boostbook] doxygen docs for enums
by Angus Leeming 27 Sep '04

27 Sep '04

Next question ;-) I find that boostbook can handle doxygen docs for classes and for functions but it ignores enums totally. That's both enums nested in classes and global enums. Any chance of getting it to add glob_flags.html to the list below? Regards, Angus Writing globbing.user_guide.html for section(globbing.user_guide) Writing bad_glob.html for refentry(bad_glob) Writing glob_iterator.html for refentry(glob_iterator) Writing glob_predicate.html for refentry(glob_predicate) Writing glob_traits.html for refentry(glob_traits) Writing glob.html for refentry(glob) Writing globbing.reference.html for section(globbing.reference) Writing globbing.history_and_acknowledgements.html for section(globbing.history_and_acknowledgements) Writing index.html for chapter(globbing) Writing HTML.manifest namespace boost { /** @brief The boost::glob function accepts a @c glob_flags * argument made up of a bitwise OR of zero or more of the * following symbolic constants. */ enum glob_flags { /** The vanilla, POSIX glob behaviour. */ glob_basic = 0, /** Do not sort the returned pathnames. */ glob_nosort = (1 << 0), /** If no pattern matches, return the original pattern. */ glob_nocheck = (1 << 1), /** Characters (including meta chars) cannot be quoted by backslashes. */ glob_noescape = (1 << 2), /** csh-style brace expressions {foo,bar} are expanded. * The glob will match either alternative. */ glob_brace = (1 << 3), /** Only directories are matched. */ glob_onlydir = (1 << 4) }; } // namespace boost

2 3

Re: immutable string
by Igor Kholodov 27 Sep '04

27 Sep '04

>reverse_iterator and reverse_const_iterator actually >refer the same type: > > typedef char_type const* iterator; > typedef char_type const* const_iterator; > typedef std::reverse_iterator<iterator> >reverse_iterator; > typedef std::reverse_iterator<const_iterator> >reverse_const_iterator; Agree, but which name should we used - "reverse_const_iterator" or "const_reverse_iterator"? I thought it was the latter. Igor Kholodov cttl(a)users.sourceforge.net http://cttl.sourceforge.net/

2 1

Re:[boost] Re:[serialization] scoped_ptr.hpp broken
by Robert Ramey 27 Sep '04

27 Sep '04

Vladimir wrote: >I think the docs are a bit unclear: Well, I guess that's no surprise as the whole question is still not totally clear to me. >What's the meaning of 'dependent' type? Do you mean 'dependent in context >of 'serialize'? Then, if I write: > template<class Archive> > inline void serialize( > Archive & ar, > my_class & t, > const unsigned long int file_version) {} >then the type to be serialized is never dependent type. Or do you refer to >a case where 'serialize' is templated on saved type? I'd suggest that you >write that explicitly, as "dependent type" is a bit vague. >From Vandervoorde and Josuttis book "C++ Templates - A Complete Guide" page 119 I quote: "A name is a dependent name if it depends in some way on a template parameter. For example, std::vector<T>::iterator is a dependent name if T is a template parameter but it is a nondependent name if T is a known typedef (for example, of int)." That is the definition I'm using for "dependant type" >> Before this change, there is a problem with compilers which implement >> two-phase lookup. Overrides for templates have to be defined before their >> usage in another template. >It would be great if you could put the explanation to the docs. I'll try to expand on this a little. >BTW, I start >to wonder if two-phase lookup does any good, for all additional portability >problems that it has. I've "wondered" about that as well. I brought this up before and the rationale was explained to me but I was left unsatisfied. I have to say this is the kind of thing that raises doubts in my mind about the applicability of C++ for programming jobs assigned to people who can't justify the rigorous parsing of the standard and extremely subtle compiler variations. That is - the rest of us. >> This conflicted with the implementation of >> BOOST_CLASS_EXPORT. To support these compilers, I had to either put >> non-intrusive serialization functions in the same namespace as the type >> being serialized or re-organize export. The latter is non-trivial and >> couldn't be guaranteed to be ready in time for release (at least at the >> time the issue came up). >Is the issue really with BOOST_CLASS_EXPORT? It seems that on compilers >with two-phase lookup, if 'save' overloads are in boost::serialization, >they must be seen before any code which uses 'save'. And this requirement >is not specific to BOOST_CLASS_EXPORT. And also, btw, the table says >boost::serialization is suitable for 'save' overload if compiler supports >ADL, two-phase lookup and type is dependent. Why is it so? Damn - now I have to figure it out all over again. I honestly don't remember. I believe I concluded that the problem could be addressed by requiring all the serialization headers be specified before all the archive headers, but that THAT conflicted with the implementation of export which required the opposite. It turned out invoking serialization without namespace qualification delayed lookup until instantiation and that resolved the solution. My current thinking is that I should re-implement export so that all serializations can be required to be before inclusion of all archive headers. Then serializations could be in any of the following namespace (on conforming compilers: Boost::serialization The namespace of T The namespace of Archive And that section of the manual could be eliminated. Robert Ramey

1 0

FORMAL review of "Output Formatters" - votes needed
by John Torjo 27 Sep '04

27 Sep '04

Dear boosters, There's been quite a hot debate about "Output Formatters" library. Reece has provided some input facilies in this library as well. This has drawn people to either sides: some don't want these input facilities, while others do. To conclude, I would like to ask you to vote: - "Yes" - in favor of Input facilities - "No" - don't want Input facilities. My personal vote is "No". Please share your own. Best, John Review Manager -- John Torjo -- john(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)

8 12

cvs wedged?
by Neal D. Becker 27 Sep '04

27 Sep '04

Been saying this for a while now: cvs update: [15:53:19] waiting for david_abrahams's lock in /cvsroot/boost/boost/libs/numeric/ublas/test4

2 1