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

[string_algo] cw8.3 problem
by Pavol Droba 15 May '05

15 May '05

Hi, There is a reported problem with string_algo lib and cw8.3 http://tinyurl.com/bk9u2 I don't know what can be the problem. Can anybody with the access to this compiler have a look at it, please? Thank you. Pavol.

2 2

RE: ACT SPAM:[boost] [preprocessor] What syntax to present to the user
by Roman Yakovenko 15 May '05

15 May '05

> -----Original Message----- > From: loic.actarus.joly(a)wanadoo.fr > [mailto:loic.actarus.joly@wanadoo.fr] > Sent: Friday, May 13, 2005 1:22 PM > To: boost(a)lists.boost.org > Subject: ACT SPAM:[boost] [preprocessor] What syntax to > present to the user > > > Hello everybody, > > I'm trying to use the boost preprocessor library to allow the user to > define "rich" enums, for instance enums that cannot be > converted to int, > whose values can be displayed in human readable form on a stream... > > I think I have to use macro to ease the writing of such enums, and I ... There is a better approach. Try to search "smart enums" within boost mailing list archive Roman

1 0

failures-markup
by Pavol Droba 14 May '05

14 May '05

Hi Boosters, I'd like to ask for more caution when modifying explicit-failures-markup.xml file. Somebody has marked vc7 as unusable for string_algo lib, although the workaround is already on the way, and there is just few fixes to be done. I have unmarked this toolset few days ago, but it gets marked again. (Probably by mistake) It slows down my work since I don't have a direct access to this compiler so I must relay on the regression tests. Thanks. Pavol

2 1

[policy_ptr]source, sink policies proposal
by Larry Evans 14 May '05

14 May '05

Currently, policy_ptr: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/pol… constains a conversion policy which determines whether or not to contain an implicit conversion to the raw pointer via the smart_ptr</*polcies typelist*/>::to<Referent> method: operator automatic_conversion_result(void) const; where: typedef typename conversion_policy::result_type automatic_conversion_result; However, since smart_ptr<...>::to<Referent> is derived as: class smart_ptr<P1, P2, P3, P4>::to : public detail::policy_ptr::conversion_policy_ couldn't the automatic conversion operator just be defined (in the case of allow_conversion) or not (in the case of disallow conversion) in the conversion policy itself? In addition, instead of allowing the raw pointer to escape from the "protection" of the smart_ptr via the storage policy's get_impl, why not delegate this decision to a "sink" policy, which decides how the pointee is exposed to outside use? IOW, rename the conversion policy to the sink policy which decides whether 'operator pointer_type()' or 'get_impl' are publicly exposed. This would allow for a "safer" smart pointer. Along the same lines, why not allow a "source" policy which decides the "inputs" (the CTOR args) to the smart pointer. Currently, for smart_ptr<...>::to<Referent>, the only "source", IIUC, is Referent*. (By source, I mean any CTOR arguments that don't include another smart pointer ). This would also allow for a "safer" smart pointer since the sole source could be something like David Abraham's auto_ptr_new: http://lists.boost.org/MailArchives/boost/msg42996.php

2 5

[Formal review] Singleton library
by Pavel Vozenilek 14 May '05

14 May '05

The formal review of Singleton library written by Jason Hise starts today, May 5th, and lasts 10 days. The library is available at http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&di… The singleton documentation can be browsed online at http://www.ezequal.com/chaos/docs/html/singleton/ Singleton is feature rich library: - ensuring single instance of a class and global access point to this instance - with policies specifying: - when the instance gets created (manually, immediatelly, when first used, ...) - how is the instance created (by new, malloc, in static memory, ...) - when the instance gets destroyed (never, by priority, after another singleton, ...) Parametrized singleton called Multiton is provided City::pointer p1("Chicago"); City::pointer p2("Brussels"); will create two different "singletons" of the same type. Another feature is ability to register resources (like shared pointer) who will get destroyed in controlled order, when the application exits. Not yet implemented features are: - MT safety - self-destroying singleton with timeout - bjam compatible tests The library is known to work with several newer compilers, VC7.1 among them. Help with other compilers is welcomed. When submitting reviews, please state explicitly whether or not you believe that the library should be accepted into Boost. For more information on the Boost formal review process, please see http://www.boost.org/more/formal_review_process.htm. /Pavel

18 58

[program_options] Fix for 64 bit platforms
by Markus Schöpflin 14 May '05

14 May '05

Hello, attached patch has just been committed to program_options/src/cmdline.cpp. It fixes the test failures observed on Tru64 for the cmdline_test test and probably applies to all 64 bit platforms. As a side note, there are many other incorrect uses of unsigned in this file which also should replaced by the correct size_type, but currently these uses don't cause a test failure. Markus Index: cmdline.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/program_options/src/cmdline.cpp,v retrieving revision 1.18 diff -u -r1.18 cmdline.cpp --- cmdline.cpp 6 May 2005 07:48:45 -0000 1.18 +++ cmdline.cpp 13 May 2005 11:21:38 -0000 @@ -351,7 +351,7 @@ { string name, adjacent; - unsigned p = tok.find('='); + string::size_type p = tok.find('='); if (p != tok.npos) { name = tok.substr(2, p-2);

2 1

[website] New design is in CVS.
by Rene Rivera 14 May '05

14 May '05

The new design is now in CVS! But before people start saying.. "We don't like it! Why dis you put it in?" ... It was decided that having something now was better than having to wait for another release and have no progress shown on the website. Hence expect the design to continue to evolve after the release. Yell if you do an update, and find any problems. One WARNING, if you update either of the two new pages, index.htm and more/version_history.html, please process them with: tidy --tidy-mark no -i -wrap 78 -m -asxhtml --doctype strict [file] So as to ensure no errors creep in, and to make the formatting consistent. I'm trying to find a place to an instruction to that effect, but I can't readily see a place for it. Anyone have a suggestion where I should document running of tidy? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

4 5

[Boost-bugs] [ boost-Bugs-1201779 ] compiler error on Mac implementation of threads
by SourceForge.net 14 May '05

14 May '05

Bugs item #1201779, was opened at 2005-05-13 21:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1201779&group_… Category: threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mike Glassford (glassfordm) Summary: compiler error on Mac implementation of threads Initial Comment: e-mail: myoula(a)videotron.ca With CW 9.4, Carbon (no Mach-O), and BOOST_HAS_MPTASKS defined I got: Error : illegal use of incomplete struct/union/class 'boost:: function<long, long>' safe.cpp line 50 boost::function<OSStatus, Duration> oWaitOnSemaphore; The error statement is marqued below by --> OSStatus safe_wait_on_semaphore(MPSemaphoreID pSemaphoreID, Duration lDuration) { -->boost::function<OSStatus, Duration> oWaitOnSemaphore; oWaitOnSemaphore = bind(MPWaitOnSemaphore, pSemaphoreID, _1); return(safe_wait(oWaitOnSemaphore, lDuration)); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1201779&group_… ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[range] vc support update
by Jonathan Turkanis 13 May '05

13 May '05

[My email to Thorsten bounced, so I'm posting it here] Thorsten, I finally got around to Boost.Range today. Sorry for the long delay. I've been able to get all the regression tests to pass on VC6, and all the tests to compile on VC7.0. I can't run the tests on the latter platform because of errors in Boost.Test. There are two points which deserve mention: 1. Array support only works for arrays of fundamental types. This should be mentioned in the docs, since it's not apparent from the regression test results. 2. With VC6, the function template arguments to range_end<>::fun() and range_size_<>::fun() were not deduced properly, leading to compiler errors. Since explicitly specifying the arguments caused internal errors, I used a trick from iostreams, and put the static function fun() in a nested class template whose template argument can be explicitly specified without problem; e.g.: template<> struct range_end<std_container_> { template< typename C > struct inner { static BOOST_RANGE_DEDUCED_TYPENAME range_result_iterator<C>::type fun( C& c ) { return c.end(); }; }; }; .... template< typename C > inline BOOST_DEDUCED_TYPENAME range_result_iterator<C>::type end( C& c ) { return range_detail::range_end<range_detail::range<C>::type>:: inner<C>::fun( c ); } This workaround is applied only for VC6. My question is: does this interfere with the extension protocol? If so, I think I can fix it, but only by adding another level of indirection. If you approve, I'll commit these changes. I haven't started working on Borland or GCC 2.9x yet. Jonathan P.S. I ended up not using the collection_traits headers -- the new dispatch mechanism made that unnecessary.

2 5

[1.33] README: Lots of files with no license/copyright
by John Maddock 13 May '05

13 May '05

There are currently quite a few source files showing up with no recognised license or copyright holder information: boost/graph/simple_point.hpp boost/wave/util/flex_string.hpp libs/date_time/example/local_time/local_date_time.cpp libs/date_time/example/local_time/seconds_since_epoch.cpp libs/graph/src/graphviz_digraph_parser.hpp libs/graph/src/graphviz_graph_parser.hpp libs/mpl/book/chapter1/binary.hpp libs/mpl/example/fsm/player2.cpp libs/ptr_container/test/algo_test_data.hpp libs/ptr_container/test/cast.cpp libs/ptr_container/test/concept_check_data.hpp libs/ptr_container/test/convert.cpp libs/ptr_container/test/indirect_vector.cpp libs/ptr_container/test/map_value_iterator.cpp libs/ptr_container/test/null_object.cpp libs/ptr_container/test/ptr_unordered_map.cpp libs/ptr_container/test/ptr_unordered_set.cpp libs/ptr_container/test/sequence_point.cpp libs/ptr_container/test/stack_example.cpp libs/ptr_container/test/tut5.cpp libs/ptr_container/test/vector_size.cpp libs/ptr_container/test/xml_tree_test.cpp libs/python/test/cltree.cpp libs/python/test/tuple.cpp libs/range/test/compat1.cpp libs/regex/performance/time_dynamic_xpressive.cpp libs/test/test/boost_check_equal_str.cpp libs/test/test/config_file_iterator_test.cpp libs/test/test/config_file_test.cpp tools/build/jam_src/filesys.c tools/build/jam_src/hcache.h tools/build/jam_src/subst.c tools/build/v2/test/boostbook/a.hpp tools/build/v2/test/dependency-test/src1/z.h tools/build/v2/test/unused/b.cpp And one file has both, but no date on the copyright: boost/ptr_container/detail/default_deleter.hpp Fixes would be much appreciated, before the release! Thanks, John.

11 26

Re: [ptr_container] memory corruption in ptr_set test
by Caleb Epstein 13 May '05

13 May '05

On 5/12/05, Thorsten Ottosen <nesotto(a)cs.aau.dk> wrote: > I can't easily deduce what the error should be from that file. Unfortunately I > don't have any of the failing compilers. > > Could the problem be related to dynamic cast and not enabling RTTI in the > compiler? No, thats definitely not it. Gcc enables RTTI by default. It looks to me like this call is the problem (for the instantiation of ptr_set_test< ptr_set<Base>, Base, Derived_class >): associative_test_data.hpp:108 i = c.find( *t ); According to valgrind, the memory location pointed to by t was previously deleted. Indeed, I added some debugging output to the Base class ctor and dtor methods, and this is what is happening: Running 1 test case... Base::Base @ 0x1bb45770 Derived_class @ 0x1bb45770 Base::Base @ 0x1bb45c58 Derived_class @ 0x1bb45c58 Base::Base @ 0x1bb46140 Derived_class @ 0x1bb46140 Base::Base @ 0x1bb46628 Derived_class @ 0x1bb46628 Base::~Base @ 0x1bb45c58 Base::~Base @ 0x1bb46140 Base::~Base @ 0x1bb46628 Base::~Base @ 0x1bb45770 Base::Base @ 0x1bb47d90 Derived_class @ 0x1bb47d90 Base::Base @ 0x1bb48798 Derived_class @ 0x1bb48798 Base::Base @ 0x1bb48c80 Derived_class @ 0x1bb48c80 ==15713== Invalid read of size 4 [...] ==15713== Address 0x1BB45770 is 0 bytes inside a block of size 24 free'd ==15713== at 0x1B904CA8: operator delete(void*) (vg_replace_malloc.c:155) ==15713== by 0x8062A4E: Derived_class::~Derived_class() (result_iterator.hpp:59) ==15713== by 0x8063A43: void boost::checked_delete<Base const>(Base const*) (checked_delete.hpp:34) ==15713== by 0x8063A22: void boost::delete_clone<Base>(Base const*) (clone_allocator.hpp:32) ==15713== by 0x8063A0E: void boost::heap_clone_allocator::deallocate_clone<Base>(Base const*) (clone_allocator.hpp:50) ==15713== by 0x80639FA: boost::ptr_container_detail::reversible_ptr_container<boost::ptr_container_detail::set_config<Base, std::set<void*, boost::void_ptr_indirect_fun<std::less<Base>, Base, Base>, std::allocator<void*> > >, boost::heap_clone_allocator>::null_clone_allocator<false>::deallocate_clone(Base const*) (reversible_ptr_container.hpp:112) The address 0x1BB45770 corresponds to the first Base object, which comes from "t = new T" on line 56 of associative_test_data.hpp. This operation seems to be causing it to be deleted: associative_test_data.hpp:66 c3.clear(); > Running 1 test case... > unknown location(0): fatal error in "test_set": std::bad_typeid: Access > violation - no RTTI data! > > ^^^^^^^^^^ > > or is the compiler trying to say that it has seen a null pointer > ("location(0)") ? I assume it is due to the runtime zeroing out memory after it is freed, so the vtable of this object is overwritten. -- Caleb Epstein caleb dot epstein at gmail dot com

3 2

Non-intrusive serialization with VC2003 (7.1)
by Marcin Tustin 13 May '05

13 May '05

I'm trying to use the serialization and archive libraries, and I'm having a bit of trouble getting non-intrusive serializaton to work; I keep getting the error "c:\boost_1_32_0\boost\serialization\access.hpp(106): error C2039: 'serialize' : is not a member of 'D2::Message'". My guess is that for some reason the "long int" hack isn't working properly. I have serialize methods in the boost::seralization namespace like this: namespace boost { namespace serialization { template<class Archive > static void serialize(Archive & ar, const D2::Message& g, const unsigned int version) { //... } } }; Which are textually before any use of the library, as far as I can tell. Any help would be much appreciated. Marcin Tustin IT Innovation Centre 2 Venture Road Chilworth Science Park Southampton, SO16 7NP, UK tel: +44 23 8076 0834 fax: +44 23 8076 0833 mailto:mt@it-innovation.soton.ac.uk http://www.it-innovation.soton.ac.uk

2 1

[ublas] 1.33 regressions in test4 and test5
by John Maddock 13 May '05

13 May '05

I don't know who (if anyone?) is maintaining ublas at present, but test4 and test5 are failing *on every single compiler* at present. I've partly traced the problem: an exception is being thrown in banded.hpp line 192, in : boost::numeric::ublas::banded_matrix<double,boost::numeric::ublas::basic_row_major<unsigned int,int>,boost::numeric::ublas::unbounded_array<double,std::allocator<double> > >::operator()(unsigned int i=0x00000000, unsigned int j=0x00000001) Line 192 + 0x34 C++ The cause is that the member data member _upper has been initialised to zero, which means any attempt here to access members of the matrix results in an exception being thrown! At present I'm stumped, I haven't been able to figure out what the code is supposed to do well enough to even begin to suggest a fix, so I'm just hoping this will ring a bell with someone, who'll know what to do :-) Regards, John.

2 2

[cvs] agurtovoy's lock
by Cromwell Enage 13 May '05

13 May '05

I keep running into it while attempting to get the latest and greatest version of Boost.Parameter; guess I'll wait until tomorrow. Cromwell D. Enage Discover Yahoo! Get on-the-go sports scores, stock quotes, news and more. Check it out! http://discover.yahoo.com/mobile.html

2 1

Critique of Boost.Threads
by Beman Dawes 12 May '05

12 May '05

With Kevlin Henney's permission, the following is a repost of a message he recently posted on the C++ committee's library reflector. It gives his views on Boost.Threads in the context of possible standardization. --Beman ------- In considering a threading library for C++ based on a fairly standard set of primitives, there are essentially two parts to such a library and it is worth considering these separately: the actual threading part, ie the part of the library concerned with the creation, execution and management of separate threads of execution; the synchronisation part, ie the part of the library concerned with locking. The two parts are obviously related in terms of execution, but there is no necessary relationship between them in terms of interface dependencies. These two parts are also in addition to the necessary guarantees of a reasonable memory model and other primitives appropriate for lock-free programming, which are also under related but separate discussion. For the C++ standard library a reasonable goal for both the threading and the synchronisation parts would be to adopt a generic-programming style of design. Although Boost.Threads uses templates in expressing some of its capabilities, it is a relatively closed design wrt extension, and hence not what would normally be termed generic. However, Boost.Threads does offer a starting point, and with only a few considerations and changes it is relatively easy to evolve a more open and appropriate design from it. Considering first the question of the threading part, Boost.Threads is currently based on the idea that a thread is identified with an object that launches it. This notion is somewhat confused by the idea that on destruction the thread object is destroyed but the thread is not -- in other words the thread is not identified the thread object... except when it is. There needs to be a separation of concepts here, which I will come back to in a moment. Another appropriate separation is the distinction between initialisation and execution. These are significantly different concepts but they are conflated in the existing thread-launching interface: the constructor is responsible both for preparing the thread and launching it, which means that it is not possible for one piece of code to set up a thread and another to initiate it separately at its own discretion, eg thread pools. Separating the two roles into constructor and executor function clears up both the technical and the conceptual issue. The executor function can be reasonably expressed as an overloaded function-call operator: void task(); ... thread async_function; ... asynch_function(task); The separation also offers a simple and non-intrusive avenue for platform-specific extension of how a thread is to execute: configuration details such as scheduling policy, stack size, security attributes, etc, can be added as constructors without intruding on the signatures of any other function in the threading interface: size_t stack_size = ...; security_attributes security(...); thread async_function(stack_size, security); The default constructor would be the feature standardised, and an implementation would be free to add additional constructors as appropriate. So far, this leads to an interface that looks something like the following: class thread { public: thread(); template<typename nullary_function> void operator()(nullary_function); void join(); ... }; Given that the same configuration might be used to launch other threads, and given the identity confusion of a thread being an object except when it's not, we can consider the interface not to be the interface of a thread but to be the interface of a thread launcher, also generally known as an executor: http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executor.htm l http://www.cse.buffalo.edu/~crahen/papers/Executor.Pattern.pdf A thread initiator can submit zero-argument functions and function objects to an executor for execution: threader run; ... run(first_task); run(second_task); A standard library would offer a standardised threader type, but as a concept an executor could be implemented in a variety of ways that still conform to the same basic launching interface, ie the function-call operator. As a pleasing side effect, the potential confusion over the name "thread" is also removed: entities are named after their roles. Given that a threader can be used to launch multiple threads, there is the obvious question of how to join with each separately run thread. Instead of returning void, the threader returns an object whose primary purpose is to represent the ability to join with the completion of a separately executing thread of control: class threader { public: threader(); template<typename nullary_function> joiner operator()(nullary_function); ... }; The role played by the joiner in this fragment is that of an asynchronous completion token, a common pattern for synchronising with and controlling asynchronous tasks: http://www.cs.wustl.edu/~schmidt/PDF/ACT.pdf Via the joiner the initiator can poll or wait for the completion of the running thread, and control it in other ways -- eg request cancellation of the task (should we chose to attempt standardising in some form this often contentious and challenging capability). The joiner would be a copyable, assignable and default constructible handle, and as its principal action the act of joining can be expressed as a function-call: joiner wait = run(first_task); ... wait(); If there are no joiners for a given thread, that thread is detached, a role currently played in Boost.Threads by the thread destructor: run(second_task); // runs detached because return value ignored The final piece in this sketched refinement is the recognition that common across many C threading APIs is the ability to return a result from the function executed asynchronously (void * in Pthreads and DWORD in Win32). It seems to have become habit to discard this value in more OO interfaces, giving a result of void. For many threaded tasks this makes sense, but where a thread is working towards a result then the idea that an asynchronously executed function can return a value for later collection should not be discarded. With a void-returning interface the programmer is forced to set up an arrangement for the threaded task to communicate a value to the party that wants the one-time result. This is tedious for such a simple case, and can be readily catered for by making the joiner a proper future variable that proxies for the result: http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Future.html http://www.laputan.org/pub/sag/act-obj.pdf http://kasparov.skife.org/blog/src/futures.html This leads to a threader interface like the following: class threader { public: threader(); template<typename nullary_function> joiner<result_of<nullary_function>::type> operator()(nullary_function); ... }; For the common default configured threader, a wrapper function, thread (as verb rather than noun), can be provided: template<typename nullary_function> joiner<result_of<nullary_function>::type> thread(nullary_function); And usage as follows: void void_task(); int int_task(); ... joiner<void> wait_for_completion = thread(void_task); joiner<int> wait_for_value = thread(int_task); ... int result = wait_for_value(); wait_for_completion(); The benefit of programming with futures is that for a certain class of code that would use end-of-thread synchronisation to pick up results, programmers are not presented with unnecessarily low-level synchronisation APIs. The function-based model is applied consistently. The sequence of steps, and the design considerations involved, to get from Boost.Threads to this design is hopefully clear and can be seen to be grounded in a great deal of existing practice, plus the benefit of a more native C++ appearance. Now, in terms of synchronisation the Boost.Threads library offers a number of primitives, such as mutexes, but unfortunately couples them to a relatively closed programming model. The synchronisation primitives provided do not lead to a general model for locking and force the user into using resource acquisition objects when this is not always the best solution. Given that C++ should aim to be the language and API of choice for systems-level work, the restriction of a mandatory scoped-locking interface does not seem appropriate. A more orthogonal approach based on the capabilities found in common across C++ synchronisation libraries, Boost.Threads included, would be a good starting point: lockability and locking strategy are kept separate. Taking a more generic approach, this means considering a related set of lock categories, eg Lockable and TryLockable. Something like Lockable would (syntactically) be little more than a.lock() and a.unlock(), and something like TryLockable would extend with a.try_lock(). Boost.Threads has some of this but restricts the interface of the lockable types themselves. With respect to these categories both primitives (eg mutex) and higher-level types (other externally locked objects) can be implemented. There is no dependency on the locking strategies that can be used against lockable objects -- scope bound, transaction linked, smart-pointer based, etc. The library would be expected to provide at least scope lockers to simplify the tedious and error-prone business of ensuring that scope-related critical regions are exception safe, but programmers would be free to define additional ones based on specific needs. There is also no requirement to pollute the nested scope of a lockable class with special typedefs. The Boost.Threads synchronisation library does not appear to satisfy the goal of openness and genericity. This is in part based on its well intended but mistaken belief that preventing programmers from using locks manually is the key to safe code: preventing users from using multiple threads and locks is the only way to do this. It is easy but annoying to work around the restriction (eg dynamically allocate the locker objects and control the lifetime on the heap instead of automatically wrt scope), but it should not be something that a programmer should have to work around. The Boost.Threads documentation itself admits that its restricted approach is extreme, but a more open and proven -- and less extreme -- approach is probably a better fit for standardisation. Therefore, the design we need to aim for is one that recognises that any use of explicit threading or any form of synchronisation is the programmer's responsibility. It should make common tasks easier and less error prone than they might otherwise be -- eg the provision of scope lockers -- but it should also allow the programmer the freedom to implement locking strategies as they see fit rather than force them to work around the API or seek another. I've only sketched it out, but hopefully there is enough rationale there to see why, without some refinement, Boost.Threads is not quite the right interface and execution model to standardise, but also how few hops it takes to build from Boost.Threads to an alternative API model that meets a reasonable and reasoned set of design objectives. Kevlin --

3 2

[repost][interfaces] would the following work?
by JOAQUIN LOPEZ MU?Z 12 May '05

12 May '05

Allow me to repost this, since given the current traffic in the list it could well have passed unnoticed. Is (the proposed) Boost.Interfaces lib able to handle the following scenario? template<typename T> interface IIterator { T& operator*()const; ... }; template<typename T> interface IContainer { IIterator<T> begin(); IIterator<T> end(); ... }; It is not the issue of specifying an operator as part of the interface IIterator (this'll be taken care of in the future according to the docs), but the fact that IContainer::begin is required to return an object implicitly convertible to IIterator<T>. Can Boost.Interfaces do that? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo PS: Just for motivation, I' think this idiom could be taken advantage of in a possible implementation of a dynamic multi-index container.

2 1

[filesystem] status() semantics?
by Beman Dawes 12 May '05

12 May '05

To nail down the semantics of status(), let's try a different approach. Some of the difficulty may be a matter of miscommunication, so perhaps actual code will add clarity. Perhaps Peter or others who have views on what the semantics of boost::filesystem::status() should be could change the code below to implement those semantics. Hopefully that will eliminate any confusion as to exactly meaning. --Beman --------- status_flag status_imp( const char * path, system_error_type * ec ) { struct stat path_stat; if ( ::stat( path, &path_stat ) != 0 ) { if ( ec != 0 ) *ec = errno; return ((errno == ENOENT) || (errno == ENOTDIR)) ? fs::not_found_flag : fs::error_flag; } system_error_type result(0); if ( S_ISDIR( path_stat.st_mode ) ) result |= fs::directory_flag; if ( S_ISREG( path_stat.st_mode ) ) result |= fs::file_flag; return result; }

2 2

[Boost-bugs] [ boost-Feature Requests-1200940 ] Support for embedded VC++ 4.0
by SourceForge.net 12 May '05

12 May '05

Feature Requests item #1200940, was opened at 2005-05-12 19:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1200940&group_… Category: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: spinooch (spinooch) Assigned to: Peter Dimov (pdimov) Summary: Support for embedded VC++ 4.0 Initial Comment: Are there any plans to release a version of the smart pointer library that will compile under embedded VC++ 4.0? While trying to resolve the following compiler error: "shared_count.hpp(116) : error C2039: 'type_info' : is not a member of 'std'" I noticed that there are include files referenced in the hpp files that do not exist in the SDK provided with eVC++. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1200940&group_… ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Feature Requests-1200890 ] Support for embedded VC++ 4.0
by SourceForge.net 12 May '05

12 May '05

Feature Requests item #1200890, was opened at 2005-05-12 18:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1200890&group_… Category: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: spinooch (spinooch) Assigned to: Peter Dimov (pdimov) Summary: Support for embedded VC++ 4.0 Initial Comment: Are there any plans to release a version of the smart pointer library that will compile under embedded VC++ 4.0? While trying to resolve the following compiler error: "shared_count.hpp(116) : error C2039: 'type_info' : is not a member of 'std'" I noticed that there are include files referenced in the hpp files that do not exist in the SDK provided with eVC++. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1200890&group_… ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Bug in boost 1.32: date_time/microsec_time_clock.hpp
by martin troxler 12 May '05

12 May '05

It is possible, that the following line boost::posix_time::ptime now = boost::posix_time::microsec_clock::local_time(); which invokes template<class time_type> class microsec_clock { static time_type local_time() { timeval tv; gettimeofday(&tv, 0); //gettimeofday does not support TZ adjust on Linux. return create_time(&tv); } static time_type create_time(timeval* tv) { time_t t = tv->tv_sec; boost::uint32_t fs = tv->tv_usec; ::std::time(&t); tm* curr = localtime(&t); .... returns a time with 1s off its correct value. The reason for this bug is the line with ::std::time(&t); that overwrites the second value just a few µs after the call to gettimofday. This new second value is used together with the fs value from gettimeofday. Example: tv from gettimofday: 12345s/999998 µs t from std::time: 12346s resulting time: 12346s/999998 µs !!!! Question: Why this call to std::time? I commented it out and it worked. Regards Martin

2 1

[iostreams] gcc-3.4.4 and amd64 patches
by Jürgen Hunold 12 May '05

12 May '05

Hi ! Please find a patch attached which tries to fix 2 issues: First, signed/unsigned mismatch in boost/iostreams/char_traits.hpp The fix is to change is_good(int) to is_good(std::wint_t) Second, boost/iostreams/filter/symmetric_filter_adapter.hpp contains two template implementations without corresponding definitions. gcc-3.4.x chokes on them. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de

2 1

VS 2005 Beta 2 + 1.32
by Gordon Smith 12 May '05

12 May '05

Anyone build 1.32 (gold) with VS 2005 Beta 2? If so how? Thanks, Gordon.

2 3

[Boost-bugs] [ boost-Support Requests-1200700 ] Boost on opteron AMD
by SourceForge.net 12 May '05

12 May '05

Support Requests item #1200700, was opened at 2005-05-12 14:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1200700&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: finte (finte) Assigned to: Nobody/Anonymous (nobody) Summary: Boost on opteron AMD Initial Comment: Hello, I need some help. How can I build boost on solaris 10 opteron amd as a 64-bit libraries? It's no problem to build bjam as 64-bit executables but with boost I failed. Has anybody any ideas? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1200700&group_… ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[ptr_container] memory usage causes problem with regression tests
by Martin Wille 12 May '05

12 May '05

Hello, for approximately a week now, I'm experiencing crashes when I run the regression tests. Victor told me he also noticed tests consuming unusual amounts of memory. I think I now found the culprit: the ptr_container test suite. This is the second time I notice the kernel run out of memory when once of the ptr_container tests is run. This is a problem for running the tests since the kernel then starts to kill processes. So this needs to get fixed ASAP. The ptr_set test output is: *** glibc detected *** free(): invalid pointer: 0x14347b4c *** Running 1 test case... unknown location(0): fatal error in "test_set": signal: SIGABRT (application abort requested) *** errors detected in test suite "Pointer Container Test Suite"; see standard output for details We need a way of portably specifying and enforcing time and memory limits for tests (it's not the first time I've been hit by tests running wild). We also need the authors of tests to make use of that feature, once we have it. I think displaying the time and memory used by a test in the regression results would be helpful (requires changes to Boost.Build, too, obviously). In this special case, it also would have been helpful if absolute times were printed in the output of Boost.Build, since all I have is the time-stamp from the error messages of the kernel but no way of correlating this time-stamp with the regression tests except for incidentally looking at the screen when the crashes happen. Regards, m

3 7

shared_ptr_test fails on rsi-sol g++ 4
by Peter Dimov 12 May '05

12 May '05

Any ideas why the three use_count() tests: { boost::shared_ptr<int> pi(new int); boost::shared_ptr<void> pv(pi); boost::shared_ptr<int> pi2 = boost::static_pointer_cast<int>(pv); BOOST_TEST(pi.get() == pi2.get()); BOOST_TEST(!(pi < pi2 || pi2 < pi)); BOOST_TEST(pi.use_count() == 3); BOOST_TEST(pv.use_count() == 3); BOOST_TEST(pi2.use_count() == 3); } fail as described here: http://www.meta-comm.com/engineering/boost-regression/cvs-head/developer/ou… http://tinyurl.com/cq7qy ? -- Peter Dimov http://www.pdimov.com

1 2

[polymorphic_downcast]
by Thorsten Ottosen 12 May '05

12 May '05

Hi, is there any reason why we cannot say Base& get_ref(); Derived& boost::polymorphic_downcast<Derived&>( get_ref() ); ? It works with pointers, shouldn't we overload for references? -Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

2 3

[Regression Reports] Test case categorization
by Aleksey Gurtovoy 12 May '05

12 May '05

I'd like to draw library authors' attention to a recent generalization in the explicit markup scheme which allows one to control the grouping of a particular library's test cases in the Boost-wide regression reports, as demostrated here -- http://www.meta-comm.com/engineering/boost-regression/example/developer/lib… (http://tinyurl.com/bdd5u) The generalization is aimed at improving representation of library reports in at least two common situations: 1) "Duplicate" test cases: many libraries have two or more variations of the same test case for different configurations (DLL vs. static linking, char vs. wchar_t, etc.). 2) Test cases covering corner-case/optional/advanced functionality. In both of these cases, it's common to have an explicit markup (or actual failures) painting a group of test cases in a different color for one or more deficient toolsets -- see, for example, Boost.Thread page (http://tinyurl.com/8duf6) Test case categorization allows library authors to reduce the amount of visual clutter in the reports, giving them a more organized/structured look -- ultimately improving visitors' experience. Assigning a category to a test case or a group of test cases is just a matter of specifying the 'category' attribute to the corresponding '<test>' elements in "status/explicit-failures-markup.xml", e.g. <library name="my_library"> <test name="*_dll" category="DLL"/> </library> or <library name="iterator"> <test name="is_convertible_fail" category="Corner-case tests"> <mark-failure> <toolset name="borland"/> <toolset name="borland-5_6_4"/> <toolset name="msvc"/> <toolset name="vc7"/> <note refid="2"/> </mark-failure> ... As always, feedback is more than welcome. Enjoy, -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Sandbox vault issues
by David Abrahams 12 May '05

12 May '05

Wow. Clicking typeof.zip gives me: Archive contents: Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Filename Size Date/Time boost/typeof/config.hppSD. -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 4

[filesystem] status() if neither file nor directory?
by Beman Dawes 12 May '05

12 May '05

In http://www.esva.net/~beman/filesystem_operations_predicates.htm, the assumptions was that file system entities are either files or directories. But an operating system might support additional file system entities which can only be accessed via a specific API, and can't be accessed via fstreams or directory_iterators. For example, on some operating systems, sockets are file system entities and may be found during directory iterations, but can't be opened as either directories or fstreams. What to do? Possibilities: 1) Add an other_flag and a matching is_other() function. Change definition of exists() to status() & (directory_flag|file_flag|other_flag) 2) Try to identify specific other types like sockets, and define flags and predicate functions for each. Handle future needs by saying an implementation has to define suitable flags and predicate functions for any additional kinds of files. 3) Treat such entities as files. 4) Treat such entities as errors. 5) Treat such entities as not found. To me, (1) seems best. (2) is too open ended, and without a matching API to access the additional types, doesn't do much beyond (1). The others are not acceptable because they are misleading and don't match expectations. Comments? --Beman

4 22

[ptr_container] references & copyability etc (was [ptr_container] indirect_fun - do we still need it?)
by Pavel Chikulaev 11 May '05

11 May '05

"Thorsten Ottosen" <nesotto(a)cs.auc.dk> wrote in message news:d5tnql$2ll$1@sea.gmane.org... > what do you need the returned reference for? Just remembering rule: "Create your own classes that behave like int". isn't it? And IMO we should return reference to do these things: template<typename T> class ptr_cc_vector : public ptr_vector<T> //User's class to enable copyability { public: ptr_cc_vector(const ptr_cc_vector & that) : ptr_vector<T>(that.clone()) {} ptr_cc_vector & operator = (const ptr_cc_vector & that) { return *this = that.clone(); // :))) //Above is a bit better than //*this = that.clone(); //return *this; :)) } }; So, using ptr_container::clone is some kind of _very_ explicit copy constucting and assignment operator. Compare: a = b; a = ( b.clone() ); a(b); a( b.clone() ); and should behave like oridinal copy ctor and operator =. /////////////////////////// Let's start a new discussion about copyability :) I find ptr_cc_vector<T> very handy. Why not just enable copy ctor and assignment operator but in docs you will say explicitly that invoking copy ctor and assignment operator can be very very expensive in capital letters?? Or compromise: Add policy class By default ptr_containers are not copyconstructible, but it can be redefined if someone is willing to make ptr_containers copyconstructible template<typename T, ...., bool EnableCopyCtorAnd = DefaultBehavior> class ptr_vector; Someone, like you, will make DefaultBehavior for his ptr_containers Forbid. Someone, like me, will make DefaultBehavior for his ptr_containers Permit. IMO quite flexible, and everybody will be happy :) P.S. What's about clone_allocators - are they going to be not stateless or not? -- Pavel Chikulaev

2 1

Formal Review Request -- Interfaces
by Jonathan Turkanis 11 May '05

11 May '05

Hi, I would like to propose the proposed Boost Interfaces library, which I introduced several months ago, for formal review. (Or maybe I should say: I'd like to nominate the candidate Boost Interfaces library.) See http://www.kangaroologic.com/interfaces/ for download and documentation. The version to be reviewed will include a number of changes from the above version; in particular, about half of the features described in "Future Directions" will be implemented. However, the above version is self-contained and suitable for review, so I would like to propose it now and work on integrating the changes while it is sitting in the review queue. Jonathan

8 13

[ptr_container] indirect_fun - do we still need it?
by Pavel Chikulaev 11 May '05

11 May '05

Thorsten, Now, when we got rid of ptr_iterators, we don't need indirect_fun, do we? At least as part of ptr_container library? P.S. About copyability: may be then provide some cloning mechanism like: ptr_vector<int> a; ptr_vector<int> b(a.clone()); b = a.clone(); Where ptr_vector<T>::clone doesn't create clone immeadiately, but returns some object that refers to this, and ptr_vector<T> has ctor and assignment operator taking that object. Thoughts? -- Pavel Chikulaev

3 7

Re: (Another) socket streams library
by Nathan Myers 11 May '05

11 May '05

I was directed to this thread after some work to make GNU libstdc++ expose POSIX pipe semantics at the istream::readsome() level, which probably will show up in release 4.0.1. (Cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21286 ) It started me thinking about how to make an iostream useful when attached to a non-blocking socket. Reading this thread, it seems to me you have stepped in the same trap as most other attempts. There are many, many libraries to make various sources and sinks, including sockets, look like iostreams, but without actually being iostreams. We don't seem to find ourselves using them. For nonblocking socket support to be widely useful, it must be possible to pass such a stream to a library that takes a regular istream& or ostream& argument. This has been characterized as impossible, because iostream semantics are not compatible with non-blocking I/O. While the latter is true, the former is not. The key to the paradox is the expression "out-of-band". The owner of the stream may know things about it, and its underlying socket, that the user of the istream or ostream does not, and can act accordingly. Most particularly, the owner may know that the amount of input or output to be done will not cause any system calls to return EWOULDBLOCK. The next question is, how do we know how much I/O we can do without blocking? It is common for select not to wake up a process for writing on a socket until there is more than (say) 4K of space in the output buffer. Therefore, any use of the socket that will not produce more than 4K of output is safe. An actual TCP "out-of-band" notification from the other end may help, indicating that the last written data have all arrived, proving that a full 64K of buffer space awaits. On input, we must ensure that our override of streambuf::underflow is satisfied by a short read, and that the user of the attached istream will be satisfied with what it actually finds, and won't loop trying to get more. These conditions seem awfully restrictive, but there remain a large class of problems for which they are not *too* restrictive. What remains is to identify and package up all the usable out-of-band notification mechanisms associated with sockets, and try to achieve some abstraction and perhaps even (who knows?) portability. Nathan Myers ncm(a)cantrip.org

5 15

parameters library and rvalue pitfall
by David Abrahams 11 May '05

11 May '05

I just added an index_result metafunction that was requested during the review, for getting the result of a named parameter lookup, possibly with a default or a lazy default. Whereas previously, you would write the following to implement your function with named parameters, template<class Params> void f_impl(const Params& p) { g( p[name] , p[value || boost::bind(&value_default) ] , p[index | 999 ] ); } now you have the option to write something like this: template<class Params> void f_impl(const Params& p) { typename boost::parameter::index_result< Params, struct name_>::type& n = p[name]; typename boost::parameter::index_result< Params, struct value_, double >::type const& v = p[value || boost::bind(&value_default) ]; typename boost::parameter::index_result< Params, struct index_, int >::type const& i = p[index | 999]; g(n,v,i); } The problem, which you may have noticed, is that in the latter case you may be creating dangling references to destroyed rvalues. In the case of the index parameter above, the rvalue 999 gets bound to a const reference that then *passes through* the operator[] and initializes i. Since p[index | 999] returns a const reference and not a value, i is bound directly to the original rvalue 999 which is destroyed at the end of the full expression. The question is, what should we do about this? It turns out to be surprisingly hard to write the declarations of these temporary variables so they work in all cases. For example, v had to be a const& because in one case index_result<...>::type turned out to be char const[4] and when the default is used, it's double with p[value || ...] returning a double rvalue (by value). Thoughts? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 10

[test] and bcc32 errors
by Russell Hind 11 May '05

11 May '05

Running the regression tests on boost.test with bcc32 leads to many errors like this (and also in other libs regression tests) basic_cstring_test.cpp: Error E2093 c:\Users\russell\Projects\boost-cvs\boost\boost/test/predicate_result.hpp 51: 'operator!' not implemented in type 'tt_detail::equal_impl_frwd' for arguments of the same type in function predicate_result::predicate_result(const tt_detail::equal_impl_frwd &) Any ideas what is going on? Thanks Russell

2 8

Re: [boost] Re: FOREACH / C++ "for" proposal
by brangdon＠cix.compulink.co.uk 11 May '05

11 May '05

In-Reply-To: <428133DD.20505(a)dcook.org> darren(a)dcook.org (Darren Cook) wrote (abridged): > Wouldn't someone wanting to do something "clever" like that fall back to > using a normal for() or while() loop? I thought for(i:vect){} is a > convenience function to save typing and make code clearer; can it do > something a while() loop cannot? I don't think it makes the code clearer, because it looks like a use of i rather than a declaration. I think it is very important for readability that names be declared explicitly. That is a general point. What you are proposing: for (i: vec) is especially misleading because it is inconsistent with: for (i = vec.begin(); i != vec.end(); ++i) I really don't think one should declare i and the other, not. What's wrong with: for (auto i: vec) ? -- Dave Harris, Nottingham, UK.

2 1

Re: [boost] Re: Re: Formal Review: FOREACH macro
by brangdon＠cix.compulink.co.uk 11 May '05

11 May '05

In-Reply-To: <00fb01c55599$e9fc23e0$6401a8c0@pdimov2> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > I think that defining size( T[N] ) as N or N-1, depending on whether T > is a character type, will cause problems in generic code and preclude > the widespread use of the library. I agree. If we do support null-terminated character strings, can we support other kinds of terminators too? (Without undue loss of efficiency.) For example: int array[] = { 1, 2, 3, -1 }; int *pArray = array; for (int i, terminator_adaptor(pArray,-1)) cout << i; // Does not write -1. This can be useful if the size of the array is not visible to for(:). I use terminators fairly often, usually NULL for pointers, 0 or -1 for integral types, and "end" for enums. It's not something specific to characters. In fact, for me the need to enumerate character strings is rarer than for these other types. Usually strings are either wrapped in std::string or similar, or else passed to some other routine. By "Without undue loss of efficiency" I really mean without scanning the sequence an extra time to find the end. My impression is that BOOST_FOR_EACH had a fairly general termination mechanism which could cope with that. -- Dave Harris, Nottingham, UK.

1 0

Re: [boost] Re: FOREACH / C++ "for" proposal
by brangdon＠cix.compulink.co.uk 11 May '05

11 May '05

In-Reply-To: <d5qtbh$cpi$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > which example are you referring to? The one using my_range_adapter, in section 4 of: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1796.html > chances are that <vector> will include <iterator> anyway. I'd rather not have to take chances with my code. -- Dave Harris, Nottingham, UK.

1 0

[test] mingw (3.2.3) failure
by Gennadiy Rozental 11 May '05

11 May '05

Does anybody know what the deal here? Test output: mslater - test - basic_cstring_test / mingw Linker output [2005-05-10 22:57:32 UTC]: "g++" "-Wl,--enable-auto-image-base" -g -Wl,--allow-multiple-definition -mno-cygwin -o "C:\testing\boost\results\bin\boost\libs\test\test\basic_cstring_test.test\mingw\debug\basic_cstring_test.exe" -L"C:/testing/boost/results/bin/boost/libs/test/build/libboost_unit_test_framework.lib/mingw/debug" "C:\testing\boost\results\bin\boost\libs\test\test\basic_cstring_test.test\mingw\debug\basic_cstring_test.obj" "C:\testing\boost\results\bin\boost\libs\test\build\libboost_unit_test_framework.lib\mingw\debug\libboost_unit_test_framework.lib" "C:\testing\boost\results\bin\boost\libs\test\build\libboost_unit_test_framework.lib\mingw\debug\libboost_unit_test_framework.lib" C:\testing\boost\results\bin\boost\libs\test\test\basic_cstring_test.test\mingw\debug\basic_cstring_test.obj(.text$_Z19asignment_test_implIwEvPN5boost4typeIT_EE+0xef): In function `ZSt4setwi': c:/mingw/include/c++/3.2.3/iomanip: undefined reference to `std::char_traits<wchar_t>::compare(wchar_t const*, wchar_t const*, unsigned)' And a lot more like this. Why references to std::char_traits<wchar_t> symbols are undefined? Gennadiy

3 4

Re: [boost] Re: Formal Review: FOREACH macro
by Peter Dimov 11 May '05

11 May '05

Peter Dimov wrote: > Eric Niebler wrote: > >> Yes, but I was refering to native (C-style) strings, as in: >> BOOST_FOREACH(char ch, "hello world") > > This is a good opportunity to ask: what does this do? > > char const a[] = { 0, 1, 2 }; Or for extra fun, drop the 0. > BOOST_FOREACH( int x, a ) > { > std::cout << x << std::end; > }

6 20

Review Schedule (11-May-2005)
by Tom Brinkman 11 May '05

11 May '05

The singleton library review started on 5-May-2005. If you haven't done so already, download the library at http://tinyurl.com/6qvrd. You should submit a review by 15-May-2005. The Typeof Library review begins 20-May-2005. You can download this library at http://boost-sandbox.sourceforge.net/vault/ (typeof.zip) Contact Tom Brinkman at reportbase(a)gmail.com for updates to this schedule. Review Queue as of May 11, 2005 1) Singleton (Current) 5-May-2005; Ends: 15-May-2005 2) Typeof Starts: 20-May-2005; Ends: 30-May-2005 3) Function Types Starts: 5-June-2005; Ends: 15-June-2005 4) Logging To be confirmed: 20-June-2005; Ends: 30-June-2005 5) Policy Pointer To be confirmed: 5-July-2005; Ends: 15-June-2005 Other Libraries (no particular order): 6) Fixed Strings 7) Intrusive 8) TR1 9) Fusion 10) Factory 11) Interfaces 1) Singleton Author: Jason Hise chaos(a)ezequal.com Review Manager: Pavel Vozenilek pavel_vozenilek(a)hotmail.com Availabe At: http://tinyurl.com/6qvrd The singleton library provides multiple powerful methods of controlling the lifetimes of global resources. Client code can choose among the many provided methods of creation, or can easily write new creators for specialized initialization needs. Client code can additionally control precisely when a singleton instance is automatically created and destroyed, can create and destroy singleton instances explicitly any number of times, and can set up dependencies between singletons in an easy and natural way. 2) Typeof Author: Arkadiy Vertleyb Arkadiy Vertleyb, Peder Holt vertleyb(a)hotmail.com peder.holt(a)gmail.com Review Manager: Andy Little andy(a)servocomm.freeserve.co.uk Available: http://boost-sandbox.sourceforge.net/vault/ (typeof.zip) The proposed Typeof library implements the functionality of the non-standard typeof() operator. Depending on the compiler, it utilizes one of the following three methods: 1) Forwards to the non-standard typeof extension, usually called __typeof__, on the compilers where such extension is available; 2) Utilises a loophole, available on the Microsoft vc6.5, vc7.0, and vc7.1; 3) Emulates typeof by the means of template and preprocessor metaprogramming for the compilers that do not fall into above two categories, such as vc8.0 beta, etc. This method is rather portable, and can also be used on the compilers that implement the __typeof__ as a language extension, when compiling with language extensions switched off. The emulation mode is currently working with vc7.1, vc8.0 beta, and gcc 3.3/3.4; The MS-specific trick is working with vc6.5, 7.0, and 7.1. The __typeof__ extension forwarding is working with gcc 3.3/3.4 and Metrowerks. 3) Function Types Author: Tobias Schwinger tschwinger(a)neoscientists.org Review Manager: John Maddock john(a)johnmaddock.co.uk Available at: http://tinyurl.com/4oe7q This library provides a metaprogramming facility to classify, decompose and synthesize function-, function pointer-, function reference- and member function pointer types. For the purpose of this documentation, these types are collectively referred to as function types (this differs from the standard definition and redefines the term from a programmer's perspective to refer to the most common types that involve functions). The classes introduced by this library shall conform to the concepts of the Boost Metaprogramming library (MPL). The Function Types library enables the user to: * test an arbitrary type for being a function type of specified kind, * inspect properties of function types, * view and modify sub types of an encapsulated function type with MPL Sequence operations, and * synthesize function types. This library supports variadic functions and can be configured to support non-default calling conventions. 4) Logging Library Author: John Torjo john.lists(a)torjo.com Review Manaer: Hartmut Kaiser hartmut.kaiser(a)gmail.com Available at: http://torjo.com/code/logging-v132.zip The Boost Log Library is a small library, who: * makes it very easy to declare/define new logs * allows you very simple access to logs * allows for log hierarchies, and for modifying log hierarchies * allows for easy and efficient enabling/disabling of logs/log hierarchies * allows for easy manipulation of log behaviors (the log's destination(s) and/or adjusting the original message) * is thread-safe Using the library in code is easy and straightforward: int i = 1, j = 2, k = 3; BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k << std::endl; BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something...."; Additions to v1.3.2 - can be compiled as a static/dynamic runtime (works as a DLL as well) - removed dependency on boost_thread Note: I did not test this on Unix, but it should work. If anybody can take a look at detail/ts_posix.hpp, I'd appreciate it. - solved other small issues, based on feedback - slightly improved documentation 5) Policy Pointer Author: David B. Held dheld(a)codelogicconsulting.com Review Manager: Gennadiy gennadiy.rozental(a)thomson.com Available At: Boost Sandbox under policy_ptr Smart pointers are used to automate memory management by handling the deletion of dynamically allcoated objects (and other resources). They assist in ensuring program correctness, exception safety, and memory integrity. Policy Pointer is a policy-based smart pointer framework designed to accomodate the large number of smart pointer designs. Through the use of policy classes, virtually any smart pointer type can be constructed within this framework. This library is a Boostification of the original Loki::SmartPtr type with significant modifications. 6) Fixed Strings Author: Reece Dunn msclrhd(a)hotmail.com Review Manager: Beman Dawes bdawes(a)acm.org Available At: boosts-sandbox/boost/fixed_string The fixed string library provides buffer overrun protection for static sized strings (char s[ n ]). It provides a C-style string interface for compatibility with C code (for example, porting a C program to C++). There is also a std::string-style interface using a class based on flex_string by Andre Alexandrescu with a few limitations due to the non-resizable nature of the class. 7)Intrusive Author: Olaf Krzikalla krzikalla(a)gmx.de Review Manager: Needed Available At: http://people.freenet.de/turtle++/intrusive.zip Library presenting some intrusive containers to the world of C++. While intrusive containers were and are widely used in C, they became more and more forgotten in the C++-world due to the presence of the standard containers, which don't support intrusive techniques. Boost.Intrusive not only reintroduces this technique to C++, but also encapsulates the implementation in STL-like interfaces. Hence anyone familiar with standard containers can use intrusive containers with ease. 8) TR1 9) Fusion 10) Factory Author: Federico Stella f.stella(a)flashnet.it 11) Interfaces Author: Jonathan Turkanis <technews(a)kangaroologic.com> Review Manager: Needed Available: http://www.kangaroologic.com/interfaces "Boost.Interfaces provides a macro-based Interface Definition Language (IDL) which can be used to define C++ class types called interfaces. An interface is a lightweight value type associated with a set of named function signatures. An interface instance can be bound at runtime to any object which implements the interface, i.e., to any object of a type with accessible non-static member functions having the same name and signature as the set of functions associated with the interface. The functions of the bound object can then be invoked through the interface instance using the 'dot' operator. Binding is completely non-intrusive: the object's type need not declare any virtual functions or derive from any particluar base class. "Current applications of Boost.Interfaces include: * Non-intrusive dynamic polymorphism — interfaces can often be used in place of abstract base classes, and are sometimes much faster (see Performance). * Dynamic inheritance — allows function calls to be forwarded automatically to an object specified at runtime (see Delegation). * Smart Interface Pointers — smart pointers which can manage the lifetime of any object whose type implements a given interface. * Smart References — like smart interface pointers, but the managed object is accessed using the "dot" operator."

1 0

Boost.Test: major update
by Gennadiy Rozental 11 May '05

11 May '05

Hi, I would like to take this moment to share with you finally the modifications Boost.Test went through during last couple month. Most of Boost.Test components undergo a major or significant change in both design and implementation. I've strived to keep an interface unchanged as much as possible. The primary goals for this update were: * Make a unit test framework better suited for different 'runners' * Make unit test framework simpler internally by eliminating test cases hierarchy * Make test tools more uniform * Make auto unit test framework as usable as possible Following are details of what updated/changed specifically in each area of Boost.Test: I. Execution Monitor The execution monitor design changes from inheritance to delegation. If previously one needed to inherit from the boost::execution monitor to do a monitored run of a function, now one need to employ an instance of the boost::execution_monitor: boost::execution_monitor em; // register translators for custom user exception em.register_exception_translator<ExceptionType>( my_translator ); em.execute( function_to_execute ); function_to_execute should be any zero arity function or function object. To implement the polymorphic function handling I employ my own class callback (see utilities section). I did not want to introduce a dependency on Boost.Function. But in a future I plan to switch to tr1::function. In addition following features implemented: * Debugger presence detected, in which case catching system errors (SEH) is disabled unless explicitly enabled. For now only works for msvc family * Automatic detection of memory leaks introduced. For now only works for msvc family Unit test framework turns this feature on by default. User could manage it by specifying runtime parameter (in a form of command line argument or environment variable). For example test --detect_memory_leak=<leak_allocation_number> set leak_allocation_number to integer number: 0 - to disable detection of memory leaks; 1 - to enable detection of memory leaks; N>1 - to enable detection of memory leaks and set a system breakpoint at the moment of Nth memory allocation. For more on how to find N and some issues with usage of this feature see documentation II Unit test framework (UTF) This component of Boost.Test undergo a most dramatic changes in both design and implementation. Here are main modifications: 1. UTF doesn't employ test cases hierarchy anymore. There is single class test_case that model one testing unit and class test_suite that model a collection of test units. Previously UTF employed compound test cases (for example parameterized test case) which went through it's components (simple subtests) during testing run time. Now compound test present itself as test case generator which produce a collection if test_case instances during test tree construction time. One consequence of this is that user doesn't need to keep track of compound test case parameters is it used be. test_case now employs a polymorphic callback to a actual test function. As a result of this one could supply any zero arity function as an argument of BOOST_TEST_CASE. SO no extra support needed to be able to create boost::function or boost::bind based tests cases. 2 .Introduced generic mechanism to traverse the test tree. Anyone willing to do so just need to implement test_tree_visitor interface and employ traverse_test_tree. This allows to implement any pre/post processing over test tree. 3. Introduced a notion of framework. The framework is responcible for: a) initializing and providing access to master test suite b) providing access to current test case c) running testing from given test tree node (simple or compound). By default it runs from root - master test suite. Supports both sequential and random order. d) One may register any test observer agent (implements test_observer interface) and framework notifies it of all test events e) providing access to any test case based to unique test unit id Using the framework one could implement different test runners. UTF library supplies one console runner (unit_test_main.cpp). But it's possible to do one winmain based or anything else. For example GUI program that build test tree and then run tests by request from any point in test tree. 4. Unit test log interface changed to single line (used to be begin/end macros). Unit test log formatter interface changed. How it much simpler and straightforward. Two supplied implementation are separated. 5. Notion of unit test result that was responcible for result collection and reporting eliminated. Instead introduced independent notions: results_collector and results_reporter. Results reporting formatter interface made public. Also results_reporter now allows to change an output stream. 6. Progress monitor functionality (which used to be activated in log level log_progress) now is an independent test observer and implemented by class progress_monitor. 7. Test case template interface changed. Now user doesn't need to explicitly register meta class. In addition couple more features implemented: * Added support for test case timing * UTF made __cdecl - safe * Result report include skipped tests * io saver facilities employed to guard against undesirable modification in output streams formatting * template test case automatically generate name that includes type name * --detect_memory_leak and --random cla added III Test Tools The two major changes in Test Tools are: * Test Tools interfaces to provide 3 version for each tool: CHECK- reports an error if assertion failed WARN - reports a warning if assertion failed REQUIRE - reports an error if assertion failed and aborts test case execution * Test Tools implementation completely reworked. All tools implemented now through single vararg function In addition following modifications made: * CHECK_COLLECTION interface changed: it now expect 4 arguments * BITWISE_EQUAL renamed to CHECK_BITWISE_EQUAL; old name still provided, but is deprecated * CHECK_COLLECTION interface changed to use PP_SEQ and as a result support arbitrary(actually maximum is fixed but configurable) number of predicate arguments * most of templates eliminated speeding up test modules compilation * floating-point precision set to include all significant digits (actually the formula may require some rework since it obviously doesn't do a good job sometimes) * BOOST_CHECK/WARN/REQUIRE_SMALL test tool added * old test tools names are *deprecated* IV Auto unit test framework Interesting discussion with Noel Llopis and several user requests lead to several additions to the auto_unit_test.hpp. Here is a short descriptions: * BOOST_AUTO_UNIT_TEST renamed to BOOST_AUTO_TEST_CASE. Old name still provided but deprecated * BOOST_AUTO_TEST_CASE_TEMPLATE provides an ability to write a self-registering test case template * BOOST_FIXTURE_TEST_CASE provides an ability to write a self-registering test case with fixture * BOOST_AUTO_TEST_CASE_EXPECTED_FAILURES provides an ability to specify a number of expected failures in any self-registering test case * BOOST_AUTO_TEST_SUITE and BOOST_AUTO_TEST_SUITE_END provide an ability to structure test cases into self-registering test suites V Included components Implementation moved from source files (.cpp) under lib/test/src into implementation files (.ipp) under boost/test/impl to eliminate dependency of included/minimal components on lib/test/src directory. VI Utilities Basic utilities that may have value outside of Boost.Test now separated into utils subdirectory. If there is an interest to promote any of them onto public boost level I am ready to discuss it. Here is a short descriptions (some of them existed before, but most are new): 1) algorithm.hpp Implements several variations of STL algorithms including 4-arg mismatch 2) assign_op.hpp Hook for overloadable assignment 3) callback.hpp Implements a polymorphic function callback facility (similar to boost::function). 4) class_properties.hpp Simple facility that mimic notion of read-only read-write properties in C++ classes 5) custom_manip.hpp Simple helpers for creating custom output manipulators 6) fixed_mapping.hpp Fixed sized mapping (initialized in constructor ) with specified invalid value. 7) foreach.hpp This is an abridged version of BOOST_FOREACH. The only difference is portability. 8) named_params.hpp Facility for named function parameters support. Even though Dave A. did not see a value in my suggestion during Boost.Parameter review period. I couldn't justify for myself using that inconvenient interface (IMO) and absence of optional parameters. This facility implements an alternative solution with different set of tradeoffs and features. It used in several places in Boost.Test. 9) nullstream.hpp I should probably deprecate this one , but more-io was not accepted. 10) rtti.hpp Simple alternative to compiler RTTI. Provides an access to unique type id at runtime. I plan to extend this to implement type_descr similar to what is described in "C++ template metaprogramming". 11) trivial_singleton.hpp As the name suggest this simple singleton helper. 12) wrap_stringstream.hpp Wraps strstream and stringstream (depends with one is present) to provide the unified interface 13) basic_cstring/ class template basic_cstring wraps raw memory pointers and provide std_string like interface 14) iterator/input_iterator_facade.hpp Helps to build input iterators 15) iterator/token_iterator.hpp Yet another token iterator 16) iterator/istream_line_iterator.hpp Iterate over istream and produce lines 17) runtime/ This is long promised framework for parsing CLA handing environment variable and parsing config files. This is an alternative solution to what boost::program_options present. Unfortunately I did not have enough time to incorporate it completely into Boost.Test main components, so the detailed description will follow once this will happened. Sorry, for babbling for so long. Any comments are greatly appreciated. Regard, Gennadiy

3 5

[patch] Memory leak in the thread_specific_ptr implementation in Boost.Threads
by Jeremie Detrey 11 May '05

11 May '05

Hello, It seems to me that there is a possibly huge memory leak in the file boost/libs/thread/src/tss.cpp, as the thread specific data slot vector is allocated (line 120) but never freed. It causes a few bytes' memory leak for each thread, as it appears when using valgrind (see attached files: input program = example.cpp, valgrind output = example.valgrind). I propose here a simple patch to fix this. It works perfectly with my programs, and frankly I cannot see why it should not work. Thanks, Jeremie Detrey.

1 0

Boost.Python embedding/extending example
by Neb Naic 11 May '05

11 May '05

Hello, I have an application that I need to both embed and extend Python. The Python portion is actually an existing plotting utility that I�m trying to leverage in a legacy C++/OpenGL application. The Boost.Python tutorial has helped me successfully expose my C++ classes to Python. However, I�m having difficulty embedding the Python � accessing Python interfaces from C++. The tutorial examples seem to lean toward embedding Python statements rather than actually addressing interface issues (IMHO). Assuming the Python code to embed is in its own file (not actually embedding Python statements), does Boost.Python provide an encapsulated class or functional interface? Documentation/examples? Any help is greatly appreciated. Thanks, Niac __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

2 1

[interfaces] would the following work?
by Joaquín Mª López Muñoz 11 May '05

11 May '05

Is (the proposed) Boost.Interfaces lib able to handle the following scenario? template<typename T> interface IIterator { T& operator*()const; ... }; template<typename T> interface IContainer { IIterator<T> begin(); IIterator<T> end(); ... }; It is not the issue of specifying an operator as part of the interface IIterator (this'll be taken care of in the future according to the docs), but the fact that IContainer::begin is required to return an object implicitly convertible to IIterator<T>. Can Boost.Interfaces do that? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo PS: Just for motivation, I' thinkthi s idiom could be taken advantage of in a possible implementation of a dynamic multi-index container.

1 0

Re: [mpl] Math sublibrary: new version.
by Cromwell Enage 11 May '05

11 May '05

--- Andy Little wrote: > > There may be an implementation of gcd<> that is > > more efficient even if it works solely on > > big_integral<> numbers. > > Surely it would make sense to specialise this for > big_integral. Yes. > > Or there may not, but for now, I shouldn't rule out > > anything that promises to make big_integral<> > > operations less expensive. > > But these operations will now be unneccessarily > expensive for small_int types. Then there should be a gcd specialization for them, too, right? One that doesn't require recursive apply2<> calls? > Your version of gcd looks is obviously optimised > for big_integral. Really? I haven't even taken advantage of anything that's specific to big_integral<>, but okay... ...if I ever get big_integral<> to work. > However my requirements on rational would be for a > large number of smallint types. I hope you will take > this into account in the design and favour the > implementation more towards small_int types as well. Okay. > OK maybe that would be quicker, and give better error > messages. But you will need a tag dispatch mechanism > anyway wont you?, to avoid a large number of > specialisations. Yes. Like I said, I'll do that. Cromwell D. Enage Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html

1 0

[patch, boost.regex] Kill warning when compiling without exceptions
by larsbj＠gullik.net 11 May '05

11 May '05

This is the only warning I get when compiling the subset of boost that is included in LyX. Would be nice to see this in 1.33. This is with gcc 3.3.3. diff -ru --exclude=CVS boost/boost/regex/v4/basic_regex_parser.hpp lyx-upboost/boost/boost/regex/v4/basic_regex_parser.hpp --- boost/boost/regex/v4/basic_regex_parser.hpp 2005-05-09 10:35:34.000000000 +0200 +++ lyx-upboost/boost/boost/regex/v4/basic_regex_parser.hpp 2005-05-10 22:27:37.124642889 +0200 @@ -147,6 +147,8 @@ template <class charT, class traits> void basic_regex_parser<charT, traits>::fail(regex_constants::error_type error_code, std::ptrdiff_t position) { + // Avoid warnings when compilinging without exceptions. + (void)position; if(0 == this->m_pdata->m_status) // update the error code if not already set this->m_pdata->m_status = error_code; m_position = m_end; // don't bother parsing anything else -- Lgb

2 1

[mpl] Math sublibrary: new version.
by Cromwell Enage 11 May '05

11 May '05

--- Dan Perry wrote: > I need some sort of compile time float type that > supports multiplication and division. I found your > comments on the gmane.comp.lib.boost.devel newsgroup > via google but I can't access your mpl_math.zip > file. Could you send me your source? Thanks. The file has a new home. Go to <http://boost-sandbox.sourceforge.net/vault/>, look under the subdirectory "expaler", and download from there. Major issues: 1. The big_integral<> numeric "metatype" is still a compiler resource hog. If I could use list<> instead of vector<>, I may be able to make it more efficient. To do so, I would need to know how to iterate through two lists "concurrently" instead of one list at a time. Aleksey Gurtovoy, any pointers? 2. The most recently added numeric metafunctions, which are square_root<>, exponent<>, sine<>, cosine<>, arctangent<>, hypersine<>, and hypercosine<>, are either insufficiently tested or not tested at all. 3. The numeric_caster_rt facility probably needs a more appropriate name. It is untested with wrt boost::rational as the ResultType. It is also non-functional wrt complex_number<>, at least until I figure out how to use std::complex. 4. Documentation should be available in the next version. For now, the source code, examples, and test programs will have to suffice. Andy Little wrote: > Why not call this one mixed_number? Okay, your suggested name changes have been applied. Also, except for big_integral<>, the NumberSign parameter is now removed. Examples: rational<int_<11>,integral_c<long,16> > rational_c<long,-9,5> mixed_number<long_<2>,int_<54>,integral_c<int,100> > mixed_number_c<int,0,-2,5> The following expressions are currently illegal: rational<int_<1>,int_<0> > rational_c<long,9,-5> mixed_number<long_<3>,int_<-1>,integral_c<int,2> > mixed_number_c<int,0,6,5> I'm currently debating with myself about whether to make aux::rational2mixed_number<> part of the public interface; and if so, whether to rename it to something more legible; or if not, whether mixed_number<> and mixed_number_c<> should take default parameters. > IMO the rational Concept should hold independent of > the exact parameters. The types used for the > parameters are a trade off between using small_ints > and having a relatively quick compile with the > possibility of everflow, as against big_integers with > long compile (and posibly run) times. Actually only the relationship between the concept and the implementation models was dependent on the parameter "metatypes". But I know what you meant, so don't worry about it. > However in a large number of cases a rational has > known bounds, so an inbuilt int has ample range. Yeah. It's when you try things like the square_root<> example program (included in the zip file) that the inbuilt range becomes not enough. > I am wondering if the more lazy implementation > possible by moving away from integral constant > expansion might improve matters. OTOH perhaps it > will make matters worse. (I am no expert on 'lazy' > programming...but it must have some benefit?) I'll try to implement some lazy versions of both big_integral<> and the new numeric metafunctions in the next version. > It is merely one among several possible compile time > types that Might be useful as parameters. Other > possibilities are the aforementioned big_int and a > complex, should One not try to make the thing generic > as possible? I dont think anything is lost by it. > Even if the helper functions like gcd and abs are not > useful for this they may come in useful somewhere > else. I've reimplemented rational<> so that it accepts any numeric constants M and N for which modulus<M,N> is a valid expression. That should improve its genericity. Cromwell D. Enage __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

2 3

[serialization] gcc 3.4.3 / ld / serialization issue?
by Christoph Ludwig 10 May '05

10 May '05

Hi, this post belongs to the thread <url:http://lists.boost.org/MailArchives/boost/msg76063.php> but I don't have that thread in my local archive anymore. I face the same problem as Curtis Spencer did. Linking an application built with g++ 3.4.3 against boost_serialization-gcc-mt produces warnings from the linker: g++ -pthread -g -O2 -pthread -o testsuite-LaRed testsuite-LaRed.o ReductionTestdata.o testcase-Testdata.o testcase-Matrix.o testcase-GS.o testcase-LLL.o testcase-BKZ.o testcase-RSR.o -L/home/cludwig/Cxx/gcc3.4/LaRed-0.1-BUILD/src /home/cludwig/Cxx/gcc3.4/LaRed-0.1-BUILD/src/.libs/liblared_ntl.a /home/cludwig/Cxx/gcc3.4/LaRed-0.1-BUILD/src/.libs/liblared.a -lboost_unit_test_framework-gcc-mt -lboost_serialization-gcc-mt -lboost_filesystem-gcc-mt -L/home/cludwig/Cxx/gcc3.4/usr/lib/ -lntl /usr/lib/libgmp.a `.gnu.linkonce.t._ZNK5boost7archive17archive_exception4whatEv' referenced in section `.rodata' of /home/cludwig/Cxx/gcc3.4/usr/lib//libboost_serialization-gcc-mt.a(basic_iarchive.o): defined in discarded section `.gnu.linkonce.t._ZNK5boost7archive17archive_exception4whatEv' of /home/cludwig/Cxx/gcc3.4/usr/lib//libboost_serialization-gcc-mt.a(basic_iarchive.o) (There are similar warnings from basic_text_iprimitive.o and xml_grammar.o. The compiler / Boost configuration are reported at the bottom of this post.) The linker generates an executable anyway and it _seems_ to work. However, I observe infrequent crashes of the application that I don't observe on a machine where I built Boost and the application (without any warnings) with gcc 3.4.2 / ld 2.14.90.0.5. Thus I suspect that the warning is there for a reason and points to the problem causing the crashes. Has anyone an idea what to do about this? I am not sure the problem is caused by the serialization library, but Googling araound I found that it is often exposed by boost_serialization-gcc-mt. There is already a gcc bugreport (PR #16625) w.r.t a similar problem but it seems neither specific to gcc 3.4.3 nor do I see a resolution. Thanks Christoph I built both Boost and my application with gcc 3.4.3: cludwig@cdcNT56:~/Cxx/gcc3.4/LaRed-0.1-BUILD> LC_ALL=C g++ -v Reading specs from /opt/gcc/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=/opt/gcc/gcc-3.4.3 --enable-threads=posix --enable-version-specific-runtime-libs --enable-languages=c,c++ --enable-__cxa_atexit --enable-c-mbchar --enable-libstdcxx-debug --enable-c99 --enable-libstdcxx-pch Thread model: posix gcc version 3.4.3 The linker is: cludwig@cdcNT56:~/Cxx/gcc3.4/LaRed-0.1-BUILD> ld -v GNU ld version 2.15.91.0.2 20040727 (SuSE Linux) Boost was built using the following script: cludwig@cdcNT56:~/Cxx/gcc3.4/LaRed-0.1-BUILD> cat ~/Cxx/boost_1_32_0/build-boost_gcc34.sh #!/bin/bash bjam -d2 --with-pydebug \ --prefix=$HOME/Cxx/gcc3.4/usr \ --builddir=$HOME/Cxx/gcc3.4/boost-1.32.0-build \ -sTOOLS=gcc \ -sBUILD="debug release <threading>multi" \ install bjam -d2 --without-python \ --prefix=$HOME/Cxx/gcc3.4/usr \ --builddir=$HOME/Cxx/gcc3.4/boost-1.32.0-build \ -sTOOLS=gcc \ -sBUILD="debug release <define>BOOST_DISABLE_THREADS <threading>single" \ install -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

2 2

Re: [dynamic_bitset] Stream extraction failures on CodeWarrior 9.4
by Gennaro Prota 10 May '05

10 May '05

--- Doug Gregor <dgregor(a)cs.indiana.edu> wrote: > The stream extraction operators for dynamic_bitset are failing on > CodeWarrior 9.4. See: http://tinyurl.com/addko > Is anyone familiar enough with the quirks of Metrowerks' iostreams to > fix this issue? Hi Doug, Jeremy and Howard unfortunately, due to a series of vicissitudes that would be too long to tell, I have no home connection at the moment (a situation that lasts from several months) and thus I can't work on CVS. Howard Hinnant is probably the person who knows Metrowerks compiler and library best. Howard? -- Genny. Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html

2 2