- Boost-users - lists.boost.org

bug in mersenne twister
by Morgan 11 Jan '05

11 Jan '05

This is my first bug report(ever), so feel free to point out how I could do a better job of this... Anyways I have found a bug with the mersenne_twister random number generator class, where results when calling for a random number vary between codewarrior 9.0 and gcc 3.4.1 with boost 1.31.0. A simple example is shown below: #include <boost/random/mersenne_twister.hpp> // for mt11213b typedef boost::mt11213b base_generator_type; class foo { public: foo(const base_generator_type gen):m_gen(gen) {} ~foo(void) {} rand_type operator() ( void ) { const float x = m_gen(); return x; } private: base_generator_type m_gen; } int main(void) { base_generator_type gen( (uint32_t) 2000); seed is not important foo f(gen); cout << "Random result is " << f() << endl; } The resulting numbers will be different between codewarrior 9.0 running on windows and gcc 3.4.1 running on Suse linux 7.3.(Hope that is enough info). I tracked the cause of the bug down to class initialization. In the case of CW9.0, the compiler when constructing a foo, will use a mersenne_twister copy ctor when initializing m_gen, while in the case of gcc 3.4.1 it will choose the following in the .hpp file template<class Generator> explicit mersenne_twister(Generator & gen) { seed(gen); } therefore using the provided generator as a seed to the new generator rather than just copying its state, even though no template parameter is provided. Anyways I will leave it up to the more informed to decide which is more desirable/proper; however, this is a fairly nasty bug at the moment as

1 0

How can I uninstall Boost with bjam?
by Welson Sun 11 Jan '05

11 Jan '05

I tried "bjam uninstall", but doesn't work. I searched the web and maillist, looks like no one has ever talked about it. Yours, Welson Sun

2 4

Serialization and shared_ptr
by Jarl Lindrud 11 Jan '05

11 Jan '05

Hi! A question on serializing pointers to derived classes: When I serialize naked polymorphic pointers through base pointers, things work as expected, ie the derived classes are serailized and deserialized. However, when I replace the naked pointers with corresponding boost::shared_ptr's, I get an archive_exception, to the tune of "unregistered class". I'm using BOOST_CLASS_EXPORT, and not the register_type<> functions. Is this supposed to happen, or do I need some additional type registration beyond what was necessary for serializing naked pointers? Thanks! Jarl. The code: //B and C derive from A std::ostringstream os; boost::archive::text_oarchive oa(os); //A *pb0 = new B(15,16); //A *pc0 = new C(17, 18, 19); boost::shared_ptr<A> pb0( new B(15,16) ); boost::shared_ptr<A> pc0( new C(17, 18, 19) ); oa << pb0; oa << pc0; std::string data = os.str(); { std::istringstream is(data); boost::archive::text_iarchive ia(is); //A *pa1 = NULL; //A *pa2 = NULL; boost::shared_ptr<A> pa1; boost::shared_ptr<A> pa2; ia >> pa1; ia >> pa2; B* pb = dynamic_cast<B *>(pa1.get()); C* pc = dynamic_cast<C *>(pa2.get()); } _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 1

Forwarding problem in base_from_member
by Jens Theisen 11 Jan '05

11 Jan '05

Hello, the above class (doesn't?) currently addresses the forwarding problem by passing constructor argument by value. Would it not be a better idea to use const&? We can't pass variable references at the moment, can we? Cheers, Jens

2 2

RE: [Boost-users] Re: C++ Template Metaprogramming - Exercise 2-0
by Trask, Bruce (US SSA) 11 Jan '05

11 Jan '05

Philippe, > Given that, it is trivial to modify Eric's solution to have the > proper result. > Right. As they say in New England, Dawn in beginning to break over Marblehead. It took me four cracks to get it, but I think I got it now (see below and tell me if I do). (thanks for not telling me the answer outright) I starting to get the hang of it. Exercise 2.0 down. That's one in a row :) #include <iostream> #include <boost/type_traits/is_reference.hpp> #include <boost/type_traits/add_reference.hpp> #include <boost/type_traits/add_const.hpp> #include <boost/type_traits/is_same.hpp> #include <boost/static_assert.hpp> using namespace std; template<typename T> struct add_const_ref { typedef typename boost::add_reference<typename boost::add_const<T>::type>::type type; }; int main() { BOOST_STATIC_ASSERT((boost::is_same<boost::add_const<int>::type, const int>::value)); BOOST_STATIC_ASSERT((boost::is_same<boost::add_reference<int>::type, int&>::value)); BOOST_STATIC_ASSERT((boost::is_same<boost::add_const<int&>::type, int&>::value)); BOOST_STATIC_ASSERT((boost::is_same<boost::add_reference<boost::add_cons t<int>::type>::type, int const&>::value)); BOOST_STATIC_ASSERT((boost::is_same<add_const_ref<int&>::type, int&>::value)); BOOST_STATIC_ASSERT((boost::is_same<add_const_ref<int>::type, int const&>::value)); return 0; } Thanks for the input, Bruce > Philippe > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: C++ Template Metaprogramming - Exercise 2-0
by Lemings, Eric B. (Contr) 11 Jan '05

11 Jan '05

Dave Abrahams wrote: > Actually there's a much more concise solution using the type traits > library. That is, after all, the focus of the chapter. I believe that would be: template <typename T> struct add_const_ref { typedef add_const<add_ref<T>::type>::type type; }; Correct me if I'm wrong. Eric.

1 0

Re: C++ Template Metaprogramming - Exercise 2-0
by Lemings, Eric B. (Contr) 11 Jan '05

11 Jan '05

Dave Abrahams wrote: > Actually there's a much more concise solution using the type traits > library. That is, after all, the focus of the chapter. I believe that would be: template <typename T> struct add_const_ref { typedef add_const<add_ref<T>::type>::type type; }; Correct me if I'm wrong. Eric.

3 2

Zero/Null Metafunction?
by Lemings, Eric B. (Contr) 10 Jan '05

10 Jan '05

Hi, I was wondering if there is a zero/null value metafunction in the Boost libraries? Something like the following: null<int>::value // 0 null<float>::value // 0.0 null<void*>::value // 0 or NULL null<int&>::value // undefined Thanks, Eric.

1 0

Re: [sigc] Re: [Boost-users] Signals & Slots
by Doug Gregor 10 Jan '05

10 Jan '05

On Jan 9, 2005, at 11:35 AM, Martin Schulze wrote: > Am 07.01.2005 14:19:20 schrieb(en) Douglas Gregor: >> If I'm right in assuming that the code will not compile (because the >> signatures do not match exactly), then the "No Clue" could be replaced >> by "Not Applicable", because >> Signals performs all of the implicit conversions. > > I'm afraid, you're wrong here. Implicit conversions do work. > retype(_return) is for explicit conversions. > However, using implicit conversions in libsigc++-2.0 without > retype(_return) can cause troubles (at least warnings) with some > compilers. Okay, good. Then I don't have to try to motivate the need for implicit conversions :) >> - About ptr_fun/mem_fun: you can use them in either library, if >> you'd >> like to be more explicit. >> - About bind: bind is now in the C++ Library TR (an addendum to the >> standard, which should be approved in the near future), so we're >> forced >> to build on it to create any signals & slots library for the standards >> committee. (We'll have a long, uphill battle if we try to introduce >> our >> own special binders and don't support bind). > > Is there a way to deduce the return type of the bind functor object > that is part of the TR? Yes. It's called "result_of" in the Library TR. > Will it be possible to "visit the targets" that are stored in the > bind functor object with a function like Boost::visit_each() or > sigc::visit_each()? This functionality was not included because it was not necessary for anything in the Library TR (and would otherwise be hard to motivate). We could propose this as part of a signals 'n' slots system, of course. >> - Regarding libsigc++'s specialization for T_accumulator=nil: We >> don't need to discuss this in a standards proposal, because it's >> entirely a quality-of-implementation issue. >> - Regarding Signals and Function: They don't play well together, >> but >> we're going to have to deal with this one way or another because >> Function is also part of the C++ Library TR. > > I always thought that Boost had quite some influence on standard > proposal? Who come that the TR is in a bad shape for a signal system, > then? I wouldn't say that it is in bad shape for a signal system. The problem with {boost:: or tr1::}function and a signals system is that they both do the same thing: erase the static type of a function object so that it can be called through an entity that does not encode that type. The problem is that we need to call visit_each before we erase that type: 'function' shouldn't do it all the time, because that could be costly, and the signal/slot can't do it because the type is gone. We can probably come up with a not-too-painful solution, if we're clever enough. Doug

2 2

Dumb multi_array question about assignment
by Grant Goodyear 10 Jan '05

10 Jan '05

I'm currently working on a numerical project that uses boost.python, and since we already had boost as a dependency we've begun using boost/multi_array_ref to simplify multi-dimensional array handling in our code. I was rather surprised when the following code fragment spit out pages of errors when I tried to compile it: float* data = (float*) malloc(nx*ny*sizeof(float)); [...] boost::multi_array_ref<float, 2> xy(data, boost::extents[nx][ny]); xy = 0.; // errors out here Looking through the docs I realized that operator= isn't even mentioned, so perhaps I shouldn't have been surprised. It is rather unfortunate, though, that such a statement isn't allowed. (Unless, of course, I'm doing something wrong, which is completely possible.) Is there any plan to add such functionality in the future, or would it make more sense for us to switch to a different library (blitz++ or something similar)? Thanks, Grant Goodyear -- Grant Goodyear web: http://www.grantgoodyear.org e-mail: grant(a)grantgoodyear.org

2 2