- Boost - lists.boost.org

dynamic_cast with WeakPtr?
by Sören Freudiger 24 Nov '08

24 Nov '08

Hi @all Maybe you can help me. I tried to use weak_ptr for breaking circular references, but I found out that this pointers can't handle derived classes. But in my classes I have some neighbor relations that I want to tore with shared_ptr: class Base { public: boost::shared_ptr<Base> neigh; }; class Derived : public Base { }; int main() { { boost::shared_ptr<Base> a(new Base); boost::shared_ptr<Derived> d(new Derived) a.neigh = d; d.neigh = a; } //both objects are in memory because of circular references, but weak pointer doesn't work, //becaus eit seems to be unable handling derived classes... and there's no dynamic cast } How do you solve problems like that with boost pointers avoiding circular references? Best reagrds, SirAnn

1 0

[threadpool] draft n2276 - interrupting tasks
by k-oli＠gmx.de 24 Nov '08

24 Nov '08

Hello, the draft specifies that the threapool::submit() function returns a future object in order to retrieve the result of the submited task. What about task cancelation/interruption? Instead returning a future the pool could return a task< R > object which contains a future< R > (access over R task< R >::get()) and interruption routines. boost.threadpool in the boost vault implements somthing like: task< R > threadpool::submit(...); template< typename R > class task { ... // interrupt task and return immediatly void interrupt(); // interrupt task and wait till it's finished void interrupt_and_wait(); // interrupt task and wait a certain time till it's finished or timeout template< typename TimeDuration > void interrupt_and_wait( TimeDuration const& td); // interrupt task and wait to a specific system time till it's finished or timeout void interrupt_and_wait( system_time const& st); bool interrupt_requested(); R get() { return impl_fut_->get(); } bool ready() const { return impl_fut_->ready(); } bool has_value() const; bool has_exception() const; }; Following Herb Sutters sugestions the submited task must be cooperative (contain interruption_point). What do you think? Should/Could it be added to the draft? regards, Oliver { return impl_fut_->has_exception(); }

2 1

[Chrono] Proposed library now feature complete
by Beman Dawes 24 Nov '08

24 Nov '08

The Chrono library in the sandbox is now more-or-less feature complete. In addition to the C++0x features, timers have been added to replace the old Boost.Timer library which will become deprecated. The feature list includes: * The C++0x Standard Library's time utilities, including: o Class template duration o Class template time_point o Clocks: + |system_clock| + |monotonic_clock| + |high_resolution_clock| * Class template |timer|, with typedefs: o |system_timer| o |monotonic_timer| o |high_resolution_timer| * Process clocks and timers: o |process_clock|, capturing real, user-CPU, and system-CPU times. o |process_timer|, capturing elapsed real, user-CPU, and system-CPU times. o |run_timer|, convenient reporting of |process_timer| results. * The C++0x Standard Library's compile-time rational arithmetic. See http://svn.boost.org/svn/boost/sandbox/chrono The implementation is now working and lightly tested on Windows with VC++ 9.0 SP1 and Intel ia32 11.0 compilers, and on Ubuntu Linux with GCC 4.2.4 compiler. There is a bit more documentation, but it is still needs much work. Comments are welcome. --Beman

6 11

Re: [boost] [MPL] new run-time algorithm: for all
by thijs＠sitmo.com 23 Nov '08

23 Nov '08

---- Oorspronkelijk bericht ---- Van: Larry Evans <cppljevans(a)suddenlink.net> Verzonden: 23 Nov 2008 18:33 +00:00 Aan: <boost(a)lists.boost.org> Onderwerp: Re: [boost][MPL] new run-time algorithm: for_all On 11/23/08 11:43, George van Venrooij wrote: > Larry Evans wrote: > >> Judging from the "what is it?" on that tinyurl, it is the cross product >> of the mplbook's exercise 7-8 mentioned in my previous post. > > It indeed has similar behavior when feeding it 2 sequences as the cross > product, or to be more precise, an outer product (as you mentioned > earlier) since both sequences need not have the same length. > > Looking at Wikipedia's definition: > http://en.wikipedia.org/wiki/Outer_product then my algorithm produces > the outer product when called with 2 sequences. When called with 3 > sequences, it generates some kind of 3-way outer product that I am not > able to find a good name or definition for. Perhaps Tensor product? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[asio] Multithreaded UDP server
by Miroslav Beranič ml. 23 Nov '08

23 Nov '08

Hi, would it be possible to post multithreaded UDP server example? Some pointers on internet or just some tips how to build one? Best regards, -- Miroslav Beranič ml.

3 3

Re: [boost] Breaking existing libraries
by Dave Handley 23 Nov '08

23 Nov '08

I'll comment on a few parts of the thread here: David Abrahams wrote: > Of course backward compatibility is desirable, but maintaining it > rigidly prevents forward progress. Judicious breakage does not > necessarily mean that the library is "experimental" in any meaningful > way. Nobody really has a problem with the stability of shared_ptr, for > example, and yet look at its list of breaking changes over the years: > http://www.boost.org/doc/libs/1_37_0/libs/smart_ptr/compatibility.htm Breaking changes are certainly sometimes required, and this type of page in the boost docs is an ideal example of what *should* be done when breaking changes are needed. Most of these changes are additions rather than changes, they are well documented, and they actually make sense. The changes in boost.range (based on my review of the changes last night - so I might be wrong) are that they are breaking changes, they are not documented at all, and that they don't really make sense. It is not possible to detect a singular range in the current version of the library (at least in release code), despite an issingular function existing. This basically means that a default constructed range cannot be detected to have been default constructed. This in turn makes it hard to use a range and a container in the same template code - which is the source of the problem here. Being able to use a range just like a container and vice versa is one of the strongest use cases for range IMHO. David Abrahams wrote: > So what happens to the iterators library when it's time for the rewrite > I've been planning? I intend, as much as possible, to maintain > compatibility with the old interfaces, of course. Is that still a > "stable" library? Simple. Because the iterators library is presumably in the stable "core" part of the boost library, the new version gets produced, internally tested, and prepared for release, including detailed documentation of any breaking changes. The tests include testing it with any dependencies in core and general boost (to continue with my old, perhaps poor, naming standard). Once testing is complete, it goes out in the next boost core beta for an extended beta test; at the end of which, if accepted, it goes into the next release of boost. I don't think anyone would want to completely disallow breaking changes, we are all used to them, so long as they are documented and released well. The main idea of having 2 separate release cycles is simply that new code can come into boost very quickly (which is desirable), and also come into boost in a way that companies can pick it up much faster. But at the same time, old stable code has a much more cautious review timescale, in keeping with the fact that much of this code is used by huge numbers of C++ developers around the world. When I've been a library writer in the past, I take complaints about breaking changes to my code as a sort of compliment. It means people use my code, and like it enough to complain when it changes in an unsuspected way. David Abrahams wrote: > Which versions of the "stable" library would the "new" libraries be > required to work with? This is a pretty simple one to answer. The latest version of the core library. The way the release cycle would work is simply that the fast changing library (which new code would go into) would update as regularly as boost does at present. When it was decided to up-rev the core library, both core and general would up-rev together to maintain compatibility; then the general library (and any new libraries) would be required to work with the new core. I've used this type of development methodology myself in the past and it is very successful IMHO. Dave

3 2

How to design boost package web page?
by Peng Yu 23 Nov '08

23 Nov '08

Hi, I want to submit a package as well as the documentation. The existing web pages for all the packages look similar in style. I'm wondering if there are some utilities to make the web page appearance consistent. Thanks, Peng

4 6

Re: [boost] [Boost-users] Maintenace Guidelines wiki page
by vicente.botet 23 Nov '08

23 Nov '08

----- Original Message ----- From: "Robert Ramey" <ramey(a)rrsd.com> To: <boost-users(a)lists.boost.org> Cc: <boost(a)lists.boost.org> Sent: Sunday, November 23, 2008 7:39 AM Subject: Re: [Boost-users] [boost] Maintenace Guidelines wiki page >>> My view is that it is good practice to consider >>> breaking an interface should be considered a bug. > >> Does your view accepts that exceptionally a well documented breaking >> change with a reasoable deprecated period could not be considered a >> bug? > > Well, if its intentional, it's by definition not a bug - its a feature. Right. <snip> > Actually, I'm thinking the the a library author face entirely > different problems. Do you mean the user and the author of course. > a library author want's to cover as much ground (compilers, > user errors, use cases, etc) as possible. So suggestions like > don't break an interface, I think that this guideline is implicit on the other guidelines, but I could add it explicitly. > use things like boost/config, How boost/config helps on maintenace? > Use Boost.Concepts to help your find mistakes in > library usage, etc. are to him. Could you detail how Concepts helps on mantenance? > a user want's to get done with as little as trouble and suprises > as possible. So suggestions like avoiding "using" are helpful. > For users, I'm thinking of suggestions similar to "Effective > C++, oriented to boost. Any writing "Effective Boost"? Could you be more precise? Best, Vicente

1 0

Severe shared_ptr limitation WRT dynamically loaded libraries
by J.D. Herron 23 Nov '08

23 Nov '08

Hello, I would like to raise what I think is a serious limitation of the boost shared_ptr implementation. I have thought a bit about solutions but don't have anything concrete to offer as yet but would be interested in seeing the thoughts of the boost library developers. I work in an architecture that uses dynamically loaded factory patterns quite a lot and factories can also be dynamically unloaded. This also makes heavy use of shared_ptrs to make memory management a breeze. The basic problem is that the boost implementation of the sp_counted_base relies on virtual functions to deallocate which are implemented by various templates in the detail namespace. If I have a dynamically loaded factory interface that returns a shared_ptr, the factory implementation causes the templates to generate the virtual function code within the factory library. Everything is fine as long as the library stays loaded but if the library is unloaded, any client code holding the shared pointer to an object generated by that factory now has an invalid virtual function table for the sp_counted_base it holds. So when the reference count goes to zero an access violation is generated. It is stated that the shared_ptr is to be as close to a raw pointer as possible which I very much agree with. However this behavior really sets it apart from raw pointers as it is certainly possible for a factory to return a dynamically allocated raw pointer to client code, unload the factory library and have the client code deallocate the raw pointer after the unload with no problem. To illustrate the problem in a windows environment, here is a simple example. Lets say I have a simple factory interface like so: class Factory { public: virtual shared_ptr<int> GetIntSharedPtr() = 0; virtual int * GetIntRawPtr() = 0; }; I implement a factory DLL to provide one of these factories that has an exported function GetFactory() like so: /// implementation of the Factory interface class TestFactory : public Factory { public: virtual shared_ptr<int> GetIntSharedPtr() { return shared_ptr<int>( new int(5) ); } virtual int * GetIntRawPtr() { return new int(0); } }; /// Library instance of the factory implementation TestFactory g_Factory; /// Exported function to return the factory for this library _declspec(dllexport) extern "C" Factory & GetFactory() { return g_Factory; } This is compiled into a library named "TestFactory.dll". Now I create a simple command line application that does the following: /// Typedefinition for for the GetFactory exported function typedef Factory & (_cdecl * GetFactory)(); int main() { // dynamically load the TestFactory library HMODULE hFactoryDll = ::LoadLibrary( "TestFactory.dll" ); // get the GetFactory() interface from the loaded library GetFactory pfnGetFactory = ::GetProcAddress( hFactoryDll, "GetFactory" ); // Acquire the factory object Factory & factory = pfnGetFactory(); // Call the factory interfaces to get dynamically allocated integers int * pRawInt = factory.GetIntRawPtr(); shared_ptr<int> spInt = factory.GetIntSharedPtr(); // everything is fine so far, now unload the factory library ::FreeLibrary( hFactoryDll ); // deallocating the raw pointer recieved from the factory works just fine delete pRawInt; // THIS WORKS! // However due to the reasons outlined in this post, releasing the shared_ptr causes // an access violation spInt.reset() // THIS CRASHES! } I would like to see a solution that would make this simple example and very reasonable use case work for shared_ptrs. Note that the argument that the client code cannot know what the factory is actually returning requires that the factory library be in memory so that appropriate subclass destructors can be called does not hold water here. This example uses simple integers. The root of the issue is not one of the virtual function table for the wrapped type getting corruped on library unload but rather the virtual function table for a member of the shared_ptr itself. I will put some thought toward this but am interested to see what boost developers might be able to come up with as well. J.D.

6 11

[xpressive] or [spirit] Searching for multiple patterns at once.
by Raindog 23 Nov '08

23 Nov '08

Is there anything in xpressive or spirit that supports aho-corasick dictionary matching or at least something efficient? (http://en.wikipedia.org/wiki/Aho-Corasick_algorithm)

3 5