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

Re:Re: [boost] Re: 1.32 release preparation
by Robert Ramey 06 Jul '04

06 Jul '04

Johannes Brunen wrote: >> And if there are a large >> number of new things left out by that approach then we should plan >> another release sooner rather than waiting 4 months. >However, then you need new volunteers which have to spend the time for the >whole procedure again. The release procedure is too onerous. This isn't the problem, it's a symptom of a more subtle problem. If the source of this difficulty can be found can corrected, then releases can occur more frequently. My personal view is that it's a symptom of a development process that couples otherwise independent/orthogonal efforts. This is due to the fact that we're all working against a development tree that has experimental code in it. So minor issues ripple across all efforts. >I could think of a review process which accepts a library only after the >list of requested changes has been made. > I would prefere a review process which leads to final > acceptance only after a library is 'CVS' compatible i.e. does not yield to > any (known) regressions of the existing pool libraries and is equipted > with a working testing facility. The review process qualifies submissions for inclusion into boost. I don't think there are any libraries that have been accepted then suffered changes which made them unacceptable. It's not fair to ask a submitter to require that that he totally "finish" the package before submission when it cannot be guaranteed that it will be accepted. The review process isn't the problem, its working quite well. It's just that there is more effort than first meets the eye between the time a library is deemed acceptable and the time it is ready for inclusion into boost. The serialization library including code, headers, tests, html, jamfiles, *.bat, and shell scripts is has passed 25,0000 lines. This takes time and no changes in the review or release procedure can change that. There is the review package which seems to work pretty well. But I would be reluctant to check it in as it doesn't match the review acceptance conditions and I'm concerned about trying to maintain a package which I have now moved beyond. Robert Ramey

3 3

Re: [ublas-dev] Re: [boost] Re: Boost Mathematicians
by Jeremy Graham Siek 06 Jul '04

06 Jul '04

On Jul 5, 2004, at 11:54 AM, Peter Schmitteckert wrote: > Salut, > > (note that I only use the dense matrices of ublas) > > On Mon, 5 Jul 2004, Toon Knapen wrote: > > > > This is just a matter of documentation. AFAIK there is no accepted > > concept that demands 'num_rows' and 'num_columns'. The '1' and '2' > refer > > to the first and second index which is also a nice convention IMO. > > I prefer size1 and size2, since it fits to the sheme of having a > tensor > structure with a size3. Mixing up abstractions is not a good idea. Matrices and tensors are different creatures. True, sometimes it is useful to think of a tensor as a matrix, and having adaptors or views that allow for this is a good thing. The names we use for operations should match the common terminology from the problem domain. In this case, the common terminology is rows and columns. When we create concepts for tensors, we can use size1, etc. > Columns and Rows can lead to confusion concernig storage layout. I disagree. > > > > > > > > * iterator1 and iterator2 should be named column_iterator and > > > row_iterator or something memnonic. > > same as above. > > same as above. > > > > > > > > > * prod should be named operator*; this is a linear algebra library > > > after all. > > Mmmh, this open pitfalls concerning A*B*C in performance issues for > non experts. No, the right way to handle this is to have the expression template machinery identify that a temporary is needed, and create one automatically. Cheers, Jeremy _______________________________________________ Jeremy Siek <jsiek(a)osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Candidate, Indiana University Bloomington C++ Booster (http://www.boost.org) _______________________________________________

7 12

unresolved externtal symbol with .Net 2003
by Brian Carlson 06 Jul '04

06 Jul '04

I have a project that worked fine with .Net 2002 (7.0.9466). But when I open it up on .Net 2003 (7.1.3088) it compiles, but when it links I get the following warning: CDlgcEventProcessor.obj : error LNK2019: unresolved external symbol "public: __thiscall boost::thread::thread(class boost::function0<void,struct boost::empty_function_policy,struct boost::empty_function_mixin,class std::allocator<class boost::function_base> > const &)" (??0thread@boost@@QAE@ABV?$function0@XUempty_function_policy@boost@@Uemp ty_function_mixin@2@V?$allocator@Vfunction_base@boost@@@std@@@1@@Z) referenced in function "protected: int __thiscall DlgcFW2::CDlgcEventProcessor::StartThread(void)" (?StartThread@CDlgcEventProcessor@DlgcFW2@@IAEHXZ) Anyone have this kind of problem before?

2 1

RE: [boost] Boost.Test, failed assert output
by Rozental, Gennadiy 06 Jul '04

06 Jul '04

I will see what I can do about it. If I remember correctly, the problem is that I do not know where the error occurred. So I have no way to print line pointing there. I could print only line pointing where the error was caught/detected. I am not sure it is what you want. Regards, Gennadiy.

1 0

Question about stdlib in gcc-2.95.3-linux toolset
by Joaquín Mª López Muñoz 06 Jul '04

06 Jul '04

A test of mine is failing in the gcc-2.95.3-linux toolset with the following: ostream: No such file or directory which, I guess, indicates that the std library used by this toolset does not have a <ostream> header. Digging through the regression logs, seems like the library being used is SGI's. Now, there is not defect macro in config/stdlib/sgi.hpp indicating that <ostream> is not available, so my question is: * Is this defect in gcc 2.95 known, and not an installation artifact? * If so, is there any way to figure it out from Boost.Config defect macros or some combination of these and SGI-specific macros? Maybe I'm missing something obvious and this lack of standard headers by gcc 2.95 is common knowledge, I just happen not to have dealt with this compiler ever. Thanks Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Does anyone have an is_virtual_base_and_derived ?
by Robert Ramey 06 Jul '04

06 Jul '04

Type traits includes: ::boost::is_base_and_derived<T,U> Does anyone have a version that might be called is_virtual_base_and_derived<B, D> which would return true iff D is derived virtually from B ? Robert Ramey

1 0

Re: [utility] boost::reset
by jhopkin＠reflectionsinteractive.com 06 Jul '04

06 Jul '04

Daniel Frey wrote: > > Gennaro Prota wrote: > > > Does the swap trick necessarily free the memory? > > AFAIK, yes. See <http://www.gotw.ca/gotw/054.htm>. > The STL implementation I have been using seems to allocate a buffer on first insertion into any container of a given type, and frees it only when it feels like it (often on program shut-down). I don't know if it's a strictly conforming implementation in that respect, although I can't see anything in the standard prohibiting this behaviour. James Hopkin

3 2

Re: Boost Mathematicians
by Michael Stevens 06 Jul '04

06 Jul '04

On Monday 05 July 2004 22:59, David Abrahams <dave(a)boost-consulting.com> wrote: > > Almost all the major reference works on BLAS and Matrices > > simply state elements are either Real or Complex and are therefore > > implicitly a field. > > We're not just concerned about the elements of matrices, but the > vectors and matrices themselves. OK I was assuming you were looking for a clear concept definition for the element types. > This becomes a real issue when you > have to write algorithms that might operate on matrices of reals or > matrices of matrices -- yes, these things do come up in real > applications. This is very odd. In linear algebra there is no such thing as a matrix of matrices. This impacts on the while prod/operator* controversy. That is, the primary advantage of not defining operator*. It prevents you passing matrix to an algorithm (not necessarily part of the uBLAS itself) that uses operator* and not unreasonably makes the assumption that operator* is commutative. The assumption is not unreasonable as all built in types operator* is exactly commutative. That said I have also argued in favour of operator* instead of prod in the past. It's central role in LA certainly argues in favour of using operator*. This involves so much peoples expectation as for algebraic notation, programming practice and just personal taste. > >> * Redundant specification of element type in matrix/vector storage. > > See my reply to Toon. Ah yes value_type is specified in both the matrix vector and storage type parameter list. In itself this is not good as the storage type should parameterise the matrix/vector with the value_type. It is simply there to make the syntax in the default case simple without the need for a type generator as in MTL. > > For std::slice (valarray) compatibility stride should be last. Not sure why > > this was not picked up on a long time ago!! > > valarray (and uBLAS) use size (not end) for good reason however. > > ...which is...? The begin end definition fails when stride==0. Slices of finite size with stride==0 are very useful. Similarly when (end-begin) *stride <0 the behaviour would have to be defined. > > Interesting solution. Agreed, the current implementation is closed to other > > objects because of the intrusive base class. Sadly uBLAS was designed before > > enable_if. Any pointers to compile/runtime effects of the enable_if solution? > > I can't really imagine what you're asking for here. I was looking for any publications/links to compare how compilers do between the two solutions. Anyone have any pointers? Thanks, Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

4 5

[utility] boost::reset
by Daniel Frey 06 Jul '04

06 Jul '04

Hi, I just wrote a small helper function to clear a container. Well, OK, we already have that, do we? For a container 'cont': cont.clear(); But this doesn't neccessarily free the memory allocated. The "usual" workaround is: Cont().swap( cont ); But Cont (the type of the container) is sometimes rather large and the code doesn't communicate well what I intended. I thus wrote the following small helper: template< typename T > void reset( T& t ) { T().swap( t ); } Would this make a good addition to boost.utility? Any comments welcome... Regards, Daniel -- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey(a)aixigo.de, web: http://www.aixigo.de

5 13

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Glen Knowles 06 Jul '04

06 Jul '04

> From: Howard Hinnant > > Exploring the case: throw exception if unable to atomically > promote read to write: > > If an exception is not thrown, then you are guaranteed what > you previously read is still true, and all is well. If an > exception is thrown, then you have to re-read to determine > current state. First, to be clear, a promote() _must_ not be allowed to silently fail, otherwise you break the contract and people will spend several days tracking down the problem. If you want that behavior you should use try_promote(). I don't have a problem with it simply deadlocking, or, if that's unacceptable don't have the blocking promote() function. The complexity involved in determining a deadlock may be well beyond what you want to do at this level in the library, I'll come back to this later. But for now, lets talk about throwing. In my mind the purpose of throwing is to allow the other thread (or threads, with the database work I've been doing multiple read locks on an object all trying to be promoted to write locks at the same time happens more often then you might think) to proceed, which it can't do unless you give up your _read_ lock. > > Hmm... > > Given that when you have write privilege you also implicitly > have read privilege, this seems a little extreme. Would it > not be both more efficient and easier to follow if you just > reaffirm your state under the write lock rather than assume > your state, and write a catch block to reassert it if it > happens to be false? That is, this: > > bool try_sale(rw_mutex& m) > { > read_lock rl(m); > > long balance = get_balance(); > long cost = get_total_cost(); > > if (balance > cost) > { > write_lock wl(rl); > set_balance(balance - cost); > // ... > return true; > } > return false > } > > bool do_sale(rw_mutex& m) > { > while (true) > { > try_again: > try { > return try_sale(m); > catch (rw_promotion_error&) { > // Try the whole thing again > // how is this implemented? > goto try_again; // ? > } > } > } > > vs this: > > void do_sale(rw_mutex& m) > { > read_lock rl(m); > > long balance = get_balance(); > long cost = get_total_cost(); > > if (balance > cost) > { > rl.unlock(m); > write_lock wl(m); > set_balance(balance - cost); > wl.transfer_to_read_lock(rl); > balance = get_balance(); > } > // ... > } > > My assertion is that you don't know a-priori if the > read-to-write promotion achieves anything or not. If you > allow it to fail, by exception, or by error code, or by any > other means, then you have to write code to re-read the > current state. If you don't allow it to fail, then you must > make it block until it succeeds. The latter seems simpler in > logic, and smaller in code size. The logic is quite simple: > > read_lock to write_lock promotion is not atomic. > > Once that is understood, the programmer can just deal with > it. Trying to encapsulate this bit of reality only serves to > obfuscate the necessary logic. The reason that "release read, acquire write" appears a complete alternative to promotion is because your example is too simple. You may need the read lock to keep the object alive in a cache, where it could be flushed to disk and destroyed if you release it, forcing you to re-read it before getting your write lock. I think that the library should either commit to detecting deadlocks or don't do it at all. Is it going to throw a promotion exception in this case? Thread A: read lock x Thread A: read lock y Thread B: read lock y Thread B: write lock x, blocks Thread A: promote y to write lock, blocks In order to detect things like this you essentially need to build a complete conflict matrix of all held locks in the system, and if you do that I assume you'd also use it to detect deadlocks of regular locks: Thread A: lock x Thread B: lock y Thread A: lock y, blocks Thread B: lock x, blocks Glen

2 1