- Boost - lists.boost.org

Status of accepted libraries
by Jody Hagins 26 Jul '06

26 Jul '06

I asked this a while back, but can not find a response... Is there a place on the website that we can check on the status of accepted libraries? Specifically, it would be nice to know in which release each library is planned to be introduced... Thanks!

2 1

[multi_index] Getting an iterator from a pointer
by Bruno Martínez 26 Jul '06

26 Jul '06

Hi. There was a discussion long time ago[*] about how to convert a pointer to an object contained in a multi index set to the corresponding iterator. Has there been progress in this area? [*] http://thread.gmane.org/gmane.comp.lib.boost.devel/136418/focus=136972 Regards, Bruno

2 2

none.hpp
by Joe Gottman 26 Jul '06

26 Jul '06

In order to avoid having an unnamed namespace inside a header file, none.hpp has been rewritten as namespace boost { none_t const none = ((none_t)0) ; } // namespace But if two source files contain none.hpp won't this violate the one-definition rule? What's wrong with defining none_t and none as follows: namespace boost { enum none_t {none = 0}; } This allows us to have a unique value boost::none of type boost::none_t that can be included in any number of source files without violating the ODR. Joe Gottman

6 12

[inspection] License+copyrights in RC branch (was: [mpl] Metafunction terminology - revival?)
by Rene Rivera 26 Jul '06

26 Jul '06

Gennaro Prota wrote: > On Mon, 24 Jul 2006 13:06:03 -0500, Rene Rivera > >> >While your in there changing MPL docs, could you do us the favor of >> >adding some of the missing copyright+license information. MPL is *1* in >> >the number of those issues. > > Rene, next time we should remember to run the inspect tool (and fix > its discoveries :-)) before branching for release, so that we don't > have to duplicate all corrections on head and branch. Historically it hasn't made a difference when we run the inspect tool. People mostly ignored it and hence why we have an accumulation problems now. Now perhaps that it's in the form of a constant nagging email instead of a web page people will pay attention (cross-fingers). As for the amount of work I don't think libraries have diverged that much between HEAD and RC so it's likely not that much work since one only has to merge to the RC branch. > Or maybe the > inspect tool should run once a week or so, in general. Not sure about the schedule, but definitely it will running all the time from now on. I haven't enabled runs of it in HEAD yet as I expect that would generate a somewhat larger set of issues. But perhaps we could start such runs on HEAD on a weekly schedule? (Did a test run, and the *LC* email on HEAD would exceed the 75K limit. Only by a hair though.) > PS: maybe we want to highlight this in a separate thread? Yep :-) -- -- 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

2 5

Library-Centric Software Design 2006, Second Call for Papers
by Jeremy Graham Siek 26 Jul '06

26 Jul '06

LIBRARY-CENTRIC SOFTWARE DESIGN - LCSD'06 http://lcsd.cs.tamu.edu/2006 Workshop, on October 22nd, 2006 at the OOPSLA'06 conference in Portland, Oregon, October 22-26, 2006 CALL FOR PAPERS Libraries are central to all major scientific, engineering, and business areas, yet the design, implementation, and use of libraries are underdeveloped arts. This workshop is one of the first steps in the process of placing all aspects of libraries on a sound technical and scientific basis through research into fundamental issues and documentation of best practices. A software library is an organized collection of code with associated tools supporting programming in general or in specific domains, usually united by a specified set of principles and conventions. Most libraries are aimed for use by several people and in different environments. The areas of software library research include * Design and implementation of libraries * Program and system design based on libraries * Libraries supporting specific application domains, such as biology or banking * Evolution, refactoring, and maintenance of libraries * Empirical studies of library use * Performance of libraries, including benchmarking and library-based optimizations * Design of language facilities and tools in support of library definition and use * Validation, debugging, and testing of libraries * Extensibility, parameterization, and customization * Distribution of libraries * Specification of libraries and their semantics * Usability for library users and developers * Assessing quality of libraries * Documentation and teaching of libraries * Creating and supporting communities of library users * Using several libraries in combination We invite the submission of extended abstracts on software library research, including, but not limited to, the above list of topics. The extended abstracts should address issues important to libraries as a field, i.e., describe ideas or techniques that can be reused for libraries across problem domains and/or languages; they should refrain from merely describing a particular library, no matter how novel the choice of domain. As an additional criterion, the extended abstracts are reviewed against suitability for a journal publication of the corresponding full paper. For uniformity, authors should use the latest ACM SIGS conference style file (option 1) at http://www.acm.org/sigs/pubs/proceed/template.html. Submissions should be limited to 10 pages in this style. Accepted extended abstracts will be posted on the workshop's Web site prior to the workshop, and collected in a proceedings published as a Rensselaer Polytechnic Institute tech report. Authors of selected papers will be invited to submit a full paper for a special issue of a journal, to be announced later. IMPORTANT DATES Aug 11 Submission of extended abstracts Sep 12 Notification of acceptance Oct 10 Submission of final versions of the extended abstracts Oct 15 Final version posted on Workshop web pages Oct 22 or 23 Workshop SUBMISSION PROCEDURE For details of the electronic submission procedure, see the workshop's Web site, http://lcsd.cs.tamu.edu/2006. ORGANIZERS * Josh Bloch, Google Inc. * David Musser, Rensselaer Polytechnic Institute * Jaakko Jarvi, Texas A&M University * Sibylle Schupp, Chalmers University of Technology * Jeremy Siek, Rice University PROGRAM COMMITTEE * Dave Abrahams, Boost Consulting * Olav Beckman, Imperial College London * Herv=C8 Br=88nnimann, Polytechnic University * Cristina Gacek, University of Newcastle upon Tyne * Douglas Gregor, Indiana University * Doug Lea, State University of New York at Oswego * Andrew Lumsdaine, Indiana University * Erik Meijer, Microsoft Research * Tim Peierls, Prior Artisans LLC * Doug Schmidt, Vanderbilt University * Anthony Simons, University of Sheffield * Bjarne Stroustrup, Texas A&M University and AT&T Labs * Todd Veldhuizen, University of Waterloo In addition, the organizers will serve as program committee members, with Jaakko Jarvi and Josh Bloch as program co-chairs. Primarily, the email address lcsd06(a)cs.tamu.edu should be used for questions addressed to the organizers. KEYNOTE ADDRESS There will be an invited talk by Sean Parent, Adobe Inc. WORKSHOP GOALS AND ACTIVITIES The workshop is a scientific forum for presenting original research in the design, implementation, and evaluation of software libraries. Other major activities include the identification of open questions specific to library research and the discussion of a strategic plan for establishing library research as a field. The outcome of the workshop is a combination of research contributions and specific next steps for improving the infrastructure for library research. Participants are expected to read the accepted submissions beforehand. The technical presentations, although based on the accepted papers, should not provide mere summaries of the papers. Instead, authors are encouraged to use their presentation slots (20 + 10 mins) to bring up topics for discussion. The technical presentations are mixed with scientific and organizational discussions. The discussions aim at furthering the topics of the presentations, thus their agenda will be publicly discussed among the participants and then posted on the website of the workshop. All participants are expected to come prepared with their tentative answers or thoughts. The full-day workshop starts with a keynote talk for the stimulation of discussion and concludes with a plenary discussion that decides the specific next steps for improving the infrastructure for library research. FOR MORE INFORMATION AND UPDATES please visit the workshop's Web site, http://lcsd.cs.tamu.edu/2006

1 0

Re: [boost] [mpl] Metafunction terminology - revival?
by JOAQUIN LOPEZ MU?Z 26 Jul '06

26 Jul '06

----- Mensaje original ----- De: David Bergman <David.Bergman(a)bergmangupta.com> Fecha: Lunes, Julio 24, 2006 7:33 pm Asunto: [boost] [mpl] Metafunction terminology - revival? > Ok, I don't know what happened to the old discussion about > naming of stuff that can be safely applied by mpl::apply. > > We have the following constructs: > > 1. "metafunctions," which are templates classes with a type > identifier called 'type', > > 2. "metafunction classes," which are classes with a nested > template class called 'apply', which is a "metafunction" in > its own right, and > > 3. "lambda expression." > > Two of them - #2 and #3 - share a quite important trait: they can > be passed as the first argument to mpl::apply. > > I suggest that we call anything applicable via mpl::apply a > "metafunctor."And have "metafunctoid" denote that category > extended with #1 - ordinary > metafunctions - above. > > It is a bit boring not to be able to use a common name for these > constructs,especially when trying to tech others about > metaprogramming techniques in C++. And I do not see such common > names in the MPL documentation (or book.) > Hello David, Please correct if I'm wrong, but I'd say the official definition for a MPL lambda expression: http://boost.org/libs/mpl/doc/refmanual/lambda-expression.html actually encompasses both metafunction classes and placeholder expressions ("proper" lambda expressions, if you wish), so "lambda expression" is the common name you're after. Am I missing something? (I've got the hunch I am, actually.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 10

[inspection] Unnamed namespaces in include files [was: Boost inspection notifications (RC_1_34_0)]
by Gennaro Prota 26 Jul '06

26 Jul '06

On Tue, 25 Jul 2006 16:02:46 -0500, "Hartmut Kaiser" <hartmut.kaiser(a)gmail.com> wrote: > >Rene Rivera wrote: > >> |wave| >> boost/wave/cpplexer/validate_universal_char.hpp: >> *U* unnamed namespace at line 39 >> boost/wave/util/cpp_iterator.hpp: >> *U* unnamed namespace at line 1253 >> *U* unnamed namespace at line 1654 >> *U* unnamed namespace at line 414 >> *U* unnamed namespace at line 799 > >This puzzles me a bit because I thought, that unnamed namespaces in headers >are problematic only if these are in the global namespace. The unnamed >namespaces above are inside the boost::wave namespace, I can't see any harm >in that. But what is the benefit? I think that's the key question. If they don't have any they are just misleading. I'd say there are very few exceptions to this (in truth the only one which comes to mind is the nifty counter idiom). -- [ Gennaro Prota, C++ developer for hire ]

2 3

[bgl] Bug in depth_first_search (and therefore topological_sort...)
by Loïc Joly 25 Jul '06

25 Jul '06

Hello, There is a bug in the boost graph library in depth_first_search. When we look at the implementation, we can see in file boost/graph/depth_first_search.hpp): detail::dfs_dispatch<C>::apply (g, choose_param(get_param(params, graph_visitor), make_dfs_visitor(null_visitor())), choose_param(get_param(params, root_vertex_t()), *vertices(g).first), params, get_param(params, vertex_color) ); This code makes the assumption the the graph is non-empty, since it calls *vertices(g).first. For empty graphs, this call fails. Best regards, -- Loïc

5 9

Re: [boost] [Test] BOOST_*COLLECTIONS
by Sohail Somani 25 Jul '06

25 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Philippe Vaucher > Sent: Tuesday, July 25, 2006 10:23 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] [Test] BOOST_*COLLECTIONS > > > I was even returning ostream by value... /me leaves C++ > alone for a while > > If you read me correctly you'd have read "You'd return an > ostream& too." ;) IF I had. :)

1 0

Re: [boost] [Test] BOOST_*COLLECTIONS
by Sohail Somani 25 Jul '06

25 Jul '06

I was even returning ostream by value... /me leaves C++ alone for a while > -----Original Message----- > From: Sohail Somani > Sent: Tuesday, July 25, 2006 10:17 AM > To: 'boost(a)lists.boost.org' > Subject: RE: [boost] [Test] BOOST_*COLLECTIONS > > AHHHHH. Brain fart. Thanks. > > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org > > [mailto:boost-bounces@lists.boost.org] On Behalf Of Philippe Vaucher > > Sent: Tuesday, July 25, 2006 10:07 AM > > To: boost(a)lists.boost.org > > Subject: Re: [boost] [Test] BOOST_*COLLECTIONS > > > > > > > > template<typename T,size_t N> > > > std::ostream operator<<(const std::ostream & os, const > > boost::array<T,N> & > > > arr) > > > > > > > The ostream can't be const, as you write to it. > > You'd return an ostream& too. > > > > Philippe > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > >

2 1