- Boost - lists.boost.org

[type_erasure] Difficulties with const
by Christophe Henry 19 Sep '12

19 Sep '12

Hi Steven, I have a const problem. Consider the following classes: struct Something { Something(const char* n): myName(n){} std::string const& getName()const { return myName; } std::string myName; }; struct Container { typedef std::vector< AnyNameable > PublicData; Container() { Something s1("bla"); Something s2("blabla"); myData.push_back(s1); myData.push_back(s2); } PublicData getData()const { PublicData res; for (Data::const_iterator it = myData.begin(); it != myData.end() ; ++it) { res.push_back(AnyNameable(*it)); } return res; } private: typedef std::vector< Something > Data; Data myData; }; Container is simply a class returning its "Something", hidden behind AnyNameable (nice way to realize C++ Coding Standards Item 42 BTW). I have a simple test function: void test() { Container c; Container::PublicData data = c.getData(); for (Container::PublicData::const_iterator it = data.begin(); it != data.end() ;++it) { AnyNameable a(*it); std::cout << "data: " << a.getName() << std::endl; // auxiliary question: why does this not work if I use const _self&? //std::cout << "data: " << (*it).getName() << std::endl; } } int main() { test(); return 0; } Now comes the interesting part. If I define AnyNameable using the concept interface, all goes (almost) well: template<class C, class T> struct getName { static T apply(C const& cont) { return cont.getName(); } }; namespace boost { namespace type_erasure { template<class C, class T, class Base> struct concept_interface< ::getName<C, T>, Base, C> : Base { T getName() { return call(::getName<C, T>(), *this); } }; } } typedef any< mpl::vector< getName<_self,std::string const&>, relaxed_match, copy_constructible<>, typeid_<> >, const _self& > AnyNameable; This compiles and outputs as expected. Problem 1: This will not compile std::cout << "data: " << (*it).getName() << std::endl; Hmmm ok not so bad. I'll gladly pay the extra line. (interestingly, it would compile and work without const) Problem 2: if I use the MEMBER macro: BOOST_TYPE_ERASURE_MEMBER((has_getName), getName, 0); typedef any< mpl::vector< has_getName<std::string const&()>, relaxed_match, copy_constructible<>, typeid_<> >, const _self& > AnyNameable; Then the code does not compile, unless I accept to give up all of my consts. On one hand, I will find it a easier job to sell type_erasure with the macro, OTOH, I will not give up my consts ;-) Would it be possible to have the macro AND const-correctness? Attached, a small test with the complete code. Thanks, Christophe

2 3

Interest in a GPU computing library
by Kyle Lutz 19 Sep '12

19 Sep '12

This is a call for interest in a GPU computing library for Boost. I have been working on the library in my spare time for the past month or so and it’s reached a point where I am ready for feedback. Below gives a brief overview, some notes on the design, and a small example of the library which I’ve named Boost.Compute. --- Overview --- * C++ library for general-purpose computing on GPUs/Accelerators * Based on OpenCL (Open Computing Language) * Header-only implementation * API inspired by the STL, Boost and Thrust * Boost dependencies: Config, Utility, Iterator, Exception, Preprocessor, TypeTraits, StaticAssert, MPL, Proto --- Design --- OpenCL is a framework for writing programs that run on parallel computing devices such as GPUs and multi-core CPUs. The OpenCL language is based on C99 with a few extensions to simplify writing parallel and vector-based code. More background: http://en.wikipedia.org/wiki/OpenCL. The core of the Boost Compute library is a thin C++ wrapper over the OpenCL C API. It provides classes for creating and managing various OpenCL entities such as contexts, buffers, devices and kernels. These classes are written in a style consistent with Boost and the C++ standard library. Written on top of the core library is a partial implementation of the C++ STL which includes common containers (e.g. vector<T>, array<T, N>) and algorithms (e.g. copy, find_if, sort) along with a few extensions (e.g. scatter, exclusive_scan, flat_set<T>). The aim of Boost.Compute’s STL API is to provide a familiar interface to developers wanting to easily write new code or port existing code to run on GPU devices. It also features a few “fancy” iterators inspired by the Boost.Iterator library such as transform_iterator<>, counting_iterator<>, and permutation_iterator<>. Furthermore, a lambda expression library was written using Boost.Proto which allows for mathematical expressions to be defined at the call site of an algorithm and then be executed on the GPU. For example, to multiply each element in a vector by the square root of itself and then add four: transform(v.begin(), v.end(), v.begin(), _1 * sqrt(_1) + 4); --- Example --- Below is a small example of using the Boost.Compute API to sort a vector of int values: // create vector of random values on the host std::vector<int> host_vector(10000); std::generate(host_vector.begin(), host_vector.end(), rand); // create a compute context for the default gpu device boost::compute::context gpu_context = boost::compute::default_gpu_context(); // create a vector on the gpu boost::compute::vector<int> device_vector(gpu_context); // transfer the values to the device device_vector = host_vector; // sort the values on the device boost::compute::sort(device_vector.begin(), device_vector.end()); // transfer the sorted values back to the host boost::compute::copy(device_vector.begin(), device_vector.end(), host_vector.begin()); --- Conclusion --- The Boost Compute library provides a useful, intuitive, and familiar interface for running high-performance parallel code on GPU devices. Incorporating Boost.Compute into the Boost libraries would make GPU computing readily accessible to a large number of C++ developers. All comments and feedback are welcome and greatly appreciated. Thanks, Kyle

17 34

[graph] msvc failure on trunk
by Jürgen Hunold 19 Sep '12

19 Sep '12

Hi all, currently all graph test with msvc on trunk fail with: C:\Users\BoostTest\Trunk\boost\boost/pending/property.hpp(101) : error C2182: 'lookup' : illegal use of type 'void' C:\Users\BoostTest\Trunk\boost\boost/pending/property.hpp(101) : see reference to class template instantiation 'boost::lookup_one_property_internal<boost::property<Tag,T,Base>,boost::vertex_bundle_t>' being compiled See http://www.boost.org/development/tests/trunk/developer/output/DrWeb_x86-boo… bin-v2-libs-graph-test-basic_planarity_test-test-msvc-9-0-debug-address- model-32-threading-multi.html for details. It seems this affects mscv-9.0 and 10.0. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 2

[geometry] [polygon] What's the relationship?
by Dave Abrahams 19 Sep '12

19 Sep '12

Could someone please explain the relationship, if any, betweeen these two libraries? They seem to cover similar domains. Do they interoperate? Is one better than the other for certain kinds of problems? Was Boost.Polygon once called the Geometry Template Library, as suggested by the BoostCon 2009 slides? Boy, that's confusing. Lastly, could we get these libraries' documentation to mention one another and explain the information I'm asking for? Thanks in advance for answering. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

5 5

[date_time] merge from trunk to release
by Vicente J. Botet Escriba 19 Sep '12

19 Sep '12

Hi, I have tried to merge (https://svn.boost.org/trac/boost/changeset/80051) Boost.DateTime from trunk to release to merge and I suspect that the svn merge tools has not been used since a long time. I'm getting a long diff with a lot of mergeinfo. Property changes on: boost/date_time/gregorian_calendar.ipp ___________________________________________________________________ Deleted: svn:mergeinfo Reverse-merged /trunk/boost/date_time/gregorian_calendar.ipp:r38329-41356,41778,41955,41983,42067,42076,42080,42141,42424,42988-42990,43112-43113,43209-43210,43799,44807,44825,44897,45097-45098,45264,45283,46445,46508,46544,46580,46632,46673-46674,46790,46801,46803-46804,46808,46819-46820,46826-46829,46832,46936,47024-47027,47058,47064,47086,47093,47254,47283,47301,47389,47392,47401,47456,47754,47768,47793-47794,47797,47938,47940,47942,47985-47987,47993,48089,48204,48226,48252,48280,48478,48496,48663,48695,48729-48730,48973,49111,49118,49121-49122,49131,49254,49333,49345-49346,49424,49433,49510,49586,49601,49620,49627-49628,49691,49693,49945,49970-49971,49980,49996-49998,50019-50020,50024-50027,50059,50237,50240,50244,50312,50413,50447,50486,50497,50516,50997,50999,51031,51045,51066,51104,51120,51171,51189,51210,51239,51253,51284,51311,51337,51400,51410,51413,51422,51448-51449,51862,51881,51909,51912,51961,52231,52258,52425,52773,52866,52879-52881,52937,53048,53050,53061-53062,53125,53141,53143,53187,53211-53212,53218-53219,53233,53261,53293,53343,53425,53462,53476,53478,53544,53577,53619,53648-53649,53651,53671-53672,53682,53699,53751,53780,53790,53800,53802,53888,54385,54594,54873,54914,55097-55100,55132,55138,55140,55146,55151,55159,55184-55185,55224,55370,55470,55473,55484,55500,55507,55528,55573,55656,55667-55670,55698,55718,55723,55728-55729,55749,55780,55838,55877-55902,55905-55917,55921-55922,55990-55992,56009-56010,56014-56017,56020,56028,56077,56089,56097,56116-56117,56125-56128,56140,56147,56202,56207,56300-56302,56319,56321,56328-56329,56339,56346-56349,56360,56362-56363,56374,56440-56441,56454,56461,56468,56473,56557-56563,56570-56571,56603,56633,56651,56654,56658,56682,56697-56699,56715,56717-56719,56732,56796-56797,56855-56856,56859-56860,56868,56922,56942,56988-56989,57005-57006,57008,57126,57139,57150-57153,57159,57170,57174,57177,57196,57249,57290,57346-57348,57388-57389,57393,57395,57412,57433,57479,57520,57525-57526,57542,57544,57559-57560,57580,57592-57593,57601,57613,57618,57631,57645-57646,57663,57665,57670-57672,57694-57695,57703-57704,57706,57708,57710,57717-57718,57721,57724,57726,57730,57732,57734-57738,57748,57751,57757-57759,57782,57790,57826,57828,57830,57859,57863,57865,57869-57871,57875-57877,57892,57894-57896,57898,57901-57907,57909-57911,57913-57914,57923,57928-57930,57933-57934,57939,57944,57949,57951,57953-57955,57957-57958,57973-57974,57986,58005,58034-58035,58037-58039,58041-58043,58047-58049,58057,58061,58071,58073-58074,58082-58083,58086-58087,58090-58091,58093-58094,58105-58109,58114,58117-58118,58120-58121,58123-58125,58127-58129,58145-58146,58148,58171-58172,58179-58181,58183,58196,58219,58246,58270,58272,58275,58279,58295,58297-58298,58306,58310,58323,58333,58356,58375,58378-58379,58392,58400-58401,58407-58408,58412-58415,58427,58437-58439,58444,58452-58453,58467,58469,58491-58492,58501,58520,58531,58533,58555,58563-58565,58570,58574,58576,58588-58589,58598,58602,58611,58621-58630,58634-58636,58647-58652,58670-58671,58694-58695,58698-58699,58703-58708,58713-58721,58740,58761-58762,58768-58770,58772,58779,58782-58783,58793,58796-58799,58824,58850-58851,58859,58865,58870-58871,58876,58887,58900,58914-58920,58942-58943,58965-58966,58971,58994-58995,59005,59062-59063,59103-59106,59129-59134,59141-59142,59156,59163-59168,59241-59242,59244-59248,59256-59257,59277,59341-59344,59347-59361,59374-59376,59390,59407,59413,59416-59417,59420-59424,59440-59441,59486-59491,59496,59519-59522,59537-59538,59540-59543,59574,59583-59584,59618,59628,59662,59667,59713-59726,59729,59734,59742,59748,59761,59795,59854,59910,59928-59935,59937,59946,60078-60079,60126-60127,60141-60143,60152-60155,60164,60172,60178,60180-60181,60184-60185,60190-60192,60195-60199,60201,60210,60216-60218,60220,60225-60227,60256-60260,60279-60280,60282-60283,60295-60296,60313,60315,60335-60336,60339-60340,60343-60357,60359,60365-60366,60373,60380,60384-60385,60391,60395,60403,60451-60453,60455,60470-60472,60479,60485,60494-60496,60503,60526-60527,60608,60610-60611,60615,60619-60620,60624,60633,60639,60645-60646,60651,60657,60659,60669-60671,60681-60683,60685,60687,60689,60692,60705-60707,60717-60725,60738,60740,60743-60746,60750,60752,60756,60767,60769-60770,60775,60781,60788,60817-60820,60828-60829,60849-60850,60859-60861,60869,60874,60882-60885,60888,60899-60900,60916-60923,60925,60938-60941,60958,60961-60962,60995-61000,61002,61009-61010,61012-61013,61015-61016,61055-61064,61074,61076,61085,61100-61101,61104,61117,61122-61124,61127-61128,61131,61151-61152,61155-61156,61159,61165,61171-61172,61174,61179,61182-61183,61185,61190-61192,61194,61212-61214,61217-61225,61230-61232,61234-61240,61244-61251,61254,61257,61262-61266,61273-61276,61282-61287,61290-61292,61294-61299,61302-61303,61307-61308,61310-61312,61315-61326,61328,61330-61331,61333-61336,61338-61340,61342-61344,61347-61348,61350-61357,61360,61367-61369,61371-61373,61381,61384,61388-61392,61398,61405,61416,61421-61422,61424-61426,61435,61437,61445-61451,61460,61462,61465-61468,61471,61475-61481,61483,61489,61491-61492,61499-61503,61506,61510,61514-61515,61520-61521,61523-61525,61543,61547-61549,61551,61553,61564-61569,61573-61582,61606,61643,61645,61649,61668-61669,61674-61677,61679,61696-61699,61708,61717,61723,61726-61728,61748,61750,61764,61766,61769,61782-61783,61788,61795-61796,61824,61832,61838,61841,61843-61844,61856,61858-61859,61876,61881,61918-61919,61925,61928,62042,62046,62051,62074,62080-62081,62084,62098-62099,62116,62139,62142-62148,62150-62152,62165-62166,62176,62182-62184,62245-62246,62248,62251,62255,62259,62271,62368,62371-62373,62394,62404-62406,62426,62479,62497-62499,62506,62530-62533,62535,62545,62547-62550,62556-62558,62579,62592-62593,62595,62605-62607,62609,62611,62616-62620,62622,62626-62630,62660-62661,62671,62678,62683-62684,62686,62693,62698,62725-62727,62736,62753-62754,62781,62798,62811,62825,62827,62829,62897-62898,62909,62926-62927,62932-62935,62937,62951-62952,62957,62960-62966,62972,62984,62994,62998-63000,63002,63004,63006,63012,63016,63020-63021,63023-63024,63031,63033-63039,63048-63049,63057,63084,63086-63088,63091-63094,63097-63098,63101,63125-63128,63137-63147,63149-63155,63180,63188-63204,63217,63221-63225,63227,63234,63240-63241,63244,63247,63260-63261,63268-63270,63274,63276-63280,6328: and much more. Even if the modifications to merge were simple, the diff file is more that 200K lines. I have made a diff between the trunk and the release and the single differences are due to a $Date tag that includes the commit date. Hrrr. Could this merge be done? I could do it if permission is granted from the author or the release manager team. Best, Vicente

3 5

How to bind program termination with end-of-stream in Boost.Process 0.5?
by alfC 18 Sep '12

18 Sep '12

Hi, I have a simple question about the latest Boost.Process 0.5 library. Namely how to How to bind program termination with end-of-stream in Boost.Process 0.5? For example, in this example http://www.highscore.de/boost/process0.5/boost_process/tutorial.html#boost_… One can make a look to read the output of the process until the program finishes, but the stream is not invalid after program termination. ... while(std::getline(is, s)){ // is is an stream associated with a process (e.g. '/usr/bin/ls') std::cout << "read: " << s << std::endl; } std::clog << "end" << std::endl; // never reach ... I originally posted the question in http://stackoverflow.com/questions/12329065/how-to-bind-program-termination… but now I think it can be overlooked there. Since now there seems to be extra layers (Boost.Streams) it may be that I don't know how to set up the file_descriptor_source, etc. BTW, the solution to this question can be used to improve the example code in http://www.highscore.de/boost/process0.5/boost_process/tutorial.html Thanks, Alfredo -- View this message in context: http://boost.2283326.n4.nabble.com/How-to-bind-program-termination-with-end… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 10

VS2012 and bootstrap
by Pedro Larroy 18 Sep '12

18 Sep '12

Hi I'm trying to compile boost with VS2012 in the exact same way that it succeeds with VS2010. And get an error w32_getreg.c: fatal error C1083: Cannot open include file: 'windows.h' Anyone knows how to solve this? Thanks. Pedro.

1 0

[ANN] ODB C++ ORM 2.1.0 released, adds support for Uuid, Multi-Index
by Boris Kolpackov 18 Sep '12

18 Sep '12

Hi, I am pleased to announce the release of ODB 2.1.0. ODB is an open source object-relational mapping (ORM) system for C++. It allows you to persist C++ objects to a relational database without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. Major new features in this release: * Ability to use accessor/modifier functions and expressions to access data members. In most cases ODB is capable of discovering suitable accessor/modifier functions automatically. * Support for virtual (imaginary) data members that can be used to handle the C++ pimpl idiom as well as aggregate or dis-aggregate real data members. * Ability to define database indexes on data members. Multi-member indexes as well as indexes with database-specific index types, methods, and options are supported. * Support for mapping extended database types, such as geospatial types, user-defined types, collections (arrays, table types, etc.), key-value stores, XML, JSON, etc., to suitable C++ types. * The Boost profile library now provides persistence support for the Uuid and Multi-Index container libraries. * The Qt profile library now provides persistence support for the QUuid type. * Support for generating single (combined) database schema file from multiple C++ header files. This release also adds support for Visual Studio 2012 and Clang 3.1. Specifically, all the runtime libraries, examples, and tests now come with project/solution files for Visual Studio 2012 in addition to 2010 and 2008. A more detailed discussion of these features can be found in the following blog post: http://www.codesynthesis.com/~boris/blog/2012/09/18/odb-2-1-0-released/ For the complete list of new features in this version see the official release announcement: http://www.codesynthesis.com/pipermail/odb-announcements/2012/000018.html ODB is written in portable C++ and you should be able to use it with any modern C++ compiler. In particular, we have tested this release on GNU/Linux (x86/x86-64), Windows (x86/x86-64), Mac OS X, and Solaris (x86/x86-64/SPARC) with GNU g++ 4.2.x-4.7.x, MS Visual C++ 2008, 2010, and 2012, Sun Studio 12, and Clang 3.1. The currently supported database systems are MySQL, SQLite, PostgreSQL, Oracle, and SQL Server. ODB also provides profiles for Boost and Qt, which allow you to seamlessly use value types, containers, and smart pointers from these libraries in your persistent classes. More information, documentation, source code, and pre-compiled binaries are available from: http://www.codesynthesis.com/products/odb/ Enjoy, Boris

1 0

[contract] static_assert in contracts or not?
by Lorenzo Caminiti 18 Sep '12

18 Sep '12

Hello all, If static assertions make sense within contracts (preconditions, postconditions, and class invariants) is a questions that has been raised by both Vicente and Andrzej. I don't have a definitive answer so I'd like to discuss with the ML. On Wed, Aug 29, 2012 at 2:48 PM, Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: > (6) > Static assertions: is there any value in providing them, given that we > already have this ability in Boost? I see that N1962 decided to abandon > them; I am pretty sure the reason was that static_assert was already there. > They somehow do not fit conceptually into the model of preconditions, > postconditions and invariants. Precondition, for instance tries to detect a > run-time condition occurring immediately before a function is called this > time. Static assertion is not even executed then. What point is there in > putting such assertion into the precondition? Documentation says " static > assertions can be selectively disabled depending on where they are > specified [...] so it is still important to logically associate them with > preconditions, postconditions, etc." -- technically this sentence makes > logical sense, but can you think of a single example where this selective > disabling of assertions would be useful? What is the point in disabling > such assertions at all, if they cost you nothing in run-time? I propose to > remove them and give a sort of recommendation that software quality is > assured by using a number of fairly independent tools: DbC, concepts, > static assertions. I think we can break down the question in two parts. Let's assume N1962 is accepted into C++1x so we have both contracts and static_assert. 1) Would you expect to be able to use static_assert within contract assertions (preconditions, postconditions, and class invariants)? Note that only boolean conditions are allowed by N1962 within contracts, general code is not allowed, therefore this is not a trivial question. For example, would you expect to be able to do the following option A: template< typename To, typename From > To* memcopy ( To* to, From* from ) precondition{ static_assert(sizeof(To) >= sizeof(From), "destination too small"); static_assert(boost::is_convertible<From, To>::value, "incompatible types"); to; // pointer not null from; // pointer not null } { // ... } In this case, would it ever make sense to use static_assert in postcondition and/or class invariants even if that were allowed? Or would you just use static_assert in the body, option B: template< typename To, typename From > To* memcopy ( To* to, From* from ) precondition{ to; // pointer not null from; // pointer not null } { static_assert(sizeof(To) >= sizeof(From), "destination too small"); static_assert(boost::is_convertible<From, To>::value, "incompatible types"); // ... } I don't like this because the assertions are about the specifications (they assert a requirement of the interface) so they should go in the declaration and not in the implementation. Or maybe the assertions should be represented as concept requirements on To and From, option C: template< typename To, typename From > requires SizeofGreaterEqual<To, From>, Convertible<From, To> To* memcopy ( To* to, From* from ) precondition{ to; // pointer not null from; // pointer not null } { // ... } (Only we don't have concepts...) 2) Let's assume, we answered option A to question 1): template< typename To, typename From > To* memcopy ( To* to, From* from ) precondition{ static_assert(sizeof(To) >= sizeof(From), "destination too small"); static_assert(boost::is_convertible<From, To>::value, "incompatible types"); to; // pointer not null from; // pointer not null } { // ... } Would you expect these static_asserts to be disabled when precondition compilation and checking is turned off at compilation time? I'd think so. Thanks. --Lorenzo

4 11

[contract] future directions
by Lorenzo Caminiti 18 Sep '12

18 Sep '12

Hello all, Now that Boost.Contract has been accepted :D, I couldn't help but to share where I see the library going next :) First of all, I'll have to put Boost.Contract in one of the upcoming Boost releases and I know that will be a lot of work! After that however, I see the library pursuing the following future directions: 1) Reduce compilation times (both preprocessor and template meta-programming optimizations) and possibly improve the (preprocessor) syntax error messages. IMO the x30 compilation time is the largest barrier for the lib adoption in production code, much more so than the strange syntax. I think the 2nd largest barrier is the cryptic syntax errors. The rationale is that you can learn a new syntax especially if that's the only way to program C++ contracts (assuming you actually need contracts) but if your projects takes 1 months instead of 1 day to compile and/or if the compiler errors don't help you understand what you did wrong, you will find it very hard to use the lib in large projects. 2) Support concepts similarly to Boost.Generic (N2081) and/or N3351. This will probably be for C++11 only but many of us wish concepts were part of C++11 and I think many people will favor a lib that supports them (e.g., many people were interested in Boost.Generic). 3) Refactor the macro parsing code so the syntax can be extended by the user. Ideally, this will result in something like Boost.Proto for the preprocessor, maybe "Boost.PreprocessorProto" (even if the actual API might be different and not necessarily equivalent to Boost.Proto API because dealing with macro expansions instead of the template expressions). I don't know if any of the above can actually be achieved but if I'll have time after the 1st Boost.Contract release I'll start working on these projects in the listed order of priority. Thanks. --Lorenzo

1 0