- Boost - lists.boost.org

[contract] with Boost.Parameter (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.Parameter together with the current implementation of Boost.Contract. However, I have not yet verified compatibility with the entire set of Boost.Parameter features (template parameters, free-functions, etc). #include <boost/parameter.hpp> #include <boost/graph/depth_first_search.hpp> #include <contract.hpp> #include <iostream> namespace graphs { BOOST_PARAMETER_NAME(graph) BOOST_PARAMETER_NAME(visitor) BOOST_PARAMETER_NAME(root_vertex) BOOST_PARAMETER_NAME(index_map) BOOST_PARAMETER_NAME(color_map) struct g { CONTRACT_CLASS( (g) ) BOOST_PARAMETER_MEMBER_FUNCTION( (void), depth_first_search, tag, (required (graph, *) ) (optional (visitor, *, boost::dfs_visitor<>()) (root_vertex, *, *vertices(graph).first) (index_map, *, get(boost::vertex_index, graph)) (in_out(color_map), *, default_color_map(num_verticies(graph), index_map)) ) ) CONTRACT_FUNCTION( (public) (template)( (typename)(graph_type) (typename)(visitor_type) (typename)(root_vertex_type) (typename)(index_map_type) (typename)(color_map_type) ) (void) (depth_firt_search)( (graph_type&)(graph) (visitor_type&)(visitor) (root_vertex_type&)(root_vertex) (index_map_type&)(index_map) (copyable)(color_map_type&)(color_map) ) (postcondition) ({ CONTRACT_ASSERT( color_map == CONTRACT_OLDOF(color_map) + 10 ); }) (body) ({ color_map += 10; std::cout << "graph=" << graph << std::endl; std::cout << "visitor=" << visitor << std::endl; std::cout << "root_vertex=" << root_vertex << std::endl; std::cout << "index_map=" << index_map << std::endl; std::cout << "color_map=" << color_map << std::endl; }) ) }; } // namespace int main() { using namespace graphs; g gg; int cm = 0; gg.depth_first_search(1, 2, 3, 4, cm); std::cout << std::endl; gg.depth_first_search("1", '2', _color_map = cm, _index_map = "4", _root_vertex = "3"); return 0; } This function declaration syntax is terrible as it mixes the syntactic complexity of both Boost.Parameter and Boost.Contract... I will try to provide the following syntax instead: CONTRACT_FUNCTION( (public) (void) (depth_first_search)( // No (tag)(namespace-id) so use `tag`. // (auto) for no type requirements (preprocessor can't use `*`). (auto) (graph) // (default) for optional param. (auto) (visitor) (default)(boost::dfs_visitor<>()) (auto) (root_vertex) (vertices(graph).first) (auto) (index_map) (default)(get(boost::vertex_index, graph)) // (inout) for in-out type. (copyable)(inout)(auto) (color_map) (default) (default_color_map(num_verticies(graph), index_map)) // Plus, (deduced)( parameter-sequence ) for deduced params. ) (postcondition) ( (color_map == CONTRACT_OLDOF(color_map) + 10) ) ({ color_map += 10; std::cout << "graph=" << graph << std::endl; ... }) (IMO, this syntax looks cleaner that the original Boost.Parameter one.) -- Lorenzo

1 0

[intrusive.set] Accessing the last (largest) element.
by Andy Venikov 15 Apr '10

15 Apr '10

Since there is no "back" method for intrusive set, what's the best way to access the last (greatest) element? Is this OK:? IntrusiveSet set1; IntrusiveSet::iterator itEnd = set1.end(); //Make sure that set isn't empty. Value v = *--itEnd; ++itEnd; //will itEnd point to set1.end() after this? In general, is there anything sinister about this construct? (provided that the set isn't empty) Thanks, Andy.

2 2

[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