- Boost - lists.boost.org

[SoC] More Ideas
by Andrey Ryabushenko 05 May '06

05 May '06

I have some ideas in the field of my specialty - memory management. I can develop any of these with pleasure. But I want to hear from you which are most wanted or unwanted:) I can't write three great proposals at the same time so I am asking you. 1. Garbage collector. Smart pointers are great, but there is easier solution that do not require neither special knowledge nor available code modification. 2. Memory Leak Detector. Very helpful in big projects. It is worth to say that 70-80 percent of mistakes is memory leakage. 3. Develop a suite of allocators(multi threaded, small object allocator and others). I think the allocator based on Hoard algorithm that shows great perfomance in the multithreaded applications is worth merging into boost) take a look at more detailed descriptions www.cs.umass.edu/~emery/pubs/berger-asplos2000.pdf http://developers.sun.com/solaris/articles/multiproc/multiproc.html Please let me know if you have any interest in these topics.

2 1

[Boost-bugs] [ boost-Bugs-1482220 ] "memory exhausted" in regex matching
by SourceForge.net 05 May '06

05 May '06

Bugs item #1482220, was opened at 2006-05-04 17:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1482220&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: regex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: "memory exhausted" in regex matching Initial Comment: Using the following regex: (a*ba*)*c to match the following text: abababababababababababab will throw an exception saying "Memory exhausted" (tried with g++ 4.0.4 on linux with boost 1.32 and 1.33. Similar problem on Windows/mingw with 1.32) The following, more useful expression has the same problem: (a*ba*d?)*c Charles-Henri Gros <chgros(a)coverity.com> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1482220&group_… ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[MPL] sequence-preserving
by David Abrahams 04 May '06

04 May '06

Joel de Guzman <joel(a)boost-consulting.com> writes: > So MPL is not sequence preserving after all. It really depends what you mean by "sequence preserving." If it returned the same type, it couldn't really do anything. So you have to decide how many guarantees you're going to give about the result type. Andy wants it to be spelled as a specialization of the same template, so transform operating on mpl::vector<t1,t2,t3> would yield something spelled mpl::vector<t1a,t2a,t3a>. > transform merely returns a sequence with the same properties as the > original. This makes perfect sense. In Fusion, algorithms are not > sequence preserving by design. However, we do have conversion > functions/metafunctions to get a *true* vector/list/set/map from an > arbitrary sequence. No, I don't think that would satisfy Andy, because you're surely not guaranteeing that the result type will be spelled fusion::list<t1,t2,t3,...> or you wouldn't be able to do this to lists of arbitrary length (and why else use a list, after all?). You probably have to conjure up something spelled cons<t1,cons<t2,cons<t3,nil> > >, which, while it's a "true list", it isn't a specialization of fusion::list. Which leaves fusion right back in the same place as MPL. Unless I'm missing something, of course ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: [boost] Header ordering [was: Vector of Polymorphic Pointers]
by David Abrahams 04 May '06

04 May '06

Thorsten Ottosen <tottosen(a)dezide.com> writes: > Robert Ramey wrote: > >> Note that its not enough to include BOOST_CLASS_EXPORT. It has to >> be included after the *archive.hpp classes that you're using. Double check >> that this is the case. > > Robert, why is this needed? It seems like something that is *very* easy > to forget and get wrong. Yes, header ordering is notoriously hard to control. Robert, I'd like to discuss the design problem it is solving and see if we can come up with a better approach. Can you boil it down to a really simple example? -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 15

[ANN][thread_new] New thread launching library based on N1883
by Ion Gaztañaga 04 May '06

04 May '06

Hi to all, In recent "Report from Berlin C++ Standards Committee meeting" thread, I asked about N1883 status and Beman personally proposed implementing a thread launching interface above Boost.Threads to test it and propose it for TR2. I've been working lately on this and the result is the "thread_new" library. It implements the N1883 thread launching interface and also proposes some issues to improve that proposal. The library (thread_new.1.1.zip ) is Boost Vault Concurrency folder: http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=C… The online documentation is here: http://ice.prohosting.com/newfunk/boost/libs/thread_new/ The library is a single header file that uses Boost.Threads to implement the "future" based thread launching interface. The implementation is not optimal, but I wanted to achieve portability. I (and others) prefer this thread-launching interface than Boost.Thread's current approach. I would want to see what Boosters think so that there is a feedback about the interface and we can propose it for TR2. The interface has also a common ground with asynchronous programming, and this possibility is commented in the documentation. If you are interested in threads and C++, your opinion is welcome! Regards, Ion

2 2

Re: [boost] [shmem] New bugfix version in Boost Vault and sandbox cvs
by Ion Gaztañaga 04 May '06

04 May '06

Ho Jan, Jan Stetka(e)k dio: > Yes I understand that I can't use shmem::map and std::map if they are > both on the global namespace. I've looked at the implementation of the > std::map header from the STL implementation that is included in vc++ 7.2 > and that doesn't forward declare std::list in <map>. This is a design > issue rather than a bug. Why forward declare shmem::list by including it > in map.hpp when it isn't used? All classes in Shmem include shmem_fwd.hpp or container_fwd.hpp where Shmem defines default arguments (for example default Less, or Allocator template parameter). That's why you get the predeclaration of list including map. Another alternative would be to declare a *_fwd.hpp for each class defined in Shmem, but you would get a lot of extra headers, and I would have a lot of work to maintain. Even if I don't include list predeclaration with map, I'm free to use any Shmem container in any Shmem class (for example, I can implement a pooled allocator using a list container), so it's likely that a Shmem class include will include more Shmem classes (predeclarations, or full declarations). I don't consider it a design error, but a design choice. What I see dangerous is pushing two namespaces, std, and shmem to the same context because they have similar classes. An alternative would be to rename shmem classes like "vector" to "shmem_vector", .... But weren't namespaces born to allow that? Regards, Ion

1 1

[SoC-2006] Associative containers...
by Rene Rivera 04 May '06

04 May '06

To Whomever added the " Associative containers specialized for low memory footprint and fast lookup" item to the project list <http://tinyurl.com/lprgp>. I curious which containers in particular you have in mind? I'm asking because I'm working on such a container, both for myself and for Boost, bjam, and binutils/ld/bfd. The particular container is the radix tree <http://en.wikipedia.org/wiki/Radix_tree>. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

3 2

[SoC] New proposal in the wiki for a geometry library
by Hervé Brönnimann 04 May '06

04 May '06

Sorry to be so late in the process, but I just decided to put in a proposal for a geometry library in the wiki. I've seen a lot of proposals on the mailing list over the years, some recently, and I feel that it's time to propose some real work on it. Google's SoC is a golden opportunity to recruit a top-notch programmer on it. I'm passionate about the topic, I publish research papers about geometric algorithm and algorithm engineering, I've even organized an ACM Symposium on Computational Geometry in 2004 and been on their Program Committee in the past, I've worked with Boost in the past. For this project, I have a very clear and ambitious vision, and my participation in the work is funded by an NSF CAREER grant! I already have students and a reasonable but heterogenous code base, and a PhD student who will also work on this project this summer, but many hands make lighter and better work. So don't hesitate to step up! -- Hervé Brönnimann CIS, Polytechnic University hbr(a)poly.edu PS: if you wonder about the relationship between this and CGAL, esp. since I was once a technical manager and maintainer of CGAL, let me put you at ease: we're not proposing to write a competitor. CGAL is a much bigger project. In fact, I would design this library so that that this library can be used independently but also that CGAL kernels (of very high quality) can be used, and that CGAL algorithms can easily be reused as well. CGAL uses boost internally, and so cross-fertilization would eventually work both ways. The licensing issues, however, will probably keep both works separate.

1 0

Re: [boost] [MISC SoC] request for mini-review
by Matias Capeletto 04 May '06

04 May '06

I am glad to annouce that the MISC SoC library mini-review has begin. No, really... Joaquin, (and anyone that is interested) Ok, finally i manage to build a first draft of the MISC docs. I have uploaded the webpage to h1.ripway.com/mcape/boost/libs/misc/index.html I am eager to read the list feedback. I will refactor the docs once i hear the voices of the boosters and (i hope) my mentor and send the application to Google. Best Regards Matias PD: Thanks again for quickbook! It is quite a doc tool... Nobody answer me if it is a nice thing to be able to highligth the .qbk sintaxis in the Kate editor, i will do it anyway and if i see that it is a production improvement i send it to the list.

4 5

Re: [boost] [MISC SoC] request for mini-review
by Roman Yakovenko 04 May '06

04 May '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Matias Capeletto > Sent: Thursday, May 04, 2006 8:54 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] [MISC SoC] request for mini-review > > > h1.ripway.com/mcape/boost/libs/misc/index.html > Small fix for documentation needed. http://h1.ripway.com/mcape/boost/libs/misc/boost_misc/user_s_guide/installi… Supported Compilers Currently, Boost.Misc is known to work on the following compilers: * Kate * Notepad * Word 2003 Are you sure :-) ? > > Best Regards > Matias

1 0