November 2008 - Boost - lists.boost.org

[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

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: Saturday, November 22, 2008 9:19 PM Subject: Re: [Boost-users] Maintenace Guidelines wiki page > > This is a laudable effort, Thanks. > but my guess is that it's doomed to failure. > > My own take on this was posted in > http://lists.boost.org/Archives/boost/2008/07/139893.php I remember your participation and your point of view on this long thread. > So far, no one else has endorsed such a pledge. Indeed, the responses > suggested that > the breaking interfaces was a normal, acceptable and unavoidable practice. I don't think this is the case. Breaking changes should be exceptional and taken because there is no better solution. I think that most of the Boost authors respect that. As every rule this one has its exceptions, there has been some library evolution that have break user and even Boost library code. This is regretable and we need to setup whatever is needed to make this exceptions more than exceptional. I really think that *we can* achieve this goal. > I think that differing points of view reflect different backgrounds of > different > developers. In my particular case, I work on relatively short term projects > under huge pressure to produce results. I absolutely depend upon boost > and other libraries (e.g. MFC) to get the job done. If a library changes, > then > I have to go back and re-visit something that was already considered > "finished". > The creates a big problem for me. I understand your concern. > In other environments, programmers work on huge projects which might > go on for years. In this constext, this is not such a huge problem as > things > are constantly evolving anyway. So continuing to break things and > having to fix them is a normal and in any event unavoidable. Even in this case breaking code is a inacceptable because there is a lot of code to modify and test. So if we want that the Boost library is used widely we need to *try* to provide backward compatible versions, and warm when this is no more possible. In my personal work, we use to do provide some scripts that either they are able to automaticaly do the complete transformation or they warm when automatic transformation is not possible. Usualy this let 20% of the code to be transformed manually. > Your "Maintainence Guidlines" presume a consensus > about what should be acceptable practice where no > such consensus actually exists. Which acceptable practice are you referring to for which there is no consensus? > As a practical matter what do I do. > > I need a facility. My experience would suggest that such > a facility might be already existing in some sort of library. > According to the situation, I will review a couple of candidates > and select one to try. It might be a commercial product or > it might be something like boost. Then I'll try to introduce > the library to my code. This has to be pretty easy or I'll discard it. > It needs to have good documentation and it needs to "just work" > I then copy the library in to my project. I try to avoid making > a big commitment to a library - or anyone else's code so > that I can drop one library if I have to in the future. > > With the serialization library, it has to include the latest > boost libraries that it uses. If I find that the library > author can't maintain a stable and relieable product, > I design that library out of the serialization library. This > has happened several times. Given the fact that > the serialization library is not my full time job > (though at times it seems that way), I don't feel > there is any real alternative. I hope that you are not proposing that to the end users. Are you? Please could you participate in the elaboration of this guidelines, your opinion is very important to the Boost community. Thanks, Vicente

2 2

[interprocess] A little gentle criticism
by Tom Brinkman 22 Nov '08

22 Nov '08

>> Please Boost developers, C++ programmers deserve not to deal with C-style strings anymore. With all respect, this is not a view that I share. I'm a c++ developer who prefers C-style strings. Most of the coding standards on C++ projects that I have been on over the last 10 years or so have discouraged using C++ string wrappers. This hasn't changed recently from what I can see. I rarely if ever use std::string or std::basic_string. Many C++ developers still prefer C style string handeling. Tom

2 1

Maintenace Guidelines wiki page
by vicente.botet 22 Nov '08

22 Nov '08

Hi, I have started the Maintenace Guidelines wiki page. You can access it directly https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines or via https://svn.boost.org/trac/boost/wiki Guidelines * Maintenance Guidelines There page need to be completed and surely reworked but this is an starting point. Please be free to improve the page directly or post your comments or suggestions to this list. Hopping this goes on the right direction, Vicente

1 0

[quickbook] Problem integrating doxygen style examples into quickbook
by Joachim Faulhaber 22 Nov '08

22 Nov '08

Hello, I successfully installed the quickbook toolchain and I am joyfully using the tool to write docs for my library. (Thank you, to the authors:-) One of the things I like is the doxygen integration. But I have encountered a problem here: I guess my problem is a typical one that other authors might share. I already have example files that are using doxygen style documentation. The documenting texts are in the example file so it's easy to maintain: ----------- boost_party.cpp --------------------- /** Example boost_party.cpp \file boost_party.cpp Text documenting this example using <em>doxygen</em> style formatting features. ... Finally there is an include command that allows to insert the example code to this introductory text: \include boost_party/boost_party.cpp */ #include <boost/.../some.hpp> class to_be_documented { ... } ... //more code -------------------------------------------------- Now I would like to recycle text and code for quickbook such that (1) Text and code can stay in the example file. (2) Text and code don't have to be replicated some place else (e.g. in example.qbk). (3) There is only a minimal additional formatting noise, so the example file itself stays readable. What I've learned so far is to bring the code (or snipplet parts of it) into quickbook: ... //[example_boost_party #include <boost/.../some.hpp> class to_be_documented { ... } ... //more code //] But how to handle the text part? Cheers Joachim

1 0