- Boost - lists.boost.org

[bgl] Manual include necessary for is_in_subset predicate
by Matthias Walter 28 Mar '10

28 Mar '10

Hi! I'm using a filtered_graph for a project, which filters edges via the is_in_subset predicate. Is it intended that one must manually include boost/graph/detail/set_adaptor.hpp for this to work? If I only include boost/graph/filtered_graph.hpp and want to use the predicate, the compiler complains about missing set_contains function. I didn't find anything about manual includes in the docs, but maybe there are reasons for it. best regards Matthias Walter

2 1

[geometry] Inclusion in the next release?
by Romain CHANU 28 Mar '10

28 Mar '10

Hi boosters, Does anyone know if the Boost Geometry Library is going to be shipped in the next release of Boost? Cheers, Romain

4 12

GSoC 2010 : BigInt
by Mario Ynocente Castro 28 Mar '10

28 Mar '10

Hi, I'm a engineering student from Peru. I'm really interested in the BigInt project for GSoC 2010, but there's a part for which I would like a better explanation, the description says : "A successful proposal will include a discussion of licensing concerns". What does it mean? I must choose the license under which the code will be released and indicate it when I submit the aplication? -- Mario Ynocente Castro 20074016B FIIS - UNI

2 5

About Boost XML
by Qingli Ma 28 Mar '10

28 Mar '10

Hi! My idea about XML is listed below: 1.I have experience on processing larege scale xml files(database files).So I feel having boost proccess large xml files in SAX model will be useful and I've make that in Java before. 2.Reading spec about all kinds of XML APIs, and improve current Boost interfaces in Boost to support all kinds of processing without thinking about the backend implemention.By this, interfaces is independent from the backend, thus dynamic backend bindings is possible. 3.Maybe we need a new backend that serves for the API interface,like libxml2.It can parse,tranverse,writer and search(XPath) the document. 4.I am graduating this summer and I'll have enough time. Have you any sugguestions for me?

2 2

[GSoC 2010] Sweepline algorithm
by Marcin Fatyga 28 Mar '10

28 Mar '10

Hello, My name is Marcin Fatyga and I am doing double degree program in computer science and mathematics on Warsaw University. I would like to participate in GSoC 2010 - I would like to implement the sweepline algorithm and use it to solve the problems related to it. In my project I would like to implement the sweepline and then use Fortune's Algorithm to solve the Voronoi Diagram's problem. Then I would provide some modifications to solve the two remaining connected problems : Delanuay triangulation and medial axis. All of these problems have many applications in differnet fields of science and solving them could be useful to may users. Though I don't have quite much experience with the boost library itself, I am particularly interested in algorithms and have some experience with both C++ and generic programming. Though there is no geometry library in current release, I can see it is in development phase. Should the project be integrated with it/use it? Best wishes Marcin Fatyga

7 9

[preprocessor] Computational complexity analysis
by Lorenzo Caminiti 28 Mar '10

28 Mar '10

Hello all: Is there a computational complexity analysis of Boost.Preprocessor data structures? This would be in terms of preprocessing time. For example: Does BOOST_PP_SEQ_ELEM() run* in O(n)? Do BOOST_PP_TUPLE_ELEM() and BOOST_PP_ARRAY_ELEM() run* in O(1)? (*) "Run" within the preprocessor so maybe "expand" is a better term... Thank you. Lorenzo

2 3

[GSoC] Some Ideas about the Boost.Process
by Felipe Tanus 27 Mar '10

27 Mar '10

Hello, I have been studying the project idea about Boost.Process for a while. Some ideas/opinions poped up in my mind and I feel like to share. Please, comment. IMHO, the best design for the library is not to split the APIs from Windows and POSIX. I Believe that boost should provide a higher abstraction level, and get rid of the platform problems. 1.The current implementation of Boost.Process library has the class boost::process::child, and two classes that inherit it, win32_child and posix_child. I don't believe that this is the best solution. There is only one concept of child in both APIs; some resources are different, it is true, but the concept is only one. For example, the call "boost::process::win32_launch()" is defined to launch a process "the windows API way", with the Win32 context. I don't see why can't we create a process with this call in a POSIX system ignoring what don't apply to it (or find some similar concept and use it instead, as named pipes<->fifos). After all, if you are using a Win32 only class, there is no way to run in linux, so if the code works or don't, it does not matter. By doing this way, we could easy a possibly port to another system. This could be done with programming practices as suggested by Vicente Botet, in a previous topic [1] 2.The wait() method, to wait a process (child actually, but this is another problem) to die, is not asynchronous. Sometimes programmers want a synchronous wait() method, so there is no motive for we to remove this. We should implement a new asynchronous wait() method. This method should not be in the asio library, because it's process specific. It may require the asio library, or the asynchronous piece should be implemented in the boost.process. I'm not sure about this, both seems good for me, so please comment. 3.About the process creation, I think the following practice from the documentation should be avoided: “Another important requirement is to always pass at least one argument to the executable. This must be the name of the executable itself”. There is no motive to require a parameter that you can deduce by yourself. The first parameter, in this case, should be implicit. 4.Would really be nice boost::process::launch() be able to receive any kind of string? This tend to let the programmer go for a single platform solution. As a multiplatform library, this may be avoided. I'm not sure about this matter as well, but if the library is here to provide a higher abstraction level, should it also accept API related types? I believe it should not. There is also another points that I would like to discuss in my GSoC proposal; They are well known problems so I'll just cite they: List and access other processes functionality Named pipes and FIFO (following the item #1, would be the same thing? Something would change? Something to be researched yet) move wait from child to process (as well as future asynchronous wait) Deal with process killing bugs (as well as any other known issue) Test platform issues. Should this be enough for a GSoC proposal? Do you have any other suggestion about what could I discuss in it? Thank you for your time, []'s [1] http://thread.gmane.org/gmane.comp.lib.boost.devel/188736 -- Felipe de Oliveira Tanus E-mail: fotanus(a)gmail.com Blog: http://www.itlife.com.br Site: http://www.inf.ufrgs.br/~fotanus/ ----- "All we have to decide is what to do with the time that is given us." - Gandalf

7 18

GSOC query for Heaps and Que
by Chirag 27 Mar '10

27 Mar '10

Hello Sir The Boost C++ library has mutable_heap and mutable_que and the current container works perfectly for basic datatypes like double , int etc but for datatypes like pointers it requires that user should have knowledge of property_map types. Sir for making mutable heaps , can we ask user for a hash function from the user for the data type he want to make the heap. This way we can hash each newly added value to heap and store pointer for that which will point to its location in the original heap. Here two problem i am facing 1) Can user provide a hash function for all data types 2) Worst case of hashing search would be O(n) though it chances are very low . I know O(n) case is not wat we are aiming to achieve but for users who dont want to get into understanding of property map they can use this heap instead , and I am thinking of giving it as a option to the already available mutable que in boost. This is just a idea I am proposing and its definately not final , I am thinking on other ways to improve it . I just want to know if it is a good option to give or not. Thanks Chirag IIT guwahati -- Life is short live it happily

1 0

Stability: More on 3 level Boost libraries
by vicente.botet 27 Mar '10

27 Mar '10

Hi, I would like to come back to the 3 level proposition but from a different point of view (stability and quality) 1st level: stable Libraries belonging to this level must be very stable, any modification on the public interface must be reviewed. The goal been that changes in these libraries don't break user code, even if they will need to recompile. Libraries can pretent to be in this level if the library use only libraries at this level, has not introduced breaking changes for a given amount of time and of course if the author wants to be constrained to have a review for changes on the public interface and to correct quicky the possible tickets. 2nd level: quite stable Libraries at this level, even if stable, introduce breaking changes from time to time. Libraries can go to this level if the library use only libraries at this level or the 1st level, after a deep review of the of the interfaces, the documentation, the implementation and the test coverage and have a reduced number of tickets since a to be defined period. 3rd level: unstable It is assumed that young libraries will have a lot of breaking changes at the public interface level. Libraries can go to this level after a review of the interfaces and the documentation. Comments are welcome, _____________________ Vicente Juan Botet Escribá

10 22

Help with GSoC; BigInt and Heaps & Queue
by Lucas Gambarra 27 Mar '10

27 Mar '10

Hi, I'm very interested in participating in GSoC. While watching the list of ideas proposed by the boost C++ Libraries, I was really interested in two of them: 'Heaps & Queues' and 'BigInt'. I am a student of Computing Sciences of the Federal University of Paraíba - Brazil. I wanted information on how to contact the mentortes of such projects. Could someone help me? Forgive me for my English. ------------ --------- --------- --------- --------- --------- --------- --------- -------- Lucas Lucena Gambarra Estagiário no Laboratório de Sistemas Digitais (LASID - UFPB) Projeto Brazil-IP 2010 email: lucas.ufpb(a)gmail.com.br MSN: lucas_gambarra@hotmail. com

2 1