May 2004 - Boost - lists.boost.org

RE: [boost] Re: Re: [Thread] Perennial rw_mutex question
by Hurd, Matthew 05 May '04

05 May '04

> On Behalf Of Michael Glassford > * Rename to improve consistency and eliminate abbreviations: > Use "read" and "write" instead of "shared" and "exclusive". Just a quick note from the bike shop. I've always had an issue with rw/read/write as this is a common use case rather than shared/exclusive which is the real deal. Going along these lines I think rw_mutex is a bad name, though I grant it is commonly understood. The oxymoron shareable_mutex or something other shorter name would make me happier. 0.000000000000002 lira, Matt Hurd IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

3 2

Re: [Boost] Big integer library
by Richard Peters 05 May '04

05 May '04

"Thorsten Ottosen" <nesotto(a)cs.auc.dk> wrote in message news:c6quof$dtl$1@sea.gmane.org... > I have some questions. Will it be possible to say > > 1. typedef boost::rational< big_integer > big_rational. Yes. In fact, the big_integer_example contains an example where boost::rational<big_integer> is used. > 2. Why is faculty() a part of the interface. I have a generic version of > faculty in some prob&stat code I'm doing that I hope would work > with big_integer. Your generic version will most probably work. There is one difference, my version returns an expression instead of a value, which saves the creation of one temporary value. In this case, the gained performance is probably minimal. I'm happy to refactor this function out of the library, throw it away, or come up with a hybrid solution where the expression-returning version is included when both big_integer and your library is included. > 3. Are you planning big_float? I would be happy with focus on interface > specs and then better implementation later. Unfortunately not. I can see that big_float would have its uses, but I rarely even use float. My interests ly in algebraic computations such as cryptology. > The C++ standard could really use a "big" library and it's always nice > with a version in boost first. > > br > > Thorsten Thanks for the response, Richard Peters

10 18

compiler confirmance table
by Max Khesin 05 May '04

05 May '04

Hi, do you know if anyone has a compiler->boost library table of some sort? As I am going through some of the boost libs to get an idea what I can benefit from working in vc6 environment you have to do quite a bit of poking in the docs to figure out if and how much of a given library will compile/work on this platform. It would be nice to have a table like this (just for example) MSVC6 ======= bind - ok function - ok using portable syntax BLL - forget it xyz - runtime problems ... GCC ===== ... of course if there were standardized unit tests for each lib this could be somewhat automated. max. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

4 4

Re: Generative programming support in boost
by Dave Gomboc 05 May '04

05 May '04

> I'm not sure what your question is. Generative programming > itself is a design process/idiom. I can't really imagine how > you'd directly support it with a library, though of course we > have lots of tools in Boost that can be used to practice > generative programming. Indeed, my original message missed the mark -- perhaps I'm not sure what my question is either. :-/ Let me try again. I'm wondering about support for the automatic assembly of components as described in [CE2000], based upon defining mandatory and variable (optional and alternative) features of components, plus the creation of domain-specific languages (a la Spirit), but particularly for component configuration. Of course, boost::mpl aides the specific task of static template metaprogramming. Chapters 13 and 14 of the book contain examples of generative programming applied to bank accounts and to matrix computation. It'd be of value if there was an reimplementation of these that used parts of boost as applicable. I think I've more-more-than-less grokked chapter 12 (the list generator). Dave

1 0

RE: [boost] bdb and mpi selectors for the graph library
by Roman Yakovenko 05 May '04

05 May '04

Pierre wrote: > What I propose, in the case of bdb, is just an edge and a vertex > container, which allows you to do something like : > typedef adjacency_list<bdbS, bdbS, ...> Graph; > and store you whole graph in a berkeley DB database, so that you can > play with fairly big graphs... > > Hope it answers your question... > > > Pierre Definitely. Thanks. Yes, I am interested. I have to deal with DAG, implemented on bdb. I am in design phase of the project. So if you want to share your thought, it will be grate. Roman

1 0

RE: [boost] bdb and mpi selectors for the graph library
by Roman Yakovenko 05 May '04

05 May '04

Hi. I don't understand what do you propose. > The second is aimed at situations when you can't distribute > your graph (e.g. > you're partitionning it before distributing it), or speed > isn't an issue. It > uses a berkeley DB database to store the graph. Do you propose interface that suitable for boost::graph library while implementation of graph is BDB ? If so I'd like to see some code or\and documentation. Roman

3 2

Re: Big integer library
by Richard Peters 05 May '04

05 May '04

I have uploaded a new version of the big_integer library which also compiles with GCC 3.4.0 (cvs version). This version now compiles on compilers which implement two-stage name lookup. The library is available at http://groups.yahoo.com/group/boost/files/big_integer/, the version is 0.1. best regards, Richard Peters "Giovanni Bajo" <giovannibajo(a)libero.it> wrote in message news:c5mf2u$bt0$1@sea.gmane.org... > Richard Peters wrote: > > > A few months ago there was some discussion about an arbitrary > > magnitude integer library. I have now implemented such a library, > > which is located at > > http://groups.yahoo.com/group/boost/files/big_integer/. > > Compiling the code generate hundreds of failures because of two-stage name > lookup. You tested it under MSVC 71 and GCC 3.2 which both fail to implement > lookup rules correctly. I suggest you try again with GCC 3.4.0 (a pre-release > binary package should be available now) or EDG-based compilers. > -- > Giovanni Bajo

11 24

[Thread] Perennial rw_mutex question
by Douglas Paul Gregor 05 May '04

05 May '04

What is the status of rw_mutex and its brethren? It's been languishing on the thread_dev branch for far too long, but lots of people (myself now included) need it. Are there design issues holding it up? Some coding that still needs finishing? Testing? Doug

2 3

[serialization] pointers to built-in types
by Li Lirong 05 May '04

05 May '04

I remember that pointers to built-in types can not be serialized directly in earlier versions of the library. The user would have to write a wrapper around the built-in type. How is the situation now? Best regards, Lirong

1 0

patch: iterator/zip_iterator.hpp
by Antony Searle 05 May '04

05 May '04

While using zip_iterator I encountered some minor bugs. Bugs: The include guard is broken (the #define has been omitted). The function "tuple_equal" causes multiple-definition linker errors. Patch: Added missing #define to header guard. Added missing "inline" keyword to "tuple_equal" definition. Please find attached the patch file. Best, Antony Searle zip_iterator.hpp.patch: *** zip_iterator.hpp.orig 2004-05-05 10:35:41.000000000 +1000 --- zip_iterator.hpp 2004-05-05 11:08:45.000000000 +1000 *************** *** 19,24 **** --- 19,25 ---- // Borland 5.5.1 (broken due to lack of support from Boost.Tuples) #ifndef BOOST_ZIP_ITERATOR_TMB_07_13_2003_HPP_ + #define BOOST_ZIP_ITERATOR_TMB_07_13_2003_HPP_ #include <stddef.h> #include <boost/iterator.hpp> *************** *** 315,321 **** // No point in bringing in a bunch of #ifdefs here. This is // going to go away with the next tuple implementation anyway. // ! bool tuple_equal(tuples::null_type, tuples::null_type) { return true; } template<typename Tuple1, typename Tuple2> --- 316,322 ---- // No point in bringing in a bunch of #ifdefs here. This is // going to go away with the next tuple implementation anyway. // ! inline bool tuple_equal(tuples::null_type, tuples::null_type) { return true; } template<typename Tuple1, typename Tuple2>

1 0