http://blog.gmane.org/gmane.comp.lib.boost.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.lib.boost.devel/179321 Dear reader, I've been wanting to implement a future in C++ for some time, and combined some code to come up with the attached. The idea is that the future is a function wrapper around a function call which will call the function in a second thread upon creation. Then at a later moment, the future can yield the return value of the wrapped function (or block until this result is know). I'm happy with the result I got so far. It's a very rough draft, and I would like your help to clean up some details: - I would like to have the Future wrapper work with the boost::function< int (argument, argument)> syntax, but I can't figure out how to get the return type from that syntax to allow for the return value to be defined (the d_result member). - What would be the best way to handle function arguments? Binding all the parameters before passing the resulting bound function object seems like the solution, but is it really the best solution? And last but not least: has this already been done and what is the general opinion within the boost community on having a class like this? Greetings, Bram Neijt Attached are two files, one is the Future class and the second is a test program showing it's general functioning. The output of running the test program should show: Creating future Future thread working Main waiting for 3 seconds Future thread working Future thread working Calling upon future to return Future thread working Future thread working Future thread working Future thread working Future thread working Future thread working Future returned: 9 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Bram Neijt 2008-08-29T23:23:22 http://comments.gmane.org/gmane.comp.lib.boost.devel/179306 Hi all together, I found a very strange example of the memcpy() function on the web page: http://www.boost.org/community/generic_programming.html ---------------------------------------------------------- void* memcpy(void* region1, const void* region2, size_t n) { const char* first = (const char*)region2; const char* last = ((const char*)region2) + n; char* result = (char*)region1; while (first != last) *result++ = *first++; return result; } ---------------------------------------------------------- Perhaps I missed something essential, but usually the memcpy() function returns a pointer to the destination (region1 in this case). The above version of memcpy() returns region1+n. regards Jens ---- Visit us at IFA 2008 / Berlin (Germany), 29 August - 3 September 2008 / Hall 5.3 Booth 17 http://www.hhi.fraunhofer.de/de/veranstaltungen/aktuelle-veranstaltungen/ifa-2008-berlin-germany.html IBC 2008 / Amsterdam (NL), 12 - 16 September 2008 / Hall 8 Booth C81 http://www.hhi.fraunhofer.de/index.php?id=2399&L=1 insite 2008 / Johannesburg (South Africa), Sandton Convention Centre / 15 - 17 September 2008 http://www.insitex.co.za _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Jens Guether 2008-08-29T14:11:47 http://comments.gmane.org/gmane.comp.lib.boost.devel/179291 Hi, I'd like to request a review of my polynomial library which I wrote during Google Summer of Code project this year. The zip file is in Boost Vault (called polynomial.zip). It includes the library, tests and documentation. The same files (not compressed) are also available in sandbox: http://svn.boost.org/svn/boost/sandbox/SOC/2008/polynomial/ Thanks Paweł Kieliszczyk 2008-08-29T15:04:07 http://comments.gmane.org/gmane.comp.lib.boost.devel/179274 Hello, some adaptor ranges need certain constant information about their underlying ranges. For example, iterating over a forward "difference_range", the difference between two sorted ranges, requires access to the ends of the underlying ranges. These two additional iterators are constant, they do not change when the difference_iterator is incremented. Now, where should this additional constant information be stored? a) In the difference_range, and each iterator holds a reference to the difference_range? That requires the difference_range to be alive as long as its iterators are alive. This may be difficult to ensure if the difference_range is a temporary. b) In the iterators, so the lifetime of adaptor iterators is independent of the adaptor range. Of course, one can use shared_ptrs and so on, but still the iterators are ultimately responsible to keep that information available. This initially seemed more natural to me, but if implemented naively by storing the additional iterators in the iterator itself, it leads to storage bloat: each difference_iterator needs 4 instead of 2 of its underlying iterators. When stacking difference iterators, the difference in required storage grows exponentially: instead of 2^N, you need 4^N storage... I feel that in order to solidify the range concept, one needs to make a choice whether a) or b) is "standard", because any user of ranges would need to know. Any thoughts on this? Arno -- Dr. Arno Schoedl · aschoedl< at >think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Arno Schödl 2008-08-29T10:12:44 http://comments.gmane.org/gmane.comp.lib.boost.devel/179259 Hi, It seems like we are missing some of our recent members. -Thorsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Thorsten Ottosen 2008-08-28T09:18:18 http://comments.gmane.org/gmane.comp.lib.boost.devel/179258 As it turns out I think a release() member function should be added to the smart pointer. Its purpose is to give away ownership of the object. See the following pseudo-code: template <typename T> class smart_ptr { ... smart_ptr(element_type *); value_type * get(); element_type * release() { element_type * __p = pointer_ref(); pointer_ref() = 0; if (-- counter_ref()) return 0; else return __p; } }; It follows the same idea of its predecessor auto_ptr<> but will return a null pointer if the object is still shared thus not ready to be deleted. This way the allocator will be much easier to support either by calling this function before deallocate(), inside it or by using a specialized wrapper class to handle it: template <typename T> class allocator { ... typedef smart_ptr<T> pointer; void deallocate(pointer & __p) { delete p.release(); } }; -Phil _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Phil Bouchard 2008-08-28T07:15:57 http://comments.gmane.org/gmane.comp.lib.boost.devel/179256 As it turns out I think a release() member function should be added to the smart pointer. Its purpose is to give away ownership of the object. See the following pseudo-code: template <typename T> class smart_ptr { ... smart_ptr(element_type *); value_type * get(); element_type * release() { element_type * __p = pointer_ref(); pointer_ref() = 0; if (-- counter_ref()) return 0; else return __p; } }; It follows the same idea of its predecessor auto_ptr<> but will return a null pointer if the object is still shared thus not ready to be deleted. This way the allocator will be much easier to support either by calling this function before deallocate(), inside it or by using a specialized wrapper class to handle it: template <typename T> class allocator { ... typedef smart_ptr<T> pointer; void deallocate(pointer & __p) { delete p.release(); } }; -Phil _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Phil Bouchard 2008-08-28T05:07:39 http://comments.gmane.org/gmane.comp.lib.boost.devel/179254 Two quick queries. Would it make sense to have the iterator increment and decrement operators and begin() member function of ptr_vector< nullable<> > skip missing records so that applications have no need to check? What is stopping pointer container classes from being used with opaque types as a compilation firewall? -- Andrew Hain Oasys http://www.oasys-software.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Andrew Hain 2008-08-28T17:12:44 http://comments.gmane.org/gmane.comp.lib.boost.devel/179251 The following patch fixes the mapped_file_test compilation error for msvc 7.1 (daw-msvc71): Index: libs/iostreams/src/mapped_file.cpp =================================================================== --- libs/iostreams/src/mapped_file.cpp (revision 48407) +++ libs/iostreams/src/mapped_file.cpp (working copy) < at >< at > -434,7 +434,7 < at >< at > void mapped_file_source::close() { pimpl_->close(); } -mapped_file_source::operator safe_bool() const +mapped_file_source::operator mapped_file_source::safe_bool() const { return pimpl_->error() ? &safe_bool_helper::x : 0; } bool mapped_file_source::operator!() const David PS Is this the right place to post patches? Should I use Trac instead? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost David Walthall 2008-08-28T16:36:23 http://comments.gmane.org/gmane.comp.lib.boost.devel/179249 Rather than repeating myself too much here I refer the review manager to my two previous posts where I implemented a couple of simple problems using this library. My initial expectation was that I would find the library useful for these problems, but it became clear that the resulting code was no better than an ad-hoc implementation without the use of the library. I was hoping that in the time since then the author or some other reviewer would produce an example that would convince me that there are classes of problems where this library is useful, but no such example has appeared. The main mode of use of this library doesn't seem to offer enough beyond what's possible with a more ad-hoc implementation style to be worthwhile. I note that it also has a more declarative mode (with a state transition table) which I did not evaluate properly. I have not evaluated the implementation. It is sufficient. I have not been convinced that this library is useful. I did not try to compile any of my code. A few hours. Not especially. Actually in a previous life I knew a lot about implementing and optimising FSMs in hardware, but that doesn't really have a lot to do with most software implementations. No, not unless some convincing examples of applications where it is useful can be produced. Regards, Phil. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Phil Endecott 2008-08-28T16:19:52 http://comments.gmane.org/gmane.comp.lib.boost.devel/179246 In the page: http://www.boost.org/doc/tools.html the description of Wave says: A Standards conformant C/C++ preprocessor usable on top of any other compiler. Usable for instance for the debugging of the expansion of macros in your code or as a replacement for your build in preprocessor. ^^^^^^ built- Jonathan Biggar 2008-08-28T04:39:00 http://comments.gmane.org/gmane.comp.lib.boost.devel/179245 The docuemntation page on the website: http://www.boost.org/doc/ only has two subbullets (Boost Jam and Boost Build) under the "Tools" bullet. But if you click on the Tools bullet, you get a longer list: Boost.Build Boost.Jam Regression Inspect BoostBook bcp QuickBook Wave Shouldn't those all appear on the doc page. It took me a while to find the BoostBook documentation because of this. Jonathan Biggar 2008-08-28T04:36:38 http://comments.gmane.org/gmane.comp.lib.boost.devel/179217 The following code does not compile with Boost 1.36 and MSVS 2008: #define BOOST_FILESYSTEM_NO_DEPRECATED #include <boost/filesystem.hpp> In get the following error message: 1>C:\Program Files\Boost\boost_1_36_0\boost/filesystem/convenience.hpp(98) : error C2275: 'boost::filesystem::path' : illegal use of this type as an expression 1> C:\Program Files\Boost\boost_1_36_0\boost/filesystem/path.hpp(49) : see declaration of 'boost::filesystem::path' 1>C:\Program Files\Boost\boost_1_36_0\boost/filesystem/convenience.hpp(100) : error C2275: 'boost::filesystem::wpath' : illegal use of this type as an expression 1> C:\Program Files\Boost\boost_1_36_0\boost/filesystem/path.hpp(65) : see declaration of 'boost::filesystem::wpath' 1>C:\Program Files\Boost\boost_1_36_0\boost/filesystem/convenience.hpp(103) : error C2275: 'boost::filesystem::path' : illegal use of this type as an expression 1> C:\Program Files\Boost\boost_1_36_0\boost/filesystem/path.hpp(49) : see declaration of 'boost::filesystem::path' 1>C:\Program Files\Boost\boost_1_36_0\boost/filesystem/convenience.hpp(105) : error C2275: 'boost::filesystem::wpath' : illegal use of this type as an expression 1> C:\Program Files\Boost\boost_1_36_0\boost/filesystem/path.hpp(65) : see declaration of 'boost::filesystem::wpath' 1>C:\Program Files\Boost\boost_1_36_0\boost/filesystem/convenience.hpp(108) : error C2275: 'boost::filesystem::path' : illegal use of this type as an expression 1> C:\Program Files\Boost\boost_1_36_0\boost/filesystem/path.hpp(49) : see declaration of 'boost::filesystem::path' 1>C:\Program Files\Boost\boost_1_36_0\boost/filesystem/convenience.hpp(110) : error C2275: 'boost::filesystem::wpath' : illegal use of this type as an expression 1> C:\Program Files\Boost\boost_1_36_0\boost/filesystem/path.hpp(65) : see declaration of 'boost::filesystem::wpath' --Johan Råde _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Johan Råde 2008-08-27T15:14:46 http://comments.gmane.org/gmane.comp.lib.boost.devel/179216 Hi, The nightly tests are dying with the error from, apparently, the spirit library. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). error: Unable to find file or target named error: 'qi/confix.cpp' error: referred from project at error: '../libs/spirit/test' Thanks. K. Noel Belcourt 2008-08-27T15:13:50 http://comments.gmane.org/gmane.comp.lib.boost.devel/179215 The formal review for Andrey Semashev's Finite State Machines (FSM) ends today. If anyone is working on a review, please post it no later than Friday. I will post the results of the review early next week. Thanks to everyone who participated in the review. MV _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Martin Vuille 2008-08-27T14:24:25 http://comments.gmane.org/gmane.comp.lib.boost.devel/179209 Below is my sample code to use boost string algorithm in VS2005, using platform Windows Mobile 6 Professional SDK. {code} #define BOOST_NO_STD_LOCALE #include <boost/algorithm/string.hpp> using namespace std; void main(){ vector<string> strList; string str = "aaa, bbb, ccc"; using namespace boost::algorithm; split(strList, str, is_any_of(" ,")); } {code} The compilation fails, because Windows Mobile 6 Professional SDK doesn't have <locale> file. I found "boost\algorithm\string\classification.hpp" this file always includes <locale> file, even that BOOST_NO_STD_LOCALE is defined before. Is there any way to use string algorithm without the existence of std locale file? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Miki 2008-08-27T13:34:39 http://comments.gmane.org/gmane.comp.lib.boost.devel/179203 I like this idea of having many release managers worry about the releasing of suitably tested and properly packaged point/major releases of the library. This way boost library authors can concentrate on maintaining a single version of the library -- the one in trunk for example -- which passes a test suite and performs as expected. What I see though is that the problem with this approach is/are the following: * Changes to libraries can only be made by library authors/maintainers, so if a bug is filed against a certain release (1.35 for example) fixing it would be the responsibility of the authors/maintainers of the library on that branch/release. If it was possible to have bugs fixed by others in a given branch and changes are licensed under the Boost Software License, then letting the authors/maintainers worry about the latest and greatest version of their libraries would be feasible -- and changes from releases are then submitted 'upstream' to be integrated to 'trunk'. * Currently, a release branch is cut from the previous release branch and changes for individual libraries are cherry picked and merged "as seen fit" by authors/maintainers. If it was possible to cut a major release branch from trunk and let a team do the cherry picking of changes that get into trunk back into the major release branch, then the quarterly release can still happen -- one team maintains 1.36 (stable), another 1.37 (latest). Debian has the same process of having a 'stable' branch which lives on its own and has a team managing it (and bug fixes that need to go out), an 'unstable' branch which has the greatest flux but lots of testing as well, and a 'testing' branch which eventually comes from 'unstable' to get merged with (and becomes) 'stable'. Changes from 'unstable' that pass the testing criteria are then merged to 'testing', gets tested, and once it passes gets merged into 'stable'. * Back-porting changes from trunk to point releases as well as 'up-streaming' a patch from point releases to trunk is a tedious process which can only be managed by people other than the library authors/maintainers. This opens up the possibility of greater contribution and opportunity for those who want to contribute to be able to do so without having to contend with the authors'/maintainers' time and bandwidth. If we let authors/maintainers of libraries concentrate on making the libraries better -- supporting new features, experimentation, testing, etc. -- instead of asking them to do the merge and maintenance of released versions, maybe we can stick with the quarterly releases branching from trunk, and letting released versions get maintained at their own pace. We can then start retiring older versions of the library and mark them as 'unsupported' after a certain period of time without having to ask authors/maintainers to keep worrying about previous releases and users of these previous releases. One possibility in this regard is to encourage the use of virtual machines in the testing of libraries. Although severely limited, for instance testing of Sun compilers on OpenSolaris and Intel compilers in Linux can be done inside a Virtualbox/VMWare image. Interested testers would just have to set these virtual machines up and offer them as downloads somewhere that people can play around with. One thing that comes to mind is testing of specific compiler versions Dean Michael Berris 2008-08-27T09:29:43 http://comments.gmane.org/gmane.comp.lib.boost.devel/179197 I am unclear of what the vault contains, and of its relation to the sandbox. The sandbox is a versioned repository, whereas the the vault appears not to be. What is the workflow here, if there is one? By what path do libraries arrive at Boost proper (ie. part of some release), and where in the process are the review points? Thanks, Rob. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Robert Jones 2008-08-27T08:36:33 http://comments.gmane.org/gmane.comp.lib.boost.devel/179196 Some time ago i had noticed some strange behavior in the boost pool_allocator regarding its memory usage. Now that i've found these great mailinglists ;) i've reproduced the error and with some additional analysis i can post the thing here. My environment: - VS2005 - Windows XP - Boost 1_34_1 with BOOST_ALL_DYN_LINK set (if it makes a difference) - Running release build The test code: { std::pair<int, int> pairStart(m_spLeakDetection->ReportLeaks(_T("boost test 1a"))); { std::vector<int> v; std::pair<int, int> pairInterim2(m_spLeakDetection->ReportLeaks(_T("boost test 1b"))); //0 bytes (only stack memory used) for (int i = 0; i < 1000; ++i) { v.push_back(5); } std::pair<int, int> pairInterim3(m_spLeakDetection->ReportLeaks(_T("boost test 1c"))); //4264 bytes in 1 block v.clear(); } std::pair<int, int> pairInterim4(m_spLeakDetection->ReportLeaks(_T("boost test 1d"))); //0 bytes } { std::pair<int, int> pairStart(m_spLeakDetection->ReportLeaks(_T("boost test 2a"))); { std::vector<int, boost::pool_allocator<int> > v; std::pair<int, int> pairInterim2(m_spLeakDetection->ReportLeaks(_T("boost test 2b"))); //0 bytes (only stack memory used) for (int i = 0; i < 1000; ++i) { v.push_back(5); } std::pair<int, int> pairInterim3(m_spLeakDetection->ReportLeaks(_T("boost test 2c"))); //16312 bytes over 7 blocks; 136, 264, 520, 1032, 2056, 4104, 8200 v.clear(); } std::pair<int, int> pairInterim4(m_spLeakDetection->ReportLeaks(_T("boost test 2d"))); //still 16312 bytes over 7 blocks boost::singleton_pool<boost::pool_allocator_tag, sizeof(int)>::release_memory(); std::pair<int, int> pairEnd(m_spLeakDetection->ReportLeaks(_T("boost test 2e"))); //8112 over 6 blocks; 136, 264, 520, 1032, 2056, 4104 { std::vector<int, boost::pool_allocator<int> > v; for (int i = 0; i < 10; ++i) { v.push_back(5); } std::pair<int, int> pairInterim3(m_spLeakDetection->ReportLeaks(_T("boost test 2f"))); //8112 over 6 blocks; 136, 264, 520, 1032, 2056, 4104 v.clear(); } { std::vector<int, boost::pool_allocator<int> > v; for (int i = 0; i < 1000; ++i) { v.push_back(5); } std::pair<int, int> pairInterim3(m_spLeakDetection->ReportLeaks(_T("boost test 2g"))); //24504 bytes over 7 blocks; 136, 264, 520, 1032, 2056, 4104, 16392 v.clear(); } } - why does the boost::pool_allocator reserve 16312 bytes for 1000 int's while the default stl vector consumes (only) 4264 bytes? - why does a call to release_memory( ) not remove all the memory allocations done by the pool_allocator? But only the last block? - why does the size of each new block gets duplicated in size (even after release_memory)? Does this make sense to any of you? Best regards, Paul _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Paul Bormans 2008-08-26T18:44:14 http://comments.gmane.org/gmane.comp.lib.boost.devel/179180 Hello, When dealing with a signature of void return type, the Boost.Signals version of last_value only returns last_value::unusable when the compiler doesn't support void returns: http://svn.boost.org/trac/boost/browser/trunk/boost/last_value.hpp#L34 But the thread-safe version always returns last_value::unusable: http://svn.boost.org/trac/boost/browser/sandbox/thread_safe_signals/boost/last_value.hpp#L68 Could the thread-safe version be made consistent with Boost.Signals? Thanks, Stjepan _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Stjepan Rajko 2008-08-26T21:44:33 http://comments.gmane.org/gmane.comp.lib.boost.devel/179167 Hello, I found the following problem when using BOOST_MPL_ASSERT_MSG under Visual Studio 2005 Express Edition: * Create a basic console project * Include files foo1.cpp and foo2.cpp (files attached) * Build; the following error shows up at linking time: * * * * * * * * * * * * (__thiscall `bool __cdecl f<int>(void)'::`2' ::ALWAYS_TRUE::** * * * * * * * * * * __cdecl `bool __cdecl f<int> (void)'::`2'::ALWAYS_TRUE0::assert_arg(void))(int)" (?assert_arg< at >ALWAYS_TRUE0< at >?1???$f< at >H< at >< at >YA_NXZ< at >SAPAPAPAPAPAPAPAPAPAPAPAP8<mailto:?assert_arg< at >ALWAYS_TRUE0< at >?1???$f< at >H< at >< at >YA_NXZ< at >SAPAPAPAPAPAPAPAPAPAPAPAP8> ALWAYS_TRUE< at >?1???$f< at >H< at >< at >YA_NXZ< at >AEPAPAPAPAPAPAPAPAPAPAPAPAUfailed< at >mpl< at >boost< at >< at >H< at >ZXZ<mailto:ALWAYS_TRUE< at >?1???$f< at >H< at >< at >YA_NXZ< at >AEPAPAPAPAPAPAPAPAPAPAPAPAUfailed< at >mpl< at >boost< at >< at >H< at >ZXZ>) already defined in foo1.obj This duplication problem happens only when BOOST_MPL_ASSERT_MSG is used at function or member function level. At class level everything works OK. Has anyone seen this before? I've created a ticket for this issue: http://svn.boost.org/trac/boost/ticket/2262 Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarollo #include "foo.hpp" static bool b=f<int>(); #include "foo.hpp" static bool b=f<int>(); int main(){} #include <boost/mpl/assert.hpp> #include <boost/type_traits/is_same.hpp> template<typename T> bool f() { BOOST_MPL_ASSERT_MSG( (boost::is_same<T,T>::value), ALWAYS_TRUE, (T)); return true; } _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost JOAQUIN M. LOPEZ MUÑOZ 2008-08-26T16:28:58 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.boost.devel