April 2004 - Boost - lists.preview.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

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

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

[patch] GCC 3.4 removed __GLIBCPP__ macro
by Jonathan Wakely 04 May '04

04 May '04

Hi, The version of libstdc++ that ships with GCC 3.4 has changed a number of macro names, so the boost/config/stdlib/libstdcpp3.hpp file no longer works. __GLIBCPP__ -> __GLIBCXX__ _GLIBCPP_USE_WCHAR_T -> _GLIBCXX_USE_WCHAR_T _GLIBCPP_USE_LONG_LONG -> _GLIBCXX_USE_LONG_LONG The attached patch adds a check for __GLIBCXX__ to select_stdlib_config.hpp and includes a new libstdcxx3.hpp file if it's defined. That new file is also attached. If noone's already working on this, is my approach the best one? jon -- "Surrealism aims at the total transformation of the mind and all that resembles it" - Breton

2 3

Re: Re: [BGL] forced client complexity
by Provisional Dissonance 02 May '04

02 May '04

>Yea, but first the original poster should indicate if this is what he's >looking for -- I never needed this myself. What I was looking for, really, was dialog on existing design strategies. It sounds like your issues with property maps mirror my confusion with the library design, though. While I can fully appreciate the desire to write generic code, it feels like BGL has pushed the complexity of creating and enforcing coupling between the generic graph/node/visitor/algorithm/etc onto the client. At a basic conceptual level, I think of a graph as a data structure composed of nodes and edges. If I'm modeling a family tree, I expect the nodes to be objects of some family-member class. C++ exposes many robust and elegant methods for modeling the family-member - why should I, as a client, have to use property-maps at all? If the node's "index" is related to the object, why would it not be a natural member of the node-type's class? If, instead, it is a synthesized construct for communication between a graph and the algorithm operating over it, why should the client be responsible for its maintenance instead of the framework? What are the advantages of this approach? What are the disadvantages of simplifying things for the client? This is the type of design issue that I intended to question with my initial post. -prs __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

6 16

bind question/request
by Max Khesin 02 May '04

02 May '04

I am refactoring code that looks something like this: if (op == LN::FILTER_IN || op == LN::FILTER_NOT_IN) { where += handle_set_operation(column, type, format, op, expr_set); } else if (op == LN::FILTER_RANGE) { where += handle_range_operation(column, type, format, op, expr_set); } else if (op == LN::FILTER_NULL || op == LN::FILTER_NOT_NULL) { where += handle_null_operation(column, op); } ... This would obviously be handled better with a map of some sort (has to map int to function). The problem here is that some functions have more arguments than others, precluding the possibility of uniform type for the function value of the map. I cannot just go and change the function sig to include dummy values ('cause it's a dumb idea). This situation made me think of boost.function/boost.bind, which allows to effectively shorten the function parameter list by binding some of the args. so given int f(int a, int b) { return a + b; } bind(f, _1, 5)(x); is equivalent to f(x, 5); and by extension bind(f, _1, _2, _0)(x, y, z) would be equivalent to f(x, y) thoughts? thanks. 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.

5 4

BOOST_TRY, can we make it into CVS?
by Pavel Vozenilek 01 May '04

01 May '04

I would like to ask someone with write access to CVS to create file boost/details/exception_helpers.hpp (or so) with content: #include <boost/config.hpp> #include <boost/detail/workaround.hpp> #if !(defined BOOST_NO_EXCEPTIONS) # define BOOST_TRY { try # define BOOST_CATCH(x) catch(x) # define BOOST_RETHROW throw; # define BOOST_CATCH_END } #else # if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) # define BOOST_TRY { if ("") # define BOOST_CATCH(x) else if (!"") # else # define BOOST_TRY { if (true) # define BOOST_CATCH else if (false) # endif # define BOOST_RETHROW # define BOOST_CATCH_END } #endif circular_buffer, serialization and multi_index_container may use this code. It was discussed on the list and reaction was rather positive. TIA /Pavel

2 1

looping construct
by michael toksvig 30 Apr '04

30 Apr '04

A while back, Erik Niebler was testing the waters for inclusion of his very, very clever looping construct into boost, but nothing really came of it. Erik's technique is described here: http://www.nwcpp.org/Meetings/2004/01.html Yup, macros are involved and they are yucky, and yup, there already exists a for_each in the standard that works just fine if you care to move your loop body away into a function, and yup, the name BOOST_FOREACH could use a little love. But there is no denying the notational clarity and succinctness of e.g.: foreach(double &d, container) d += 2; Versus the rather redundant: for (list<double>::iterator i = container.begin(); i !=container.end(); ++i) *i += 2; (Note that the latter stops working if container is represented using a vector or a built-in array instead) /Michael Toksvig

11 52

Can't access repositories using :ssh:
by Victor A. Wagner Jr. 30 Apr '04

30 Apr '04

Starting yesterday (it's still Thursday here) I started getting errors in my update and build scripts. When I chased it down, I was getting: WARNING - POTENTIAL SECURITY BREACH! The server's host key does not match the one PuTTY has cached in the registry. This means that either the server administrator has changed the host key, or you have actually connected to another computer pretending to be the server. The new key fingerprint is: ssh-dss 1024 4c:68:03:d4:5c:58:a6:1d:9d:17:13:24:14:48:ba:99 If you were expecting this change and trust the new key, hit Yes to update PuTTY's cache and continue connecting. If you want to carry on connecting but without updating the cache, hit No. If you want to abandon the connection completely, hit Cancel. Cancel is the ONLY guaranteed safe choice.1¦ I tried it manually a few times, then surrendered and said yes.... that didn't solve the problem now I get: C:\Projects\boost>cvs update -dPA Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Cannot access /cvsroot/boost/CVSROOT No such file or directory I get this behavio(u)r on both boost and boost-sandbox a simpler command yields (logging in just to make sure...): C:\Projects\boost>cvs login Logging in to :ssh:vawjr@cvs.boost.sourceforge.net:22:/cvsroot/boost CVS password: ******* C:\Projects\boost>cvs co -c Cannot access /cvsroot/boost/CVSROOT No such file or directory Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

3 3

cycle_iterator update
by Neal D. Becker 30 Apr '04

30 Apr '04

Here is an update to cycle_iterator. This is based on the original design by Gennadiy Rozental. After fairly extensive performance testing I am getting good results (compared to my old implementation which was hand-written, not based on boost iterators), after adding operator[]. There are two versions, both give about the same performance in my tests. One version, which I prefer, modifies the underlying base iterator for operations such as increment. The other implementation never touches the base iterator, but modifies an integral offset value. Also included is a Ring container adaptor class, which adapts a container (e.g., std::vector) to a ring. Basic operations are there, but more can be added. Also a simple test program.

4 9