- Boost - lists.preview.boost.org

[regex] Matching space - help needed
by Roman Yakovenko 27 Nov '08

27 Nov '08

Hello. I have some strange problem and have no idea how to solve it or where to look father. I have two regular expressions: (\s) ( ) //<== this one contains single space between brackets. I use match algorithm and as a argument I pass string with single space. In the product, the first regular expression (\s) doesn't work, while the second does. I created stand-alone tester - both expressions work as expected. Using proc file system, I compared environment variables, specifically LANG is set to "en_US.UTF-8". Both executables load same Boost.Regex shared library. I am using GCC 3.3.3, on RedHat. The boost version is 1.34. Searching the web didn't help too. Any help is appreciated. Thank you. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/

3 8

boost::signals2 performance
by Hansi 27 Nov '08

27 Nov '08

I have made now a lot of tests with the new signals2 library. The only thing because I don't want to use it now, is because it is really slow... I have made now performance tests with the dummy_mutex which is included. I have found out the about 50% of the time that it takes to call 10000000 is inside in slot_call_iterator---->lock_next_callable function. Here the follwing lines takes the 50% of the executing time: lock_type lock(**iter); tracked_ptrs = (*iter)->nolock_grab_tracked_objects(); I hope that one has an idea how it can be made it faster... Best regards Hansjörg

2 2

[interthreads] Library under development
by vicente.botet 26 Nov '08

26 Nov '08

Hi, If the Boost community is interested in the InterThreads library I could work on to complete for submission. InterThreads ------------------- :Author: Vicente J. Botet Escribá :Download: Boost Vault: <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=intert…> Boost Sandbox: https://svn.boost.org/svn/boost/sandbox/interthreads Html doc included only on the Vault :Description: Boost.InterThreads extends Boost.Threads adding some features: * thread decorator: thread_decorator allows to define setup/cleanup functions which will be called only once by thread: setup before the thread function and cleanup at thread exit. * thread specific shared pointer: this is an extension of the thread_specific_ptr providing access to this thread specific context from other threads. As it is shared the stored pointer is a shared_ptr instead of a raw one. * thread keep alive mechanism: this mechanism allows to detect threads that do not prove that they are alive by calling to the keep_alive_point regularly. When a thread is declared dead a user provided function is called, which by default will abort the program. * thread tuple: defines a thread groupe where the number of threads is know statically and the threads are created at construction time. * set_once: a synchonizer that allows to set a variable only once, notifying to the variable value to whatever is waiting for that. * thread_tuple_once: an extension of the boost::thread_tuple which allows to join the thread finishing the first, using for that the set_once synchronizer. * thread_group_once: an extension of the boost::thread_group which allows to join the thread finishing the first, using for that the set_once synchronizer. (thread_decorator and thread_specific_shared_ptr) are based on the original implementation of threadalert written by Roland Schwarz. Best regards, Vicente

1 0

[preprocessor] half-open or closed ranges?
by Eric Niebler 26 Nov '08

26 Nov '08

I've noticed an inconsistency with how the preprocessor library handles integer ranges. Consider this: #define M0(Z,N,DATA) N BOOST_PP_REPEAT_FROM_TO(1,3,M0,~) This treats the range 1,3 as half-open. It generates the sequence "1 2". But consider this: #define BOOST_PP_LOCAL_MACRO(N) N #define BOOST_PP_LOCAL_LIMITS (1,3) #include BOOST_PP_LOCAL_ITERATE() This treats the range 1,3 as closed. It generates the sequence "1 2 3". Why the difference? -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

[Circular Buffer] Partial thread-safety
by Lasse Kärkkäinen 26 Nov '08

26 Nov '08

It would be very helpful if this container provided lock-free thread-safe implementation of concurrent reads and writes by two threads (producer-consumer), as such function is often needed where ring buffers are used. A prime example of that being receiving audio from a callback (possibly a signal handler), where the callback must not be blocked in any circumstances (meaning that it cannot wait for a lock). As this is a rather common use case, the realtime audio processing framework JACK actually implements such lock-free ring buffer: http://jackit.sourceforge.net/cgi-bin/lxr/http/source/libjack/ringbuffer.c Is there any reason why Boost.circular_buffer should not also implement this kind of thread-safety?

5 5

accepted libraries for boost
by Hansi 26 Nov '08

26 Nov '08

Hello, I have one question regarding to the accepted libraries for boost. At the moment are a lot of libraries accepted which don't get the way to the released version of boost... is it not possible at least that there is one and only one place where the last version of the library is saved? At the moment it is really hard to find this last version.. Best regards Hansjörg

1 0

[intrusive] constant/non-constant time size lists
by Kevin Sopp 26 Nov '08

26 Nov '08

Hi Ion, have you thought about instantiating two different interfaces for constant and non-constant time size() lists respectively? Instead of instantiating one interface that has differing complexity guarantees and is restricted by the lowest common denominator of what is possible with constant-time size(). Non-constant time size() lists would allow to implement higher level functionality as static member functions or as non-member functions, and some functionality like splicing needs no additional list& parameter. If I had such a list I could make my functions work on iterator ranges without the need to pass the list object along. So what I need is access to the nodes so that I can call circular_list_algorithms directly on these. I don't see an easy way to achieve that goal right now. As far as I can tell I need to use the undocumented list_iterator::pointed_node() function - which is okay, I'm only hesitant because it is undocumented. I'm willing to change my code if that interface ever changes though. Kevin

3 4

[UUID] seed_rng on Windows
by Kaj Björklund 26 Nov '08

26 Nov '08

Hi all, It would be nice if seed_rng used CryptGenRandom (or something similar) on Windows instead of trying to open /dev/urandom. The patch for seed_rng.hpp at: http://www.dynaroad.com/win.diff tries to use CryptGenRandom when BOOST_WINDOWS and _WINDOWS_ (i.e. windows.h has been included before uuid.hpp) are defined. This seems to work on Windows XP SP2 and Visual Studio 2005. Cheers, -kaj

2 1

Support for std::nested_exception in Boost.Exception?
by Chris Newbold 26 Nov '08

26 Nov '08

Are there any plans (or any desire) for supporting the nested exception functionality (N2559) now in the C++0x draft in the Boost.Exception library? -Chris

4 7

Using boost::filesystem with TCHAR
by Rob Caldecott 25 Nov '08

25 Nov '08

I wish to use the boost::filesystem library with some Windows apps and want to define TCHAR-friendly types. I *think* the following code should do the trick, giving me a boost::filesystem::tpath type, but is there anything I've missed? tpath.hpp #include <boost/filesystem.hpp> namespace boost { namespace filesystem { struct tpath_traits; typedef basic_path<std::basic_string<TCHAR>, tpath_traits> tpath; struct tpath_traits { typedef std::basic_string<TCHAR> internal_string_type; typedef std::basic_string<TCHAR> external_string_type; static external_string_type to_external( const tpath &, const internal_string_type & src ) { return src; } static internal_string_type to_internal( const external_string_type & src ) { return src; } }; } // filesystem } // boost

2 1

Building 'stage' by default
by Vladimir Prus 25 Nov '08

25 Nov '08

We presently have 3 ways of building C++ Boost from top-level directory: - with 'stage' target -- only libraries are installed - with 'install' target -- both libraries and headers are installed - with no explicit target -- everything is built, but nothing installed It seems to me that the first two options are what the majority of users will want, so some of them should be the default. I have a local patch that makes 'stage' the default, and additionally prints the following message: Performing 'stage' build by default: - binaries installed into 'stage/lib' - headers not installed, use the source tree Use the 'install' target for complete installation. This message is printed only if no explicit target is specified -- if user types 'stage' or 'install', it's assumed he knows what he's doing. Anybody has any comments on this change in defaults, or about the wording of the message? Thanks, Volodya -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2

8 8

Boost version meaning
by vicente.botet 25 Nov '08

25 Nov '08

Hi, I would like to know what is the meaning of the 3 numbers on the Boost version X.Y.Z. When X changes, i.e. when we could have a Boost version 2.0.0 Which number means a complete rewriten? Which number means an incompatible evolution? Which number means new functions? Which number means major bugs corrections? Which number means only minor bugs corrections? Is this written somewhere? If we were to version individual Boost libraries which will be the apropiated schema? Should all the libraries follow the same schema? What do you think of? X: complete rewriten or incompatible evolution Y: new functions or major bugs corrections Z: minor bugs corrections Thanks, Vicente

2 3

Strange snippet around operator T()
by Joel Falcou 24 Nov '08

24 Nov '08

I was trying to find some decent way to declare named constants in my code and ended up with the following snippet : struct const_one { typedef int type; const_one() {} template<class T> const_one(T const& ) {} template<class T> operator type() const { static type const v = {1}; return v; } template<class T> operator T() const { static T const v = {1}; return v; } }; static const const_one one_; This allow me to have the following behavior : int k = one_; float e = one_; and have proper transtyping taking place when needed. Turning this into a macro allow to declare a large sample of named constant that auto-transtype them when needed. Now funny thing is that this structure allow me to do stuff like : float k = one_ / ( 1. + three_); Now if I remove the operator type(), I can't. But if i add a printf statement in this one, it is never called. Do someone has a clue about this behavior or am I playing with some undefined behavior ? TIA -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

2 3

Re: [boost] dynamic_cast with WeakPtr?
by Sören Freudiger 24 Nov '08

24 Nov '08

ups, sorry, my fault.. the example seems to work, but I run into that problem because I tried to perform an dynamic_cast on that weak_ptr. How this should be done in this simple example? class Base { public: boost::weak_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; //like that? boost::shared_ptr<Derived> pD2 = boost::shared_dynamic_cast< Derived >( a->neigh.lock()); } } -----Ursprüngliche Nachricht----- Von: Sören Freudiger [mailto:muffmolch@gmx.de] Gesendet: Montag, 24. November 2008 21:03 An: boost(a)lists.boost.org Betreff: dynamic_cast with WeakPtr? 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

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

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