- Boost - lists.boost.org

[config] BOOST_NO_INITIALIZER_LISTS patch
by Daniel James 04 Dec '08

04 Dec '08

Hi John, I've attached a patch for adding BOOST_NO_INITIALIZER_LISTS to config. Is it okay to commit? thanks, Daniel

2 1

[shared_ptr] make_shared and enable_shared_from_this with boost 1.36
by Michael Marcin 04 Dec '08

04 Dec '08

The following code throws boost::bad_weak_ptr using boost 1.36. #include <boost/shared_ptr.hpp> #include <boost/enable_shared_from_this.hpp> #include <boost/make_shared.hpp> class Test : public boost::enable_shared_from_this<Test> {}; int main() { boost::shared_ptr<Test> test = boost::make_shared<Test>(); test->shared_from_this(); } -- Michael Marcin

2 1

Re: [boost] [Boost-users] [review][constrained_value] Review of ConstrainedValue Library begins today
by raindog＠macrohmasheen.com 04 Dec '08

04 Dec '08

I totally agree. Pre contstraining a value for assignment to constrained_value seems to defeat the purpose of the library all together. ------Original Message------ From: Edward Diener Sender: boost-users-bounces(a)lists.boost.org To: boost-users(a)lists.boost.org Cc: boost(a)lists.boost.org ReplyTo: boost-users(a)lists.boost.org Sent: Dec 3, 2008 7:58 PM Subject: Re: [Boost-users] [review][constrained_value] Review of ConstrainedValue Library begins today Mathias Gaunard wrote: > Edward Diener wrote: > >> I disagree with your analysis. The '26' value could be a run-time >> calculation and not just a compile-time constant. In which case you >> are saying that the assignment of a run-time calculation should assert >> only when run in debug mode and otherwise should be ignored. I can not >> agree with that idea. > > I say it is up to the programmer to ensure valid values are provided. > If the value is only known at runtime, there should be explicit checking > in the code prior to assignment. Suppose the value is provided by the end user of the program. Do you still feel such a value, when used in a constraint, should assert only in debug mode rather than throw an exception ? A large part of the constrained value concept is that the constraint provides the necessary checking, in the form of a policy, which alleviates specific pre-checking by the programmer. I like that, else the constraint library serves less purpose than it could. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users Sent from my Verizon Wireless BlackBerry

1 0

[review][constrained_value] Bounded value
by Edward Diener 04 Dec '08

04 Dec '08

This is not a full review of the constrained_value library but rather a comment on one of the concepts of the library. I hope to give a full review by December 10 if I have the time. I believe the bounded objects are actually a subset of a larger concept, which is the set of valid values for an object. Ideally what one could have is a set of bounded values which define the valid values. Each member of the set could be a pair ( or two-element tuple ) defining a lower and upper value inclusive, and of course a single value in the set would have its lower and upper value be the same. In this way one could define, as an example, a constrained object whose integer value could be between 0 and 20 and between 50 and 70. Currently the bounded object concept only allows one "bounds". With the larger concept I mention, a bounded object can have any number of bounds. While the single bounds bounded object can still be supported, I would like to see the constrained value library implement a multi-bound concept, in which case the current bounded object concept is just a subset of the multi-bound with a single bound.

2 4

[vault] trojan in vault?
by Eric Niebler 03 Dec '08

03 Dec '08

Looks like someone uploaded a trojan or something to the boost file vault. Can someone with permissions please delete shell.php4 here: http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=eric_… Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Re: [boost] [unicode] Interest Check / Proof of
by Graham 03 Dec '08

03 Dec '08

Hi, I have taken a different approach and distilled the Unicode character rules down into a library as the rules are too complex to be defined algorithmically. This library gives full Unicode support for iterators for the full Unicode set of characters. It just needs the string wrapper round it. Please see the Unicode character library at: http://www.boostpro.com/vault/ Unicode_lib.zip. Good Luck. Yours, Graham

1 0

[Function] Problem using target() with boost::mem_fn and boost::bind
by Pengcheng Song 03 Dec '08

03 Dec '08

Hi, I have encountered a crash trying to use the target() function to retrieve a function pointer from a boost.function initialized with a member function (using boost.bind). See the code below. // =========================================== #include <iostream> #include <boost/bind.hpp> #include <boost/function.hpp> typedef double(*FunctionType) (double); double Square( FunctionType f, double x ) { return f(x) * f(x) ; } class A { private: double x_; double y_; public: A() : x_(1.0), y_(1.0) {} double Area(double x, double y) { x_ = x; y_ = y; return x_ * y_; } }; int main() { A a1; boost::function<double(double)> f1 = boost::bind( boost::mem_fn(&A::Area), &a1, _1, 2.5 ); double s1 = f1(2.0); // this works FunctionType f2 = *f1.target<FunctionType>() ; // Error: this would crash s1 = Square( f2, 2.0 ); return 0; } // ====================================================== After debugging the code, I found out that the crashed happened inside target() function in file function_base.hpp: template<typename Functor> Functor* target() { if (!vtable) return 0; detail::function::function_buffer type_result; type_result.const_obj_ptr = &typeid(Functor); vtable->manager(functor, type_result, detail::function::check_functor_type_tag); return static_cast<Functor*>(type_result.obj_ptr); } After vtable->manager() call, type_result became null, and this caused static_cast to fail. I was using boost_1_36_0 precompiled by BoostPro with Visual Studio 2008. Is this an expected behavior? Your feedback would be greatly appreciated. Pengcheng Song -- View this message in context: http://www.nabble.com/-Function--Problem-using-target%28%29-with-boost%3A%3… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[python] Bug during build process?
by Robert Dailey 03 Dec '08

03 Dec '08

Hi, I execute the following command to build the entire boost 1.37 library with python debugging ON: *bjam --toolset=msvc --layout=system link=shared threading=multi variant=debug python-debugging=on stage* I then use dependency walker <http://www.dependencywalker.com/> to load the file *boost_python-mt-gyd.dll* and I see that both python25.dll and python25_d.dll are being loaded side by side. This obviously shouldn't be happening and only python25_d.dll should be loaded. Is there a bug in the build script for boost python, or am I doing something wrong?

2 2

[inteprocess] maximum length for names of mutexes, memory segments etc.
by JOAQUIN M. LOPEZ MUÑOZ 03 Dec '08

03 Dec '08

Boost.Flyweight uses long names for some internal mutexes and memory segments inside the intermodule_holder component, with the purpose of guaranteeing name unicity. For instance, this is a typical name for such an internal mutex, with length 87: boost_flyweight_intermodule_holder_mutex_5660_601342046_2913549788_3054690985_591945496 However, on some platforms line NetBSD 87 chars is too much:

1 0

[future N2561] Implementation comments
by vicente.botet 03 Dec '08

03 Dec '08

Hi, on the current Future (N2561) library proposal the promise protect the value setting/getting from multiple threads using a lock, but the lock do not protect the future initialization (lazy_init()). void set_value(typename detail::future_traits<R>::source_reference_type r) { lazy_init(); boost::lock_guard<boost::mutex> lock(future->mutex); if(future->done) { throw promise_already_satisfied(); } future->mark_finished_with_result_internal(r); } I'm wondering if we don't need to extend the protection or avoid the lazy initialization? I'm missing something? BTW, Is it safe to take the address of a promise? If not, why not delete the operator&()? Best, Vicente

2 6