July 2004 - Boost - lists.preview.boost.org

Boost.Test problem
by Joel de Guzman 16 Jul '04

16 Jul '04

Hi, I'm having some minor problems with Boost.Test. Using g++3.2, MinGW, I get: In file included from ../../../boost/test/included/unit_test_framework.hpp:20, from ../../../libs/spirit/test/actor/unit_test.cpp:9: ../../../libs/test/src/test_tools.cpp: In function `bool boost::test_tools::tt_detail::equal_and_continue_impl(const wchar_t*, const wchar_t*, boost::wrap_stringstream&, boost::unit_test::basic_cstring<const char>, unsigned int, boost::unit_test::log_level)': ../../../libs/test/src/test_tools.cpp:188: `wcscmp' undeclared in namespace ` std' unit_test.cpp is just: #include <boost/test/included/unit_test_framework.hpp> Any hints? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

6 24

Re:Re: [boost] Re: Serialization Menu
by Robert Ramey 16 Jul '04

16 Jul '04

Robert Ramey wrote: >Mattias Flodin wrote: >>> (ii) Requiring all documentation to support a no-script option. >>In think (ii) is an absolute requirement. I find myself using >>text-based browsers from time to time, especially when working across >>an SSH connection, and I get quite annoyed by some documentation sites >>that navigation exclusively though Javascript. I would hate for boost >>to go the same way. >>In addition to some text browsers not supporting Javascript at all, >>the CERT has on numerous occasions advised that Javascript be disabled >>in browsers such as IE for security reasons, and some companies make >>that a policy decision. > Actually I agree with this. I will change the serialization navigation > pane so that it works on browsers that don't support scripting. This > would leave the navigation pane but it would always be maximally expanded > for browsers that don't support it. I think that would fulfill the > requirement of making the documentation universally useable and still > permit us to use the facility we like most of the time. I've just modified contents.html slightly so that the expand/collapse functionality is only enabled all of the following are true: a) scripting is supported by the browser b) scripting is not turned off c) the browser is either IE or Netscape Under all other conditions, the navigator pane is displayed fully expanded with no graphic +/-/o buttons. The links to the actual doc pages work the same in all cases. I have tested this with Netscape with scripting enabled and disabled. I've tested with IE only with scripting enabled as I was unable to discover where to turn javascript off (or perhaps I did find it but it didn't work). If anyone wants to tweak this to enable this functionality for their favorite browser - be my guest. I would hope that almost everyone could find this solution satisfactory. Robert Ramey

2 1

Re:Re: [boost] Re: Serialization Menu
by Robert Ramey 16 Jul '04

16 Jul '04

Vladimir Prus wrote: >Jonathan Turkanis wrote: >> I think Robert's menu is very effective, and was hoping it represented >> a de facto relaxation of the no-script policy. >>I have some reservation >>1. It does not work very nice when image loading is turned off (as it is for me). >>2. It takes qutie a lot of screen space. Hmm - on IE and Navigator I can slide the frame all the way to the right and make the navigation window disappear. This also raise the question about browsers that don't support frames. It would be my understanding that usage of frames would also make documentation un-displayable on some browsers. >I think it's probably better to somehow make all new libraries use >Boost.Book. >If that's done, any presentation issues can be solved in one place. For >example, I think there were already discussion about expandable TOC on the >boost-doc failings list. I would like to see one package done in boost book before we impose such a requirement. When I go to the NightlyCVS link in the main boost page it shows what looks like boost book generated main page (whose aesthetics I'm not crazy about). When I click on one of the items it's a dead link. This gives me the impression that boost.book is still in development and that there are still too many pending issues to impose such a requirement. > At all events, I'd prefer constistent look of all Boost library docs (and > the ability to print them), to every author introducing something they > like. I think the boost documentation information www.boost.org is pretty good and helps promote this idea. I think it should used as a starting point. Robert Ramey

2 1

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 16 Jul '04

16 Jul '04

Mike, > > And I feel that the interface (representing convenience, > > flexibility, usability, etc.) is the first thing that a library will be > > judged by. > > Perhaps, but the next thing it will be judged by is efficiency and > speed. Ultimately, many C++ programmers won't use even the cleanest and > most elegant designs if they result in code that isn't fast enough or > efficient enough--especially in something like a multi-threading library. > > Peter Dimov's argument, if I understand correctly, is that the "cleaner" > design could be made as fast/efficient as the current one, not that we > should choose a cleaner design at the expense of speed or efficiency. [Batov, Vladimir] I never advocated forgetting efficiency. Only that the first thing needs to be addressed/settled on first. Then, we move on to the second within the constraints of the first choice. > > I feel that for the user having different types of mutexes is > > inconvenient and unnecessary restricting. > > Inconvenient I can see, but how is having more choices restricting? [Batov, Vladimir] It is restricting because I presume that different types of mutexes will have different functionality. Therefore, the plain mutex will not have something I need for try_lock. If that assumption of mine is not correct and, say, try_mutex is complimentary -- an efficient implementation of the generic mutex (with efficiency vs. functionality trade-offs), then I am fine with it. > > Having additional (and maybe unused) data in a mutex does not seem like > > a huge problem > > Not for you, perhaps, but I can guarantee that there are others who > don't feel that way. [Batov, Vladimir] True. I am fine if we address the mainstream use first (that is, a generic mutex represents an access serialization to the relevant data with the *kind* of serialization (timed, try, etc.) refined by locks). Then, mutex refinements will be just that -- refinements for a particular purpose. Like generic mem. allocation mechanism (kinda OK for everyone) vs. optimized (extremely good for some). > > (as long as it does not impose performance penalties) --s > > memory is cheap and mutexes are not usually created in huge numbers. > > Memory isn't cheap for everybody: there are still some (many?) who are > forced to work in more constrained environments. For instance, > programmer's of handheld devices often deal with insufficient memory > problems. [Batov, Vladimir] True. That falls into the same specialization category. I simply do not want that specialization at the expense of the mainstream users/applications.

1 0

Re:[boost] Regression Tests, Boost.Serialization
by Robert Ramey 15 Jul '04

15 Jul '04

Martin Wille wrote: > Houston, we have a problem. I am sorry about this. A couple of weeks ago I did raise the issue about testing resources regarding Boost Serialization. I was mainly concerned more about execution time. After a short back and forth I was left with the impression that no one thought testing this would be a problem. I'm open to suggestions. Again I apologize for not giving a more specific warning on this - I guess having a 100MB on my home system just skewed my perspective. Robert Ramey

1 0

RE: [boost] Re: Lock unification [was: Boost.Threads: Do we need all those mutexes?]
by Batov, Vladimir 15 Jul '04

15 Jul '04

> Christopher Currie wrote: > > I can infer that the apparent justification for unification would be to > > allow a single lock to be used in different ways, but I have a hard time > > imagining a use case where this would be as clear and as error-resistant > > as separate scopes with separate locks. If anyone has one, or any other > > rationale, please respond. > > The main motivation behind the idea of unifying the lock types (and > mutex types) is simplification of concepts, I believe. > > Mike [Batov, Vladimir] I would not call it 'simplification' as it can send a wrong message but rather 'streamlining'. It's because conceptually (and in implementation) try_lock = timed_lock(time=0) scoped_lock = timed_lock(time=infinite) Although I have to agree that from user perspective those locks are distinct and it makes sense to me to provide thin timed_lock, try_lock, blocking_lock interfaces for the majority of mainstream uses.

1 0

RE: [boost] Re: Lock unification
by Batov, Vladimir 15 Jul '04

15 Jul '04

I like the suggestion of constructing an appropriate lock via the appropriate constructor rather than a function (after all, that's what constructors are for :-) ). Although I'd probably try being more explicit typedef scoped_lock Lock; Lock l(m); // block Lock l(m, Lock::try); // try Lock l(m, Lock::time(33)); // timed Lock l(m, Lock::deferred); // deferred BTW, I love 'deferred'. IMHO it is very good and descriptive name for a parameter. Much better than we had before (was it block/non-block?). > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > Sent: Friday, 16 July 2004 7:24 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Lock unification > > "Eric Niebler" <eric(a)boost-consulting.com> writes: > > > David Abrahams wrote: > >> "Eric Niebler" <eric(a)boost-consulting.com> writes: > >> > >>>I continue to believe that a better interface for a unified lock > >>>involves descriptively named helper functions: > >>> > >>>scoped_lock l1( m ); // lock unconditionally > >>>scoped_lock l1 = defer_lock( m ); // don't lock > >>>scoped_lock l2 = try_lock( m ); // try lock > >>>scoped_lock l3 = timed_lock( m, t ); // timed lock > >>> > >>> It's just as clear as you could hope for, > >> I'm not convinced it is. It potentially puts information about the > >> kind of locking being done very far from the actual call that does > >> locking. > > > > > > True, but the other design under consideration doesn't help with > > that. It requires two-step construction for some constructs which > > could result in code like: > > > > scoped_lock l( m, false ); > > maybe_takes_the_lock_i_dont_know( l ); > > I don't know what you're referring to. I don't see any two-step > construction going on there. Links or examples, please? > > >>>and it's extensible. I feel that the single lock c'tor with a bool > >>>arg is less readable and rather inflexible. > >> Inflexible how? > >> > > > > User's can't add more constructors if they want a different locking > > strategy, but they can add as many helper function as they like. For > > instance, they could define a function that tried to take a timed_lock > > and logs failures. Or throws an exception. Or they could write a > > lock_if helper that takes a predicate. And they can do all that with > > simple one-step construction syntax. It's more concise and it permits > > the lock declaration to appear in the condition of if statements. > > Sorry, I missed the "single lock ctor" part. I think I agree with > you there. > > BTW, it just occurred to me that > > timed_lock(m, 0) > > could potentially generate different code from > > timed_lock(m, some_int) > > If we can detect literal zero... which I think is possible. > > What about: > > scoped_lock l(m); // block > scoped_lock l(m, 0); // try > scoped_lock l(m, 33); // timed > > scoped_lock l(m, deferred); // deferred > scoped_lock l(deferred(m)); // alternate > > ?? > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: Boost.Threads: Do we need all those mutexes?
by Iggy Veresov 15 Jul '04

15 Jul '04

While reading a discussion concerning different types of mutexes and guards in Boost, I thought it would be pertinent to highlight another possible approach to implement a multithreading library. In libMAGE (http://libmage.sourceforge.net/) we have a universal lock (unilock) abstraction, that provides a common way for construction of different lock managers (exclusive, read/write and even more complicated ones) with replaceable scheduling strategies. Furthermore, they can be easily adapted to mutex interface and used, for example, in methods of condition objects. /Igor Veresov

1 0

explicit-failures-markup.xml validating
by Bart Garst 15 Jul '04

15 Jul '04

I noticed a URL in boost/status/explicit-failures-markup.xml that can be used for validating. I made a couple changes to that file and ran it through the validator. My changes validate ok but there were other errors with the algorithm/string entries. Will these errors cause all entries in this file to not make it into the regression output? Thx, Bart

3 2

Re:Re: [boost] Re: Serialization Menu
by Robert Ramey 15 Jul '04

15 Jul '04

Mattias Flodin wrote: >> (ii) Requiring all documentation to support a no-script option. >In think (ii) is an absolute requirement. I find myself using >text-based browsers from time to time, especially when working across >an SSH connection, and I get quite annoyed by some documentation sites >that navigation exclusively though Javascript. I would hate for boost >to go the same way. >In addition to some text browsers not supporting Javascript at all, >the CERT has on numerous occasions advised that Javascript be disabled >in browsers such as IE for security reasons, and some companies make >that a policy decision. Actually I agree with this. I will change the serialization navigation pain so that it works on browsers that don't support scripting. This would leave the navigation pane but it would always be maximally expanded for browsers that don't support it. I think that would fulfill the requirement of making the documentation universally useable and still permit us to use the facility we like most of the time. A real problem with this collapsible tree navigation is that I generated it by hand. OK for a one time deal but not a great long term idea. As I understand it - the boost.book idea is the long term solution. I don't know if it now has the capability to generate such a navigation pane from the source documentation - but it should. Also if the formatting were all in the cascaded style sheet it would go a long way to avoiding disputes about things like aesthetics. It would be practical as well. For example one using a text based browser might use a different CSS. Feel free to take this with a grain of salt because I've barely looked at it. Robert Ramey

1 0