- Boost - lists.boost.org

[mpl] Iterator categories for sequence views
by Daniel James 20 Aug '04

20 Aug '04

I'm not sure about this, but I think the iterator categories for joint_view, transform_view and filter_view are wrong. At the moment they are set to the category of their base iterator, but I think that they should be set to forward_iterator_tag (or maybe input_iterator_tag?) because they don't implement prior, advance or distance. I think this is the reason that the attached file fails to compile. Of course, this might not be the case in the new version? Daniel

2 1

Links to regression tests are broken
by Jeff Garland 20 Aug '04

20 Aug '04

Go to http://www.boost.org/regression-logs/ The developer and and user reports links are broken. I assume these now need to point to meta-comm? Jeff

2 1

shared_ptr feature request: void_pointer_cast
by Joe Gottman 20 Aug '04

20 Aug '04

I know this isn't the best time to request a new feature, but I just had an idea for an extremely useful new function for shared_ptr. It is common to use a shared_ptr<void> in places where a void * would otherwise be used. While a void * can point to anything, there is no safe way to determine at run-time what type it originally pointed to. Casting it to the wrong type can result in undefined behavior. Although there's no way to avoid this problem with a plain void *, except by passing type information along with it, it should be possible to improve on this situation for shared_ptr<void>, using the template function void_pointer_cast. template<class X> shared_ptr<X> void_pointer_cast(shared_ptr<void> pv); (and similarly for shared_ptr<const void>, shared_ptr<volatile void> and shared_ptr<const volatile void>) void_pointer_cast should have the following semantics: if (pv.get() && pv owns an object of type X) { return shared_pointer_cast<X>(pv); } else { return shared_ptr<X>(); } This would allow code like the following shared_ptr<void> pv = getNextObject(); if (shared_ptr<int> pInt = void_pointer_cast<int>(pv)) { // Do something with pInt; } else if (shared_ptr<string> pString = void_pointer_cast<string>(pv)) { // Do something with pString; } Note that while this code is very similar to code using dynamic_pointer_cast, void_pointer_cast would be usable even when the target type is not a class with virtual functions. On the other hand, given code like shared_ptr<void> pv(new Derived); shared_ptr<Base> pb = void_pointer_cast<Base>(pv); pb.get() would equal 0, even if Base were a public base class of Derived and had a virtual destructor. void_pointer_cast should be easy to implement, using the same techniques as were used in get_deleter, and I think it would be of great use to many programmers. Joe Gottman

1 0

problem re CW serialization tests
by Robert Ramey 19 Aug '04

19 Aug '04

Almost all the tests for the serialization system fail to link with the following message: ### mwld Linker Error: # Undefined symbol: '_errno' # referenced from 'void boost::unit_test::hrf_report_formatter::report_assertions_stat(class std::basic_ostream<char, struct std::char_traits<char> > &, unsigned int, unsigned long, unsigned long, unsigned long) (?report_assertions_stat@hrf_report_formatter@unit_test@boost@@UAEXAAV?$basi c_ostream@DU?$char_traits@D@std@@@std@@IKKK@Z)' in unit_test_result.obj (libboost_test_exec_monitor.lib) ### mwld Linker Error: # Undefined symbol: '_errno' # referenced from 'void boost::unit_test::hrf_report_formatter::report_sub_test_cases_stat(class std::basic_ostream<char, struct std::char_traits<char> > &, unsigned int, unsigned long, unsigned long) (?report_sub_test_cases_stat@hrf_report_formatter@unit_test@boost@@UAEXAAV?$ basic_ostream@DU?$char_traits@D@std@@@std@@IKK@Z)' in unit_test_result.obj (libboost_test_exec_monitor.lib) Errors caused tool to abort. To me, this suggests some issue regarding libboost_test_exec_monitor.lib . Anyone care to comment? Robert Ramey

2 1

[boost.thread] Experimental alternative TLS implementation
by Roland 19 Aug '04

19 Aug '04

While searching for a method to overcome the intentional memory leak on the windows implementation of tss, I wrote a new shrink wrapped version of tss, for discussion of possible improvements over the current implementation. The proposal will not alter the current interface, but adds the following features: * Completely orthogonal to boost::thread * No memory leaks * Twice as fast for -> operator * Threads may (in principle) live after end of main() Currently this will only work on windows, but it should be possible to port it to pthreads as well with little effort. I have uploaded the file tls_win.zip to the boost filearea on Yahoo. Roland

4 10

[Boost-bugs] [ boost-Support Requests-1012276 ] test framework does not compile on cygwin
by SourceForge.net 19 Aug '04

19 Aug '04

Support Requests item #1012276, was opened at 2004-08-19 08:30 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=1012276&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: test framework does not compile on cygwin Initial Comment: Hello, My e-mail address is : javier.revilla(a)free.fr I am trying to compile Boost on CygWin with gcc 3.3.3. My machine is a Windows 2000 PC. To install Boost I do : bjam "-sTOOLS=gcc" install I cannot compile the Test Framework. I obtain the following error report : gcc-Link-action bin/boost/libs/test/build/libboost_prg_exec_monitor. dll/gcc/debug/libboost_prg_exec_monitor-gcc-d-1_31.dll Chmod1 bin/boost/libs/test/build/libboost_prg_exec_monitor. dll/gcc/debug/libboost_prg_exec_monitor-gcc-d-1_31.dll chmod 755 "bin/boost/libs/test/build/libboost_prg_exec_monitor. dll/gcc/debug/libboost_prg_exec_monitor-gcc-d-1_31.dll" ...failed Chmod1 bin/boost/libs/test/build/libboost_prg_exec_monitor. dll/gcc/debug/libboost_prg_exec_monitor-gcc-d-1_31.dll.. . ...skipped <@boost! lib>libboost_prg_exec_monitor-gcc-d-1_31.dll for lack of <@boost!libs!test!build/libboost_prg_exec_monitor. dll/gcc/debug>libboost_prg_exec_monitor-gcc-d-1_31.dll. .. etc... What should I do ? Thank you very much for your help. Javier Revilla ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1012276&group_… ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

regex bit
by Yitzhak Sapir 19 Aug '04

19 Aug '04

Going on past my previous ETI problems thanks to Dave Abrahams' fix, I now had a problem in regex. In boost/regex/v4/regex_match.hpp, line 149+, we have: #if !defined(BOOST_NO_WREGEX) inline bool regex_match(const std::basic_string<wchar_t>& s, match_results<std::basic_string<wchar_t>::const_iterator, wregex::allocator_type>& m, const wregex& e, match_flag_type flags = match_default) This should be: #if !defined(BOOST_NO_WREGEX) inline bool regex_match(const std::basic_string<wchar_t>& s, match_results<std::basic_string<wchar_t>::const_iterator>& m, const wregex& e, match_flag_type flags = match_default) Otherwise passing a wsmatch to regex_match fails.

2 1

RE: [boost] Re: [boost.test] Patch for true64cxx65 support.
by Rozental, Gennadiy 19 Aug '04

19 Aug '04

> What about > > const_string const LOG_LEVEL = "BOOST_TEST_LOG_LEVEL"; > > That would work too. Is that ok for you? If yes, the File scope const declaration automatically assumes static anyway if I am not mistaken. Update from cvs and let me know how did it work. Gennadiy.

2 1

[signals] trackable object limitations
by Jeff Flinn 19 Aug '04

19 Aug '04

Any changes in 1.32 pertaining to: Warning: User-defined function objects and function objects from other libraries (e.g., Boost.Function or Boost.Lambda) do not implement the required interfaces for trackable object detection, and will silently ignore any bound trackable objects. Future versions of the Boost libraries will address this limitation. Thanks, Jeff

2 1

typeof and ODR
by Arkadiy Vertleyb 19 Aug '04

19 Aug '04

David Abrahams wrote: >We should try this stuff [typeof] out with EDG-based compilers in their >"template repository" link-time-instantiation mode. Also I think >Metrowerks now supports the same thing. These are the most likely >configurations to report problems from ODR violations. Can anybody help me with this? (I do realize that it's not a good timing now, but I just want to see if I can count on it once things get quieter) Thanks in advance, Arkadiy

1 0