- Boost - lists.boost.org

Re: [boost] [interprocess] non-ASCII characters in headers
by Daniel James 08 May '08

08 May '08

On 07/05/2008, Marshall Clow <marshall(a)idio.com> wrote: > > My opinion is that all of those changes are fine - > except for the one where you changed "Dietmar Kühl"'s name. I assumed it would be okay because it's spelt that way in other places: http://www.boost.org/users/people/dietmar_kuehl.html http://svn.boost.org/trac/boost/browser/trunk/boost/filesystem/operations.h… I think that the other ways to get this to work would be: to use UTF-8 in the source file, get Doxygen to output UTF-8, or get it to markup the encoding in its output. Daniel

2 1

[thread] Documentaion and implementation incoherences
by vicente.botet 08 May '08

08 May '08

Hi, Only some comments and questions. * mutex native_handle_type and native_handle() are missing in the doc Should these be defined for timed_mutex, recursive_mutex, ...? * The documentation do not includes a rationale. Could you adapt the rationale from Howard E. Hinnant Mutex, Lock, Condition Variable Rationale http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html#Introduc…, or at least add reference to this document in the rationale? Best ____________________ Vicente Juan Botet Escriba

2 2

[thread] thread_group differences between pthread and windows
by vicente.botet 08 May '08

08 May '08

Hi, Is there any hiden raison explaining the declarations and implementation of thread_group are different for pthread and windons? If not why not to put it in a separate file? Best _____________________ Vicente Juan Botet Escriba

2 1

[constrained_value] ignore_policy, overhead?
by Neal Becker 07 May '08

07 May '08

I'm wondering if I can selectively switch off bounds checking without overhead? I added: /** Error policy for constrained that ignores bounds. */ struct ignore { /// The policy invocation operator. /// If @a nv is below the range, assigns @c c.lower_bound() to @a ov. /// If @a nv is above the range, assigns @c c.upper_bound() to @a ov. /// Otherwise fires an assertion. /// @remarks @a V must be @c Assignable from @a L::result_type and @a U::result_type. template <typename V, class L, class U, class C> void operator () (V & ov, const V & nv, const within_bounds < L, value_generator::integral<bool, true>, U, value_generator::integral<bool, true>, C> & c) const { } }; I'm wondering if the this will eliminate all overhead allowing the speed of the underlying ValueType (e.g., int)?

2 1

Boost and subdirectories named 'debug'
by Edward Diener 07 May '08

07 May '08

Boost has some subdirectories named 'debug' which contain static files used by some Boost libraries and their dependencies. In some build systems, like MSVC, the 'debug' directory is a directory where intermediate build files, such as object files, are put, and these directories are dynamic in the sense that there contents can always be regenerated from source. A common, if perhaps erroneous, technique of forcing rebuilds in these systems is to wipe out the 'debug' directories. If Boost is in some tree where the 'debug' directories are all being wiped out indiscriminately, then the Boost 'debug' directories get wiped out and source using Boost libraries and/or their dependencies which have 'debug' directories will fail to compile. Yes, I know in the age of IDEs that no one is supposed to build like that anymore, or that it is a very good idea not to put Boost in some tree where the end user decides to arbitrarily wipe out all 'debug' directories in order to force a rebuild, but these things can happen. Because of that this is a gentle suggestion that Boost in the future choose some other name for a subdirectory than 'debug' for those libraries using that name.

1 0

[build] symbolic vs hard library links
by Frank Mori Hess 07 May '08

07 May '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After building boost from svn on linux, I've noticed it produces a mix of symbolic and hard links for the built libraries (output of "ls -l" attached). I'm curious if this was intentional? Have I just configured my source tree in some strange way? - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIIbi+5vihyNWuA4URApvHAJ90L2JBOjvFyPtT1KKRXFS6zsxeigCg0hNH 2FTth+XYWEqSzHFccXRCq/0= =7Uzr -----END PGP SIGNATURE-----

2 1

[test] --catch_system_errors questions
by Juergen Hunold 07 May '08

07 May '08

Hi ! I'm using Boost.Test for quite a while and now I wonder if the behaviour of "--catch_system_errors" is correct. I've attached a simple test case which just triggers a simple "assert(false);". Running the testcases with trunk bjam yields one failure and two passing tests. See "test.log" for details. Running the testcases against 1.341. yields three failures with _different_ exit codes. See test_1_34_1.log When looking at the output of trunk "with_catch.test", I see --snip--- with_catch: assert_test.cpp:13: void test_assert::test_method(): Assertion `false' failed. <TestLog><TestSuite name="Master Test Suite"><TestCase name="test_assert"><Message file="assert_test.cpp" line="11">one</Message><Info file="assert_test.cpp" line="12">check true passed</Info><TestingTime>0</TestingTime></TestCase></TestSuite></TestLog><TestResult><TestSuite name="Master Test Suite" result="passed" assertions_passed="1" assertions_failed="0" expected_failures="0" test_cases_passed="1" test_cases_failed="0" test_cases_skipped="0" test_cases_aborted="0"></TestSuite></TestResult> EXIT STATUS: 0 --snap-- So, some observations: Obviously, the UTF succeds in catching the "assert". The resulting message is not in the XML-Log The return code is 0 (Success). A quick look at the new docs prototype at http://www.patmedia.net/~rogeeff/html/utf/usage-recommendations/command-lin… found "If you got fatal exception somewhere within test case, make program generate coredump by adding extra command line argument " This was not easy to spot since the real test cases succeeded with error code 0 and the message was hidden in the log file. I found this because msvc on windows fires up an annoying debug window instead. So it seems this is not working there. So, my questions/suggestions are: Is this a bug ? Or a feature ? And if its a feature, where can I find the rationale ? I think the caught assertions should lead to a non-zero exit code and a failing test suite. And it would be nice if they got properly XML-formatted (but after a quick scan through the source, this seems difficult...) Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

4 10

[phoenix][spirit] Phoenix 2 already in trunk?
by Dean Michael Berris 07 May '08

07 May '08

I see that there's a new version of Spirit in Boost trunk. I'm just curious though, does this version already have the (much awaited) Phoenix 2 library? If not, is there a good packaging of Phoenix 2 already available? Pointers would be very much appreciated. -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://blog.cplusplus-soup.com] [mikhailberis(a)gmail.com] [+63 928 7291459] [+1 408 4049523]

2 2

[shifted_ptr][3.1] Works fine
by Phil Bouchard 07 May '08

07 May '08

Ok, I just uploaded a version that finally works fine. At this point I would doubt there is any bugs left in its functionality. Thanks, -Phil

2 7

[Random] Differing values from minstd_rand in v1.35.0
by Greg Landrum 07 May '08

07 May '08

Dear all, Sorry if this is an inappropriate forum, but neither a question I posted about this to boost.users almost a month ago (http://article.gmane.org/gmane.comp.lib.boost.user/34979) nor a bug report I submitted two weeks ago (http://svn.boost.org/trac/boost/ticket/1856) have evoked any response. The specific question/problem that I have is: After moving from boost 1.34.1 to 1.35.0 I have noticed that the sequence of values returned by the minstd_rand generator has changed. I'm curious to know if this was due to fixing a bug in the code, introducing a bug in the code, or me having incorrect expectations about boost::random (that results from the generators will remain constant across versions). Specific details, as well as code to reproduce what I've seen, are in the bug report. Please let me know if there is someone I should contact directly or a better forum for the question/problem. Thanks, -greg

1 0