April 2010 - Boost - lists.boost.org

[test] How to have a simple unit test compile on Borland/CodeGear?
by Niels Dekker - address until 2010-10-10 05 Apr '10

05 Apr '10

Is the following still a proper way to write a unit test for a Boost library component? #define BOOST_INCLUDE_MAIN #include <boost/test/test_tools.hpp> int test_main(int, char*[]) { // TODO Some testing here... return 0; } I can't get the above code compiling on the latest Borland/CodeGear compiler (Embarcadero C++ 6.21), installed by c++builder_2010_3615_win_esd.zip, downloaded from www.embarcadero.com/downloads Even though I already patched boost/smart_ptr (ticket #4067) and boost/exception (ticket #4068). I just do: bjam toolset=borland Which tries to compile <boost/test/utils/runtime/cla/dual_name_parameter.hpp> apparently, and it yields an error at line 43: template<typename Modifier> void accept_modifier( Modifier const& m ) { if( m.has( prefix ) ) { set_prefix( m[prefix] ); // line 43, "Error E2094"! ... The complete error message is down here. Interestingly, the message says that operator+ is missing (while I don't see a need for operator+ in this context). Any help is appreciated! Kind regards, Niels ------------------------------------------------------------ CodeGear/Embarcadero C++ 6.21 output: Error E2094 ..\..\..\..\boost/test/utils/runtime/cla/dual_name_parameter.hpp 43: 'operator+' not implemented in type 'nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<const unit_test::const_string,description_t,const unit_test::const_string &>,nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<bool,optional_t,bool>,nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<bool,guess_name_t,bool>,nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<const unit_test::const_string,separator_t,const unit_test::const_string &>,nfp::named_parameter<const unit_test::const_string,prefix_t,const unit_test::const_string &> > > > >' for arguments of type 'nfp::typed_keyword<unit_test::const_string,prefix_t,0>' in function void dual_name_policy::accept_modifier<nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<const unit_test::const_string,description_t,const unit_test::const_string &>,nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<bool,optional_t,bool>,nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<bool,guess_name_t,bool>,nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<const unit_test::const_string,separator_t,const unit_test::const_string &>,nfp::named_parameter<const unit_test::const_string,prefix_t,const unit_test::const_string &> > > > > >(const nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<const unit_test::const_string,description_t,const unit_test::const_string &>,nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<bool,optional_t,bool>,nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<bool,guess_name_t,bool>,nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<const unit_test::const_string,separator_t,const unit_test::const_string &>,nfp::named_parameter<const unit_test::const_string,prefix_t,const unit_test::const_string &> > > > > &)

1 0

[cpp0x] Macro to support some C++0x syntax and functionality
by Lorenzo Caminiti 05 Apr '10

05 Apr '10

Hello all, Consider the following C++0x-like example (inspired by ConceptC++ http://www.generic-programming.org/languages/conceptcpp/tutorial/ and C++ Contract Programming proposal n1962): // Example strangely uses pointers instead of iterators just to have preconditions. template<std::CopyConstructible T> requires Addable<T>, Assignable<T> // Concepts. precondition { first; last; } // Pointers not null. postcondition (total) { total == result; } // Returning result. T sum(T* first, T* last, T result) { for (; first != last; ++first) result = result + *first; return result; } What do you think of the following macro that implementes this in ISO standard C++ while keeping the above C++0x-like syntax by wrapping it within a preprocessor sequence? BOOST_CPP0X_FUNCTION( (template)( (std::CopyConstructible)(T) ) (requires)( (Addable<T>) (Assignable<T>) ) (precondition)( (first) (last) ) (postcondition)(total)( (total == result) ) (T) (sum)( (T*)(first) (T*)(last) (T)(result) ) ({ for (; first != last; ++first) result = result + *first; return result; }) ) The idea is that using the preprocessor I can parse the specified signature-sequence so I have all the tokens I need to declare/define the C++ function plus I can add the concepts (Boost.Concept), contracts (Boost.Contract), named parameters (Boost.Parameter), etc. Furthermore, the syntax of signature-sequence can be any valid preprocessor sequence that uses words (but not symbols) for keywords -- e.g., (requires) and (preconditions) are OK but (=) is not. This way I can define the signature-sequence syntax to closely match the syntax of C++0x (for concepts) and of other C++ standard proposals (like n1962 for contracts). DISCLAIMER: I think this is possible but I would need to try to implement it in order to be 100% sure and to identify possible limitations. Regards, Lorenzo P.S. I started considering this in reference to a previous email thread "Re: [boost] [contract] Contract Programming Library": On Sat, Feb 13, 2010 at 9:44 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: > On Fri, Feb 12, 2010 at 3:39 AM, Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: >> I would be very interested in trying such a library. I have one >> 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.

2 1

[google summer of code] student
by Cezary Bartoszuk 05 Apr '10

05 Apr '10

Hello, I am a CS student and I would like to patricipate in developing Heaps & Queues in Boost during Google Summer Of Code '10. Where, besides the source code, should I search for information about what's already in Boost (in the meaning of heaps/queues)? Who should I talk to about participating in Boost? Best regards, Cezary Bartoszuk, --- Faculty of Mathematics Informatics and Mechanics, University of Warsaw, Poland

3 4

Interested in Boost.Graph
by Piyush Garg 05 Apr '10

05 Apr '10

hi I am interested in upgrading the boost graph library to parallel boost graph library. I want to ask that do i have to chose one of the projects in boost.graph or i have to make them all during summer. Can i make the project on that or i have to suggest my own idea? Thanks Piyush Garg.

3 7

[GSoC] data structures library for summer of code 2010
by Dan Fox 05 Apr '10

05 Apr '10

Hi everyone, My name is Daniel Fox. I'm interested in working on making the advanced data structures library project idea for this year's Google Summer of Code. I've spent some time looking at the current structures in boost/pending and I believe I have an idea of what I would like to do for it.

1 0

[string_algo] first_finderF hoist empty check out of loop
by Jeff Flinn 04 Apr '10

04 Apr '10

In trying to get string algorithm icontains to work with spirit's file_iterator (which I still haven't been successful with) I noticed that the check for an empty search string is in side the loop. As: // Outer loop for(input_iterator_type OuterIt=Begin; OuterIt!=End; ++OuterIt) { // Sanity check if( boost::empty(m_Search) ) return result_type( End, End ); Wouldn't it be better to hoist this check out of the loop and only do it once? Thanks, Jeff

2 1

Semantic graphs for GSOC 2010
by Alexander Golec 04 Apr '10

04 Apr '10

Hey all, My name is Alexander Golec, and I'm a student at Fordham University studying mathematics, transferring to Columbia University to study CS engineering. I would like to ask about some specifics of the heaps and queues project. Have the items to be added to the advanced data structures library already been decided? How are the structures coupled to the BGL? Also, I would like to implement the binomial heap structure. Would anyone have any pointers for getting to know Boost's internals? Thanks, Alex

2 1

GSOC Bigint Proposal.
by swagat konchada 03 Apr '10

03 Apr '10

I would like to receive comments on my proposal for Bigint this year. To design, implement, test and document an expression template system("a wrapper for swappable Bigint providers") for the Boost.bigint around NTL, GMP(Is there enough interest around Xint?) in view of the numeric_adaptor scheme developed by Barend Gehrels in providing as many possible operators as possible. My mid-term examinations are going on and It's being impossible for me to hang around the list and study about Xint. I hope you understand... :)() -- Problem is a phenomenon indicating lack of thought. Swagat Konchada

2 1

GSoC: Enforcing Code Feature Requirements
by vicente.botet 03 Apr '10

03 Apr '10

Hi, I have recently reread the article "Enforcing Code Feature Requirements in C++" by Scott Meyers <http://www.artima.com/cppsource/codefeaturesP.html> I have posted some ideas that could improve the design (<http://www.artima.com/forums/flat.jsp?forum=226&thread=238798&start=0#372622>) I wanted to know if this could be a good subject for GSoC, if the approach I purpose to solve some issues is acceptable and if there is some students interested. Of course any comments are welcome. Best, _____________________ Vicente Juan Botet Escribá

7 14

Re: [boost] [range] Permission to merge to the Release branch
by Beman Dawes 03 Apr '10

03 Apr '10

On Fri, Apr 2, 2010 at 12:27 PM, Neil Groves <neil(a)grovescomputing.com> wrote: > Beman, > > I am seeking permission to merge the trunk version of Boost.Range into the > release branch. The regression test results have not detected new > regressions, however there are a number of the new features that are not > passing unit tests on several compilers. Since the new features would not be > usable if I did not merge my opinion is that it is worth merging to allow > the use of the newer features on more compliant compilers. In the meantime I > can seek to improve the support of adaptors and algorithms on the less > capable compilers. Go ahead and merge. For the tests that are expected to fail (because of older compilers, or whatever), please mark them up as expected failures. Ask if you need help with the markup. > > Of course, I respect that being a newbie to the Boost development and > release process that I may not be making the most informed judgement and > hence I respectfully seek your guidance. It is best to ask such questions on the main list. That allows others to comment, and if I'm not available one of the other release managers can reply. Thanks, --Beman

3 2