- Boost - lists.preview.boost.org

[serialization] deserializing asynchronously serialized types
by Andrew Hundt 04 Sep '11

04 Sep '11

I have an unusual use case for boost.serialization, and I was wondering if it would be possible to adapt it to my needs: - I have a set of over 100 types, and instances of each are generated asynchronously then serialized to a file in that order. - The most interesting serialized data will be written just before the power is unexpectedly cut. - I need to load in and run on as much data as possible when reading the serialized data back, ignoring incomplete data at the end (due to a power cut). - The basic Boost serialization examples require you to know the type of the next piece of data to be loaded when reading. Since these types are generated asynchronously they are not known in advance. - I need to write the data out immediately when it arrives because of the power issue. - Files will be getting up to around 150GB in size for binary archives, so it can't be marshaled in memory, it needs to be written immediately even if it is redundant. Is there a way to read in that serialized file using the facilities provided in boost.serialization? Here are my current ideas: - I tried using boost.variant, but it loses its will to compile when I increase the typelist limit to around ~60 types on gcc 4.4, and I have more than a hundred. - Use preprocessor metaprogramming to do something equivalent to boost.variant, but I would very much prefer a more pleasant option. - Serialize an index or custom headers indicating the next type to appear - One way of achieving some of these goals is writing one piece at a time using a binary archive to an fstream, with the index mentioned above separating data types. I don't know what aspects of my requirements will prove to be a problem, so if anyone can provide advice that would help me avoid a major pitfall, it would be greatly appreciated. Thanks for your thoughts. Cheers! Andrew Hundt

2 1

[conversion] review
by Gordon Woodhull 03 Sep '11

03 Sep '11

Hi all, Here is my review of the Conversion library. I like the idea of a uniform configurable casting operator, whether it's called convert_to, static_cast, convert_cast, or extrinsic_cast. If I had to write a conversion function, I would rather write it as an overload of a general-purpose converter, rather than giving it some ugly typeA2TypeB name. And I would rather find out what header to include and use a generic function rather than using such some specific name. I vote to accept the library (although obviously as Review Manager I'll follow the wishes of all reviewers). Part of the reason I took on the challenge of managing this review is that the library is something people don't know they need. I think uniformity of interface is a good enough reason to use the library, but when would you need a truly generic conversion function as this library offers? Or more to the point, what does it mean to have a "shadow conversion space" for types that don't know about each other? We would hope that libraries are generic enough so that their types can be adapted to work with each other (prime example: Polygon & Geometry). But it's the sad truth that most libraries are not designed this way, and any non-header library can't be designed this way. So that's where Conversion steps in to make combining those libraries cleaner. As we've already discussed, the Achille's Heel of this library is that it requires all compilation units to agree on what conversions they will use, to avoid ODR violations. In practice this probably means that users would have to maintain their own conversion setup headers, which is annoying. But it's hard to imagine an openly configurable global utility that doesn't suffer from some version of this problem. John Bytheway's suggestion of tagging libraries with type keys is an interesting idea. I think Vicente also mentioned the possibility of a scheme that would cause linker errors instead of ODR violations, which would be an improvement. (FWIW I suggested something involving #error but of course that would only work within a CU.) In my mind it is very clear that a templated function<T>(x) will probably return a T and I don't find it necessary that the proposed function has to use the preposition "to". But that's because I'm very aware that the explicit template argument must be the return type, which is understandably not clear to everyone. While the recursive features of this library look interesting and useful, I wonder if there isn't a more general way to do this. I keep thinking it's an awful lot like fusion::copy or Marsden's Traversals. Well, that's enough for now. I hope later today to post summaries of some comments I received off-list and maybe get those people to join the conversion. (You know who you are!) Cheers, Gordon

7 16

[type traits] Extension to operator detection -> choose your preferred naming
by Frédéric Bron 03 Sep '11

03 Sep '11

It is time to include the type trait extension to the official boost trunk. These traits can detect if you can use a given operator with given arguments. For example: has_plus<double, int>::value is true because the following program compiles without error: double lhs; int rhs; lhs+rhs; We have come to three proposed lists of names (A, B and C): https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames I have included the corresponding names of standard keywords, standard function objects from <functional>, boost Proto and boost Operators. Please give your preference between A, B and C before Sept. 5th. Regards, Frédéric

15 17

[preprocessor]BOOST_PP_CHECK_2 with wrong number args
by Larry Evans 02 Sep '11

02 Sep '11

boost/preprocessor/detail/check.hpp in boost version 1.47.0 contains: # if ~BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_MSVC() && ~BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_DMC() # define BOOST_PP_CHECK_D(x, type) BOOST_PP_CHECK_1(BOOST_PP_CAT(BOOST_PP_CHECK_RESULT_, type x)) # define BOOST_PP_CHECK_1(chk) BOOST_PP_CHECK_2(chk) # define BOOST_PP_CHECK_2(res, _) res # elif BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_MSVC() The above shows BOOST_PP_CHECK_2 is called with 1 argument on rhs of BOOST_CHECK_1; yet, the arity is 2, as shown on the next line. This results in the errors reported here: http://article.gmane.org/gmane.comp.lib.boost.devel/222795 when that line is changed to: # define BOOST_PP_CHECK_1(chk) BOOST_PP_CHECK_2(chk,_) the reported error goes away; however, several other errors occur about too many instead of too few arguments passed to BOOST_PP_CHECK_2. Is this a BOOST_PP bug? If not; how can the errors reported in: http://article.gmane.org/gmane.comp.lib.boost.devel/222795 be avoided? TIA. -regards, Larry

2 8

[Boost.serialization] - Json Serialization (Marshalling and unmarshalling)
by Demetrio Car 02 Sep '11

02 Sep '11

I need some example of how to serialize/deserilize from Json format to Object and from Object to Json. I used this example http://www.boost.org/doc/libs/1_47_0/libs/serialization/doc/index.html, but it only serialize to a simple text. In my project, for other requirenments, I am using boost library with success. I am almost sure that I do need some other specific library like Json-Spirit or standard QT library (QScriptEngine). Any simple example will be very appreciate. This is an example of the Json files I must serialized to a class. [{"DscTipoEstrutura":"Unidade de Neg\u00f3cio","FlgAtivo":true,"IdDominio":1,"IdTipoEstrutura":1,"NroOrdem":0},{"DscTipoEstrutura":"Regi\u00e3o","FlgAtivo":true,"IdDominio":1,"IdTipoEstrutura":2,"NroOrdem":1},{"DscTipoEstrutura":"Distrito","FlgAtivo":true,"IdDominio":1,"IdTipoEstrutura":3,"NroOrdem":2}] Ps.: I found http://www.codeproject.com/KB/recipes/JSON_Spirit.aspx and http://boost-spirit.com/repository/applications/show_contents.php similiar to I need but, because I am C++ begnnier, I couldn't understand them neither run the example after some couple of hours. I need some simple example.

1 0

Acknowledgement for Certs 4 Less
by Dave Abrahams 02 Sep '11

02 Sep '11

All--- For some time now, Boost has been using the CA-signed wildcard SSL certificate that was very generously donated by Certs 4 Less. I promised them, in return, that Boost would acknowledge them on our website, as we have done in the past for other donors. We acquired the certificate so we could accept e-payments for BoostCon, but in the end we decided to pay EventBrite to take payments for us... so as far as I know, the cert is only being used at the moment for https://svn.boost.org Two questions: 1. Where does the acknowledgement belong? 2. Can someone who knows how put it there? P.S. I would be very happy not to get separate answers to those, if someone who knows how to edit the website *and* an appropriate placement for the acknowledgement could just take care of it ;-) Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

4 6

Version 10 of Boost.Algorithm available
by Marshall Clow 02 Sep '11

02 Sep '11

Changes since -009 * Predicate versions of the search functions have been removed. * Search functions now work for raw pointers * Now use tr1/unordered_map everywhere - this should make (most versions) of gcc happy. * Now including <climits> in search.hpp, which defines CHAR_BIT. * Fixed a bug in boyer_moore::create_suffix_table, which caused the search to fail sometimes. * The skip table is now templated on the value_type being searched on, rather than the iterator type. * Documentation has been updated (more to come here) Thanks to Mikhail Levin, TONGARI, and Sebastian for bug reports. Since the vault is gone, I've put the code here: http://dl.dropbox.com/u/11048326/Boost.Algorithm-010.zip -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

2 1

[review] conversion - Kevlin's comments
by Gordon Woodhull 02 Sep '11

02 Sep '11

Hi Vicente, all - I got this comment from Kevlin Henney, author of lexical_cast: On Sep 1, 2011, at 11:45 AM, Kevlin Henney <kevlin(a)curbralan.com> wrote: > I was looking through the docs and they seem to offer a solution to a common family of conversion problems. Based on casual reading, it feels a little more complex and requires a higher-entry level of knowledge than would be appropriate for many of the people who actually need this functionality. These are initial impressions only, so don't read too much into them. The eternal battle between power and simplicity. :-) Cheers, Gordon

2 2

[proto] Can't use functions in expressions?
by John Maddock 02 Sep '11

02 Sep '11

So.... I have a function that returns an expression template of proto::tag::function type, like so: template <class Exp>\ typename proto::result_of::make_expr<\ proto::tag::function\ , detail::BOOST_JOIN(func, _funct)<typename detail::backend_type<Exp>::type>\ , detail::big_number_exp<Exp>\ >::type const \ func(const detail::big_number_exp<Exp>& arg)\ {\ return proto::make_expr<proto::tag::function>(\ detail::BOOST_JOIN(func, _funct)<typename detail::backend_type<Exp>::type>() \ , arg \ );\ }\ and it all works fine, until I try and use the result of such a function call in an expression: sqrt(arg) + arg yeilds: 1>m:\data\boost\sandbox\big_number\libs\math\ide\extended_real\scrap\scrap.cpp(25): error C2893: Failed to specialize function template 'const boost::proto::detail::enable_binary<boost::proto::domainns_::deduce_domain,boost::proto::detail::not_a_grammar,boost::mpl::or_<boost::proto::is_extension<T>,boost::proto::is_extension<Right>>,boost::proto::tag::plus,const Left,const Right>::type boost::proto::exprns_::operator +(const Left &,const Right &)' 1> With the following template arguments: 1> 'boost::math::detail::big_number_exp<Expr>' 1> with 1> [ 1> Expr=boost::proto::exprns_::basic_expr<boost::proto::tag::function,boost::proto::argsns_::list2<boost::math::detail::big_number_exp<boost::proto::exprns_::basic_expr<boost::proto::tag::terminal,boost::proto::argsns_::term<boost::math::detail::sqrt_funct<boost::math::mpfr_real_backend<50>>>,0>>,boost::math::detail::big_number_exp<boost::proto::exprns_::expr<boost::proto::tag::terminal,boost::proto::argsns_::term<boost::math::big_number<boost::math::mpfr_real_backend<50>> *>,0>>>,2> 1> ] 1> 'boost::math::mpfr_real_50' So I figured I needed to update my grammar, so I tried adding this case: template<> struct big_number_grammar_cases::case_<proto::tag::function> : proto::function< proto::_ > {}; But still no joy (same error message). Any ideas on what I'm doing wrong? BTW I couldn't find any examples of using proto::function in a grammar, it wasn't obvious to me what it's template arguments should be, or indeed whether this actually enabled the function call operator rather than my use case? Thanks, John.

4 6

Basic boost::mpl::max_element question.
by Yves Dolce 02 Sep '11

02 Sep '11

Hi everyone, Once past the basic understanding of C++ metaprogramming (factorial, vector/typeslist, .), I must confess I have a hard time using max_element in my particular scenario. And I have not found a lot of samples on the net. Consider this "repro" first: template <unsigned char L> struct Level { static const unsigned char value = L; }; template <class LEVEL> struct CTA { typedef LEVEL Level_t; }; typedef boost::fusion::vector<CTA1, CTA2, CTA3, CTA4> CTAS; Now, using max_element, I'd like to pick the one CTAn for which CTn::Level_t::value is the biggest. Can you enlighten me? Thanks! An MPL/FUSION beginner. J

2 1

[TypeTraits] A patch for clang's intrinsics (was: [type_traits] is_enum on scoped enums doesn't works as expected)
by Michel MORIN 01 Sep '11

01 Sep '11

John Maddock wrote: >> Boost.TypeTraits does not use intrinsics for clang yet. >> (c.f. https://svn.boost.org/trac/boost/changeset/72725) >> >> >> this explains why it is not working now. Is someone working on this issue? > > Not me, we need a Clang expert to look into it - or at least someone with > access to Clang to take care of the testing - someone did submit a patch to > enable intrinsic support for Clang, but it broke more things than it fixed > so it got reverted :-( Let's proceed step by step. As a first step, I made a patch to use clang's intrinsics except problematic intrinsics (i.e. `is_pod` and `is_empty`). All the tests run successfully on gcc-4.4, 4.5, 4.6, clang (trunk) and Mac OS X Lion's clang (Apple clang version 2.1). Regards, Michel

4 7

Re: [boost] [any] new version
by Martin Bidlingmaier 01 Sep '11

01 Sep '11

> Mathias Gaunard wrote: >> You could make next_id a function with weak extern linkage, which should >> be able to make it work. Thanks for the replies, I hope I fixed the linkage problems now, by making next_id() inline. There were other linker related issues, which are hopefully fixed now as well. The modified any.hpp header and a simple linker test are attached -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

2 2

[shared_ptr] Implicit 2 phase construction with enable_shared_from_this
by Sebastian Karlsson 01 Sep '11

01 Sep '11

There's been some discussion about solving the problem with shared_from_this() not being available in the constructor. This is fairly natural as shared_ptr ownership doesn't happen until after the constructor leaves, and we're not even guaranteed that the object enters shared_ptr ownership at all. What I'm suggesting is the addition of a private void enable_shared_from_this<T>::accepted_shared_ptr() {}. Then inside enable_shared_from_this<T>::_internal_accept_owner we add: const_cast< T* >( static_cast< const T* >( this ) )->accepted_shared_ptr(); Just beneath: weak_this_ = shared_ptr<T>( *ppx, py ); This allows clients of enable_shared_from_this to add their own accepted_shared_ptr() which will correctly be called while I believe not breaking any old code. I just added the const_cast because I'm not familiar with the rationale behind _internal_accept_owner being const. This change nets us: 1 ) Generic code dealing with construction of shared_ptrs ( in any of its forms ) does not need to bother themselves with 2 phase construction. 2 ) The distinction between construction & transfer of ownership to shared_ptr makes it easier to cope with both the case where T is not managed by a shared_ptr and the case where it is. One gotcha I've found is that for example: struct foo : enable_shared_from_this< foo > { foo() { boost::shared_ptr< foo > tmp( this, null_deleter() ); } // We might be allocated on the stack, so use a null_deleter for now void accepted_shared_ptr() { /* here we can patch it up with shared_from_this(), which will use our assigned deletion strategy */ } } Does not behave as one would want to. Basically in this case I'd want to use a shared_ptr<> which makes no assumptions about whether we're managed by a shared_ptr or not, we want a shared_ptr which acts as a plain pointer. The problem however is that the shared_ptr which we construct with the null_deleter will grab the enable_shared_from_this before even construction is complete. This can be solved by the following, as seen in boost::make_shared: ... boost::shared_ptr< foo > empty_with_deleter( static_cast< foo* >( 0 ), null_deleter() ); boost::shared_ptr< foo > tmp( empty_with_deleter, this ); // This one is safe to use ... Which doesn't enter boost::detail::sp_enable_shared_from_this. Would love some input from someone a bit more knowledgeable about shared_ptr. Kind regards, Sebastian Karlsson

1 0

[review] Conversion - About specialization, overloading and ODR
by Vicente J. Botet Escriba 01 Sep '11

01 Sep '11

Hi, during the Boost.Conversion review and pre-review it has been argued that as the user must provide specializations of the conversion function for other UDT's, it could promotr ODR violations as two independent libraries can provide the same specialization making them incompatible for an end user. This issue is present for any library for which the user could provide an overload or could specialize a class. The standard library protects itself from this issue saying that is undefined behavior any specializations of standard classes (except maybe numeric_traits that has a single parameters and it is intendeed to be specialized by the library providing the UDT). My question is: Should Boost (all the Boost libraries) document explicitly that any class specialization or overload of free fuctions could result in undefined behavior? Is this already implicitly acknowledged? Best, Vicente

3 7

[review] Conversion review ends today
by Gordon Woodhull 01 Sep '11

01 Sep '11

Folks, The review of Vicente's Conversion library ends today. Unfortunately there have only been four reviews, which is hardly enough to provide proper feedback. If you've considered writing a review or if you have any thoughts about the topic, please speak up now. Or if you'd like to submit a late review, just let me know. Thanks, Gordon

5 19

[boost/property_tree/json_parser] - Consuming a Json file returning from rest web service
by Demetrio Car 31 Aug '11

31 Aug '11

> > Could someone send me an example of how to use json_parser to read a Json > file? I will need to consume a Rest web service developed in Rails. This web > service will respond to my code using json, in other words, from my C++ code > running over linux I will access an url which will return to me a file in > Json format. The main point is: how do I access the url > http://my_gienah:3000/dominios/dominiosAll.json<http://gienah:3000/dominios/dominiosAll.json> or > the url > http://my_gienah:3000/Tipoestruturas/ObtemTipoEstrutura_IdDominio/1.json<http://gienah:3000/Tipoestruturas/ObtemTipoEstrutura_IdDominio/1.json> .In > the last url, I must set parameters. The return is something like this: > > [{"DscDominio":"Johnson Argentina"},{"DscDominio":"Johnson Brasil"},{"DscDominio":"Farmoqu\u00edmica"},{"DscDominio":"Dom\u00ednio Inativo"},{"DscDominio":"NIKKHO"},{"DscDominio":"teste"},{"DscDominio":"Dominio"},{"DscDominio":"teste"},{"DscDominio":"teste"},{"DscDominio":"Teste"},{"DscDominio":"Teste"},{"DscDominio":"Dom"},{"DscDominio":"teste"},{"DscDominio":"teste"},{"DscDominio":"Teste"},{"DscDominio":"descricao"},{"DscDominio":"DesccricaoTeste"},{"DscDominio":"teste"},{"DscDominio":"teste p"},{"DscDominio":"teste p 2"},{"DscDominio":"teste p 3"},{"DscDominio":"Teste Dominio Produto x"},{"DscDominio":"Teste Dominio Produto x"},{"DscDominio":"Teste Dominio Produto x"},{"DscDominio":"Dominio Produto 123"},{"DscDominio":"subdom2"},{"DscDominio":"teste"},{"DscDominio":"2"},{"DscDominio":"3d"},{"DscDominio":"X"}] > >

2 1

[review] conversion - Vladimir's comments
by Gordon Woodhull 31 Aug '11

31 Aug '11

Hi Vicente, all, I had hoped that Vladimir Batov, author of Boost.Convert reviewed earlier this year, would contribute an "informal review". Instead I hope he doesn't mind if I quote some correspondence he sent off-list, and perhaps get him to join us. (I normally would never quote off-list communication on-list, but I don't see how a review manager can use off-list contributions without quoting them, if there's no request for anonymity. I hope Vladimir agrees that I've been judicious. ;) On Aug 1, 2011, at 8:47 PM, Vladimir Batov wrote: > On the conceptual level it is far from clear to me if such a framework is needed to begin with. In the Scope section Vicente explicitly states that his library "is not particularly concerned with cases of...". Those "excluded" cases happen to be the most tricky/used/needed cases. With those string-to-type, etc. cases taken out of the picture from the set-go, the usefulness of the remainder was many times questioned during Convert discussions (well before the Convert review) ... I never had a need for such a generic type-to-type conversion framework. Obviously, it's my own limited experience and it can be vastly different for others. > Secondly, on the implementation level I raised a few concerns in our conversations with Vicente about his library ... I do not feel Vicente's implementation is sufficiently generic. In particular, I am under strong impression that having Target and Source together as in > > template< class Target, class Source > > Target explicit_convert_to( Source const & u ); > > does not really work on a bigger scale. That does indeed work for *concrete* Target and Source types. However, when one tries to generalize (partially specialize) for a range of similar types, then I feel the framework easily falters. Namely, if I decide to specialize the above for a range of related Target types (say, string-related types) *and* separately specialize for a range of related Source types. Then compilation will fail if these two separate specializations happen to overlap for some Target-Source pair. That is not an academic case but concrete issues I faced with Convert. I'd expect it to be as relevant with Vicente's library. I agree that it will take some careful shepherding to define a set of conversions without ambiguous overloads, which might be tricky to avoid if you're working with converters written by other people. Vicente, do you have any solutions for this? Cheers, Gordon

5 10

interprocess locks and move semantics compile problem [SEC=UNCLASSIFIED]
by Levy, Gabriel (Contractor) 31 Aug '11

31 Aug '11

UNCLASSIFIED Hi all, I'm having a problem getting this trivial couple of statements compile on VC9 SP1 (VS2008), specifically the "move" emulation. The sanitised snippet looks like this: using namespace boost::interprocess; interprocess_upgradable_mutex mMtx; sharable_lock<interprocess_upgradable_mutex> sherLock(mMtx); upgradable_lock<interprocess_upgradable_mutex> upgLock(move(sherLock)); The error message I'm getting is (nothing more, nothing less): 1>d:\experimental\notificationcentre.cpp(632) : error C2664: 'boost::interprocess::upgradable_lock<UpgradableMutex>::upgradable_lock( boost::interprocess::scoped_lock<Mutex> &)' : cannot convert parameter 1 from 'boost::interprocess::rv<T>' to 'boost::interprocess::scoped_lock<Mutex> &' 1> with 1> [ 1> UpgradableMutex=boost::interprocess::interprocess_upgradable_mutex, 1> Mutex=boost::interprocess::interprocess_upgradable_mutex 1> ] 1> and 1> [ 1> T=boost::interprocess::sharable_lock<boost::interprocess::interprocess_u pgradable_mutex> 1> ] 1> and 1> [ 1> Mutex=boost::interprocess::interprocess_upgradable_mutex 1> ] Strangely the compiler thinks that the best fit for the constructor overload (with the "move") is the one with "scoped_lock" parameter type instead of the "sharable_lock" version of it. The same is the problem combining lock's move across the other types (up or down grading the type of lock) I must be missing something since I can't see anyone else experiencing this problem. Could anyone advise and shad some light as to why the "move" doesn't work for me on the original interprocess locks? Thanks in advance for any help. Gabe Gabe Levy Senior Software Engineer, HiQ Systems Pty Ltd IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email.

1 0

[Conversion] Review
by Antony Polukhin 30 Aug '11

30 Aug '11

First of all, there is already a Boost.Conversion library (released in 1.20.0). Users will be confused, because two libraries have same names. * What is your evaluation of the design? It is simple and looks good. But consider the following situation: lexical_cast<char>(1) and numeric_cast<char>(1) will produce output. It must be documented, which cast will your library use in which cases. There must be some tags, to allow user to choose, which conversion is required. There are some dummy::type_tag tags in source code, but looks like they are not used, and not documented! * What is your evaluation of the implementation? Did not look very carefully trough the sources. * What is your evaluation of the documentation? There is no documentation about which conversion when used. convert_to<char>(1) will call numeric_cast or lexical_cast? * What is your evaluation of the potential usefulness of the library? Usually user just want to use lexical_cast or numeric_cast. Situations, when generic conversion is required are less often. * Did you try to use the library? With what compiler? Did you have any problems? I did not used it. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A quick reading. * Are you knowledgeable about the problem domain? I am knowledgeable about lexical conversions domain. Generic conversions are close enough to that domain. * Do you think the library should be accepted as a Boost library? Yes, it should. But only after the documentation will be updated and tags added. Until then, it is not clear which cast is when used and library is not as generic as possible. But such big changes to library design will require some new short review.

3 5

[Feedback] Towards a Better Boost.BloomFilter
by Alejandro Cabrera 30 Aug '11

30 Aug '11

Hello all, The GSoC coding period is over. However, I have every intent to continue to develop, improve, and maintain the Boost.BloomFilter package. Your feedback last time around was very useful, and made me think very carefully about the operations supported by each Bloom filter variant implemented. Thank you. Now, I could use feedback on at least the following aspects: - Are all the operations you need implemented by Boost.BloomFilter? Serialization support is still missing, though at least now it is possible to access the underlying storage for each structure implemented through the data() member function. - Are there are any particular variants you'd like to see implemented sooner? I've gathered together most Bloom filter literature on the bibliography page: http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/libs/bloom_filter… http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/libs/bloom_filter… (Note: twohash_ Bloom filters have been implemented.) - There is much talk of C++11 as of late on the mailing list: do you see anywhere in the implementation where taking advantage of C++11 features may produce a better Bloom filter package? - Regarding compiler support, this Bloom filter has been tested on several compiler suites (gcc-4.6, gcc-4.6 -std=c++0x, clang-2.9, clang-2.9-darwin), but has been primarily developed on Linux. Does the test suite compile and pass on your target compiler? My goal is to produce a review-ready Bloom filter library by the end of the year. Any feedback helps. Thank you for your time! A few links: - repository trunk: http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/ http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/ - documentation: http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/libs/bloom_filter… http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/libs/bloom_filter… Cheers, -Alejandro Cabrera -- View this message in context: http://boost.2283326.n4.nabble.com/Feedback-Towards-a-Better-Boost-BloomFil… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 6

miscompilation: boost.mpi, gcc 4.6 and c++0x
by Christophe Prud'homme 30 Aug '11

30 Aug '11

Dear Boost Developers I created the ticket [1] several month ago regarding an issue between g++-4.6 with option -std=c++0x and boost.mpi I haven't had any feedback yet. Any idea wether boost or gcc is at fault here ? it is easy to fix this by adding the right member function. 1. https://svn.boost.org/trac/boost/ticket/5538 let me recap what is going on consider the following code in t.cpp: #include <boost/mpi.hpp> compile it with g++ -std=c++0x -c -I/usr/include/mpi t.cpp and you get in Debian unstable In file included from /usr/include/c++/4.6/memory:67:0, from /usr/include/boost/mpi/allocator.hpp:18, from /usr/include/boost/mpi.hpp:22, from t.cpp:1: /usr/include/c++/4.6/bits/stl_uninitialized.h: In function 'void std::__uninitialized_default_n_a(_ForwardIterator, _Size, _Allocator&) [with _ForwardIterator = char*, _Size = long unsigned int, _Allocator = boost::mpi::allocator<char>]': /usr/include/c++/4.6/bits/vector.tcc:474:8: instantiated from 'void std::vector<_Tp, _Alloc>::_M_default_append(std::vector<_Tp, _Alloc>::size_type) [with _Tp = char, _Alloc = boost::mpi::allocator<char>, std::vector<_Tp, _Alloc>::size_type = long unsigned int]' /usr/include/c++/4.6/bits/stl_vector.h:592:4: instantiated from 'void std::vector<_Tp, _Alloc>::resize(std::vector<_Tp, _Alloc>::size_type) [with _Tp = char, _Alloc = boost::mpi::allocator<char>, std::vector<_Tp, _Alloc>::size_type = long unsigned int]' /usr/include/boost/mpi/detail/packed_oprimitive.hpp:96:46: instantiated from here /usr/include/c++/4.6/bits/stl_uninitialized.h:576:6: error: no matching function for call to 'boost::mpi::allocator<char>::construct(char*)' /usr/include/c++/4.6/bits/stl_uninitialized.h:576:6: note: candidate is: /usr/include/boost/mpi/allocator.hpp:168:8: note: void boost::mpi::allocator<T>::construct(boost::mpi::allocator<T>::pointer, const T&) [with T = char, boost::mpi::allocator<T>::pointer = char*] /usr/include/boost/mpi/allocator.hpp:168:8: note: candidate expects 2 arguments, 1 provided note that if you remove -std=c++0x, it compiles fine. Best regards C. -- Debian Developer - member of Debian Science http://wiki.debian.org/DebianScience Prof. at Univ. Grenoble in Applied Math. http://ljk.imag.fr/membres/Christophe.Prudhomme/

2 1

[C++0x] ISO/IEC approves C++0x standard!
by Beman Dawes 30 Aug '11

30 Aug '11

The C++0x standard has been approved by ISO/IEC. The vote was unanimous; all 21 National Bodies voting were in favor. That means the dozen or so Boost libraries that were in TR1 are now part of the standard itself. Good work, Boosters! --Beman

10 12

BOOST_STRONG_TYPEDEF conflicting defs in 1.47
by Michael Goldshteyn 30 Aug '11

30 Aug '11

There seem to be conflicting definitions for the BOOST_STRONG_TYPEDEF macro: 11>e:\dev\devel\libs\boost\boost_1_47_0\boost\strong_typedef.hpp(45) : warning C4005: 'BOOST_STRONG_TYPEDEF' : macro redefinition 11> e:\dev\devel\libs\boost\boost_1_47_0\boost\serialization\strong_typedef.hpp(45) : see previous definition of 'BOOST_STRONG_TYPEDEF' They are slight different, but function identically (i.e., the one in serialization has an explicit default constructor call on the member variable t). Are both of these necessary, or should serialization just use the default one from the boost directory? Thanks, Michael Goldshteyn

2 2

[conversion] conversion domains
by Gordon Woodhull 30 Aug '11

30 Aug '11

Hi Vicente, all, I've been thinking a bit about Conversion's ODR problems and the annoyance of headers that customize something globally (using e.g. template specialization) when they are included. I think I would prefer a design that allowed to define sets of conversions, or conversion domains. When creating a converter, you would specify the list of conversions which you want. That way a conversion domain is specified in one place, and not because you #include something. Of course it also means there's no default domain, for better or worse. I tried a number of approaches but only found one way that would work. This uses function overloading over an inheritance chain of converter classes, each of which brings its parent's convert() function(s) into scope with 'using'. Yes, it is requires ugly, specific code to define a converter (and mpl::quoting the converters when specifying the domain yuk), and I wonder if anyone could find a better way to do this. (I would prefer if it were possible to use partial specialization of template classes, but I guess there is no way to combine specializations of a nested template using inheritance, and it invokes a weird bug in gcc [1] if you try to do so.) Vicente, have you considered similar approaches? Cheers, Gordon [1] http://stackoverflow.com/questions/1413158/partial-specialization-of-a-clas… This cites a claim that the bug was fixed in 4.5.0 but I am still seeing it in 4.5.3 - have not tried more recent. #include <iostream> #include <string> #include <boost/mpl/vector.hpp> #include <boost/mpl/fold.hpp> #include <boost/mpl/apply_wrap.hpp> #include <boost/lexical_cast.hpp> #include <boost/utility.hpp> #include <boost/numeric/conversion/cast.hpp> #include <boost/icl/type_traits/is_numeric.hpp> namespace mpl = boost::mpl; template<typename T> struct wrap {}; struct converter_start { struct dummy; dummy convert(dummy, wrap<dummy>); }; template<typename Tail> struct x2string : Tail { using Tail::convert; template<typename Source> std::string convert(Source const& x, wrap<std::basic_string<char> >) { return boost::lexical_cast<std::string>(x); } }; template<typename Tail> struct string2x : Tail { using Tail::convert; template<typename Target> Target convert(std::string const& s, wrap<Target>) { return boost::lexical_cast<Target>(s); } }; template<typename Tail> struct numeric : Tail { using Tail::convert; template<typename Target, typename Source> typename boost::enable_if_c<boost::icl::is_numeric<Target>::value && boost::icl::is_numeric<Source>::value, Target> ::type convert(Source const& x, wrap<Target>) { return boost::numeric_cast<Target>(x); } }; typedef mpl::vector<mpl::quote1<string2x>, mpl::quote1<x2string>, mpl::quote1<numeric> > my_conversions; struct my_converter : mpl::fold<my_conversions, converter_start, mpl::apply_wrap1<mpl::_2, mpl::_1> >::type { template<typename Target, typename Source> Target cast(Source const& source) { return convert(source, wrap<Target>()); } }; int main() { my_converter cvt; std::cout << cvt.cast<std::string>(1.7) << " " << cvt.cast<int>(std::string("17")) << std::endl; std::cout << cvt.cast<int>(1.7) << " " << cvt.cast<float>(17)/10.f << std::endl; return 0; }

2 2

The Lonely Song of the MPL Maintainer -- or Boost support for antediluvian compiler and the future supprot of C++11
by Joel falcou 30 Aug '11

30 Aug '11

This is meant to be a serious thread and not some trollfest about w/e compilers. I am currently fixing bugs and applying feature request in MPL and it just happens I spend more time deciphering the web of compatibility #ifdefs than doing actual code. A rough guestimate tells me that on a 100 lines MPL files, 80 of them are #ifdef for compatibility. It could fine and dandy if those #ifdefs where not, for a majority, targeted at compiler i didnt even knew hwere standard conformant (ICC 5, really) or still in serious use (Borland whatever). Some other are more debatable (like MSVC 6 or such). Considering such compilers are so broken that upgrading boost is out of question for these users and that C++11 and its new set of supporting compilers are around the corner, also taking into account my limited amount of sanity (IRC people can testify on this), can't we start some support clean up in this library ? <radical> Going further, shouldn't we start thinking at boost 2.0 which will definitevely let c++03 die its peaceful death and start, on a voluntary effort, move boost component toward C++11. I know we have a fully working Fusion for 0x only. mpl, proto and other strategic infrastructure libraries should benefit from that. Some are a trivial port like Boost.PP and all the TR1 boost library that will just either disappear or forward the C++11 version. </radical> Here is the status of the thingy. Letting Boost 2.0 aside, what should be the status of MPL and its sharazadian list of supported compiler ?

23 41