- Boost - lists.boost.org

[1.41] Release Notes
by Daniel James 17 Oct '09

17 Oct '09

Hello everyone, Since we've more or less entered feature freeze, it's time to add any updates to the release notes. As always, you can just email me a line or two and I'll add it, ideally including the Trac tickets that have been fixed. Or if you want to do it yourself, the release notes directory is: https://svn.boost.org/svn/boost/website/public_html/beta/feed/history/ It would be best if you could do this before Sunday so that your changes will be included in the beta notes. thanks, Daniel

2 1

Re: [boost] [1.40.0] Compilation errors in Visual Studio
by jeremyShiers 17 Oct '09

17 Oct '09

I had the same problem the options you have listed include /Za which means disable language extensions (c/c++ ; Language ; Disable Lanauge Extensions = yes in visual studio) I changed this and it compiled who knows why changing from boost_1_39 to 1_40 should expose this. cheers Jeremy Yes, I join to this question. My setup: - VS2005 and try to compile QuantLib. - boost_1_40 Yes, I join to this question. My setup: - VS2005 and try to compile QuantLib. - boost_1_40 -- View this message in context: http://www.nabble.com/-1.40.0--Compilation-errors-in-Visual-Studio-tp253364… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

C# LINQ-like library: Boost.Qlang.
by Germán Diago 16 Oct '09

16 Oct '09

IMPORTANT: Sorry I forgot to attach the code. This is the correct mail, ignore the other one. Hello. I'm working on a library that is very early in its development, but I wanted to share it to get some feedback and to know if someone would be interested in it. I have named the library Boost.Qlang, and, over the time, maybe I could launch it. Now about the library. Boost.Qlang is a library inspired in C#'s linq extensions. For now, as this is an early prototype, Boost.Qlang is implemented ONLY for c++0x making use of lambdas and variadic templates. The plan is to make it compatible with c++98 , but as I'm not very familiar with Boost.Preprocessor library, I sticked to c++0x to test the ideas. Now for the library, by example. The library uses this struct (for testing) and this vector: struct Person { std::string name_; std::string surname_; int age_; public: Person(const std::string & name, const std::string & surname, int age) : name_(name), surname_(surname), age_(age) {} }; vector<Person> persons = { {"German", "Gallardone", 23}, {"Pedro", "Ruiz", 28}, {"Hilario", "Pinose", 34}, {"Manolito", "Gafotas", 29}, {"Tomas", "Todonte", 56}, {"Tomas", "Ruiz", 33}}; Example 1: auto query = from(persons).where([](const Person & d) { return d.surname_ == "Ruiz"; }). select(full_object); What does this do? It selects Persons with surname "Ruiz". The full_object in select is a placeholder that selects the full object. The query is NOT executed, instead, a select_<...> object is returned, which represents a query. A query models the Range concept, so if you want to evaluate the query, you can do it like this: for (auto it = query.begin(); it != query.end(); ++it) cout << person.surname_ << std::endl; Any struct can be used for queries without any kind of adaptation. The original range cannot be modified through the query. Everything returned is a new object. If you want to evaluate immediatly the query and store it, to_list() and to_vector() can be used from the query object: vector<Person> vec = query.to_vector(); Example 2. Selecting a subset of the fields in Person. Sometimes we want to select just a subset of the fields in a query. This is done like this: auto query2 = from(persons).where([](const Person & d) { return d.surname_ == "Ruiz"; }). select(&Person::surname_); The query returns elements of type boost::tuple<std::string> containing the surname. Maybe in the future a specialized tuple will be returned, in order to access the elements in a readable way, maybe something like: get<&Doctor::surname>(elem); For now just a field can be selected at the same time in select, but the plan is to be able to select as many as necessary. There are also plans to be able to use as placeholders in select unary member functions (for now it's just pointer to member data) and lambdas. For example something like this could be done: auto myquery = from(persons).where([](const Person & d) { return d.surname == "Ruiz";}). select([](const Person & p) { return std::string(p.name_ + " " + p.surname_; }); The return type would be that of the lambda. Example 3. Nested queries: auto query3 = from(query).where([](const Person & a) { return a.age_ == 28; }). select(&Person::name_); This query holds an object with a subquery inside it. You can traverse the query and will get the expected results. For now the library, in theory, can use any class that models the range concept in the from clause. The plan would be to add xml access (I don't know much about xml, though) and for databases and so on, to get a uniform interface for data access for every single data source you can imagine. The library has been tested with gcc svn, which includes lambdas. There is a file attached to this mail with a qlangtest.cpp file in the qlang folder. The boost folder contains all the implementation. Feedback is very welcome.

2 1

Is there a web site?
by gmane 16 Oct '09

16 Oct '09

That can answer the question of "What's new or changed in 1.41?" before the 1.41 beta comes out? Thanks

1 0

[1.41] Build files locations, try 3
by Vladimir Prus 15 Oct '09

15 Oct '09

Some time ago, I have raised the concern that CMakeList.txt files violate directory structure requirements. See: http://thread.gmane.org/gmane.comp.lib.boost.devel/189496/ I have pinged this a few times, see: http://permalink.gmane.org/gmane.comp.lib.boost.devel/193415 to no response. Now, with 1.41 going out soon, can we finally solve this issue? To rehash, the options we have are: 1. Move Jamfiles to the top-level directory of each lib 2. Move CMakeList.txt files to the build subdir 3. Adjust library guidelines. 4. Remove library guidelines, since they seem to be ignored. I hope we don't end up with option 4, of course. Thanks, Volodya

3 8

How to get the size of an C-array?
by vicente.botet 15 Oct '09

15 Oct '09

Hi, On TBoost.STM, I need to do something before deleting an array on each one of the elements of the array, or more precissely with the address of each one of the elements. T* ptr = new T[3]; // in another file, the number of elements to which ptr points is unknown. // before deleting for (size_t i=0; i< 'ptr size'; ++i) { // do something with &ptr[i] } delete [] ptr; As the number of elemenst is unknow in the separated unit, I have no mean to iterate on ptr to get the address of the elements. The C++ compiler or the C++ standard library knows this number of elements as it needs to call the destructor of each element when deleting the pointer. Is there something in Boost or a portable way to recover the number of elements of the array, maybe overloading the new [] operator and prefixing the allocate storage with some information? But what information can be stored so the implementation is portable? Any hint is welcome. Best, _____________________ Vicente Juan Botet Escribá

6 16

Re: [boost] [1.41] boost-cmake leaving svn
by pete＠pcbartlett.com 15 Oct '09

15 Oct '09

On Thu 15/10/09 07:00 , "troy d. straszheim" wrote: Eric Niebler wrote: > > Not only is it disruptive, but it's against policy to commit directly > to release. I know that, I was just trying to spin it. > My opinion: the cmake build system should be like other parts of > boost: polished, documented, tested, reviewed, accepted, merged to > trunk and then to release, and actively maintained. Please forgive me for saying this is a bit far-fetched. If I propose a library for inclusion and it gets rejected, fine, I still have a library. If I propose a build system (arguably more work than a typical library) and it gets rejected, I've got nothing. A new library doesn't typically require everybody to change the way they do business throughout the entire release cycle, from development to testing, and therefore doesn't encounter the inertia of the community. For that matter, I'm having trouble imagining how one would merge a build system from trunk to release. This is the same problem that provoked this discussion. > Distributing an experimental build system in an official boost > release was probably a mistake. Well we thought we would get some users, and we got lots of them on the end-users' side, but it didn't catch on with boost developers as I'd hoped. C'est la vie. I think the better way is: * A few notes in Getting Started with pointers to the cmake stuff * One root CMakeLists.txt that just prints a message on where to get boost-cmake * A link to some boost-cmake tarball area alongside the standard boost tarballs. That's the new proposal. > In that light, I must reluctantly agree that removing cmake from > trunk and release is probably the right thing. Beman? I doubt that it is necessary to agree at this point. That stuff either comes out of release or goes out broken. > My worry is that as a side project, the cmake build system will get > less use and less attention. It's been 2 years since the cmake effort > began, and where are we? I don't see it that way. We have 115 people on the boost-cmake list, and a bunch of them were really helpful (thanks guys) in tuning up the build for 1.40.0, and we'll do it again in a few weeks for 1.41.0. Participation has been signficantly wider than when it was just Doug and I. There are docs, happy users, all that stuff. > I *really* want our users to have a standard option for building > boost that integrates well with their chosen build environment. They've got that. It's done. -t _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Links: ------ [1] http://lists.boost.org/mailman/listinfo.cgi/boost

5 4

[graph] Include conflict when using spirit classic and graph libraries together
by Oliver Koenig 15 Oct '09

15 Oct '09

Hello, boost/graph/depth_first_search.hpp includes boost/spirit/home/phoenix.hpp. This include points to Phoenix2, what finally leads to conflicts if the spirit classic library (using Phoenix1) is used together with the Boost graph library. Is the spirit include in boost/graph/depth_first_search.hpp needed at all? I cannot see where something from phoenix is used in that header and in our code everything seems to work fine if I simply remove this include. Sincerely ok -- ---------------------------------------------------- Oliver Koenig EVEN - Evolutionary Engineering AG WWW : www.even-ag.ch ---------------------------------------------------- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

2 1

[bind] bound object type introspection
by Gennadiy Rozental 14 Oct '09

14 Oct '09

Hi, Following the discussion on users list I came to conclusion it's impossible at the moment to deduce argument types of bound object passed to the function template. Is there any reason why this can't be added in the manner similar to the boost::function typedefs? Gennadiy

3 2

math/tools/rational.hpp gcc 3.2 problem
by Ralf W. Grosse-Kunstleve 14 Oct '09

14 Oct '09

gcc 3.2 doesn't compile this code (works with gcc 3.3 and up): #include <boost/math/distributions.hpp> int main() { boost::math::students_t_distribution<double> dist(1.); dist.find_degrees_of_freedom(1.,2.,3.,4.,5.); return 0; } Reduced: template <unsigned N, class T, class V> inline V evaluate_polynomial(const T(&a)[N], const V& val) { return val * a[0] * static_cast<T>(N); } int main() { double a[3]; double val; double result = evaluate_polynomial(a, val); return static_cast<int>(result); } dbg2.cpp: In function `int main()': dbg2.cpp:12: no matching function for call to ` evaluate_polynomial(double[3], double&)' Does anyone have an idea for working around the problem? Ralf

4 5