- Boost - lists.boost.org

[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

[xpressive] regex_token_iterator - bug, feature, misunderstanding query?
by Michael Goldshteyn 03 Dec '08

03 Dec '08

OK, so I want to use the sregex_token_iterator functionality to split a data string. The data string contains: /a/b//c/ The delimiter is the forward slash and I do want empty strings. I expect to get: {}{a}{b}{}{c}{} What I actually get is: {}{a}{b}{}{c} The empty string after {c}, which I expect because the data string ended in a forward slash, is missing. What do I have to do to get the empty string after {c} if the data string ends in a forward slash? The code is as follows: --- #include <iostream> #include <string> #include <boost/xpressive/xpressive.hpp> #include <boost/xpressive/regex_token_iterator.hpp> int main(int argc, char *argv[]) { // Split the path using namespace boost::xpressive; // For simplicity sregex levelSplitter(as_xpr('/')); std::string nodePath("/a/b//c/"); sregex_token_iterator begin(nodePath.begin(),nodePath.end(),levelSplitter,-1); sregex_token_iterator end; for (sregex_token_iterator iCur=begin;iCur!=end;++iCur) std::cout << '{' << *iCur << '}'; std::cout << std::endl; return 0; } --- Thanks, Michael Goldshteyn

2 2

Re: [boost] [Boost-users] [review][constrained_value] Review of Constrained Value Library begins today
by Mika Heiskanen 03 Dec '08

03 Dec '08

Mathias Gaunard wrote: > 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. If the value must be checked beforehand, why bother using a constrained type at all? Where's the benefit if all assignments are already guaranteed to be valid by external tests? Might just as well use a test+POD combination. --> Mika Heiskanen

1 0

How to access the Boost wiki?
by vicente.botet 03 Dec '08

03 Dec '08

Hi, In order to access the Boost wiki I do COMMUNITY > Requesting a New Feature > " ticket system," > Wiki. Is there a shorter way? If not can we add it on COMMUNITY? Best, Vicente

1 0

Which Future library will be reviewed?
by vicente.botet 03 Dec '08

03 Dec '08

Hi Anthony, your current Boost.Future(http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp + http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2561.html) library is closer to the C++0x standard than the Boost.Future from Braddock. This let me think that yours is a better candidate for Boost, but the current state of your library interface has some differences, restrictions and extensions respect to the standard http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2627.html and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2709.html I know that you have implemented a prototype for an earlier version of n2676 available at http://www.justsoftwaresolutions.co.uk/threading/updated-implementation-of-…. I would like to know which one will be reviewed? Do you plan to review your current Boost proposal and adapt it to the current C++0x proposal before the review. IMO, if you do that the review will be much more efficient. The current documentation includes often the C++0x interface and not the C++98 emulation. Do you plan to add it? before the review? In addition to the current reference, do you plan to add more documentation such as tutotial, examples, design rationale, implementation notes? before the review? I think restrictions/extensions to the standard should be stated explicitly. A comparaison of your implementation and the standard seems mandatory. * How move semantics is emulated (restrictions) * How the default constructed deleted functions are emulated (note that these are part of the interface) Next follows some differences that need attention (from http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp) ===== private: unique_future& operator=(unique_future& rhs);// = delete; versus public: unique_future& operator=(const unique_future& rhs) = delete; ===== wait_for, wait_until versus timed_wait, timed_wait_until ===== shared_future & operator=(const shared_future& rhs) = delete; versus shared_future& operator=(shared_future const& other); === shared_future(const shared_future& rhs); shared_future(unique_future<R>); shared_future(); shared_future & operator=(const shared_future& rhs) = delete; Versus shared_future(); ~shared_future(); // copy support shared_future(shared_future const& other); shared_future& operator=(shared_future const& other); ===== template<class> class packaged_task; // undefined template<class R, class... ArgTypes> class packaged_task<R(ArgTypes...)> { public: typedef R result_type; versus template<typename R> class packaged_task { HTH for the review, Vicente

1 0