- Boost - lists.preview.boost.org

regression results? (where's the beef??)
by Victor A. Wagner Jr. 28 Sep '04

28 Sep '04

Is it just me, or have the regression results not been picked up by metacomm in the past 24 hours? Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

3 2

Re: immutable string
by Igor Kholodov 28 Sep '04

28 Sep '04

>> Agree, but which name should we used - >> "reverse_const_iterator" >> or "const_reverse_iterator"? >> I thought it was the latter. > >Now I see :) Will fix it. Great, after the fix I will run the same tests with VC 7.1. It is amazing how many strings are const_string-compatible objects! Thanks, Igor Kholodov cttl(a)users.sourceforge.net http://cttl.sourceforge.net/

2 1

[boostbook] link to an enum
by Angus Leeming 27 Sep '04

27 Sep '04

I can define a link to a class with: <classname alt="boost::glob_predicate">glob_predicate</classname> How do I define a link to an enum? It seems that a shorthand notation is missing. Is there a longhand way? Regards, Angus

3 3

[boostbook] mangling of names of generated docs
by Angus Leeming 27 Sep '04

27 Sep '04

I find that if I have a header file "foo_bar.hpp" containing the declaration of a function "foo_bar" (there may be other functions in there too of course), then the generated html docs are: Writing foo_bar.html for refentry(foo_bar) Writing id2767798.html for section(id2767798) foo_bar.html contains the docs for the function whilst id2767798.html contains Header <foo_bar.hpp> namespace boost { namespace child { void foo_bar(std::string const &); } } I can see why this is done, but why not modify the mangling so that id2767798 becomes foo_bar_hpp and id2767798.html becomes foo_bar_hpp.html? Especially since each regeneration of the docs results in a different ID. Regards, Angus

1 0

Re:Re: [boost] Re: FORMAL review of "Output Formatters" - votes needed
by Robert Ramey 27 Sep '04

27 Sep '04

Reece wrote: >Roland Richter wrote: > John Torjo wrote: > >> The dilemma I see is that the outfmt library is somewhere between >> serialization (boost::serialization) and pretty-printing >> (boost::format). IMO, outfmt provides *both* at a basic level in that >> it simply adds streaming operators << and >> to STL containers, >> which, for some reason, are currently missing. What advantages does using the output formatters for output/input have over using the serialization library to do the same thing? Robert Ramey

1 0

[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