- Boost - lists.boost.org

BOOST_WORKAROUND in test files?
by Gennaro Prota 26 Jun '04

26 Jun '04

Hi, is it allowed/OK to use BOOST_WORKAROUND in the boost test files? Or should we simply use #if/#ifdef? For instance, Codewarrior 8.3 for Windows has some problems in parsing a function template in dyn_bitset_unit_tests4.cpp. A simple fix, suggested by Howard, is: #ifdef __MWERKS__ // will be: __MWERKS__ && __MWERKS__ <= xxx #pragma parse_func_templ off #endif Should this use BOOST_WORKAROUND? In general: What should compiler/library vendors see when they define BOOST_STRICT_CONFIG? Just errors in the boost headers or errors in the test files too? -- Genny.

2 1

intrusive_ptr: proposal for common base class
by Stefan Slapeta 26 Jun '04

26 Jun '04

Hi all, Sorry if this has been discussed yet, but I think there is an obvious pattern in the usage of intrusive_ptr which should be exposed as common functionality in boost. In most of the cases you just want to handle a simple reference count and delete the object which is held by the intrusive_ptr when the reference count is decreased to zero. It's very annoying that you currently have to write external add_ref/release functions for every class you want to use with this smart pointer. Additionaly, it makes the code unreadable. That's why I would like to suggest having a base class which provides the simplest functionality a user could expect from intrusive_ptr: handling the reference count and deleting the object. A class which should be maintained by intrusive_ptr can derive from it and would not have to provide any further interfaces. I'm not glad about the class name 'intrusive_ptr_base' but I don't have any good ideas at the moment :( Awaiting you comments! (code: see below) Stefan namespace boost { class intrusive_ptr_base; void intrusive_ptr_add_ref(intrusive_ptr_base*); void intrusive_ptr_release(intrusive_ptr_base*); class intrusive_ptr_base { friend void intrusive_ptr_add_ref(intrusive_ptr_base*); friend void intrusive_ptr_release(intrusive_ptr_base*); int ref_count__; protected: intrusive_ptr_base() : ref_count__(0) {} virtual ~intrusive_ptr_base() {} }; inline void intrusive_ptr_add_ref(intrusive_ptr_base* o) { ++o->ref_count__; } inline void intrusive_ptr_release(intrusive_ptr_base* o) { if (--o->ref_count__ == 0) { delete o; } } } // namespace

2 2

Hmmm.. how do I add a new test to the regressions?
by Fernando Cacciola 26 Jun '04

26 Jun '04

I forgot it.... I need to add the Numeric Conversions Library so I can start hunting compiler problems. Fernando Cacciola SciSoft

2 1

RE: Boost.Threads proposed change: lock constructors
by Batov, Vladimir 25 Jun '04

25 Jun '04

Mike, With all due respect I am not sure that the additional complexity you are proposing is justified. It appears that the differences in lock and try_lock default constructors' behavior are consistent with other libraries and actually feel intuitive and natural to me. After all, it is reflected in what I do -- with lock I try until I succeed (that is [Batov, Vladimir] the lock blocks until succeeds), with try_lock I try once and may fail (that is it unconditionally falls through for me to check the result). Best, V. Date: Thu, 24 Jun 2004 14:14:02 -0400 From: Michael Glassford <glassfordm(a)hotmail.com> Subject: [boost] Boost.Threads proposed change: lock constructors To: boost(a)lists.boost.org Message-ID: <cbf5as$hvv$1(a)sea.gmane.org> Content-Type: text/plain; charset=us-ascii; format=flowed Below I detail proposed changes to the Boost.Threads lock class constructors. Comments? Questions? Mike ----------------------------------------------------------------- The Boost.Threads lock concept constructors are currently defined as follows: Definitions ----------- L: lock type l: lock variable (type L) m: mutex variable (appropriate Mutex type) s: initial lock state (type bool, true=locked, false=unlocked) Lock Concept ------------ L l(m,s) //Blocking lock if s L l(m) //Blocking lock TryLock Concept --------------- L l(m,s) //Blocking lock if s L l(m) //Non-blocking lock TimedLock Concept ----------------- L l(m,s) //Blocking lock if s L l(m,t) //Blocking lock, failing if not obtained by time t These definitions have the following drawbacks: 1) That one of the TryLock constructors blocks while the other doesn't is neither obvious nor very consistent. 2) That the single-parameter constructor of Lock blocks while the single-parameter constructor of TryLock doesn't is neither obvious nor very consistent. 3) Part of the reason for the above inconsistencies is that it's not clear whether the constructors of TryLock should block or not. 4) The TimedLock constructors have no way to request a non-blocking lock. To address these problems, I would like to redefine the lock concept constructors as follows (changes indicated with "^"): Definitions ----------- L: lock type l: lock variable (type L) m: mutex variable (appropriate Mutex type) s: initial lock state (enum type {NO_LOCK=0, LOCK=1}) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ b: block? (enum type blocking_state {NON_BLOCKING=0, BLOCKING=1}) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Lock Concept ------------ L l(m,s) //Blocking lock if s L l(m) //Blocking lock TryLock Concept --------------- L l(m,s,b) //Lock if s; blocking if b ^ ^^^^^^^^^^^^^ L l(m,b) //Lock; blocking if b ^ ^^^^^^^^^^^^^ TimedLock Concept ----------------- L l(m,s,b) //Lock if s; blocking if b ^ ^^^^^^^^^^^^^ L l(m,t) //Blocking lock, failing if not obtained by time t Note: s and b are defined as enums rather than bools to prevent existing code from breaking silently: e.g., if s and b were bools, "TryLock l(m, false)", which currently means "construct a lock object but don't obtain a lock", would change with the new definitions to mean "construct a lock and make a non-blocking attempt to obtain a lock". Also, enums are more explicit than bools. Note: these changes will cause some existing code to break by producing compile errors; the compile errors can be fixed by appropriately adding or changing parameters being passed to the changed TryLock and TimedLock constructors. Mike

2 1

Regression logs oddity
by Gennaro Prota 25 Jun '04

25 Jun '04

Hi everybody, does anyone have hints as to why the Linux regression logs include the first 3 dynamic_bitset test files twice, in two different versions? Example: gcc-3.4.0- linux 3.4.0 ------------------------------------------------------------------- dyn_bitset_unit_tests1 Fail dyn_bitset_unit_tests1 Pass dyn_bitset_unit_tests2 Fail dyn_bitset_unit_tests2 Pass dyn_bitset_unit_tests3 Fail dyn_bitset_unit_tests3 Pass dyn_bitset_unit_tests4 Pass -- Genny.

2 1

dynamic_any campaign?
by fehrin＠t-online.de 25 Jun '04

25 Jun '04

On http://www.cuj.com/boost/ (Boost Corner) the first article is I/O System: dynamic_any campaign by Alexander Nasonov. Is dynamic_any really scheduled for inclusion in boost (1.32 say)? Greetings Franz

3 2

Re:[boost] 1.32 release preparation
by Robert Ramey 25 Jun '04

25 Jun '04

I would very much like to see the serialization library in the 1.32 Release. However, I'm not sure it will be possible to make the posted schedule. I have made all changes to address issues raised in the review. On my personal machine I have passed tests for the compilers VC 7.1 VC 6, gcc 3.3. Borland compiles (almost everything but requires some debug - it will pass most tests) Comeau- compiles everthing - accept for a show stopping problem I've been unable to resolve. My intention has been: a) post version compatible with 1.31 next week. b) build and test against the CVS tree on my computer c) check in In order to do this I need: a) authority to check in b) information on how to mark tests/compilers known to fail. c) I have a couple of questions that I need an expert opinion on. i) the first one is that in order to work, versions for vc 6.0 and borland need to be compiled with spirit 1.61. So the a special environmental variable indicating the directory path where this version of spirit is located on the testing machine. SPIRIT_ROOT. This variable has to be set when serialization libraries are built for these compilers. I should say I'm more than a little bit concerned about changes to mpl and iterators. I'm very much aware of the delays and difficulties associated with the 1.31 release - and it didn't even include this package. So I would like to continue on the path I've established above and we'll see where things stand July 16 when/if you are ready to branch for release. Good Luck ! Robert Ramey

4 4

Random number library
by Oliver Kullmann 25 Jun '04

25 Jun '04

Hi, one of my students tried some time in vain to use the random number generator from the boost library, but he couldn't understand the documentation. I must say, the documentation is not exactly "user-friendly". Here's the problem: Given integers min and max, we want to have a pseudo-random-number generator for random numbers from min, min + 1, ..., max (uniform distribution). The generator should take a seed, and then producing a sequence of pseudo-random numbers (and we should be able to find out about the period of the generator). I couldn't think of anything more basic for a library on random numbers, and so I would expect an example of how to get such a thing in the documentation. (I mean, a real example, complete with code, explanations, and how to use it.) But there's no such a thing, which I find rather strange. We have the concept of a "Uniform Random Number Generator", which looks exactly what we want, but, alas, it seems to be more of a fictitious concept, since no models seem to be provided?!?! So well, let's have a look at "Random Distribution". Only that it needs as input a "Uniform Random Number Generator", and the library does not seem to provide these things?!?! (We have the "Random Number Library Generators", but this library seems to provide only models for the most general concept, the concept of a "Number Generator", but not of a "Uniform Random Number Generator".) Let's ignore this for a moment, and continue our investigations into "Random Distribution". Here are actually some models, most useful for our purpose seems to be "Class template uniform_smallint" and "Class template uniform_int". Now, even if we would know where to get the argument urng from, still we wouldn't know which to choose: The documentation on these class templates is rather cryptic, and additionally asks us to be "wise". Shouldn't this be the job of the library?! Final rescue: "random_demo.cpp". The macros don't enhance readability. But there is an example "Define a uniform random number distribution of integer values between // 1 and 6 inclusive." where I find the text misleading (since we don't define a distribution, which is an assignment of probabilities to certain events, but we define a generator), but looking at the output of the program experiment: roll a die 10 times: 3 3 2 6 6 5 5 6 6 3 it seems to be what we want. So I could copy and past the relevant parts of the program (which is not completely trivial), and I would get close to my goals. If only I would understood the meaning of what I'm doing! Unfortunately, variate_generator.hpp seems to be of some importance, but is not documented. Sigh. --------------------------- My student didn't get to this point, although he is rather good. But there are too many unknowns in the "equation" to solve (starting with the concept of a concept, ...), so the job becomes overwhelming. Now it doesn't look too complicated for me to write a nice explanation for the above problem in a tutorial style, explaining on the way all the concepts and concepts of concepts in the library, and that's what I wanted to kindly request with my e-mail. (And also the rest of the documentation could need a sentence here and there, as mentioned in the above case study.) And, of course, for any example of the best way how to solve the above problem with the library, and explanations how it works, I would be glad! Oliver

4 9

boost::any debug assertion failed in destructor
by Olivier Tristan 25 Jun '04

25 Jun '04

Hi guys, I'm currently trying got use boost::any to create some container with different type and I'm having some trouble with a small exemple. I try this on VC2003, VC2002 and gcc 3.3 Here is my class class A { public: A(unsigned long size) : mSize(size), mBuffer(new boost::any[size]) {} ~A() { delete mBuffer; } private: unsigned long mSize; boost::any *mBuffer; }; int main(void) { A(256); return 0; } and I got an assertion in the destructor of A; Can someone tell me if I did something wrong or if there is some problem is boost::any Thanks, -- Olivier Tristan Ultimate Sound Bank

2 2

[program_options, function] vc7 problem
by Vladimir Prus 25 Jun '04

25 Jun '04

The regression logs show this error message from vc7 http://tinyurl.com/39fgc which says that pointer to function can be converted to boost::function The relevant code is: int stored_value; void notifier(const vector<int>& v) { stored_value = v.front(); } void test_semantic_values() { .... ("int", po::value< vector<int> >()->notifier(notifier)) ; } Where the 'notifier' member function is defines as: typed_value* notifier(function1<void, const T&> f) and in this case, T = vector<int>. Any ideas what I can do to make this work? - Volodya

3 3