- Boost - lists.boost.org

[vault] or maybe sandbox?
by Robert Jones 30 Aug '08

30 Aug '08

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.

6 7

Opinion and help with implementing futures
by Bram Neijt 30 Aug '08

30 Aug '08

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

2 1

Proto<markus>::review()(proto::accept);
by Markus Werle 30 Aug '08

30 Aug '08

Hi! I think Proto should be accepted for inclusion into boost. A general purpose Expression Template library is hard to write. Proto is the most sophisticated and closest approach to perfection available today. - What is your evaluation of the design? Proto is well-designed in many aspects, though I got the impression that some beauty and purity was sacrificed on the altar of compile-time efficiency, but that's OK. (And yes, I hate BOOST_PP_MACROS!) Proto catches the most important issues of a general purpose expression template library, I especially like the way how expression storage and expression evaluation is strictly separated and the way I can add my own functionality. Proto covers the most important aspects of an ET library, sometimes in very elegant ways. Proto's design adressed compile time issues. That's a value in itself. OTOH: Transforms leave me with mixed feelings. I am not very good at catching ideas without good step-by-step documentation and I got messed up with grammars vs. transforms. This part of proto is new and it looks like a candidate for rework. I'd like to have an extra review in half a year only on the grammar and transform part of proto (*)[comment below]. That's a DSEL all by itself and I guess that interface may have some pitfalls. Larry Evans has worked that out in detail. There may be issues in the naming convention used there, e.g. I am unsure whether and_ is the appropriate name for what it does. - What is your evaluation of the implementation? None. Not enough time. Steven Watanabe did it for us all. Code looks clean. For my taste too many levels of nested namespaces, but that's the boost trend at the moment. I may appreciate this style later in my life, once I understand why you need it. - What is your evaluation of the documentation? The quality varies from excellent to hard to read. I agree with all what David writes about the docs. There is some potential for improvement, but that should not hinder the inclusion into boost: we need a community effort here since Eric's skill level probably is way too high in order to have some feeling for why the unaware might have problems with parts of the doc. The teacher should be one step ahead, not too far ahead. - What is your evaluation of the potential usefulness of the library? We really, really need this. Better today than tomorrow. The whole world is waiting for this to come. And C++ again rocks - Did you try to use the library? A couple of hours, but only for some of the examples. - With what compiler? VC8, Intel 10.1 - Did you have any problems? Nope. Eric-faster-than-lightning fixed those before I could run into them ... - How much effort did you put into your evaluation? I read the docs three times and worked through some details. I investigated the type representation of expressions by reading purposely generated compiler error messages and tried to figure out the design. - Are you knowledgeable about the problem domain? I had several attempts to write some kind of ET library on my own, some parts published at daixtrose.sourceforge.net. I also planned to write something like proto myself, but due to lack of time and programming skills I lost the race before it began. (rm -rf /work/markus/ideas/expresion_templates_revisited) Eric, thanks for the time saved by the publication of proto. Markus P.S. This review is short, sorry. I had some unexpected tasks to do the last week which hindered further investigation. I'll put some more effort into this in the future. (*) I'd like to have an extra review on _every_ boost library in a 2-year-cycle. By this boost::multi_array could probably be forced to model assignable like any other STL container and ::_1 from boost::bind will move into its own namespace - just to mention my two favourite change requests ...

3 3

Re: [boost] [filesystem][xpressive] Hotfix patches available for 1.36.0
by Eric Niebler 29 Aug '08

29 Aug '08

Michael Marcin wrote: > If the > fixes are not critical enough to justify making a point release than > they should wait until the next release. So you're against hotfixes. <shrug> I would say, take the hotfix if you are experiencing the problem addressed by the hotfix. Otherwise, wait for the next release. -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

[filesystem] BOOST_FILESYSTEM_NO_DEPRECATED
by Johan Råde 29 Aug '08

29 Aug '08

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

2 1

Enabling fast swap optimization for Boost types VC9 SP1.
by Michael Marcin 29 Aug '08

29 Aug '08

The VC team recently released an update to the VC9 standard library that allows them to take advantage of types with fast swap when performing operations like vector realloc. However it appears this optimization is guarded by a trait that must be specialized. Could we specialize std::_Move_operation_category for this version of VC9 to enable this optimization for boost types that can benefit from it? http://tinyurl.com/6h298c Thanks, Michael Marcin

5 19

[filesystem][xpressive] Hotfix patches available for 1.36.0
by Beman Dawes 29 Aug '08

29 Aug '08

Hotfix patches are available to fix Boost.Filesystem and Boost.Xpressive [1.36.0] problems. See https://svn.boost.org/trac/boost/wiki/ReleasePractices/HotFixes Providing hotfix patches is something new and experimental for Boost. Please let us know if you find the patches useful or have other comments. Thanks, --Beman

1 0

Removing class type from member function signature. [probably: function_types] [repost]
by Fabio Fracassi 29 Aug '08

29 Aug '08

Hi, I'm sorry, this is a repost of a message I send to boost user, with a somewhat more restrictive subject. I didn't get any input there, and I hope that someone can help me here. I'm currently trying to wrap (or forward) a call to boost::signal<A_func_Signature>::connect(), to - amongst other things - insulate users from using boost::bind. So what I have is something like this: template< typename Signature, class Reciever > void connect( const signal_id& id, const Signature& sig, const Reciever* rcv ) { typedef ???? AdaptedSignature; get_signal< AdaptedSignature > ( id ) -> connect(boost::bind(sig, rcv, _1)); } now this code is supposed to be called like this: connect( some_signal_id, &SomeClass::some_member, someClass_instance ); where SomeClass::some_member has the same function signature as the signal which is associated with some_signal_id. e.g. boost::signal<void (bool)> signal; struct SomeClass { void some_member(bool b); }; So my question is how can I construct the "AdaptedSignature" type from the template deduced "Signature"? From what I gather from the documentation, boost function_types might hold the answer to my question, but I cannot figure out how. So is what I am trying to do possible, and is function_types the right tool? TIA Fabio

1 1

strange memcpy example
by Jens Guether 29 Aug '08

29 Aug '08

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/if… 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

1 0

Memoryleaks in boost::pool_allocator
by Paul Bormans 29 Aug '08

29 Aug '08

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(); } } >From these tests; - 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/

2 3