May 2005 - Boost - lists.boost.org

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