- Boost - lists.preview.boost.org

[asio] read_until -- possibly misleading documentation?
by Richard Smith 15 Apr '10

15 Apr '10

The documentation for Boost.ASIO (which is otherwise very comprehensive) says of the boost::asio::read_until set of overloads: | Read data into a streambuf until a delimiter is | encountered. <http://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/reference/read_unt…> What the function actually does is to read blocks of data into the streambuf, and stop when the delimiter is found. This means that frequently data beyond the delimiter will be read into the streambuf. (And this is elaborated in more detail on the individual function's pages, if a reader looks there.) I appreciate that this behaviour is compatible with the documentation, but someone less familiar with ASIO could easily assume that the function will read as far as the delimiter and no further. (And I have just spent a fair amount of time debugging a piece of code where the author had made this assumption.) Could we change the summary documentation to read something like: | Read data into a streambuf at least until a delimiter is | encountered. The implementation may read beyond the | delimiter, but will not block when doing so. While I'm on the subject of ASIO documentation, I can't see any documentation on whether the service_name parameters to the basic_resolver_query constructors are allowed to be port numbers (e.g. "80") or whether they have to be symbolic names (e.g. "http"). Port numbers work, at least on Linux, but it's not clear whether this is something that I should be relying on. Similarly for IPv4 and IPv6 addresses in the host_name parameter. Richard Smith

3 2

[contract] concepts (was "Contract Programming Library")
by Lorenzo Caminiti 15 Apr '10

15 Apr '10

On Wed, Feb 17, 2010 at 4:05 AM, Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: >> > it is inevitable, etc., but.. read on. I know at least one library in >> > Boost that also spoils function declarations in order to provide >> > additional functionality: Concept Check library; they may be others >> > too (MPL?). >> > My suggestion is that if there are (or will be) libraries that require >> > spoiling function declarations, they should all provide the same >> > "spoiled" syntax. Otherwise I will be always asking "how do I declare >> > a function in this library?". It would be very convenient if Boost >> > provided one alternative function definition syntax that when used >> > would enable all its libraries to work. >> >> I agree. However, in the past I did look into harmonizing my library >> API with the ones of Boost.ConceptCheck and/or Boost.Parameter but it >> did not seem feasible... I will double check it. > > This is not only about clarity. As a super-correct programmer I may want to > apply both concept checking and pre-/post-conditions checking to my functions. > > Perhaps, if the 'compromise' syntax is possible, it requires changing > concept-checking library. I have verified that it is possible to use Boost.ConceptCheck together with the current implementation of Boost.Contract as shown below. I will look into doing something similar also for Boost.Parameter. #include <boost/concept_check.hpp> #include <boost/concept/requires.hpp> #include <contract.hpp> #include <iostream> struct x { CONTRACT_CLASS( (x) ) template<typename T> BOOST_CONCEPT_REQUIRES( ((boost::Integer<T>)), (int)) f(const T& x) CONTRACT_FUNCTION( (public) (template)( (typename)(T) ) (int) (f)( (const T&)(x) ) (precondition) ({ CONTRACT_ASSERT( x >= 0 ); }) (postcondition) (result) ({ CONTRACT_ASSERT( result == x ); }) (body) ({ return x; }) ) }; int main() { x xx; std::cout << xx.f(123) << std::endl; // OK: Passes both concept and contract checks. // std::cout << xx.f(1.23) << std::endl; // Error: Fails concept check (compile-time). // std::cout << xx.f(-123) << std::endl; // Error: Fails contract precondition check (run-time). return 0; } This works because CONTRACT_FUNCTION() follows the function declaration which can be spoiled by BOOST_CONCEPT_REQUIRES() as usual to support concepts. However, I am planning to change CONTRACT_FUNCTION() so the function declaration tokens do not need to be repeated and I will add concept support following ConceptC++ syntax: CONTRACT_FUNCTION( (public) (template)( (typename)(T) ) (requires)( (boost::Integer<T>) ) (int) (f)( (const T&)(x) ) (precondition)( (x >= 0) ) (postcondition)(result)( (result == x) ) ({ return x; }) ) This will call Boost.ConceptCheck behind the scenes. Even after this change to CONTRACT_FUNCTION(), Boost.Contract will still provide a CONTRACT_FUNCTION_DEF() that will follow the function declaration (as the current implementation of CONTRACT_FUNCTION() does). Therefore, the example above where Boost.ConceptCheck is used directly can still be programmed using the DEF() macro. Lorenzo

1 0

[date_time][patch] #2757: Warning C4244: conversion from 'int' to 'unsigned short' in microsec_time_clock.hpp line 103
by Sylvester-Bradley, Gareth 15 Apr '10

15 Apr '10

Ticket #2757 describes a simple patch for Boost.Date_Time to get rid of some annoying compiler warnings. Is anyone actively maintaining Boost.Date_Time? This patch has been sitting there for 6 releases already... https://svn.boost.org/trac/boost/ticket/2757 Thanks. ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

2 1

[contract] importance ordering (was "diff n1962")
by Lorenzo Caminiti 14 Apr '10

14 Apr '10

Hello all, On Thu, Apr 8, 2010 at 7:26 PM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: > Below is a summary of the differences between Boost.Contract and the > Contract Programming C++ standard proposal n1962. I know some of the > authors of n1962, and also of its previous revisions, are on this > mailing list -- I hope that they can provide comments at least. > > [n1962] Crowl and T. Ottosen, Proposal to add Contract Programming to > C++ (revision 4), The C++ Standards Committee, 2006. All previous > revisions of this proposal are also relevant (and related authors > comments encouraged). I would like to ask: Should Boost.Contract support assertion importance ordering? Importance ordering was introduced in revision 3 of the CP C++ standard proposal but then removed in revision 4: * From n1866 (n1962 revision 3) section 2.1.2 << default assertions syntax: 1. runtime-assertion : boolean-expression importance-ordering opt ; 2. importance-ordering : : integer-constant 8. Importance ordering allows users to specify multiple levels of assertions. The higher an integer, the more crucial it is to keep an assertion in the object code. 9. The default importance ordering is 0 and is in effect when no integer is specified.>> * From n1962 (revision 4) <<Removed the notion of "importance ordering" [10]. [10] (1, 2) In many contexts it is useful to inform the compiler of certain properties. This is true for efficient garbage collection as well as Contract Programming. The same mechanism may be reused to tag a piece of code with some property; in this case we would like to tag individual assertions.>> For example: void f(int x) precondition { x >= 0 : 100; // Importance ordering 100. find(v.begin(), v.end(), x) != v.end(); // Default importance ordering of 0. } ... And in Boost.Contract the syntax: CONTRACT_FUNCTION( (void) (f)( (int)(x) ) (precondition) ( ( x >= 0 )(importance)(100) // Importance ordering 100. ( find(v.begin(), v.end(), x) != v.end() ) // Default importance ordering of 0. ) ... ) Boost.Contract could then provide an API to say "compile and check only assertions with importance ordering within <user-specified-range>". One use case for this is to tag assertions that are expensive to check with a lower importance so they can be disabled selectively to achieve better performance trade off (this was suggested by Andrzej). [Mitchell2002] addresses this use case recommending to never program expensive assertions in preconditions because they will likely be part of production releases (while expensive assertions in postconditions and possibly invariants are acceptable because they, and their run-time overhead, will be removed from production releases). However, this is a binary approach whereas importance ordering would provide a more granular control tool to achieve better performance trade-offs. I would personally recommend for Boost.Contract to support importance ordering -- what do you think? Thank you. Lorenzo

2 1

Re: [boost] [range] iterator_range::operator[] broken
by Eric Niebler 14 Apr '10

14 Apr '10

Neil, let's keep this discussion on-list. It's important. On 4/14/2010 12:21 AM, Neil Groves wrote: > On Wed, Apr 14, 2010 at 7:13 AM, Eric Niebler <eric(a)boostpro.com> wrote: > >> On 4/13/2010 8:03 PM, Steven Watanabe wrote: >>> AMDG >>> >>> Eric Niebler wrote: >>>> Neil, I know you patched this a mere 5 hours ago, but it's still broken. >>>> The attached patch *really* fixes the problem, I think. >>> >>> Whoa. Why is this only returning a real reference for pointers? >> >> Yeah, I dunno. It's this way on the release branch, too. It's very, very >> seriously broken. I think we need to revert range on the release branch >> to the 1.42 version, and fast. >> > I would much prefer to revert just iterator_range.hpp as the change to > handle iterator proxies is orthogonal to the other changes. The change as > applied attempts to leverage the same mechanism as is used in the > iterator_facade to provide a real reference or a proxy where appropriate for > the index operator. It is a breaking interface change in a core library. What is the technical reason for it? >> Neil? >> > I need to take another look at the code and perhaps the operator[] of > iterator_range is broken, but I believe that this issue aside that the other > changes are working well. It would be extremely disappointing to revert all > of the adaptors, and algorithms just because of this issue. I'm more than > happy to fix the problem as soon as I can. I'm seeing massive breakages all over trunk and release, not all of which are related to the changed return type of iterator_range::operator[]. For instance, there seems to be some new ambiguity in the "detail" symbol. See for instance: http://beta.boost.org/development/tests/release/developer/output/RW_WinXP_V… I can't be certain at this point if RangeEx is responsible, but it's where I would start looking. Could you have a look and report back? == Volunteers Needed === If anybody else is reading this: please look at the regressions on the release branch here: http://beta.boost.org/development/tests/release/developer/summary.html. Pick a broken library that interests you and figure out why it's busted. Report back. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 3

Re: [boost] Crypto Proposal
by Chad Seibert 14 Apr '10

14 Apr '10

Straight from the maintainer. Hi Chad, I don't think I would be comfortable with this; past conversations on the list have suggested a sizeable population of the users is avoiding boost for one reason or another and there was some pushback in terms of even using boost in the library in a way that would require it for basic functionality. This change would leave these users high and dry. I'll admit I perhaps didn't read your proposal as carefully as I should have; I had been under the impression that you would be creating more or less a boost.crypto that provided crypto functionality that happened to use botan internally but did not expose much or any of botan's API directly. Sorry for the miscommunication/mess. :( -Jack I don't know what this means in terms of the project - whether we'll go with a different project or just borrow bits from Botan. I am truly sorry I didn't look into this earlier; it was entirely my fault and I apologize for not looking into this issue earlier. Chad Seibert _________________________________________________________________ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

3 2

Re: [boost] Crypto Proposal
by Chad Seibert 14 Apr '10

14 Apr '10

Thanks for all the feedback! > On 11/04/2010 7:25 PM, Rob Riggs wrote: > On 04/11/2010 10:53 AM, Chad Seibert wrote: >> Here's an example of boostified code, from one of the examples on the >> site. It's not too different from the original code (it's just >> commented out); this is because I don't want it to be a chore to port >> from Botan to Boost.Botan. Also, it is intuitively designed and I see >> no reason to change it. Of course, if it needs redesigning, we can >> discuss that afterwards > ... >> //std::auto_ptr<PKCS8_PrivateKey> >> privkey(PKCS8::load_key(arg_ca_key, rng, arg_passphrase)); >> std::auto_ptr<boost::botan::pkcs8::private_key> >> privkey(pkcs8::load_key(arg_ca_key, rng, arg_passphrase)); > Hi Chad, > > Would it make sense to have privkey() return the private key by value? > Is it non-copyable? > I think the reason is because a PKCS#8 key can be RSA/DSA or whatever else. > I'd like to be able to hold keys by value but I'm not sure whether that > is useful. I can't really see a need to copy keys around, but then again > who knows? > A Boostified Botan should consider this problem as Botan requires the > use of lots of yucky pointers in places because of the polymorphism. It's returned by pointer, since private keys are memory locked by SecureVector (see http://files.randombit.net/botan/doxygen/html/namespaceBotan_1_1PKCS8.html) to prevent flushing to disk (and other potential bugs noted here: http://files.randombit.net/botan/doxygen/html/secmem_8h-source.html) A bigger issue I see is AlgorithmIdentifier/OID mess I see in http://files.randombit.net/botan/doxygen/html/namespaceBotan.html#378aea09f…. Definitely needs to get replaced with something else. There is some rational reasoning with this, though. For example, when we load a pksc#8 key, we get an algo id, which leads to a huge if/else if statement (http://files.randombit.net/botan/doxygen/html/namespaceBotan.html#378aea09f…) It's also dependent on which libraries get build (the BOTAN_HAS_* defines). In any case, it's still far from perfect and needs to be thoughtout. I'll think about it, and get back to you. > On 12/04/2010 7:52 AM, Domagoj Saric wrote: > IMNHO that's a failed test by any standard (worse than OpenSSL and Crypto++)... > (must I really pay for e.g. virtual inheritance, dynamic_casts, > by-std::string-runtime-algorithm-lookups etc. etc... for such a simple use > case?)... > 1) If you write such simple applications, you are very lucky > 2) I think one "issue" on Botan for Windows is the entropy gatherer. > It's slow and takes a lot of memory if.. memory serves. For applications > where entropy is not THAT important, I replace it. For applications > where it IS important, I would take out life insurance. That's because you built Botan in whole; it has the ability to build only parts of itself. If we don't like the inheritance structure, I can certainly remove it when porting. For example, despite public keys being very similar in structure, they should NOT inherit from a common base simply because they are entirely different objects. Also, I certainly agree that the runtime lookup of algos is REALLY BAD and doesn't take advantage of the IH, as noted above. I agree it needs to be replaced. As for the RNG's they are easily swapped, so maybe a less expensive one should be created in the process? >> From this I gather that the original author plans to continue to develop and > maintain the original library, in which case I wonder what would be the purpose > of having a library that is nothing more but a 'parallel' 'boostified' version > of the original that in itself offers nothing new and is updated only after the > original one is updated? > I also think it is useless if Jack does not intend to treat the Boost > version as *the* version. > However, in the transition period, I think it is only sensible that the > student manually merges changes. Will take some planning... I agree that this version should become *the* version, but I was completely absent-minded and didn't bring that up when discussing this with him. I'll ask him ASAP. Hopefully this alleviates some issues, Chad Seibert _________________________________________________________________ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

3 2

FW: deadline_timer and a crash at ~io_service -> timer_base::destroy()
by Vance Grkov 14 Apr '10

14 Apr '10

Hi, I am getting a crash at the scope end (before the "catch") below in the code. This is the stack trace and the source. Does anyone know what is the problem with this code? Appreciate your help! 000801c7() > BoostThreadPoolTest.exe!boost::asio::detail::timer_queue<boost::asio::time_traits<boost::posix_time::ptime> >::timer_base::destroy() Line 211 + 0xe bytes C++ BoostThreadPoolTest.exe!boost::asio::detail::timer_queue<boost::asio::time_traits<boost::posix_time::ptime> >::destroy_timer_list(boost::asio::detail::timer_queue<boost::asio::time_traits<boost::posix_time::ptime> >::timer_base * & t=0x00338da0) Line 415 C++ BoostThreadPoolTest.exe!boost::asio::detail::timer_queue<boost::asio::time_traits<boost::posix_time::ptime> >::destroy_timers() Line 189 C++ BoostThreadPoolTest.exe!boost::asio::detail::win_iocp_io_service::shutdown_service() Line 148 + 0x2c bytes C++ BoostThreadPoolTest.exe!boost::asio::detail::service_registry::~service_registry() Line 75 + 0xf bytes C++ BoostThreadPoolTest.exe!boost::asio::detail::service_registry::`scalar deleting destructor'() + 0x2b bytes C++ BoostThreadPoolTest.exe!boost::asio::io_service::~io_service() Line 52 + 0x2e bytes C++ BoostThreadPoolTest.exe!wmain(int argc=1, wchar_t * * argv=0x003371d8) Line 152 + 0x27 bytes C++ BoostThreadPoolTest.exe!__tmainCRTStartup() Line 583 + 0x19 bytes C BoostThreadPoolTest.exe!wmainCRTStartup() Line 403 C kernel32.dll!_BaseProcessStart@4() + 0x23 bytes #include "stdafx.h" #include <iostream> #include <boost/thread.hpp> #include <boost/bind.hpp> #include <boost/shared_ptr.hpp> #include <boost/asio.hpp> #define THREAD_POOL_SIZE 10 void TimerCallback(boost::system::error_code ec, std::size_t i, std::size_t retry) { std::stringstream tmp; tmp << "Timer(" << ec.value() << ":" << ec.message() << "-" << retry << "-" << i << ")\n"; } // // MAIN // int _tmain(int argc, _TCHAR* argv[]) { try { boost::asio::io_service io(THREAD_POOL_SIZE); boost::asio::io_service::work *moreWorkToCome = new boost::asio::io_service::work(io); // Create a pool of worker threads. std::vector<boost::shared_ptr<boost::thread> > threads; for (std::size_t i = 0; i < THREAD_POOL_SIZE; ++i) { boost::shared_ptr<boost::thread> thread(new boost::thread( boost::bind(&boost::asio::io_service::run, &io) )); threads.push_back(thread); } // Lets enqueue more tasks to run after a given time std::vector<boost::asio::deadline_timer *> timers; for (std::size_t i = 1; i<50; i++) { boost::asio::deadline_timer *timer = new boost::asio::deadline_timer(io); timer->expires_from_now(boost::posix_time::seconds(3)); timer->async_wait(boost::bind(&TimerCallback, boost::asio::placeholders::error, i, 0)); timers.push_back(timer); } std::cout << "\nALL TASKS QUEUED\n"; // Now that all tasks have been queued we don't want to hold on any of the worker threads delete moreWorkToCome; std::cout << "\nRELEASE THE THREAD POOL\n"; // Wait for all tasks to be processes which also means all threads in the pool will exit. for (std::size_t i = 0; i < threads.size(); ++i) threads[i]->join(); // Cancel all timers (just in case) for (std::size_t i = 0; i < timers.size(); ++i) timers[i]->cancel(); io.stop(); std::cout << "\nPOOL DOWN\n"; } <-------------------------------------------- CRASH catch(...) { std::cout << "ERROR"; } std::cout << "\nEXIT\n"; return 0; } Hotmail: Trusted email with powerful SPAM protection. Sign up now. _________________________________________________________________ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969

2 1

[range] iterator_range::operator[] broken
by Eric Niebler 14 Apr '10

14 Apr '10

Neil, I know you patched this a mere 5 hours ago, but it's still broken. The attached patch *really* fixes the problem, I think. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 4

[GSoC] Boost.Matrix RFC
by Kornel Kisielewicz 14 Apr '10

14 Apr '10

Hello all, Last year I submitted a proposal for Boost.Matrix as a GSoC project, that provoked quite a bit discussion. Considering the fact that it wasn't unanimously rejected, and that a few things have changed since then (Boost.Geometry acceptance) as did my skills, I'd like to take the liberty of resubmitting my proposal to the list, with a request for comments. The proposal follows: == Boost.Matrix == uBLAS is Boost's general linear algebra library, and it is a fine library indeed. However, in some cases it's design decisions, while quite rational for the general use case, are restrictive. This proposal is about a new library that would address some of these issues in the specific situation of vector and matrix operations on fixed sized structures. Suggested is a new library boost::matrix. The library would introduce a single container class that allows representation of fixed size vectors and matrices, and their respective standard operations. The library would define the following template template<typename T, std::size_t Rows, std::size_t Cols, class Traits> matrix and standard operations on it. The class would make heavy use of template specialization to allow efficient vector operations (matrices with size 1xN ), and provide efficient operations for the common sizes (2-4). The class will provide the interface of STL containers with the exact concept depending on the Traits used. Care will be taken to allow transparent usage within STL and other boost libraries. In general, this library would be similary scoped as Boost.Quaternion. Recently a new library has been accepted into boost -- Geometry. As the library is deeply about matrices and vectors, and has much in common with this proposal, I'd like to take a deep focus on providing maximum interopeability between Geometry and Matrix. == Rationale == Boost.Matrix aims to be for uBLAS, what Boost.Array is for vectors - a fixed size version to remove the overhead. The need is however greater, because while uBLAS provides a template for a fixed-sized version of it's arrays, the template is just a cover for the original uBLAS matrices. While the performance is comparable, the size includes a unnecessary field size. In cases that make heavy use of fixed sized matrices and vectors ( like real-time computer graphics ), such a tradeoff is unacceptable - due to increased memory consumption as well as effective vectorized math operations, and alignment of structures passed ( a single 4D vector should effectively fit a 128 bit register, and a single 128 bit move operation ). Also, knowing the dimensions of a matrix/vector at compile time, allows for a more efficient operation implementation, both from the programmers side ( better algorithms ), as well as from the compilers side (optimization). Finally, the uBLAS introduces a lot of unneccessary bloat for users wanting only a 2,3,4 vector and 3,4 matrix classes. == Primary deliverables == Boost.Matrix library, with the following features: * a boost::matrix base container class for 2-dimensional matrices, with the proper behavious and semantics of a container, written following the boost coding guidelines, and with full portability in mind * specializations for efficient vector (1xN matrix) handling * operators for readable but efficient vector/matrix math * operator specializations for matrices and vectors of the most common size (2-4) for most efficient implementation * efficient implementation of interoperability of Boost.Matrix with other boost libraries (uBLAS, Quaternion and upcoming Boost.Geometry in particular) == Secondary deliverables == * performance test suite, for testing optimizations * unit tests for the whole library providing full operation coverage and code-coverage * documentation for the whole library in the BoostBook format, as well as doxygen markup for all the code == Bonus deliverables == ( if time allows these will be delivered during program timeline, if not, they will be implemented afterwards ) * performance tests on different compilers/architectures, further optimizations * support for further boost libraries ( Boost.Assign, sandbox libraries, etc. ) == Design issues == * compile-time concept checking to only generare functions that make sense for the given type ( no floating point operations for integral types ) * usage of template expressions to unroll the operations at compile-time to allow the compiler to optimize them ( needs to be tested case by case with the performance test suite ) and elimination temporaries * care to keep most useful memory alignment ( to provide ease of use with direct usage in architecture dependent pipelines ) -- possibly an alignment trait * design with architecture-dependent optimizations in mind ( ease of expansion ) * keeping all the standard boost practices, including workarounds for non-conformant compilers == Research == Several existing implementations were studied and evaluated before the repeated submission of this idea. I intend to encompass most of the good things I found in the following implementations into a small but very useful library: * Boost.uBLAS (obviously) * Eigen - http://eigen.tuxfamily.org/ (heavyweight) * CGAL - http://www.cgal.org/ (license issues) * Matrix Template Library - http://osl.iu.edu/research/mtl/ (similar issues to uBLAS) * VCGLib - http://vcg.sourceforge.net/ (GPL) * nVidia's vector and matrix classes (found in nVidia examples) -- regards, Kornel Kisielewicz http://chaosforge.org/

9 16

Re: [boost] [iterator] reverse_iterator<counting_iterator<T>>
by Arno Schödl 13 Apr '10

13 Apr '10

"Stewart, Robert" <Robert.Stewart(a)sig.com <mailto:Robert.Stewart@sig.com> > wrote in message news:DF2E67F3D097004694C8428C70A3FD690470B26B7F@msgbal516.ds.susq.com <news:DF2E67F3D097004694C8428C70A3FD690470B26B7F@msgbal516.ds.susq.com> ... > this->base() calls iterator_adaptor<>::base(), which returns a reference to the underlying iterator it holds. Passing that reference to boost::prior() means that prior() pre-decrements the iterator within the iterator_adaptor. It would be odd for that >decrement operator to return anything but a reference to the decremented object, so boost::prior() returns a reference to its decremented argument, a reference to the decremented iterator within the iterator_adaptor. > I see no problem. boost::prior(...) internally makes a copy of its iterator argument, decrements it and returns it by value, so far so good. counting_iterator::operator* then returns a reference into this (temporary) iterator. Returning from reverse_iterator::dereference() destroys the temporary iterator, but still returns the reference pointing into it. I overlooked that I already filed a defect a while ago for it: https://svn.boost.org/trac/boost/ticket/2640 <https://svn.boost.org/trac/boost/ticket/2640> It would be great to have it fixed, because the bug is quite subtle and may go undetected for a while. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Chausseestr. 8/E · 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 Berlin-Charlottenburg, HRB 85229

3 4

[serialization] serialization lib not thread safe?
by Jean-Marie Auffray 13 Apr '10

13 Apr '10

I use boost serialization in multi threaded application. Sometimes application crashed. I manage to avoid bug if I recompile boost serialization with BOOST_SPIRIT_THREADSAFE defined in jam file : http://archive.netbsd.se/?ml=boost-build&a=2008-07&t=8023861 But I would like keep boost default installation. I read multi thread limitations here : http://www.boost.org/doc/libs/1_42_0/libs/serialization/doc/special.html But I don't find how to use singleton to avoid crash, I attach test files to reproduct crash. I use 1.36 in test files, but same bug seems to occure in next release. How can I add singleton from serialization to avoid crash? I try some solutions but failed to find a good implementation. Thanks for help.

2 1

release managers: permission to merge?
by Frank Mori Hess 13 Apr '10

13 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to the calendar, the release branch went into "closed except by permission" yesterday. Is it all right for me to merge to release the fix for this ticket: https://svn.boost.org/trac/boost/ticket/4089 The changeset in question is https://svn.boost.org/trac/boost/changeset/61243 I've tested it locally, but have just comitted it to trunk so the tests there haven't cycled yet. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkvEbewACgkQ5vihyNWuA4XawACg1jS8IZun6NJ52GkCa2V3i4nc PAIAoJlaXBs4NqY5mfGiHMoVAYJsTSVp =NiyZ -----END PGP SIGNATURE-----

2 1

Guidelines on wiki
by Daniel James 13 Apr '10

13 Apr '10

Hello, I've copied the guidelines onto the wiki now, you can see them at: https://svn.boost.org/trac/boost/wiki/Guidelines/ Any comments? I've changed the beta site to redirect to them. I haven't linked to them from the front page of the wiki as they aren't 'official' yet. I'll be moving more pages over soon-ish. Any ideas about how the wiki should be structured? Daniel

5 10

[iterator] reverse_iterator<counting_iterator<T>>
by Arno Schödl 13 Apr '10

13 Apr '10

Hello, boost::reverse_iterator::dereference() is typename super_t::reference dereference() const { return *boost::prior(this->base()); } boost::constant_iterator<T>::reference_type is T const&. So reverse_iterator< constant_iterator<T> >::dereference returns a reference to a temporary variable. Not good. I suggest removing the reference from boost::constant_iterator::reference_type, making it T. The rule would be that reference_type must only be a reference if the reference is pointing to some underlying container, not to the iterator itself. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Chausseestr. 8/E · 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 Berlin-Charlottenburg, HRB 85229

2 1

[iterator] Re: counting_iterator<int>::difference_type
by Arno Schödl 13 Apr '10

13 Apr '10

> > counting_iterator<int>::difference_type is __int64 by default. I understand the underlying rationale, but I am not sure whether it is the right choice given the existing practice of C/C++. The problem of int minus int overflowing is not restricted to counting_iterator. Still, C/C++ chose to make int minus int -> int, probably for performance reasons. So why shouldn't counting_iterator by default behave the same way? If someone needs something else, she can still override the default. > You are able to override the difference_type by providing your own type. > See: > boost::counting_iterator<int,boost::use_default,int>::difference_type I know and I did it already. I just want to question whether the default is sensible, given the rest of the language. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Chausseestr. 8/E · 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 Berlin-Charlottenburg, HRB 85229

1 0

counting_iterator<int>::difference_type
by Arno Schödl 13 Apr '10

13 Apr '10

Hello, I am sure this has come up a few times, but I could not find the answer in the archive. counting_iterator<int>::difference_type is __int64 by default. I understand the underlying rationale, but I am not sure whether it is the right choice given the existing practice of C/C++. The problem of int minus int overflowing is not restricted to counting_iterator. Still, C/C++ chose to make int minus int -> int, probably for performance reasons. So why shouldn't counting_iterator by default behave the same way? If someone needs something else, she can still override the default. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Chausseestr. 8/E · 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 Berlin-Charlottenburg, HRB 85229

2 1

[svn] request for commit permission
by Daniel Walker 13 Apr '10

13 Apr '10

Hello, I recently became the maintainer for Boost result_of. May I have commit permission on svn? Also, if I need to make an account, where do I register? Thanks! Daniel Walker

3 2

[iostreams] Cannot compile against zlib 1.2.4
by Lars Viklund 13 Apr '10

13 Apr '10

Hi list. zlib 1.2.4 was released in mid-March, reorganzing the sources a bit. They removed gzio.c and added in a bunch of new source files, something the Jamfile for iostreams does not particularly appreciate. I submitted a ticket [1] with a somewhat tested solution (remove gzio from the list of sources), but I have no idea whether it's the right way to solve it as I'm not aware of how the guts of zlib_compressor and friends work. How does one go forward with something like this, as I don't think I've seen much activity from the iostreams camp at all lately? It would be awfully nice to get some kind of fix into 1.43.0, as it currently prevents anyone interested in building zlib automagically via bjam from doing so. One thing I guess might get in the way is whether this should support older versions of zlib sources. In my opinon no, as this only applies to people who want to build from their own freshly unpacked zlib source tree, not affecting people who use prebuilt binaries from their distro or downloads. [1] https://svn.boost.org/trac/boost/ticket/4091 -- Lars Viklund | zao(a)acc.umu.se

2 1

VS2005 SP1 Hard Debugger Crash in Class Destructor with Boost.Filesystem
by Jack Yee 13 Apr '10

13 Apr '10

Hello, I have a very strange crash involving the use of auto-linking of the boost::filesystem (1.38/1.42) and putting breakpoints in a unmanaged class destructor. It crashes hard enough that the task must be stopped through the Task Manager. Below is the test case that causes the crash: #include "stdafx.h" #include <vcclr.h> #include "boost/filesystem.hpp" // Note 1 public ref class ClassOne { public: ClassOne() {} ~ClassOne() {} }; class ClassTwo { public: ClassTwo(ClassOne^ p) {one = p;} ~ClassTwo() {one = nullptr;} // Note 2 gcroot<ClassOne^> one; }; int _tmain(int argc, _TCHAR* argv[]) { ClassOne ^one = gcnew ClassOne(); ClassTwo *two = new ClassTwo(one); delete two; // Note 3 return 0; } Note 1 -- Commenting out this header and setting breakpoint at Note 2 will be OK Note 2 -- Putting a breakpoint here with "boost/filesystem.hpp" will cause VS2005 to crash Note 3 -- Putting a breakpoint here with "boost/filesystem.hpp" will be OK BUILD CONFIGURATION: * Common Language Runtime Support (/clr) enable * Preprocessor defines: WIN32;_DEBUG;_CONSOLE; * Standard include and library search paths to your Boost installation. Other Useful information: * Running the program without breakpoints doesn't indicate any errors or non-zero exit codes. * Tried both 1.38 and 1.42 boost libraries * Debugger crash does not happen under VS2008 * Same crash results on Windows XP Professional, Vista Business and Windows 7 machines. Event Viewer Output: Faulting application devenv.exe 8.050727.867, time stamp 0x45d2c842, faulting module OLEAUT32.dll, version 6.0.6001.18000, time stamp 0x4791a74f, exception code 0xc0000005, fault offset 0x00003e56, process id 0x8ec, application start time 0x01cadab2a1430262. Hopefully the example is concise enough that I can get some other willing people to try it out and see if they get the same results. Apologies in advance if there is a typo in the source code as the work machines are isolated from connecting from the Internet. Thanks! Jack

1 0

GSOC 2010 - BGL Graph Connectives.
by Tri Nguyen 12 Apr '10

12 Apr '10

Hi, I am Tri Nguyen from South Plains College. I am interested in Graph Connectives Project of BGL. In this writing, I would like to ask two questions, and then propose my idea of doing four Connectives: union, join, intersection, and difference. My first question is: How big is the graph? Or students will try to do as big as possible. My second question is: What type of data-structures (matrix or list) will be used? I attached my ideas in the PDF file below. Please have a look. I appreciate all responses, Thank you, Tri Nguyen.

4 15

GSoC2010 Sweepline Algorithm
by Andriy Sydorchuk 12 Apr '10

12 Apr '10

Hi, Boost Community! I am interested in participation in GSoC 2010. The project I liked the most is the generic implementation of Sweepline Algorithm. Basically fast and robust Sweepline Algorithm requires implementation of next data structure: 1) Event Queue (priority queue). 2) Sweep Line (self-balancing binary search tree). 3) Output datastructures (voronoi vertices, triangulation edges, etc.). Based on that I got next questions: - Which kind of self-balancing binary trees is better for that kind of approach? I am thinking about Red-Black Trees in prefer to AVL trees, as sweepline algorithm requires more adding and deletion operations. And AVL trees are better for look up operations. - STL library includes two generic implementations of self-balancing binary trees (red-black): map, set. I am quite new with Boost library, but probably there are some more specific self-balancing binary tree implementations there? - For Voronoi diagram and delaunay triangulation input data is set of points. What about input of the Medial Axis problem? -- Best, Andrii Sydorchuk

4 33

[BGL] Revisiting Parallel BGL
by Sandeep Gupta 12 Apr '10

12 Apr '10

Hi, I raised the issue of parallel BFS not working correctly here http://lists.boost.org/boost-build/2009/10/22631.php. The issue remained unresolved. I revisited it for last two days and the incorrectness in likelihood is probably due to initialization of distance property map for all non-start vertex to be infinity. Hope this helps. Thanks Sandeep

3 17

How to use mutable_queue with non basic types
by Emili Hernàndez 12 Apr '10

12 Apr '10

Hi all, I've used mutable_queue with basic types (double and int) with no problem. Now I trying to do it with my own type: typedef MyObject entry_t; typedef vector<entry_t> storage_t; typedef MySortingCriterion comp_t; typedef boost::identity_property_map prop_map_t; typedef boost::mutable_queue<entry_t, storage_t, comp_t, prop_map_t> queue_t; queue_t Q(100, comp_t(), prop_map_t()); The definition compiles ok but when I perform an operation such Q.push(obj) //MyObject obj The following errors appear: C:\boost\boost_1_42_0/boost/property_map/property_map.hpp: In function 'Reference boost::get(const boost::put_get_helper<Reference, PropertyMap>&, const K&) [with PropertyMap = boost::typed_identity_property_map<unsigned int>, Reference = unsigned int, K = boost::shared_ptr<CAStarNode>]': C:\boost\boost_1_42_0/boost/pending/mutable_queue.hpp:94: instantiated from 'void boost::mutable_queue<IndexedType, RandomAccessContainer, Comp, ID>::push(const IndexedType&) [with IndexedType = boost::shared_ptr<CAStarNode>, RandomAccessContainer = std::vector<boost::shared_ptr<CAStarNode>, std::allocator<boost::shared_ptr<CAStarNode> > >, Comp = astarnode::SGreater, ID = boost::typed_identity_property_map<unsigned int>]' ..\CAStar.cpp:62: instantiated from here C:\boost\boost_1_42_0/boost/property_map/property_map.hpp:318: error: no match for 'operator[]' in '(const boost::typed_identity_property_map<unsigned int>&)((const boost::typed_identity_property_map<unsigned int>*)(& pa))[k]' C:\boost\boost_1_42_0/boost/property_map/property_map.hpp:553: note: candidates are: T boost::typed_identity_property_map<T>::operator[](const T&) const [with T = unsigned int] It seems the problem is with property_map. Anyone knows how to solve it?? Thank you very much, Cheers, Emili

2 4

[GSOC] summary of .BigInt library details.
by Ankit Malpani 12 Apr '10

12 Apr '10

hi all, thank you Scott McMurray, Vicente and Bruno for the prompt feedback regarding my proposed BigInt library ideas .(Sorry for the delayed reply as was busy with mid-semester exams.) In general this is what i have gathered from your responses regarding what exactly is being expected by the community from a BigInt library for Boost. 1. frontend based off Boost.Proto 2. backend implemented with the help of Boost libraries like Boost.Math. 3. probably provide two levels of implementations. ( although it would really help if you could weigh the pros and cons of both and eliminate one the the two) 3a. looking at bit-level implementation(less space and probably more execution time) 3b.) digit level manipulation (more space - and probably less execution time). i.e. for an n-digit number is it ok to use up [n/2 to n] bytes of space or necessary to stick to log n amount of space for a BigInt object. my questions are :- 1. Please give your feedback/concerns regarding the above design. 2. Any other libraries like Boost.Math which would help with the backend. -- Ankit Malpani 3rd Year Undergraduate | BE. (Hons) Computer Science BITS Pilani Goa Campus

5 5