- Boost - lists.boost.org

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

Request for mpl::empty_sequence
by Alexander Nasonov 05 May '04

05 May '04

For the purpose of forward declaration of class templates this read-only lightweight sequence might be useful. For example, one might declare class template Selector in fwd file: // empty_sequence.hpp is designed for inclusion into fwd files #include <boost/mpl/empty_sequence.hpp> template<class Variants = empty_sequence> class Selector; Another way to archieve this could be inclusion of <boost/mpl/vector_fwd.hpp> (why there is no such file in mpl?) and using mpl::vector<> instead. Although, it could extend a set of class templates with those modifying template parameter but a user would find it strange to include <boost/mpl/vector.hpp> if he only uses Selector<>. The empty_sequence definition is as simple as: namespace boost { namespace mpl { namespace aux { struct empty_sequence_iter { typedef forward_iterator_tag category; }; } struct empty_sequence { typedef aux::empty_sequence_iter begin; typedef aux::empty_sequence_iter end; }; }} This is not yet complete. I hope that support for some transformations will be added later (transformation doesn't change empty_sequence unless the size is changed) -- Alexander Nasonov Independent Developer and Consultant

2 6