July 2005 - Boost - lists.preview.boost.org

[parameter] missing link in main page and libraries.htm?
by Joaquín Mª López Muñoz 03 Aug '05

03 Aug '05

Can't find links to Boost.Parameter docs from the main page or libraries.htm. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 15

mailing list delays
by David Abrahams 03 Aug '05

03 Aug '05

The problem should be fixed now. Let's hear it for the OSL guys! From: Rob Henderson <robh(a)cs.indiana.edu> Date: July 26, 2005 8:50:35 AM MDT To: Jeff Squyres <jsquyres(a)osl.iu.edu> Cc: OSL Sysadmin <osl-sysadmin(a)osl.iu.edu>, Bruce Shei <shei(a)cs.indiana.edu> Subject: Re: boost mailing lists I wanted to let you know that I think I've figured out what is going on with the recent slowness with email to the mailman lists that was reported. The email address xxx@xxxx that is on the boost list appears to have some kind of anti-spam tarpit set up that is catching milliways. Email to this address is handled by mail.tapeinternational.no and it you telnet to port 25 on this host from milliways you will see that it is (I assume) deliberately slow. During the initial '220' response, it is sending characters at a rate of about one character per 30 seconds. This keeps the connection from milliways moving along at a rate sufficient to keep it from timing out but slow enough that delivery is taking hours. If you telnet to port 25 from any other CS/OSL host the response is very fast so it is clearly set up to catch milliways. I don't know why they have done this, but I'd say the options are to either remove that user from the list or contact them and try to get them to stop this. Please let me know if there is anything else I can do related to this issue. We have disabled delivery to the offending email address and notified its owner. -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 3

[1.33.0] Final release schedule
by Douglas Gregor 03 Aug '05

03 Aug '05

The release is starting to shape up, and here is our final release schedule. We'll stick to it unless something goes horribly wrong. Code freeze - 11pm EST on Sunday, July 24 Total freeze (including documentation) - 11pm EST on Wednesday, July 27 Final release - Monday, August 1st Doug Gregor 1.33.0 Release Manager

12 30

iterators::function_output_iterator is missing in boost_1_32_0
by Oleg Abrosimov 03 Aug '05

03 Aug '05

Hello boosters! I've just found that function_output_iterator, mentioned in boost_1_32_0/libs/iterator/doc/function_output_iterator.html is missing in the boost or boost/iterator directories both in my own copy and in sf.net CVS. Neither me nor my compiler could found it. Was it deprecated? or removed accidentally? Best, Oleg Abrosimov

2 2

singleton design plan
by Jason Hise 03 Aug '05

03 Aug '05

This message is an in depth description of my current design plan for a new singleton library, which I hope to complete and schedule for review by boost in the coming year. I would appreciate any comments, questions, or suggestions regarding this plan before I begin work on the code. Specifically, I would like to know if there are any important issues that this design fails to address, or difficulties with the interface that would turn away potential users. (My old singleton library, which was not accepted by boost, is available at http://tinyurl.com/6qvrd. It was rejected primarily because it failed to adequately address concerns related to multi threading and dlls.) Thus far, my high level design plan looks like this: The creator_policy defines fundamental pointer, const_pointer, and reference types. These hold references to a creator policy instance which maintains the singleton internally, so that the pointer types can always see and access the state of the single instance. This way, pointers to the singleton instance are not invalidated when the state of the singleton changes. The creator_policy defines create, replace, and destroy methods, as well as methods to generate instances of the various pointer types. Create only creates the instance if it does not already exist, destroy only destroys the instance if it does exist, and replace makes sure any existing instance is destroyed before attempting creation. Thus far, I hope to support the following creators: -------------------------------------------------------------------------------- in_place_creator creates/destroys inside an aligned_storage POD interface: create ( [ctor params] ); replace ( [ctor params] ); destroy ( ); pros: no memory allocation/deallocation ever required constructor params can be easily specified cons: automatic creation, when it occurs, always uses the default constructor singleton cannot be created as a derived type useful for simple, user defined singleton classes -------------------------------------------------------------------------------- source_sink_creator owns fixed source and sink functors, specified with template parameters interface: create ( ); replace ( ); destroy ( ); pros: source can return a derived type automatic creation uses source rather than default construction cons: source and sink cannot be set or changed at runtime constructor arguments cannot be specified by calling code useful for singleton types provided by untouchable code, which may require calling special functions to get pointers to instances -------------------------------------------------------------------------------- dynamic_source_sink_creator owns dynamic source and sink functors interface: create ( [source[, sink]] ); replace ( [source[, sink]] ); destroy ( [source[, sink]] ); pros: source can return a derived type automatic creation uses source rather than default construction source and sink can optionally be changed at run time source and sink can change functor types when they are set (example: from function pointer to lambda expression) cons: specifying constructor parameters to pass is non-trivial dynamic memory allocation and virtual functions must be used to store the functors in order to allow for different functor types at runtime, thus creation is more expensive and can potentially fail useful for a singleton which needs to take the forms of unspecified derived types and is frequently destroyed and created via some type of factory -------------------------------------------------------------------------------- The lifetime_policy owns and wraps the creator policy, and provides pointer and reference types which wrap those belonging to the creator. It also provides functions to generate instances of the various pointer types, and provides a function to access the creator_policy instance. The unmanaged lifetime simply typedefs the underlying pointer and reference types, and thus results in no overhead. The longevity_lifetime and lifo_lifetime behave similarly, but handle scheduling of automated destruction when any of the pointer generation methods are called. The dependency_lifetime will wrap the internal pointer types to perform reference counting (the reference count itself will be stored in the lifetime_policy instance). The timeout_lifetime will manage a separate thread that releases the instance when it finishes counting down. It will also wrap the internal pointer types to reset the timer when a pointer is dereferenced, and reset and lock the timer while any references exist. The threading_policy owns and serializes access to the lifetime_policy. It also has a function to get access to the lifetime_policy instance, and provides pointer, const_pointer, and reference types which wrap and forward to the lifetime's corresponding types. For the single_threaded policy, these pointer types are simply typedefs of the lifetime's pointer types, resulting in no overhead, and the function through which the lifetime_policy instance is accessed just returns a raw pointer to it. For the multi_threaded policy, pointer types perform locking before forwarding to lifetime pointer types, and the reference type acts as a lock throughout it's existence. The mutex is stored inside the threading_policy instance. The function which returns a pointer to the lifetime_policy instance returns a smart pointer which serializes access. A storage_policy determines how instances of the threading_policy are stored (and because these instances contain instances of the other policies, this indirectly controls how all of the policy instances are stored). static_storage stores policy instances directly as global variables, which is fine for singletons that are not required to have a specific lifetime with regard to other singletons. These global variables will be set up in such a way that it will be guaranteed that any automatic destruction takes place before the policy bundle is destroyed. group_storage allows multiple singletons to have their policies stored in a master group. No policies in this group are destroyed until all automated destruction that will be performed by any members of the group has completed. This way, if destructors of some of the singletons in this group trigger re-creation of other singletons in the same group, the policies needed to recreate the singletons are guaranteed to still exist. dll_storage requires linking with singleton.dll, and stores instances in a special exported manager singleton to ensure unique singleton instances across dll boundaries. All policy instances of this type are guaranteed to be destroyed only after all automated destruction has taken place. A singleton class exists, which takes a singleton type and a name tag as template parameters. The name will have a default type called 'unnamed'. This name parameter enables using multiple singleton instances of the same type. Policies are traits of the name specified, so using the default name 'unnamed' results in using the default policies. Policies can be specified by declaring a name as an undefined struct, and then specializing the desired policy traits for that name. The singleton class contains three pointer types, which wrap those of the threading policy. These are strong_pointer, lazy_pointer, and weak_pointer. strong_pointer attempts automatic creation of the singleton instance if it does not exist when the pointer is first created, and also attempts automatic creation if needed any time it is dereferenced. lazy_pointer only attempts automatic creation when dereferenced, and weak_pointer will never create the instance automatically. For the lifo_lifetime, a strong_pointer can be used to specify a dependency of some singleton B on some singleton A by having B own a strong_pointer to A. This will ensure that A is created before B and destroyed after B. Const versions of these three pointer types will also exist. Creation, destruction, and non-const member functions will not be allowed to be called through these const pointer types. A single reference type will exist which will be the result of dereferencing any pointer type via the unary * operator. const_pointers return const qualified references. Pointers only perform temporary locking (if the threading policy supports locking) when a member function is called via the -> operator or when a create or destroy operation is invoked. References lock the singleton throughout their entire lifetime, and thus can be used to make a series of operations on the singleton instance atomic. A reference provides an implicit conversion to a raw reference of the singleton's type (which comes back const if the reference is const). Create and destroy can only be called on non-const references. Typical code will access a singleton instance by creating one of the above pointer types and calling member functions through it via the -> operator. Ex: singleton < MyType, SomeName >::lazy_pointer ptr; ptr->DoSomething ( ); -------------------------------------------------------------------------------- I plan to sneak an improved version of the null developed by Scott Meyers in with this code in a header called boost/null.hpp, and use it in the singleton's implementation. It will be defined as follows: namespace boost { const class { private: void operator & ( ) const; public: #ifndef BOOST_NO_MEMBER_TEMPLATES // provide conversion to any pointer type template < typename Class, typename Type > operator Type Class::* ( ) const { return 0; } template < typename Type > operator Type * ( ) const { return 0; } #else //provide conversion to int if member templates are not supported operator int ( ) const { return 0; } #endif//BOOST_NO_MEMBER_TEMPLATES } null; } #undef NULL #define NULL (::boost::null) -------------------------------------------------------------------------------- Any and all comments or suggestions on this plan are welcomed. Potential problems are much easier to address at design time than after the code is written. -Jason

8 20

[1.33.0] Partial thaw on branch for fixing the remaining failures
by Doug Gregor 02 Aug '05

02 Aug '05

The RC_1_33_0 branch is partially thawed so that we can fix the remaining failures for release. I've started the regression notifications again, this time on the release branch: when no more failures show up, we release. Library authors: for any failures that you will not fix, mark them as expected failures on the branch. If you believe there is a configuration problem on one of the test machines, write to the list to say what you think is going on and we'll try to get it fixed. The list of issues we need to fix before we can release is here: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/ developer/issues.html Doug

8 15

Boost regression notification (2005-07-31)
by Douglas Gregor 01 Aug '05

01 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-07-31T16:16:22Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 31 failures in 1 library: serialization (31) |serialization| test_class_info_load_text_warchive_dll: vc-6_5 test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: vc-6_5 vc-6_5-stlport vc-7_0 test_demo_fast_archive_dll: vc-6_5 test_demo_pimpl_dll: vc-6_5 vc-7_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-9_0 test_demo_shared_ptr_dll: vc-6_5 vc-7_0 test_map_binary_archive_dll: vc-6_5 vc-7_0 test_map_text_archive_dll: vc-6_5 vc-7_0 test_map_text_warchive_dll: vc-6_5 vc-7_0 test_mult_archive_types_dll: vc-6_5 test_non_intrusive_binary_archive: vc-8_0 test_shared_ptr_132_xml_archive_dll: intel-win32-8_1

4 3

[Unicode] Some code for y'all
by Erik Wien 31 Jul '05

31 Jul '05

Hi. I finally got a few days off this weekend, so I used them to prepare a version of the Unicode library I have written so you guys can take a look at it. This is unfortunately a snapshot of the state of things a good while back, but it's the only somewhat stable version I could find in the hurry. The basic design hasn't changed much though, so it should work just fine for getting an idea of how things work. A download of the complete library, along with a *short* (and very high-level) description to help you along can be found at the site http://unicode.irritert.net. Sorry I couldn't provide you with any in-depth documentation or stuff like that right now, but you should be able to figure it out if you really want to. ;) Anyway, Feel free to comment on anything that might spring to mind. I'll try to check back now and again to answer any questions. - Erik

1 0

Re: [boost] [Serialization] Boost regression notification (2005-07-31)
by JOAQUIN LOPEZ MU?Z 31 Jul '05

31 Jul '05

----- Mensaje original ----- De: Douglas Gregor <doug.gregor(a)gmail.com> Fecha: Domingo, Julio 31, 2005 10:06 pm Asunto: Re: [boost] [Serialization] Boost regression notification (2005-07-31) > > On Jul 31, 2005, at 12:00 PM, Douglas Gregor wrote: > > 31 failures in 1 library: > > serialization (31) [...] > > I've gone through and marked up all of these, except this one > strange > regression: > > http://tinyurl.com/ajprh > > Looking at the output of the test, I don't even seeing an error. > To > make things more interesting, the other vc-8_0 tester isn't having > any > problem. Ideas, anyone? > This looks pretty much like some spurious errors I've been observing in Boost.MultiIndex tests for this same platform: no error indication or anything. The fun part is that these errors only show every so often and then disappear, so it'll probably vanish away on the next regression cycle. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo PS (OT): Excuse my insistence, but a post of mine about an (IMHO) outdated piece of info in the getting started page have received no response: http://lists.boost.org/boost/2005/07/31129.php I can't change the thing myself, I don't have CVS access during these days. Thank you, J

1 0

CVS Locked?
by David A. Greene 31 Jul '05

31 Jul '05

The threads library seems to be iniaccessible via CVS: cvs update: [20:11:39] waiting for agurtovoy's lock in /cvsroot/boost/boost/libs/thread This has been going on for about an hour now... -Dave

1 0